Bug 29206 - [4.6/4.7/4.8 regression] gcj-dbtool segfaults
[4.6/4.7/4.8 regression] gcj-dbtool segfaults
Status: RESOLVED INVALID
Product: gcc
Classification: Unclassified
Component: target
4.2.0
: P5 normal
: 4.6.4
Assigned To: Not yet assigned to anyone
: wrong-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-24 23:04 UTC by Debian GCC Maintainers
Modified: 2012-11-10 01:28 UTC (History)
7 users (show)

See Also:
Host:
Target: hppa-linux-gnu arm-linux-gnu
Build:
Known to work: 4.1.2
Known to fail: 4.2.0
Last reconfirmed: 2009-03-31 19:44:28


Attachments
Potential patch. (1.73 KB, patch)
2006-11-06 19:33 UTC, Daniel Jacobowitz
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2006-09-24 23:04:15 UTC
[forwarded from http://bugs.debian.org/387875 ]
[forwarded from http://bugs.debian.org/388505 ]

gcj-dbtool segfaults on hppa-linux-gnu and arm-linux-gnu; arm doesn't have libjava support yet; the patches available from http://gcc.gnu.org/ml/java/2006-08/msg00123.html were used.


rechecked both with a new 4.2 as a debian package and a vanilla 
upstream build. the installed gcj-dbtool crashes. I don't see the 
segfault, when gcj-dbtool is called during the build. 
 
GNU gdb 6.4.90-debian 
Copyright (C) 2006 Free Software Foundation, Inc. 
GDB is free software, covered by the GNU General Public License, and you are 
welcome to change it and/or distribute copies of it under certain conditions. 
Type "show copying" to see the conditions. 
There is absolutely no warranty for GDB.  Type "show warranty" for details. 
This GDB was configured as "hppa-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so\
.1". 
 
(gdb) set args -n 
(gdb) run 
Starting program: /scratch/packages/gcc/4.2/tstinstall/bin/gcj-dbtool -n 
[Thread debugging using libthread_db enabled] 
[New Thread 16384 (LWP 17786)] 
 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 16384 (LWP 17786)] 
GC_push_all_eager (bottom=<value optimized out>,  
    top=0xc0345d48 "&#65533;4]HB&#65533;\003@B&#65533;&#65533;&#65533;O&#65533;&#65533;") 
    at ../../../gcc-20060910/boehm-gc/mark.c:1468 
1468            q = *p; 
(gdb) p p 
$1 = (word *) 0xbfb45000 
(gdb) p *p 
Cannot access memory at address 0xbfb45000 
(gdb) bt 
#0  GC_push_all_eager (bottom=<value optimized out>,  
    top=0xc0345d48 "&#65533;4]HB&#65533;\003@B&#65533;&#65533;&#65533;O&#65533;&#65533;") 
    at ../../../gcc-20060910/boehm-gc/mark.c:1468 
#1  0x4214f74c in GC_push_all_stacks () 
    at ../../../gcc-20060910/boehm-gc/pthread_stop_world.c:307 
#2  0x42147d58 in GC_push_roots (all=16384, cold_gc_frame=0xc0345b48 "B&#65533;&#65533;@") 
    at ../../../gcc-20060910/boehm-gc/mark_rts.c:646 
#3  0x42147438 in GC_mark_some (cold_gc_frame=0xc0345d48 "&#65533;4]HB&#65533;\003@B&#65533;&#65533;&#65533;O&#65533;&#65533;") 
    at ../../../gcc-20060910/boehm-gc/mark.c:326 
#4  0x4213d5cc in GC_stopped_mark (stop_func=0x4000) 
    at ../../../gcc-20060910/boehm-gc/alloc.c:531 
#5  0x4213d9c4 in GC_try_to_collect_inner (stop_func=0x4000) 
    at ../../../gcc-20060910/boehm-gc/alloc.c:378 
