This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]