Re: [Gc] Tests crashing

 Hi Laurent,

About snprinf in cordtest.c - please provide preprocessed code (gcc -I include -E cord/tests/cordtest.c), I don't understand how that could happen neither.

About 'Unexpected heap growth' failure: is it observed on gc 7.4.2 (or master)? We, of course, could increase the limit in test but it is not a good idea to always increase the limit in such cases (because the failure might signal some gc malfunction).

Regards,
Ivan

Wed, 8 Oct 2014 13:05:43 +0000 from Laurent Deniau <[email protected]>:
>Sorry, concerning the 64 bit on MacOSX with Intel (only), one test is failing, but the GC seems to be working…
>
>gc-7.2f$ ./gctest 
>Switched to incremental mode
>Emulating dirty bits with mprotect/signals
>Completed 1 tests
>Allocated 747393 collectable objects
>Allocated 202 uncollectable objects
>Allocated 1250000 atomic objects
>Allocated 21760 stubborn objects
>Finalized 2206/2206 objects - finalization is probably ok
>Total number of bytes allocated is 104880884
>Final heap size is 27082752 bytes
>Unexpected heap growth - collector may be broken (heapsize: 27082752, expected: 25165824)
>Test failed
>Abort trap: 6
>gc-7.2f$ file gctest
>gctest: Mach-O 64-bit executable x86_64
>
>Best,
>Laurent.
>
>On Oct 8, 2014, at 2:54 PM, Laurent Deniau < [email protected] > wrote:
>
>> Dear All,
>> 
>> I have included the gc-7.2d in our physics code about 1.5 years ago and it was running like a charm until recently after an update of the Intel icc compiler to 14.0.4 (gcc 4.9.1 installed) on our MacOSX 10.8.5 server (and my laptop). Now GC_init is crashing with a segfault during a call to __intel_memset according to gdb, but this occurs only in 32 bit mode compiled with Intel icc 14.0.4 on MacOSX. Gcc 32/64 bit and Intel 64 bit work fine on MacOSX as well as all GCC/Intel 32/64 bit combination on Linux and Windows 7. I tried with 7.2d, 7.2f, 7.4.2 from the tarball, and last release from git without success. It's difficult to say if the problem is in the Intel libs (no source…) or in the Gc code. I suspect a memory alignment problem because I successfully triggered some "bus error" from time to time instead of a segfault and Intel __intel_memset uses intensively the SSE instructions set. It is very possible that the bug comes from Intel libs (i.e. 32/64 bit vs selection of SSE instructions set) but I wanted to know if someone else encountered the problem? I attach the output of the libgc compilation using icc and gcc in 32 and 64 bit for crosscheck.
>> 
>> BTW, on 7.4.2 and the git version, I had to correct an invalid selection of snprintf in the Cord test, where snprintf was selected but the buffer size (2nd) argument was discarded (i.e. sprintf-like args), shifting the literal string format to the buf size position and so on. Don't ask me how this can happen considering the defines above…
>> 
>> the warning points line 247 in
>>  https://github.com/ivmai/bdwgc/blob/master/cord/tests/cordtest.c
>> forcing snprintf with correct args works well.
>> 
>> Thanks,
>> Laurent.
>> 
>> --
>> Laurent Deniau			 http://cern.ch/mad
>> Accelerators Beam Physics	 [email protected]
>> CERN, CH-1211 Geneva 23		Tel :  +41 (0) 22 767 4647
>> 
>> <libgc-gnu.out.gz><libgc-intel.out.gz>
>
>--
>Laurent Deniau			 http://cern.ch/mad
>Accelerators Beam Physics	 [email protected]
>CERN, CH-1211 Geneva 23		Tel :  +41 (0) 22 767 4647
>_______________________________________________
>bdwgc mailing list
>[email protected]
>https://lists.opendylan.org/mailman/listinfo/bdwgc

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc