|
From: Christoph B. <bar...@or...> - 2012-06-05 16:15:26
|
Hi,
I get the following race from DRD:
Conflicting store by thread 7 at 0x55fe8aa0 size 8
by 0x5CCD8750: func() (inv_utils.C:1711)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Address 0x55fe8aa0 is at offset 0 from 0x55fe8aa0. Allocation context:
at 0x4C2BC9D: malloc (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5CCD849F: func() (inv_utils.C:1690)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Other segment start (thread 6)
at 0x4C31712: pthread_spin_lock (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x22C031FD: hunc (bn_thread.C:43)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Other segment end (thread 6)
at 0x4C30EC2: pthread_spin_init (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x22C032AD: hunc (bn_thread.C:47)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
The function func() is in essence:
{
int * data = malloc(100);
for (int i = 0; i != 100; ++i) {
data[i] = 0; <------- Line 1711
}
// Some small calculations
free(data);
}
So I wonder how there can be a data race for writting to data. The
memory has been just allocated and no other thread knows about it.
How can this happen?
Thanks
Christoph
|
|
From: Bart V. A. <bva...@ac...> - 2012-06-05 17:02:05
|
On 06/05/12 16:13, Christoph Bartoschek wrote:
> I get the following race from DRD:
>
> Conflicting store by thread 7 at 0x55fe8aa0 size 8
> by 0x5CCD8750: func() (inv_utils.C:1711)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
> Address 0x55fe8aa0 is at offset 0 from 0x55fe8aa0. Allocation context:
> at 0x4C2BC9D: malloc (in
> /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5CCD849F: func() (inv_utils.C:1690)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
> Other segment start (thread 6)
> at 0x4C31712: pthread_spin_lock (in
> /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x22C031FD: hunc (bn_thread.C:43)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
> Other segment end (thread 6)
> at 0x4C30EC2: pthread_spin_init (in
> /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x22C032AD: hunc (bn_thread.C:47)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
>
>
>
> The function func() is in essence:
>
> {
> int * data = malloc(100);
> for (int i = 0; i != 100; ++i) {
> data[i] = 0; <------- Line 1711
> }
>
> // Some small calculations
>
> free(data);
> }
>
>
> So I wonder how there can be a data race for writting to data. The
> memory has been just allocated and no other thread knows about it.
>
> 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 ?
Bart.
|
|
From: Christoph B. <bar...@or...> - 2012-06-05 18:12:41
|
>> >> 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. Christoph |
|
From: Christoph B. <bar...@or...> - 2012-06-06 07:56:21
|
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.
Is it possible that DRD thinks that the memory still belongs to a
different allocation?
I see also another strange thing:
Other segment end (thread 7)
at 0x4C32042: pthread_spin_init (drd_pthread_intercepts.c:813)
by 0x7A4719: spin_np_t::unlock(legos::spin_np_t*) (legos_spin.C:117)
The line legos_spin.C:117 is:
int rc = pthread_spin_unlock( &s->_spin );
So why is DRD reporting pthread_spin_init?
Thanks
Christoph
|
|
From: Bart V. A. <bva...@ac...> - 2012-06-06 12:41:24
|
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 ? Bart. |
|
From: Christoph B. <bar...@or...> - 2012-06-06 13:01:32
|
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. Christoph |
|
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. |
|
From: Christoph B. <bar...@or...> - 2012-06-06 13:44:18
|
Am 06.06.2012 15:12, schrieb Bart Van Assche:
>> 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 ?
No. It does nothing. I explicitly disabled all advanced memory managers
for the valgrind runs. The active one is now the DefaultMem that calls
malloc directly:
inline void *DefaultMem::alloc(std::size_t size)
{
if( size )
{
void *p = malloc(size);
if( ! p ) BN_XCP_MALLOC(size);
return p;
}
return NULL;
}
inline void DefaultMem::free(void *p, std::size_t size)
{
if( size ) ::free(p);
}
|
|
From: Bart V. A. <bva...@ac...> - 2012-06-06 14:24:23
|
On 06/06/12 13:44, Christoph Bartoschek wrote:
> Am 06.06.2012 15:12, schrieb Bart Van Assche:
>
>>> 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 ?
>
> No. It does nothing. I explicitly disabled all advanced memory managers
> for the valgrind runs. The active one is now the DefaultMem that calls
> malloc directly:
>
> inline void *DefaultMem::alloc(std::size_t size)
> {
> if( size )
> {
> void *p = malloc(size);
> if( ! p ) BN_XCP_MALLOC(size);
> return p;
> }
> return NULL;
> }
>
> inline void DefaultMem::free(void *p, std::size_t size)
> {
> if( size ) ::free(p);
> }
OK, I'll start digging in the DRD implementation. That might take some
time though.
Bart.
|
|
From: Bart V. A. <bva...@ac...> - 2012-06-13 11:43:50
|
On 06/05/12 16:13, Christoph Bartoschek wrote: > So I wonder how there can be a data race for writing to data. The > memory has been just allocated and no other thread knows about it. > > How can this happen? Should have been fixed in r12629. Bart. |