On Tue, Dec 01, 2020 at 01:14:22PM -0800, [email protected] wrote: > On Tue, 1 Dec 2020, Otto Moerbeek wrote: > > On Tue, Dec 01, 2020 at 08:00:18PM +0100, Otto Moerbeek wrote: > > > On Tue, Dec 01, 2020 at 10:13:29AM -0800, [email protected] wrote: > ... > > > The man page is lacking or even wrong in this respect. It explicitly > > > talks about how to do deallocation. > > Yeah, that's a bug in the manpage. > > > > And curiously, if I use 4*PTHREAD_STACK_MIN for both the mmap size arg > > and the pthread_attr_setstack size arg, the crash does not appear. > > Uh, that's like noting that whether a use-after-free crashes depends on > the size of the allocation: it's the UAF that's wrong, the size is > irrelevant.
Of course. I just was curious why it does npt happen with a different size. > > pthread_join() returning merely tells you that the target thread has > gotten far enough into pthread_exit() as to pass its return value to the > joining thread. It still has more cleanup to do before finally entering > the kernel to vanish and there's no standard API to detect when that's > happened. > > I suppose a masochists could use kvm_getprocs() to examine the caller's > own threads, but the real answer is that pthread_attr_setstack() is not > appropriate for threads that will come and go in a long-lived process > where cleanup of the stacks is necessary; for those, if you need to set a > different stack size, use pthread_attr_setstacksize() and let the > implementation handle the allocation and deallocation. > > > Philip >
