See <http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00734.html>. Here's one: dave@hiauly6:~/gnu/gcc-4.2/objdir/hppa-linux/libjava/testsuite$ gdb virtual GNU gdb 6.5.50.20061105-cvs 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-unknown-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libjava/testsuite/virtual [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 18871)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18871)] GC_push_all_eager (bottom=<value optimized out>, top=0xfb516e88 "°Qn\210B–*ÝBÞðl\020\027t®") at ../../../gcc/boehm-gc/mark.c:1468 1468 q = *p; (gdb) bt #0 GC_push_all_eager (bottom=<value optimized out>, top=0xfb516e88 "°Qn\210B–*ÝBÞðl\020\027t®") at ../../../gcc/boehm-gc/mark.c:1468 #1 0x4239c488 in GC_push_all_stacks () at ../../../gcc/boehm-gc/pthread_stop_world.c:307 #2 0x42394ca0 in GC_push_roots (all=1, cold_gc_frame=0xfb516c88 "B\222(Ý") at ../../../gcc/boehm-gc/mark_rts.c:646 #3 0x423943a0 in GC_mark_some ( cold_gc_frame=0xfb516e88 "°Qn\210B–*ÝBÞðl\020\027t®") at ../../../gcc/boehm-gc/mark.c:326 #4 0x4238a80c in GC_stopped_mark ( stop_func=@0x4002e51a: 0x42389b8c <GC_never_stop_func>) at ../../../gcc/boehm-gc/alloc.c:531 #5 0x4238abe4 in GC_try_to_collect_inner (stop_func=0xfad16000) at ../../../gcc/boehm-gc/alloc.c:378 #6 0x42396550 in GC_init_inner () at ../../../gcc/boehm-gc/misc.c:789 #7 0x4239681c in GC_init () at ../../../gcc/boehm-gc/misc.c:493 #8 0x4238ff7c in GC_init_gcj_malloc (mp_index=-86941696, mp=0xfb516e88) at ../../../gcc/boehm-gc/gcj_mlc.c:60 #9 0x4174ff28 in _Jv_InitGC () at ../../../gcc/libjava/boehm.cc:503 #10 0x416f80fc in _Jv_CreateJavaVM (vm_args=0x0) at ../../../gcc/libjava/prims.cc:1434 #11 0x416f88b8 in _Jv_RunMain (vm_args=0x0, klass=0x12568, name=0x0, argc=1, ---Type <return> to continue, or q <return> to quit--- argv=0x4fac980c, is_jar=false) at ../../../gcc/libjava/prims.cc:1520 #12 0x416f8c10 in _Jv_RunMain (klass=0xfb516e88, name=0xfb516e88 "°Qn\210B–*ÝBÞðl\020\027t®", argc=1121908740, argv=<value optimized out>, is_jar=3) at ../../../gcc/libjava/prims.cc:1593 #13 0x416f8c3c in JvRunMain (klass=0xfad16000, argc=1, argv=0x42def804) at ../../../gcc/libjava/prims.cc:1599 #14 0x00010c2c in main (argc=1073939190, argv=0x4003030e) at /tmp/ccXCOKNq.i:11 dave@hiauly6:~/gnu/gcc-4.2/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.2.2 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --host=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,ada,obj-c++,java Thread model: posix gcc version 4.2.2 20070914 (prerelease)
Hmmm, I also got a bunch of fails on head in my last build on mx3210: http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00736.html However, there weren't any fails on gsyprf11: http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00735.html The only recent change in hiauly6 and mx3210 relative to gsyprf11 would be an update to gcc-4.1 (Debian 4.1.2-16).
I have no idea what has triggered this bug but the problem seems to be in the setting of the stack base in GC_get_thread_stack_base(). In particular, pthread_attr_getstack() seems broken. This is the code for the line return stack_addr - stack_size; 0x4239ad40 <GC_get_thread_stack_base+96>: ldw -78(sp),r20 0x4239ad44 <GC_get_thread_stack_base+100>: ldw -74(sp),ret0 0x4239ad48 <GC_get_thread_stack_base+104>: sub r20,ret0,r20 0x4239ad4c <GC_get_thread_stack_base+108>: copy r20,ret0 At 0x4239ad48: (gdb) p/x $ret0 $5 = 0x800000 (gdb) p/x $r20 $6 = 0xfb50c000 (gdb) p/x $sp $7 = 0xfb50cc80 At 0x4239ad50: (gdb) p/x $ret0 $8 = 0xfad0c000 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. GC_push_all_eager (bottom=<value optimized out>, top=0xfb50ce88 "°P�\210B–*έBήπl\020\027t®") at ../../../gcc/boehm-gc/mark.c:1468 1468 q = *p; (gdb) p/x $r3 $9 = 0xfad0c000 It seems that pthread_attr_getstack() returns a stack_addr value that is too small, and after subtracting stack_size to obtain stack_base, we have an invalid pointer.
The problem appears to be here in pthread_support.c: # ifdef STACK_GROWS_DOWN return stack_addr + stack_size; # else return stack_addr - stack_size; # endif SUSV3 says the stackaddr argument in pthread_attr_getstack is the base (lowest addressable byte) of the storage and stacksize is the size of the storage in bytes. So, it's wrong to subtract stack_size from stack_addr in the STACK_GROWS_UP case. Fixing this appears to fix the bug.
Subject: Re: 1938 unexpected fails in libjava testsuite The attached patch fixes the problem. Dave
Created attachment 14336 [details] pthread_support.c.d
Hans, Is the attached patch correct?
Based only on code inspection, this looks fine to me. The gc7 code is different, but seems to do the same thing as the patched version. I don't think this code is used on HP/UX? If it were, it might be good to test there.
Subject: Re: 1938 unexpected fails in libjava testsuite > I don't think this code is used on HP/UX? If it were, it might be good to test > there. HP/UX doesn't appear to have, pthread_getattr_np, so this code isn't used. I don't see an obvious way to access to access the attributes of a thread in HP/UX, although possibly 11.31 now provides the necessary routines. If that's the case, it would be interesting to build and test java on 11.31 (don't have such a machine myself). Given that this is fixed in your source, I'll consider the fix to the GCC source obvious. Dave
Subject: Bug 33442 Author: danglin Date: Thu Oct 11 00:36:08 2007 New Revision: 129224 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129224 Log: PR boehm-gc/33442 * pthread_support.c (GC_PTR GC_get_thread_stack_base): If stack grows up, return stack_addr instead of stack_addr - stack_size. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/pthread_support.c
Subject: Bug 33442 Author: danglin Date: Sat Oct 13 15:01:29 2007 New Revision: 129283 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129283 Log: PR boehm-gc/33442 * pthread_support.c (GC_PTR GC_get_thread_stack_base): If stack grows up, return stack_addr instead of stack_addr - stack_size. Modified: branches/gcc-4_2-branch/boehm-gc/ChangeLog branches/gcc-4_2-branch/boehm-gc/pthread_support.c
Fixed on trunk and 4.2. I believe that this problem isn't present in 4.1.