This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/21940] New: boehm-gc gctest fails on Solaris 10/x86
- From: "gcc-bugzilla at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Jun 2005 22:04:26 -0000
- Subject: [Bug libgcj/21940] New: boehm-gc gctest fails on Solaris 10/x86
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
During a make check on Solaris 10/x86, make check in boehm-gc fails (which
unfortunately goes almost unnoticed since the failure is not included in
mail-report.log, cf. PR libgcj/11412):
/bin/ksh: 2246 Segmentation Fault
FAIL: gctest
===================
1 of 1 tests failed
===================
make[3]: *** [check-TESTS] Error 1
Running the test manually with LD_LIBRARY_PATH set so libgcc_s.so.1 is
found, one gets one of several possible results:
% LD_LIBRARY_PATH=../../gcc ./gctest
Apparently failed to mark form some function arguments.
Perhaps GC_push_regs was configured incorrectly?
Test failed
Segmentation Fault
% LD_LIBRARY_PATH=../../gcc ./gctest
Segmentation Fault
% LD_LIBRARY_PATH=../../gcc ./gctest
Apparently failed to mark form some function arguments.
Perhaps GC_push_regs was configured incorrectly?
Test failed
Abort
pstack core reveals e.g. (for a run with a plain SEGV):
core 'core' of 10995: gctest
----------------- lwp# 1 / thread# 1 --------------------
bff0d20b __lwp_park (bfe52000, 0, 806ca38, 0) + b
bff06b5e slow_lock (bfe52000, 806ca38, 0) + 3d
bff06c54 mutex_lock_impl (806ca38, 0) + ec
bff06d60 mutex_lock (806ca38, 1, bffbc7b8, bff9e2a6, 806ca38, 806cbac) + 1a
bff9e2ee GC_malloc (c, 0, 8047628, 80531b6, 0, 8051624) + 56
080531de run_one_test (8047650, 8051c29, 8064378, 8064904, 0, 805387e) + 382
08053733 main (1, 8047688, 8047690) + 83
08051b04 _start (1, 80477a0, 0, 80477a7, 804781c, 8047909) + 80
----------------- lwp# 2 / thread# 2 --------------------
bff0df17 __lwp_wait (0, bfe29f78) + 7
bff0a180 _thrp_join (0, bfe29fc4, bfe29fc8, 1) + 5a
bff0a2c2 thr_join (0, bfe29fc4, bfe29fc8, 806ca38, 0, bfe29fc8) + 20
bffa600b GC_thr_daemon (0) + 33
bff0cebf _thr_setup (bfe52400) + 4e
bff0d1b0 _lwp_start (bfe52400, 0, 0, bfe29ff8, bff0d1b0, bfe52400)
----------------- lwp# 3 / thread# 3 --------------------
bffa5d58 GC_my_stack_limits (0, bffbc904, 0, 0, 0, 0) + 2c
bffa5e7d GC_old_stacks_are_fresh (bffb92b8, bffa545c, bfffe000, 806ca58, bffc8eb8, bffb9adc) + c1
bffa35ed GC_read_dirty (40, bffb92b8, 81cded8, bff99084, 809b000, 0) + 16d
bff9f435 GC_initiate_gc (809b000, 0, 81cdee8, bff9dae2, 8303000, 8313000) + 79
bff99084 GC_stopped_mark (bff98de4, bffb92b8, 81cdf18, bff998df) + 64
bff998f4 GC_try_to_collect_inner (bff98de4, 0, 81cdf48, bff99a91, bff99b3a, bff073ab) + 9c
bff99ace GC_try_to_collect (bff98de4, bff073ab, bff0d23b, 0) + 6a
bff99b3a GC_gcollect (0, 0, 0, 0, 0, 0) + 1e
08053174 run_one_test (bff0b838, bff35000, 81cdfec, bff0cebf, 0, 0) + 318
080536ab thr_run_one_test (0) + b
bff0cebf _thr_setup (bfd10000) + 4e
bff0d1b0 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 4 / thread# 4 --------------------
bff0d20b __lwp_park (bfd10400, 0, 806ca38, 0) + b
bff06b5e slow_lock (bfd10400, 806ca38, 0) + 3d
bff06c54 mutex_lock_impl (806ca38, 0) + ec
bff06d60 mutex_lock (806ca38, bffb92b8, 82f0f48, bff99a91) + 1a
bff99aa0 GC_try_to_collect (bff98de4, 8052d84, 82f0fc8, 805316c) + 3c
bff99b3a GC_gcollect (0, 0, 0, 0, 0, 0) + 1e
08053174 run_one_test (bff0b838, bff35000, 82f0fec, bff0cebf, 0, 0) + 318
080536ab thr_run_one_test (0) + b
bff0cebf _thr_setup (bfd10400) + 4e
bff0d1b0 _lwp_start (0, 0, 0, 0, 0, 0)
Some info on this failure can also be found in
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-March/000767.html
and a couple of other postings on the gc@linux.hpl.hp.com list.
To further investigate this, I've tried a couple of experiments with the
gc6.5 release. Here's what I've found:
* With Sun cc 5.7, gctest fails like this:
Switched to incremental mode
Reading dirty bits from /proc
List reversal produced incorrect list - collector is broken
Test failed
Abort
The same binary works without problems on s10_63 (an old beta of Solaris
10, before amd64 integration), but fails on s10_70 (the first beta to
integrate amd64 support) and on Solaris 10 FCS.
Definining USE_GENERIC_PUSH_REGS in gcconfig.h doesn't change this.
* With Sun cc 5.7 and configuring with --enable-full-debug, gctest passes
on all releases. With the calls to GC_enable_incremental commented out
in tests/test.c, gctest even passes without --enable-full-debug; setting
GC_ENABLE_INCREMENTAL=1 in the environment causes it to fail again.
* With Sun cc 5.7 and configuring with --enable-full-debug
--enable-threads=posix, gctest fails again, now with the same error as
gcc (which has pthread support enabled by default).
* With gcc 3.4.3 and configuring with --disable-threads, I get the same
failure as with cc (which defaults to --disable-threads).
* With gcc 3.4.3 and configuring with --disable-threads
--enable-full-debug, gctest works.
Environment:
System: SunOS cumaru 5.10 Generic_Patch i86pc i386 i86pc
Architecture: i86pc
host: i386-pc-solaris2.10
build: i386-pc-solaris2.10
target: i386-pc-solaris2.10
configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 --enable-languages=c,c++,f95,java,objc,ada --disable-libmudflap
How-To-Repeat:
Run gctest (boehm-gc make check) as described above.
--
Summary: boehm-gc gctest fails on Solaris 10/x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-pc-solaris2.10
GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21940