Re: getaddrinfo thread-safe?

[Joshua Rogers <glibc at internot dot info>]

On 24/03/15 07:05, Joshua Rogers wrote:
> 'lock' was fired read here:
> ==30720==    by 0x6030486: _nss_files_gethostbyname3_r (files-hosts.c:127)
>
>
> It was then subsequently read here:
> ==30720==    by 0x4C30E75: ??? (in
> /usr/lib/valgrind/vgpreload_drd-amd64-linux.so)
>
>
> This is probably a bug in valgrind.
No, it's not.

http://pastebin.com/Lyt4gdjK
From http://valgrind.org/docs/manual/drd-manual.html#drd-manual.data-races:

"     Start at the bottom of both call stacks, and count the number
stack frames with identical function name, file name and line number. In
the above example the three bottommost frames are identical (clone,
start_thread and vg_thread_wrapper)."


" The next higher stack frame in both call stacks now tells you between
in which source code region the other memory access happened. The above
output tells that the other memory access involved in the data race
happened between source code lines 28 and 30 in file rwlock_race.c. "

So,
==30769==    by 0xA839486: _nss_files_gethostbyname3_r (files-hosts.c:127)
accesses 'lock

Then, somewhere between
==30769==    by 0x401434D: _dl_open (dl-open.c:613)
and
==30769==    by 0x40143BA: _dl_open (dl-open.c:661)
somethings loads the memory that holds 'lock'.

I'm going to guess it's this:
          __rtld_lock_unlock_recursive (GL(dl_load_lock));


Each run gives me new/different errors(of course), but after a few runs
they all start to re-appear.

I will continue to look through the others.



between..
==30769==    by 0x401434D: _dl_open (dl-open.c:613)


-- 
-- Joshua Rogers <https://internot.info/>

Attachment: signature.asc
Description: OpenPGP digital signature