[Gc] Re: Boehm GC on NetBSD 5.1

[Ivan Maidanski]

Hi Bruno,

It (GC_data_start problem) has been fixed already - please checkout code from Git "release" (or "master") branch.

Please retry with fresh snapshot and report whether a problem with threadkey_test still exists.

Regards.

15 -1 2012, 23:08 Bruno Haible <bruno at clisp.org>:
> [Apologies for the previous private mail. I had looked for a bug report
>  address only in the README.QUICK, not at the project page
>  http://www.hpl.hp.com/personal/Hans_Boehm/gc/#contacts
>  Oh, btw. doc/README says to write to Hans Boehm personally...? ]
> 
> Hi,
> 
> Trying to build gc-7.2alpha6.tar.gz on NetBSD 5.1/x86, I get this build
> failure:
> 
> /bin/ksh ./libtool --tag=CC    --mode=compile gcc -DHAVE_CONFIG_H    -I./include -I./include  -I./libatomic_ops/src  -I./libatomic_ops/src -Wall -fexceptions -g -O2 -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c -o os_dep.lo os_dep.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -Wall -fexceptions -g -O2 -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
> os_dep.c:501: error: redefinition of 'GC_data_start'
> os_dep.c:452: error: previous definition of 'GC_data_start' was here
> *** Error code 1
> 
> There are two codes for the same purpose.
> 
> * If I disable the defined(NETBSD) && defined(__ELF__) code, enabling
>   only the SEARCH_FOR_DATA_START code, then *sometimes* all tests pass:
> 
> Completed 6 tests
> Allocated 11991240 collectable objects
> Allocated 1218 uncollectable objects
> Allocated 7500000 atomic objects
> Allocated 137760 stubborn objects
> Finalized 13219/13219 objects - finalization is probably ok
> Total number of bytes allocated is 668700882
> Final heap size is 7360512 bytes
> Collector appears to work
> Completed 862 collections
> PASS: gctest
> Leaked composite object at 0x532eb0 (tests/leak_test.c:19, sz=8, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x533e90 (tests/leak_test.c:19, sz=9, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x533ee0 (tests/leak_test.c:19, sz=10, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x533f30 (tests/leak_test.c:19, sz=11, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x533f80 (tests/leak_test.c:19, sz=12, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x532ef0 (tests/leak_test.c:19, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x532f30 (tests/leak_test.c:19, sz=5, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x532f70 (tests/leak_test.c:19, sz=6, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x532fb0 (tests/leak_test.c:19, sz=7, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> Leaked composite object at 0x532ff0 (tests/leak_test.c:12, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x40095f
> 
> PASS: leaktest
> Final heap size is 131072
> PASS: middletest
> GC_check_heap_block: found smashed heap objects:
>  0x53ffb8 in or near object at 0x53ff90 (tests/smash_test.c:22, sz=40)
>         Caller at allocation:
>                 ##PC##= 0x4008bf
> 
> GC_check_heap_block: found smashed heap objects:
>  0x53ffb8 in or near object at 0x53ff90 (tests/smash_test.c:22, sz=40)
>         Caller at allocation:
>                 ##PC##= 0x4008bf
> 
> GC_check_heap_block: found smashed heap objects:
>  0x5c8cb8 in or near object at 0x5c8c90 (tests/smash_test.c:22, sz=40)
>         Caller at allocation:
>                 ##PC##= 0x4008bf
>  0x53ffb8 in or near object at 0x53ff90 (tests/smash_test.c:22, sz=40)
>         Caller at allocation:
>                 ##PC##= 0x4008bf
> 
> PASS: smashtest
> PASS: hugetest
> PASS: staticrootstest
> Leaked composite object at 0x534ff0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x7f7ffdc1b179
> 
> Leaked composite object at 0x534ef0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x7f7ffdc1b179
> 
> Leaked composite object at 0x534eb0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x7f7ffdc1b179
> 
> Leaked composite object at 0x534ff0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x7f7ffdc1b179
> 
> Leaked composite object at 0x534ef0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
>         Caller at allocation:
>                 ##PC##= 0x7f7ffdc1b179
> 
> PASS: threadleaktest
> PASS: threadkey_test
> PASS: initsecondarythread
> ==================
> All 9 tests passed
> ==================
> 
>   Whereas *sometimes*, the tests hang after 'PASS: threadleaktest', i.e.
>   inside the threadkey_test.
> 
> * If, on the other hand, I disable the SEARCH_FOR_DATA_START code
>   (SEARCH_FOR_DATA_START is defined in include/private/gcconfig.h line 2179)
>   and enable only the defined(NETBSD) && defined(__ELF__) code, then
>   I get a compilation error
> os_dep.c: In function 'GC_register_data_segments':
> os_dep.c:1925: error: 'DATASTART' undeclared (first use in this function)
> 
> What is the right fix? I looked a bit at porting.html, but it looks
> complicated.
> 
> Bruno
> 
>