This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/19511] 8MB memory leak in pthread_create in case of failure when non-root user changes priority


https://sourceware.org/bugzilla/show_bug.cgi?id=19511

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
SIGCANCEL cannot be lost. The parent in __pthread_initialize_minimal_internal
will setup the handler long before any pthread_create code is run.

I think the simplest solution is actually to make the parent responsible for
the cleanup since it is the owner of the PD after create_thread returns an
error.

So the parent should run pthread_join on PD to reap the stack.

e.g.

682   if (__glibc_unlikely (retval != 0))
683     {
684       /* If thread creation "failed", that might mean that the thread got
685          created and ran a little--short of running user code--but then
686          create_thread cancelled it.  In that case, the thread will do all
687          its own cleanup just like a normal thread exit after a successful
688          creation would do.  */
689 
690       if (thread_ran)
691         assert (pd->stopped_start);

If thread_ran, and !detached, then stopped_start == true, so the user code
can't have run and detached itself, so we are still the owner of PD and can
issue a pthread_join to reap the thread.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]