#6  0x42149718 in GC_init_inner () at ../../../gcc-20060910/boehm-gc/misc.c:789 
#7  0x421499e4 in GC_init () at ../../../gcc-20060910/boehm-gc/misc.c:493 
#8  0x42142f94 in GC_init_gcj_malloc (mp_index=-1078702080, mp=0xc0345d48) 
    at ../../../gcc-20060910/boehm-gc/gcj_mlc.c:60 
#9  0x4146df2c in _Jv_InitGC () at ../../../gcc-20060910/libjava/boehm.cc:503 
#10 0x41414664 in _Jv_CreateJavaVM (vm_args=0x0) 
    at ../../../gcc-20060910/libjava/prims.cc:1434 
#11 0x41414e48 in _Jv_RunMain (vm_args=0x4000, klass=0x26770,  
    name=0xc0345b48 "B&#65533;&#65533;@", argc=2, argv=0xc034540c, is_jar=false) 
    at ../../../gcc-20060910/libjava/prims.cc:1520 
#12 0x414151c8 in _Jv_RunMain (klass=0xc0345d48,  
    name=0xb <Address 0xb out of bounds>, argc=1119747456,  
    argv=<value optimized out>, is_jar=false) 
    at ../../../gcc-20060910/libjava/prims.cc:1593 
#13 0x414151f4 in JvRunMain (klass=0xbfb45000, argc=1, argv=0x42bdfd80) 
    at ../../../gcc-20060910/libjava/prims.cc:1599 
#14 0x42f14338 in __libc_start_main () from /lib/libc.so.6 
#15 0x00012610 in _start () at ../sysdeps/hppa/elf/start.S:84
Comment 1 Steven Bosscher 2006-09-25 15:04:53 UTC
Either show that it is a regression, or dont put the regression marker in the subject.
Comment 2 Debian GCC Maintainers 2006-09-28 19:30:21 UTC
(In reply to comment #1)
> Either show that it is a regression, or dont put the regression marker in the
> subject.

rechecked, that it is a regression on hppa-linux-gnu, compared to 4.1.2 SVN.

  Matthias

Comment 3 Debian GCC Maintainers 2006-09-28 19:31:38 UTC
attached the stacktrace for arm-linux-gnu

  Matthias

(gdb) run
Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db 64
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 18291)]
[New Thread 32769 (LWP 20685)]
[New Thread 16386 (LWP 20790)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 18291)]
0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1
(gdb) bt
#0  0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1
#1  0x40b988c0 in _Jv_StackTrace::UnwindTraceFn (context=0xbfffebcc, state_ptr=<value optimized out>)
    at ../../../src/libjava/stacktrace.cc:141
#2  0x41bf6a04 in _Unwind_Backtrace () from /lib/libgcc_s.so.1
#3  0x40b987cc in _Jv_StackTrace::GetStackTrace () at ../../../src/libjava/stacktrace.cc:170
#4  0x40bd9bd0 in java::lang::VMThrowable::fillInStackTrace () at ../../../src/libjava/java/lang/natVMThrowable.cc:33
#5  0x40f9aee4 in java.lang.Throwable.fillInStackTrace()java.lang.Throwable (this=0xbfffebcc)
    at ../../../src/libjava/classpath/java/lang/Throwable.java:498
#6  0x40f9a8d4 in java.lang.Throwable.Throwable(java.lang.String) (this=0x41ef2220, message=0x41f6ed98)
    at ../../../src/libjava/classpath/java/lang/Throwable.java:159
#7  0x40f846d8 in java.lang.Exception.Exception(java.lang.String) (this=0xbfffebcc, s=0xbfffebac)
    at ../../../src/libjava/classpath/java/lang/Exception.java:77
#8  0x40f8219c in java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String) (this=0xbfffebcc, s=0xbfffebac)
    at ../../../src/libjava/classpath/java/lang/ClassNotFoundException.java:83
#9  0x40fc7870 in java.net.URLClassLoader.findClass(java.lang.String)java.lang.Class (this=0x41edb2d8, className=0x41f0fb90)
    at ../../../src/libjava/java/net/URLClassLoader.java:1080
