[Gc] Re: The gcc 3.4 gc-test program boehm-gc/tests/test.c fails on linux 2.

Hans Boehm Hans.Boehm at hp.com
Sun Aug 15 21:54:37 PDT 2004


The easiest patch may be to remove the GC_enable_incremental call around
line 1809 in tests/test.c, or change the surrounding #if to a #if 0.

(I'm not sure about the line number in your version, but it's the last
such call in the file.)

The other workaround is probably to build with --enable-parallel-mark,
which is probably a good idea if you are targetting mostly
multiprocessors.

Hans

On Sun, 15 Aug 2004, John Lumby wrote:

> Thank you Hans.     I extracted latest pthread_stop_world.c from the gcc =
cvs
> ( can't tell if this is the same version 6.3alpha6 you stated or newer) a=
nd
> tried
> cd /home/gcc-build/i686-pc-linux-gnu/boehm-gc;make
> but when compiling the new pthread_stop_world.c :
> ___________________________________________________
> /home/gcc-3.4.1/boehm-gc/pthread_stop_world.c: In function
> `GC_push_all_stacks':
> /home/gcc-3.4.1/boehm-gc/pthread_stop_world.c:269: error:
> `GC_in_thread_creation' undeclared (first use in this function)
> /home/gcc-3.4.1/boehm-gc/pthread_stop_world.c:269: error: (Each undeclare=
d
> identifier is reported only once
> /home/gcc-3.4.1/boehm-gc/pthread_stop_world.c:269: error: for each functi=
on
> it appears in.)
> make[1]: *** [pthread_stop_world.lo] Error 1
> _____________________________________________
>
> I guess maybe I also need a newer header file?    Where should
> GC_in_thread_creation be defined?
>
> But of course replacing this file is changing the gcc itself, not just a
> change to the test suite.   Maybe I can't (or shouldn't) do this in versi=
on
> 3.4.1 ?       But I wonder if there is some simple change to my 3.4.1 tre=
e
> that will let the test run correctly?      E,g, would you recommend to
> replace the entire boehm_gc dir by the one from cvs and try that?   Is it
> completely self-contained and not dependent on version of other gcc
> directories?
>
> I understand you said this incremental mode is not used in the gcc itself=
 -
> so maybe I should ignore the error and install.     but  I don't like to
> "instal" a new gcc that doesn't pass its own tests.
>
> John
>
> ----Original Message Follows----
> From: Hans Boehm <Hans.Boehm at hp.com>
> To: John Lumby <johnlumby at hotmail.com>
> CC: gc at napali.hpl.hp.com
> Subject: [Gc] Re: The gcc 3.4 gc-test program boehm-gc/tests/test.c fails=
 on
> linux 2.6.7 on ix86
> Date: Sat, 14 Aug 2004 18:29:41 -0700 (PDT)
>
> I believe this was fixed by a change to signal masking in
> pthread_stop_world.c in version 6.3alpha6.  As a result, it should
> now be fixed in the gcc trunk.  I should have merged this into the
> gcc tree earlier.
>
> I don't think this actually affects normal gcj operation, since it
> should only show up in incremental GC mode, which is not enabled for gcj.
>
> Hans
>
> On Sat, 14 Aug 2004, John Lumby wrote:
>
>  > I tried to instal the gcc version 3.4.1 compiler on linux 2.6.7 runnin=
g
> on
>  > intel i686.
>  > build of compiler succeeds but the make check fails when running the
>  > .../gcc-3.4.1/boehm-gc/tests/test.c
>  >
>  > test output is
>  > Switched to incremental mode
>  > Emulating dirty bits with mprotect/signals
>  > FAIL: gctest
>  > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  > 1 of 1 tests failed
>  >
>  > If I run the test on a linux 2.4 kernel, the test succeeds.    So I th=
ink
> it
>  > is not a problem in the compiler but perhaps some incompatibility betw=
een
>  > the test program and the newer 2.6 linux.
>  >
>  > I tried debugging a little.  I was able to add GC_printfs to see progr=
ess
> of
>  > the threads and re-compile the test.c.
>  > on 2.4.18:
>  > Switched to incremental mode
>  > Emulating dirty bits with mprotect/signals
>  > thread 4000 entering run_one_test
>  > thread 4002 entering run_one_test
>  > thread 8003 entering run_one_test
>  > thread 4000 leaving run_one_test
>  > thread 4002 leaving run_one_test
>  > thread 8003 leaving run_one_test
>  > Completed 3 tests
>  > Allocated 5716744 collectable objects
>  > Allocated 306 uncollectable objects
>  > Allocated 3750000 atomic objects
>  > Allocated 34440 stubborn objects
>  > Finalized 6613/6613 objects - finalization is probably ok
>  > Total number of bytes allocated is 290418232
>  > Final heap size is 12443648 bytes
>  > Collector appears to work
>  > Completed 462 collections
>  >
>  > on 2.6.7
>  > Switched to incremental mode
>  > Emulating dirty bits with mprotect/signals
>  > thread 4002 entering run_one_test
>  > thread 4000 entering run_one_test
>  > Killed
>  >
>  > I could not find out why the "Killed" not even with gdb.
>  >
>  > Can you help at all with this?     I think there is no problem with my
>  > compiler but would like the testcase to work.
>  >
>  > John
>
> _________________________________________________________________
> Take advantage of powerful junk e-mail filters built on patented Microsof=
t=AE
> SmartScreen Technology.
> http://join.msn.com/?pgmarket=3Den-ca&page=3Dbyoa/prem&xAPID=3D1994&DI=3D=
1034&SU=3Dhttp://hotmail.com/enca&HL=3DMarket_MSNIS_Taglines
>   Start enjoying all the benefits of MSN=AE Premium right now and get the
> first two months FREE*.
>


More information about the Gc mailing list