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.