pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.

Mon Apr 23 19:52:00 GMT 2007

all,

thank you very much for your input.
i went back the first stack trace i posted which was generated
by using the core file with pdftk (dbx ./pdftk core):
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
=>[1] _Z13_Jv_FindClassP13_Jv_Utf8ConstPN4java4lang11ClassLoaderE(0x0,
0x0, 0xffffffff, 0x49, 0x839ca4, 0xc), at 0x31b0e4
  [2]
_ZN4java4lang5Class7forNameEPNS0_6StringEbPNS0_11ClassLoaderE(0x8184e0,
0x1, 0x0, 0x1, 0x0, 0x0), at 0x31aa74
  [3] _ZN3gnu3gcj7convert14UnicodeToBytes17getDefaultEncoderEv(0x832b00,
0x8187e0, 0x7d8000, 0x83cf50, 0x6b58d4, 0x6aa0d0), at 0x3d126c
  [4] _ZN4java2io11PrintStreamC1EPNS0_12OutputStreamEb(0x832b00,
0x8187e0, 0x1, 0x818c30, 0x6c4430, 0x355084), at 0x339b58
  [5] _ZN4java4lang6System18__U3c_clinit__U3e_Ev(0x32d9dc, 0x80efe0,
0x80eff0, 0x8, 0x80fc68, 0x7d3400), at 0x32dd38
  [6] _ZN4java4lang5Class15initializeClassEv(0x6b1c6c, 0x80efe0,
0x80eff0, 0x8, 0xfefe8284, 0x7d3400), at 0x31a678
  [7] _Jv_InitClass(0x6b1c6c, 0x1084, 0x94238, 0xfef54268, 0xff0d2000,
0x1000), at 0x478d3c
  [8] _ZN4java4lang6System11getPropertyEPNS0_6StringE(0x831f00, 0x1,
0x94184, 0x31c694, 0xfefe8284, 0xa), at 0x32e078
  [9] _ZN4java4lang13VMClassLoader20getSystemClassLoaderEv(0x0,
0x6ac378, 0xfefecbc0, 0x80eff0, 0xffffffff, 0x5600), at 0x330f3c
  [10] _ZN4java4lang11ClassLoader18__U3c_clinit__U3e_Ev(0x32585c,
0x80efe0, 0x80eff0, 0x8, 0x56, 0x7d3400), at 0x325860
  [11] _ZN4java4lang5Class15initializeClassEv(0x6ac378, 0x5c2898,
0x56000000, 0x0, 0x7d3554, 0x6), at 0x31a678
  [12] _Z16_Jv_CreateJavaVMPv(0xffffffff, 0x2e, 0x2d68, 0x7d7c00,
0x80808080, 0x1010101), at 0x302b8c
  [13] main(0x2, 0xffbffd6c, 0x0, 0x0, 0xff0d0100, 0xff0d0140), at
0x1c822c
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) 

which made me look at the locale settings on my solaris8 and solaris10
machines:
solaris10 # locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

solaris8 # locale
LANG=
LC_CTYPE=en_US.ISO8859-15
LC_NUMERIC=en_US.ISO8859-15
LC_TIME=en_US.ISO8859-15
LC_COLLATE=en_US.ISO8859-15
LC_MONETARY=en_US.ISO8859-15
LC_MESSAGES="C"
LC_ALL=

when i set the above LC_* environment variables on solaris10 to look
like those
on solaris8,  the pdftk program works.

i do not understand why i have a different stack trace when i run dbx
with and without the core
file.  and i do not understand why what i did made the segv go away.
if anyone has an idea as to why this works, i would be interested in
hearing....

thanks for all your help
lloyd knight

-----Original Message-----
From: Boehm, Hans [mailto:hans.boehm@hp.com] 
Sent: Monday, April 23, 2007 12:56 PM
To: Knight, Lloyd; Andrew Haley
Cc: java@gcc.gnu.org
Subject: RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.