#10 0x40bfdb48 in gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Class (this=0xbfffebcc, name=0x41f0fb90)
    at ../../../src/libjava/gnu/gcj/runtime/BootClassLoader.java:55
#11 0x40bd9788 in java::lang::VMClassLoader::loadClass (name=0x41f0fb90, resolve=0 '\0')
    at ../../../src/libjava/java/lang/natVMClassLoader.cc:208
#12 0x40bd2d90 in _Jv_FindClass (name=0x41f0d730, loader=0x0) at ../../../src/libjava/java/lang/natClassLoader.cc:407
#13 0x40bd1a40 in java::lang::Class::forName (className=0x41f6ee88, initialize=1 '\001', loader=0x0)
    at ../../../src/libjava/java/lang/natClass.cc:88
#14 0x40bf8f90 in gnu.gcj.convert.BytesToUnicode.getDecoder(java.lang.String)gnu.gcj.convert.BytesToUnicode (encoding=0x41edcaf0)
    at ../../../src/libjava/gnu/gcj/convert/BytesToUnicode.java:101
#15 0x40bd7a40 in java::lang::String::init (this=0x3, bytes=0x41efad30, offset=0, count=2, encoding=0x41edcaf0)
    at ../../../src/libjava/java/lang/natString.cc:490
#16 0x40f91210 in java.lang.String.String(byte[], int, int) (this=0x41f6eeb8, data=0x41efad30, offset=0, count=2)
    at ../../../src/libjava/java/lang/String.java:345
#17 0x40b83f24 in JvConvertArgv (argc=3, argv=0xa398) at ../../../src/libjava/prims.cc:953
#18 0x40b84e58 in _Jv_RunMain (vm_args=0x0, klass=0x16460, name=0x0, argc=4, argv=0xbffffa64, is_jar=false)
    at ../../../src/libjava/prims.cc:1537
#19 0x40b85190 in _Jv_RunMain (klass=0xbfffebac, 
    name=0x41714e90 "(d&#65533;&#65533;&#65533;Ah\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@h\036&#65533;&#65533;&#65533;@"..., argc=1085821328, argv=<value optimized out>, 
    is_jar=false) at ../../../src/libjava/prims.cc:1597
#20 0x40b851bc in JvRunMain (klass=0xbfffebcc, argc=1097944720, argv=0x0) at ../../../src/libjava/prims.cc:1603
#21 0x41c14e44 in __libc_start_main () from /lib/libc.so.6
#22 0x41c14e44 in __libc_start_main () from /lib/libc.so.6
Previous frame identical to this frame (corrupt stack?)
Comment 4 dave 2006-09-28 20:53:06 UTC
Subject: Re:  [4.2 regression] gcj-dbtool segfaults

> Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db
> 64
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 18291)]
> [New Thread 32769 (LWP 20685)]
> [New Thread 16386 (LWP 20790)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 18291)]
> 0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1
> (gdb) bt
> #0  0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1

The following patch introduced _Unwind_GetIPInfo:

2006-02-27  Jakub Jelinek  <jakub@redhat.com>

        PR other/26208
...

Dave
Comment 5 Debian GCC Maintainers 2006-10-08 11:05:06 UTC
rechecked with explicitely disabling the use of _Unwind_GetIPInfo (undefine HAVE_GETIPINFO):

(gdb) run
Starting program: /usr/bin/gcj-dbtool -n foo.db 64
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 19080)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 19080)]
GC_push_all_eager (bottom=<value optimized out>, top=0xc0473c88 "&#65533;G<\210B&#65533;\233@B&#65533;\204\234O&#65533;&#65533;")
    at ../../../src/boehm-gc/mark.c:1468
1468    ../../../src/boehm-gc/mark.c: No such file or directory.
        in ../../../src/boehm-gc/mark.c
(gdb) bt
#0  GC_push_all_eager (bottom=<value optimized out>, top=0xc0473c88 "&#65533;G<\210B&#65533;\233@B&#65533;\204\234O&#65533;&#65533;")
    at ../../../src/boehm-gc/mark.c:1468
