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: "Knight, Lloyd" <Lloyd dot Knight at adc dot com>
- To: <tromey at redhat 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: Mon, 23 Apr 2007 15:34:39 -0500
- Subject: RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
tom,
thanks for your reply.
i'm sorry, but i do not understand what you are asking for in
your questions. to check any of this i would need more instruction.
that being said, isn't this version of gcc/gcj "closed"?
meaning no fixes are applied?
i used an old version(3.4.6) because somewhere i read that it worked
with the version
of pdftk that i needed to use.
i am willing go through the "hand waving" of setting the LC_* variables
to make
pdftk work for my purposes. i just thought if someone more
knowledgeable had
an explanation, i would be more than interested in hearing it.
at this point, with limited testing, pdftk/gcc/gcj on solaris 10 is
working
and i am ok with that. if with more extensive testing i find other
issues
i'm sure i'll post more nagging questions.
thanks for your help
lloyd knight
-----Original Message-----
From: tromey@redhat.com [mailto:tromey@redhat.com]
Sent: Monday, April 23, 2007 2:52 PM
To: Knight, Lloyd
Cc: Boehm, Hans; Andrew Haley; java@gcc.gnu.org
Subject: Re: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
>>>>> "Lloyd" == Knight, Lloyd <Lloyd.Knight@adc.com> writes:
Lloyd> =>[1]
Lloyd> _Z13_Jv_FindClassP13_Jv_Utf8ConstPN4java4lang11ClassLoaderE(0x0,
Lloyd> 0x0, 0xffffffff, 0x49, 0x839ca4, 0xc), at 0x31b0e4
Lloyd> [2]
Lloyd> _ZN4java4lang5Class7forNameEPNS0_6StringEbPNS0_11ClassLoaderE(0x8
Lloyd> 184e0, 0x1, 0x0, 0x1, 0x0, 0x0), at 0x31aa74
Lloyd> [3]
Lloyd> _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