Launchpad has imported 19 comments from the remote bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2006-09-24T23:04:15+00:00 Debian GCC maintainers wrote: [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 "�4]HB�\003@B���O��") 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 "�4]HB�\003@B���O��") 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��@") at ../../../gcc-20060910/boehm-gc/mark_rts.c:646 #3 0x42147438 in GC_mark_some (cold_gc_frame=0xc0345d48 "�4]HB�\003@B���O��") 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��@", 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 Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/0 ------------------------------------------------------------------------ On 2006-09-25T15:04:53+00:00 stevenb wrote: Either show that it is a regression, or dont put the regression marker in the subject. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/1 ------------------------------------------------------------------------ On 2006-09-28T19:30:21+00:00 Debian GCC maintainers wrote: (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 Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/2 ------------------------------------------------------------------------ On 2006-09-28T19:31:38+00:00 Debian GCC maintainers wrote: 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���Ah\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@"..., 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?) Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/3 ------------------------------------------------------------------------ On 2006-09-28T20:53:06+00:00 John David Anglin wrote: 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 <ja...@redhat.com> PR other/26208 ... Dave Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/4 ------------------------------------------------------------------------ On 2006-10-08T11:05:06+00:00 Debian GCC maintainers wrote: 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 "�G<\210B�\233@B�\204\234O��") 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 "�G<\210B�\233@B�\204\234O��") 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?) Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/5 ------------------------------------------------------------------------ On 2006-11-06T19:33:59+00:00 Drow-l wrote: 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. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/6 ------------------------------------------------------------------------ On 2006-11-06T21:09:32+00:00 John David Anglin wrote: 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 Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/7 ------------------------------------------------------------------------ On 2006-11-06T21:47:54+00:00 Drow-l wrote: 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. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/8 ------------------------------------------------------------------------ On 2006-11-06T22:14:49+00:00 Debian GCC maintainers wrote: 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 Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/9 ------------------------------------------------------------------------ On 2007-05-14T22:28:37+00:00 Mmitchel-gcc wrote: Will not be fixed in 4.2.0; retargeting at 4.2.1. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/11 ------------------------------------------------------------------------ On 2007-10-09T19:22:23+00:00 Mmitchel-gcc wrote: Change target milestone to 4.2.3, as 4.2.2 has been released. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/12 ------------------------------------------------------------------------ On 2008-02-01T16:53:19+00:00 Jsm28 wrote: 4.2.3 is being released now, changing milestones of open bugs to 4.2.4. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/13 ------------------------------------------------------------------------ On 2008-05-19T20:22:57+00:00 Jsm28 wrote: 4.2.4 is being released, changing milestones to 4.2.5. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/14 ------------------------------------------------------------------------ On 2009-03-31T19:44:28+00:00 Jsm28 wrote: Closing 4.2 branch. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/15 ------------------------------------------------------------------------ On 2009-08-04T12:27:56+00:00 Rguenth wrote: GCC 4.3.4 is being released, adjusting target milestone. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/16 ------------------------------------------------------------------------ On 2009-10-26T12:29:32+00:00 Jan-Simon Möller wrote: Confirmed also for 4.4.1 on arm-linux-gnueabi. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/17 ------------------------------------------------------------------------ On 2010-05-22T18:11:15+00:00 Rguenth wrote: GCC 4.3.5 is being released, adjusting target milestone. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/19 ------------------------------------------------------------------------ On 2011-06-27T12:14:17+00:00 Rguenth wrote: 4.3 branch is being closed, moving to 4.4.7 target. Reply at: https://bugs.launchpad.net/gcc/+bug/89408/comments/20 ** Changed in: gcc Importance: Unknown => Medium ** Bug watch added: Debian Bug tracker #388505 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388505 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/89408 Title: gcj-dbtool segfaults on hppa-linux To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/89408/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