#1  0x42119be4 in GC_push_all_stacks () at ../../../src/boehm-gc/pthread_stop_world.c:307
#2  0x42119be4 in GC_push_all_stacks () at ../../../src/boehm-gc/pthread_stop_world.c:307
Previous frame identical to this frame (corrupt stack?)
Comment 6 Daniel Jacobowitz 2006-11-06 19:33:59 UTC
Created attachment 12553 [details]
Potential patch.

This hasn't been tested yet; when it has I can add a changelog and post it.  That's in progress now.

Ranjit's patch to enable prologue analysis on i386 changed the behavior for other SJLJ targets.  They used to call the no-op fallback_backtrace from sysdep/generic/backtrace.h; afterwards they called _Unwind_Backtrace.  This links for SJLJ, but does not work, and when the trace function is called for _URC_END_OF_STACK, _Unwind_GetIP segfaults.
Comment 7 dave 2006-11-06 21:09:32 UTC
Subject: Re:  [4.2/4.3 regression] gcj-dbtool segfaults

> Ranjit's patch to enable prologue analysis on i386 changed the behavior for
> other SJLJ targets.  They used to call the no-op fallback_backtrace from
> sysdep/generic/backtrace.h; afterwards they called _Unwind_Backtrace.  This
> links for SJLJ, but does not work, and when the trace function is called for
> _URC_END_OF_STACK, _Unwind_GetIP segfaults.

From the PR, I had no idea that debian was still using the SJLJ exception
support on this target.  I switched to only building and testing with DWARF2
exceptions a long time ago.

Dave
Comment 8 Daniel Jacobowitz 2006-11-06 21:47:54 UTC
I'm not sure, but I think that our hppa port hasn't switched over yet.

As for ARM, I'm not sure what to do to fix the issue.  ARM old ABI is stuck with SJLJ.  And the EABI can't implement _Unwind_Backtrace either.  I have been speaking with someone at ARM about the ABI implications of this, on and off, but I don't have a lot of hope for it working out without a GNU extension.
Comment 9 Debian GCC Maintainers 2006-11-06 22:14:49 UTC
hppa is supposed to use dwarf2 based exceptions in Debian; at least that's what the libgcc soversion (4) suggests; explicitely configuring with --enable-sjlj-exceptions would configure tu build libgcc with soversion 3.

  Matthias
Comment 10 Mark Mitchell 2007-05-14 22:28:37 UTC
Will not be fixed in 4.2.0; retargeting at 4.2.1.
Comment 11 Mark Mitchell 2007-10-09 19:22:23 UTC
Change target milestone to 4.2.3, as 4.2.2 has been released.
Comment 12 Joseph S. Myers 2008-02-01 16:53:19 UTC
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.
Comment 13 Joseph S. Myers 2008-05-19 20:22:57 UTC
4.2.4 is being released, changing milestones to 4.2.5.
Comment 14 Joseph S. Myers 2009-03-31 19:44:28 UTC
Closing 4.2 branch.
Comment 15 Richard Biener 2009-08-04 12:27:56 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 16 Jan-Simon Möller 2009-10-26 12:29:32 UTC
Confirmed also for 4.4.1 on arm-linux-gnueabi.
Comment 17 Richard Biener 2010-05-22 18:11:15 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 18 Richard Biener 2011-06-27 12:14:17 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 19 Jakub Jelinek 2012-03-13 12:47:38 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 20 Richard Earnshaw 2012-03-13 15:50:03 UTC
Last known failure was reported against 4.2.0.

Can somebody please confirm if this is still a problem on an active branch?
Comment 21 Steven Bosscher 2012-11-09 23:07:43 UTC
No response.
Comment 22 dave.anglin 2012-11-10 01:28:52 UTC
If possible, I think SJLJ support should go.  I can't remember the  
exact status of SJLJ for HP-UX 10
but a comment in hpux-unwind.h suggests that I tested dwarf2 support.   
I can check but it will take
time.....

Dave
--
John David Anglin	dave.anglin@bell.net