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.


> -----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.
> 
> 


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