Bug 15812 - [4.0 Regression] boehm-gc test fails on several targets
Summary: [4.0 Regression] boehm-gc test fails on several targets
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2004-06-03 21:30 UTC by Andreas Tobler
Modified: 2004-09-13 14:15 UTC (History)
2 users (show)

See Also:
Host: powerpc-apple-darwin7.4.0
Target: powerpc-apple-darwin7.4.0
Build: powerpc-apple-darwin7.4.0
Known to work:
Known to fail:
Last reconfirmed: 2004-07-02 19:22:09


Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Tobler 2004-06-03 21:30:54 UTC
Boehm gctest fails to run on several targets.
My targets here: darwin 7.4.0, ppclinux and sparc-sun-solaris2.9 (32/64bit) fail
with a seg fault.
Further details on request, but I feel it is reproduciable.

Also, a make check in boehm-gc leads to an undefined @LDFLAGS@ if one does try
to run it outside the make -k check.
Deleteing the @LDFLAGS@ makes it link and core cump :(
Comment 1 Andreas Tobler 2004-06-03 21:32:25 UTC
sould have entered the right target : powerpc-apple-darwin7.4.0
Comment 2 Andrew Pinski 2004-06-03 22:25:50 UTC
Confirmed, it also fails on i686-pc-linux-gnu and most likely every other target.
Comment 3 Andreas Tobler 2004-08-14 11:50:53 UTC
Passes here on darwin after the boehm-gc merge (upstream 6.3). But still
occasionally failures. Maybe depending on machine load?
Comment 4 John Lumby 2004-08-14 23:09:11 UTC
I also notice that boehm-gc test for gcc 3.4.1 runs fine on linux 2.4.18 on i686
but with same gcc and everything else same except linux kernel 2.6.7, it fails:

(with some extra GC_printf I added in run_one_test() ):

Switched to incremental mode
Emulating dirty bits with mprotect/signals
thread 4002 entering run_one_test
thread 4000 entering run_one_test

Is this the same bug?
Comment 5 Hans Boehm 2004-08-17 22:53:36 UTC
I had missed this earlier.  This was a known bug in the upstream gc6.3alpha5 
and earlier, caused by writes made by the pthread suspension handler made with 
SIGSEGV disabled.  It should affect only processes which enable incremental GC, 
something that itsn't really supported by gcj.  Thus removing the appropriate 
(last one in test.c) call to GC_enable_incremental() in the test program is 
arguably an acceptable workaround.

The probability of observing this bug seems to be MUCH higher with a Linux 2.6 
kernel than on other platforms.  This may be a consequenc of some scheduling or 
signal delivery change.

This should be fixed by Bryce's 6.3 integration.  I have not been able to 
reproduce it with the upstream 6.3 sources on either a unprocessor PIII machine 
or a dual processor Itanium, both running 2.6 kernels.  I was able to reproduce 
it with the old GC versions.

Could someone who has observed a failure after the 6.3 integration please post 
as stack trace?  (John reported separately that he's no longer getting 
the "Killed" message, so hopefully it's possible to get such a trace.)
Comment 6 Andrew Pinski 2004-08-17 22:56:41 UTC