|
From: Bart V. A. <bva...@ac...> - 2012-06-06 13:12:29
|
On 06/06/12 13:01, Christoph Bartoschek wrote: > Am 06.06.2012 14:41, schrieb Bart Van Assche: >> On 06/06/12 07:56, Christoph Bartoschek wrote: >> >>> Am 05.06.2012 20:12, schrieb Christoph Bartoschek: >>>>>> >>>>>> How can this happen? >>>>> >>>>> >>>>> Was that output produced by Valgrind 3.7.0 ? If so, do you get the >>>>> same >>>>> output if you build Valgrind from the SVN trunk ? >>>> >>>> >>>> Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20 >>>> hours. >>> >>> The first errors show up and I see the same problem. A race is reported >>> for memory that has just been allocated and is now filled. >> >> It would help if you could have a look at the assembly code generated by >> the compiler to see if the compiler really calls malloc at that point - >> maybe some header file has redefined malloc such that it allocates >> memory from a memory pool that has not been instrumented for Valgrind. >> Also, which memory allocator are you using ? The one in glibc, tcmalloc >> or even another one ? > > It is just a thin wrapper around glibc malloc. > > at 0x4C2CD6F: malloc (vg_replace_malloc.c:267) > by 0x1D78D377: st_opt_l1_wrap (st_opt_wrap.c:46) > > > indicates that Valgrind sees the malloc call. Please tell us what that wrapper does. Does it e.g. do any caching of recently freed blocks ? Bart. |