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

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

On Sunday 28 Nov 2021, at 17:30, Mouse wrote:
> > I think it's related to a DNS query, so it might be the max size of a
> > UDP packet?  (then why not 65kB?)
> 
> Because the max UDP packet size is 64k (well, 64k-1 - the length field
> is 16 bits long).

Yes, of course. I was temporarily confused ...

> Interestingly, while 5.2's getaddrinfo() has something very similar (a
> 64k array on the stack), 1.4T's does not.

Yes, it was based on PACKETSZ (with a minimum of 1024) and the commit
message is "allocate 64K recieve buffer for DNS responses".

> > And of course this also raises the stupid question: what should be
> > the minimum stack size of a thread in NetBSD?
> 
> Why should there be any particular minimum?  It seems to me it depends
> on what the thread is doing (though one page, whatever that is on the
> hardware and release in question, is probably a pretty hard minimum).

That's why I said my question is stupid :) If the thread returns
immediately, the minimum is 0 (or PTHREAD_STACK_MIN to account for
libpthread).

However, there is no obvious way to know what the libc is doing, and
how the stack should be sized if one wants to call libc functions. I
was surprised to find that big array, so I was wondering if there was
some informal convention in NetBSD about the libc stack size. 64k is
not small, so I still believe it should be on the heap.

Interestingly, I've been living with this bug in my code for a decade
or so with no visible side effect. It's only now that it cleanly
segfault ...