stack overflow in getaddrinfo(3) with a small-sized stack in pthreads

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

Hi,

I have a multi-threaded program that segfault in getaddrinfo(3).
To make a long story short, this is the backtrace from gdb:

Thread 3 "" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 14939 of process 14113]
0x00007f7ff5d3af50 in res_queryN (
    name=name@entry=0x7f7ff7e55cb0 "lotus.useless-ficus.net",
    target=target@entry=0x7f7ff7e56320, statp=statp@entry=0x7f7ff7bc8000)
    at /usr/src/lib/libc/net/getaddrinfo.c:2550
2550    {

With libc/net/getaddrinfo.c (libc.so.12.219) from this date:
-rw-r--r--  1 tho  users  68544 Dec  1  2020 net/getaddrinfo.c

The segfault is right upon entering the function, so I though it was a
stack overflow issue. Indeed, this happens in a thread that is created
with a stack size of only 65kB, with pthread_attr_setstacksize(3). If
the stack size is not altered, using the default (what's the default?),
there is no segfault.

I noticed that the res_queryN() function uses a pretty big buffer on
the stack :
	u_char buf[MAXPACKET];
with MAXPACKET being
     #define MAXPACKET	(64*1024)
(all this is from getaddrinfo.c in libc/net)

I've no idea if the buffer of MAXPACKET bytes in getaddrinfo.c has to
be that big, and furthermore on the stack. I think it's related to a
DNS query, so it might be the max size of a UDP packet? (then why not
65kB?). Wouldn't it be better to malloc it, since getaddrinfo does a
lot of malloc anyway?

And of course this also raises the stupid question: what should be the
minimum stack size of a thread in NetBSD? (I first though about
PTHREAD_STACK_MIN but it's probably not relevant here, as from what I
understand this is the minimum stack size required to start a thread,
not the size needed to run the code in it).

Thanks,
Anthony