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