[cp-patches] Re: Assertion failure
Hi, On Tue, 2006-01-10 at 19:26 +0100, Mark Wielaard wrote: Agreed. I am still hoping someone has a good analysis of the issue, or wants to upgrade our mprec to the newlib version. If not we should indeed disable the assert again before 0.20 is released. Which is what I did. For now we just disabled the assert to get us the behavior we had before. After 0.20 we should solve this correctly. I have updated the bug report to mention the things discussed in the two threads about this. 2006-01-12 Mark Wielaard [EMAIL PROTECTED] * native/fdlibm/mprec.c (Balloc): Disable assert to workaround PR classpath/23863. This solves all mauve regressions we were seeing. It would be appreciated if others could also rerun their tests with this applied. Committed, Mark diff -u -r1.6 mprec.c --- native/fdlibm/mprec.c 6 Jan 2006 01:27:20 - 1.6 +++ native/fdlibm/mprec.c 12 Jan 2006 09:20:55 - @@ -97,7 +97,9 @@ int i = 0; int j = 1; - assert ((1 k) MAX_BIGNUM_WDS); + /* FIXME - assert disabled because of PR classpath/23863 + * assert ((1 k) MAX_BIGNUM_WDS); + */ while ((ptr-_allocation_map j) i MAX_BIGNUMS) i++, j = 1; signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Assertion failure
Hi, On Tue, 2006-01-10 at 01:38 +0100, Christian Thalinger wrote: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Christian Thalinger writes: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Yes, but what is the value of k when this assertion fires? Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote: Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi, On Tue, 2006-01-10 at 10:17 +, Andrew Haley wrote: Christian Thalinger writes: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Yes, but what is the value of k when this assertion fires? You can trigger it with the following (extracted from Mauve): new java.math.BigDecimal(1e200).floatValue(); Which gives: #4 0xad75ab88 in _Jv_Balloc (ptr=0xbfa7b7d4, k=5) at mprec.c:100 100 assert ((1 k) MAX_BIGNUM_WDS); Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard writes: On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote: Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. BTW, does anybody know why we are not using the system strtod() when available? Java has some very specific requirements for floating-point to decimal conversion, and this library satisfies those requirements. strtod() doesn't, or may not. Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? OK found that out myself. Apparently some strtod implementations are indeed not thread-safe by default (but most seem to be). The other problem is that strtod depends on the locale and changing the locale isn't thread-safe... sigh. So we do need our own implementation, or do something like glib g_ascii_strtod() and convert the string representation first to the current locale form (). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from Balloc in mprec.c. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard wrote: On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? OK found that out myself. Apparently some strtod implementations are indeed not thread-safe by default (but most seem to be). The other problem is that strtod depends on the locale and changing the locale isn't thread-safe... sigh. So we do need our own implementation, or do something like glib g_ascii_strtod() and convert the string representation first to the current locale form (). In addition, many strotod implementations I encountered are subtly different when it comes to having the results that the Java specs demand for very small values. I guess that has a lot to do with floating point rounding modes being largely implementation dependant in C89 [1], so when porting to a C89-ish strtod one can only hope that the libc in question has been compiled with the right options/switches/assembly. :/ cheers, dalibor topic [1] that's one of the reasons why I prefer C99 over C89, personally. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Archie Cobbs wrote: Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from Balloc in mprec.c. Sorry for the noise, that email got delayed several hours for some reason. As we now know strtod() has different behavior than desired... In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi Archie, On Tue, 2006-01-10 at 11:59 -0600, Archie Cobbs wrote: In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). Agreed. I am still hoping someone has a good analysis of the issue, or wants to upgrade our mprec to the newlib version. If not we should indeed disable the assert again before 0.20 is released. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
