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:
>
> > On Tue, 1 Dec 2020, Sebastien Marie wrote:
> > > I have a random segfault while using threads with custom stack.
> > >
> > > In short, I am doing:
> > > - allocate a stack space for the thread
> > > - create a thread (with custom stack using pthread_attr_setstack())
> > > - join the thread
> > > - free the allocated stack
> > > - create a new thread, etc...
> > >
> > > If I remove the fact to free the allocate stack once done, it seems
> > > fine (but reach ENOMEM after a while).
> > >
> > > I am suspecting some state corruption or stack reuse, but I can't find
> > > where for now. Or am I doing bad thing and I shouldn't deallocate the
> > > stack at his place ?
> >
> > You should not deallocate the stack. To quote POSIX, XSI 2.9.8:
> >
> >
> > 2.9.8 Use of Application-Managed Thread Stacks
> >
> > An "application-managed thread stack" is a region of memory
> > allocated by the application--or
> > example, memory returned by the malloc() or mmap() functions--and
> > designated as a stack
> > through the act of passing the address and size of the stack,
> > respectively, as the stackaddr and
> > stacksize arguments to pthread_attr_setstack(). Application-managed
> > stacks allow the application
> > to precisely control the placement and size of a stack.
> >
> > The application grants to the implementation permanent ownership of
> > and control over the
> > application-managed stack when the attributes object in which the
> > stack or stackaddr attribute has
> > been set is used, either by presenting that attribute's object as
> > the attr argument in a call to
> > pthread_create() that completes successfully, or by storing a
> > pointer to the attributes object in the
> > sigev_notify_attributes member of a struct sigevent and passing that
> > struct sigevent to a function
> > accepting such argument that completes successfully. The application
> > may thereafter utilize the
> > memory within the stack only within the normal context of stack
> > usage within or properly
> > synchronized with a thread that has been scheduled by the
> > implementation with stack pointer
> > value(s) that are within the range of that stack. In particular, the
> > region of memory cannot be
> > freed, nor can it be later specified as the stack for another thread.
> >
> >
> > Note that last sentence.
> >
> >
> > Philip Guenther
> >
>
> The man page is lacking or even wrong in this respect. It explicitly
> talks about how to do deallocation.
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.
-Otto
