http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299
--- Comment #12 from Hans Boehm <Hans.Boehm at hp dot com> 2011-04-09 00:22:01 UTC --- The duplicate definition of LINUX_THREADS looks like an old problem. The upstream source now says: #ifndef GC_THREADS # define GC_THREADS #endif /* GC_THREADS */ GC_THREADS eventually results in a definition of GC_LINUX_THREADS . The other failure worries me a bit. It strongly suggests that something was prematurely collected, and put on a free list twice, resulting in a cycle in the free list. This is a common failure mode for such problems. It also looks to me like the actual objects leaked by this benchmark are the ones corresponding to p[0], which should be smaller than 48 bytes. This also suggests at first glance that the so-called leaked object is getting prematurely reclaimed in the failing runs. It might be possible to debug this case by checking (for debugging purposes only) in GC_add_leaked if GC_size(leaked) > 16, and stopping if it is. The checked-in version of threads_leak_test, unlike the upstream version, fails to call GC_INIT(), which may matter on a few platforms. > -----Original Message----- > From: pinskia at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] > Sent: Tuesday, April 05, 2011 5:27 PM > To: Boehm, Hans > Subject: [Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm- > gc.c/thread_leak_test.c > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 > > Andrew Pinski <pinskia at gcc dot gnu.org> changed: > > What |Removed |Added > ----------------------------------------------------------------------- > ----- > Target Milestone|--- |4.7.0 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
