gcj-dbtool segfaults on hppa-linux

[Matthias Klose]

Binary package hint: gcj-4.1

gcj-dbtool segfaults, when trying to add jar files to the database; see the
debian and upstream reports for more information.

[Debian GCC maintainers (debian-gcc)]

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

[stevenb (steven-gcc)]

Either show that it is a regression, or dont put the regression marker in the subject.

[Debian GCC maintainers (debian-gcc)]

(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

[Debian GCC maintainers (debian-gcc)]

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

[John David Anglin (dave-hiauly1)]

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 <email address hidden>

        PR other/26208
...

Dave

[Debian GCC maintainers (debian-gcc)]

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?)

[Drow-l (drow-l)]

Created attachment 12553
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.

[John David Anglin (dave-hiauly1)]

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

[Drow-l (drow-l)]

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.

[Debian GCC maintainers (debian-gcc)]

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

[Mmitchel-gcc (mmitchel-gcc)]

Will not be fixed in 4.2.0; retargeting at 4.2.1.

[Mmitchel-gcc (mmitchel-gcc)]

Change target milestone to 4.2.3, as 4.2.2 has been released.

[Jsm28 (jsm28)]

4.2.3 is being released now, changing milestones of open bugs to 4.2.4.

[Jsm28 (jsm28)]

4.2.4 is being released, changing milestones to 4.2.5.

[Jsm28 (jsm28)]

Closing 4.2 branch.

[Rguenth (rguenth)]

GCC 4.3.4 is being released, adjusting target milestone.

[Jan-Simon Möller (dl9pf)]

Confirmed also for 4.4.1 on arm-linux-gnueabi.

[Matthias Klose (doko)]

gcj-4.4 now works on hppa

[Rguenth (rguenth)]

GCC 4.3.5 is being released, adjusting target milestone.

[Rguenth (rguenth)]

4.3 branch is being closed, moving to 4.4.7 target.

[Jakub-gcc (jakub-gcc)]

4.4 branch is being closed, moving to 4.5.4 target.

[Rearnsha (rearnsha)]

Last known failure was reported against 4.2.0.

Can somebody please confirm if this is still a problem on an active branch?

[stevenb (steven-gcc)]

No response.

[John David Anglin (dave-anglin)]

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 <email address hidden>