7eb
Subj : Re: pthread_mutex_lock -> sem_unlink -> pthread_create?
To   : comp.programming.threads
From : David Butenhof
Date : Tue Jun 21 2005 02:06 pm

usenet@electricwords.org wrote:

> #0  0x4166da35 in pthread_getconcurrency () from
> /lib/i686/libpthread.so.0
> #1  0x4166cdb8 in pthread_create () from /lib/i686/libpthread.so.0
> #2  0x4166f210 in sem_unlink () from /lib/i686/libpthread.so.0
> #3  0x4166bd77 in pthread_mutex_lock () from /lib/i686/libpthread.so.0

My first nearly random guess is that your stack trace is bad. For 
example, you might have no symbols for private entry points in the 
libpthread, and the symbolizer is presuming any PC is within the scope 
of a fantasy routine bounded by the previous and next visible symbols. 
That is, "pthread_create" might be some PC in a local routine that 
happens to have an address higher than pthread_create but lower than the 
next retained symbol.

Of course, if you're "creating lots of threads", it's conceivable that 
the trace is correct regardless of the fact that it makes no sense at 
all. In which case you may have a rare stack corruption bug that managed 
to trash a stack frame's RETURN address so that it returned into random 
code, did something unexpected, and got progressively worse. This is not 
unknown -- but the chances of a random stack corrupter (itself a fairly 
common threaded application bug) resulting in functional return 
addresses (e.g., to executable code that at least to the hardware makes 
some sort of "sense") is fairly slim.

Although I've never looked at the code I feel fairly confident that both 
Linuxthreads and NPTL are highly unlikely to create a thread as part of 
removing a semaphore in order to implement a mutex lock. I think we can 
just rule that one right out.

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

.

0