This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Re: segfaults in MD_FROB_UPDATE_CONTEXT and MD_FALLBACK_FRAME_STATE_FOR


On Tue, Aug 31, 2004 at 05:44:30AM +0200, Jakub Jelinek wrote:
> On Mon, Aug 30, 2004 at 12:04:44PM +0930, Alan Modra wrote:
> > Executive summary:
> > A call to nptl pthread_exit can cause a segfault if a function in a
> > dlclose'd shared lib is somewhere in the pthread_exit call chain.
> > Testcase attached that demonstrates the problem on powerpc64-linux.
> > 
> > My first reaction on seeing the bug report that complained about this
> > problem was "Well, don't do that!", but after properly investigating
> > I'm reasonably convinced this is a real bug.  At least, a target that
> > doesn't use MD_FROB_UPDATE_CONTEXT or MD_FALLBACK_FRAME_STATE_FOR will
> > quite happily work with the testcase.
> 
> I think this is definitely a don't do that situation.
> As pthread_exit must be able to run all cleanups in the backtrace
> which called it, all functions in the backtrace simply must be available
> at the time pthread_exit is called.
> IMHO working around application bugs is not necessary.

Of course, the real application was a little more complicated than the
testcase.  Also, the original bug reporter gave two work-arounds, use of
pthread_join in the master, or setjmp/longjmp in the slaves to collapse
the stack before calling pthread_exit.  ie. plenty of evidence that he
wasn't an incompetent needing help with his app.  I'll quote some things
from the bug report (IBM LTC bugzilla #10704 for those who can access
it):

- begin quote
In our application, this situation can occur during shared library shutdown. 
The library asks each of its threads to shutdown. The threads respond by 
calling a framework function which notifies the waiting thread and then calls 
pthread_exit(). As soon as all slave threads have notified the master, the 
master unloads their shared library. This can happen between the notification 
and the call the pthread_exit(), leading to a situation where pthread_exit() 
is called on a stack which contains frames from unloaded functions.

This pattern is sufficiently common that Win32 actually provides an API for 
this case: FreeLibraryAndExitThread. Implementing an equivalent API for NPTL 
would be difficult, given the current implementation of pthread_exit().
- end quote

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


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