This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
- From: Tom Tromey <tromey at redhat dot com>
- To: "Knight, Lloyd" <Lloyd dot Knight at adc dot com>
- Cc: "Boehm, Hans" <hans dot boehm at hp dot com>, "Andrew Haley" <aph-gcc at littlepinkcloud dot COM>, <java at gcc dot gnu dot org>
- Date: 23 Apr 2007 13:51:37 -0600
- Subject: Re: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
- References: <51D9164BCD83B8419473392DB260487604F06EAA@mn01exch02.adc.com>
- Reply-to: tromey at redhat dot com
>>>>> "Lloyd" == Knight, Lloyd <Lloyd.Knight@adc.com> writes:
Lloyd> =>[1] _Z13_Jv_FindClassP13_Jv_Utf8ConstPN4java4lang11ClassLoaderE(0x0,
Lloyd> 0x0, 0xffffffff, 0x49, 0x839ca4, 0xc), at 0x31b0e4
Lloyd> [2]
Lloyd> _ZN4java4lang5Class7forNameEPNS0_6StringEbPNS0_11ClassLoaderE(0x8184e0,
Lloyd> 0x1, 0x0, 0x1, 0x0, 0x0), at 0x31aa74
Lloyd> [3] _ZN3gnu3gcj7convert14UnicodeToBytes17getDefaultEncoderEv(0x832b00,
Lloyd> 0x8187e0, 0x7d8000, 0x83cf50, 0x6b58d4, 0x6aa0d0), at 0x3d126c
This is weird. I didn't look at 3.4 but in 4.3 we're just calling
Class.forName here to try to load the appropriate charset converter.
We shouldn't be able to crash in _Jv_FindClass, instead we should get
an exception and carry on to the default encoder.
You'll have to do more debugging to find out what is going on here.
How does your build fare on the libgcj test suite? Do exceptions work
at all on your build? (Sometimes when we see a mysterious crash like
this it means something very low-level, frequently exception handling,
is completely broken.)
Tom