getaddrinfo thread-safe?

[Joshua Rogers]

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/>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-help/attachments/20150323/b952d02f/attachment.sig>