> -----Original Message-----
> From: Knight, Lloyd [mailto:Lloyd.Knight@adc.com]
> 
>  
> andrew,
> 
> although i did not post it, i did try the continue after segv.
> it does not seem to continue... :
[Sorry if I forgot some of the context here.] If you don't get the same
result when not running under dbx, and you want to debug this, options
are:

1) Use gdb.
2) Try "ignore SIGSEGV" in dbx.
3) Debug a core dump instead.
4) Explicitly set GC_stackbottom (e.g. to the address of a global in
main, if all heap manipulation is done in functions called by main)
before entering the collector the first time, so that the collector
doesn't go looking for it.

Hans
> 
> Reading pdftk
> Reading ld.so.1
> Reading libpthread.so.1
> Reading librt.so.1
> Reading libnsl.so.1
> Reading libdl.so.1
> Reading libsocket.so.1
> Reading libiconv.so.2.4.0
> Reading libm.so.2
> Reading libgcc_s.so.1
> Reading libc.so.1
> Reading libaio.so.1
> Reading libmd5.so.1
> detected a multithreaded program
> (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) run ./1.pdf stamp 
> dwatermark-4.pdf output 11.pdf
> Running: pdftk ./1.pdf stamp dwatermark-4.pdf output 11.pdf (process 
> id 8565) Reading libc_psr.so.1
> (l@1) signal SEGV (no mapping at the fault address) in GC_find_limit 
> at
> 0x3e3678
> 0x003e3678: GC_find_limit+0x0070:       ldsb    [%g1], %o0
> (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) cont
> (l@1) signal SEGV (no mapping at the fault address) in GC_find_limit 
> at
> 0x3e3678
> 0x003e3678: GC_find_limit+0x0070:       ldsb    [%g1], %o0
> (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) continue
> (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) cont
> (l@1) signal SEGV (no mapping at the fault address) in GC_find_limit 
> at
> 0x3e3678
> 0x003e3678: GC_find_limit+0x0070:       ldsb    [%g1], %o0
> (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where =>[1] 
> GC_find_limit(0xffbff89c, 0x7d8680, 0xffffffff, 0xfffffff8, 0x0, 
> 0x7f0000), at 0x3e3678
>   [2] GC_get_stack_base(0x7cbf08, 0x7cc048, 0xa1964, 0xfef46964, 0x0, 
> 0x0), at 0x3e36e4
>   [3] GC_init_inner(0x0, 0x1084, 0x0, 0x0, 0x0, 0x0), at 0x3e2ac0
>   [4] GC_init(0x7d8ff8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x3e2ccc
>   [5] GC_init_gcj_malloc(0x0, 0x3d6ef8, 0x0, 0x0, 0x0, 0x0), at 
> 0x3dc554
>   [6] _Z10_Jv_InitGCv(0x0, 0x1, 0xa1964, 0x0, 0x7e564c, 0xfefeb3d4), 
> at
> 0x3d7e34
>   [7] _Z16_Jv_CreateJavaVMPv(0xffffffff, 0x31, 0x2d68, 0x31312e70, 
> 0x80808080, 0x1010101), at 0x302890
>   [8] main(0x6, 0xffbffc64, 0x0, 0x0, 0xff0d0100, 0xff0d0140), at 
> 0x1c822c
> (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx)
> 
> thanks for your reply.
> 
> lloyd knight
> 
> -----Original Message-----
> From: Andrew Haley [mailto:aph-gcc@littlepinkcloud.COM]
> Sent: Saturday, April 21, 2007 4:37 AM
> To: Knight, Lloyd
> Cc: Hans Boehm; David Daney; java@gcc.gnu.org
> Subject: RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
> 
> Knight, Lloyd writes:
>  > hans,
>  > thanks for the reply.
>  >
>  > sorry, but i'm missing the point of your reply.
>  > is there anything i can try?
> 
> Continue after the SEGV.
> 
> 