Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 26 Apr 2023 19:57:43 +0200
From:      Felix Palmen <zirias@FreeBSD.org>
To:        freebsd-hackers@FreeBSD.org
Subject:   Thread safety of getaddrinfo()/getnameinfo()
Message-ID:  <invxudjtzhw6bdaf2vuy57ec4herfhn4t4lrcpyardmy2muru5@inwlenyqkzm5>
next in thread | raw e-mail | index | archive | help 

--d4ydqeqillcdqll3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

if I'm not mistaken, POSIX says getaddrinfo() and getnameinfo() should
be thread-safe.

Consider this silly test code:

#v+
#include <netdb.h>
#include <pthread.h>
#include <sys/socket.h>
#include <sys/types.h>

struct data {
    const char *hostname;
    struct addrinfo *res;
};

struct data threaddat[5] =3D {
    { "www.freebsd.org", 0 },
    { "www.google.com", 0 },
    { "www.freshports.org", 0 },
    { "www.github.com", 0 },
    { "www.kernel.org", 0 }
};

pthread_t threads[5];

void *resolve(void *d) {
    struct data *data =3D d;
    getaddrinfo(data->hostname, 0, 0, &data->res);
    return 0;
}

int main(void) {
    int i;
    for (i =3D 0; i < 5; ++i) {
        pthread_create(&threads[i], 0, resolve, &threaddat[i]);
    }
    for (i =3D 0; i < 5; ++i) {
        pthread_join(threads[i], 0);
        freeaddrinfo(threaddat[i].res);
    }
    return 0;
}
#v-

Running it through `valgrind --tool=3Dhelgrind` on 13.2-RELEASE produces
lots of these errors:

#v+
=3D=3D60960=3D=3D Possible data race during write of size 4 at 0x4A757E4 by=
 thread #5
=3D=3D60960=3D=3D Locks held: none
=3D=3D60960=3D=3D    at 0x4993391: __h_errno_set (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x4968F9E: ??? (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x496854E: ??? (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x4978E1C: nsdispatch (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x496694C: ??? (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x49664EA: getaddrinfo (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x201A2E: resolve (resolvtest.c:23)
=3D=3D60960=3D=3D    by 0x485E066: ??? (in /usr/local/libexec/valgrind/vgpr=
eload_helgrind-amd64-freebsd.so)
=3D=3D60960=3D=3D    by 0x4871A79: ??? (in /lib/libthr.so.3)
=3D=3D60960=3D=3D=20
=3D=3D60960=3D=3D This conflicts with a previous write of size 4 by thread =
#6
=3D=3D60960=3D=3D Locks held: none
=3D=3D60960=3D=3D    at 0x4993391: __h_errno_set (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x496841F: ??? (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x4978E1C: nsdispatch (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x496694C: ??? (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x49664EA: getaddrinfo (in /lib/libc.so.7)
=3D=3D60960=3D=3D    by 0x201A2E: resolve (resolvtest.c:23)
=3D=3D60960=3D=3D    by 0x485E066: ??? (in /usr/local/libexec/valgrind/vgpr=
eload_helgrind-amd64-freebsd.so)
=3D=3D60960=3D=3D    by 0x4871A79: ??? (in /lib/libthr.so.3)
=3D=3D60960=3D=3D  Address 0x4a757e4 is 0 bytes inside data symbol "h_errno"
#v-

So, is there a thread-safety issue with these functions, or a bug in
valgrind, or maybe just some false positive?

Thanks, Felix

--=20
 Felix Palmen <zirias@FreeBSD.org>     {private}   felix@palmen-it.de
 -- ports committer (mentee) --            {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

--d4ydqeqillcdqll3
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEABYKAH0WIQRpNhPVW79IN7ISOsxUreAGmHnyMQUCZElmF18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0Njkz
NjEzRDU1QkJGNDgzN0IyMTIzQUNDNTRBREUwMDY5ODc5RjIzMQAKCRBUreAGmHny
MU5LAP41gbmgOQpfy5lmknXtjAtqdkTaXjHTaiP6LSyZoelhIwEA7Xb6tlT40aPg
KdBxVc2eyMNi7hlkFio47Re/tDs3GAA=
=jJP8
-----END PGP SIGNATURE-----

--d4ydqeqillcdqll3--

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?invxudjtzhw6bdaf2vuy57ec4herfhn4t4lrcpyardmy2muru5>