More on the armv4l segfault.

[David Daney]

Rob Landley wrote:
> On Thursday 14 December 2006 10:31 pm, Paul Brook wrote:
> 
>>>Ok, the fix is to take weak_function off of __pthread_mutex_unlock in
>>>ulibc_pthread.h.  I have no idea _why_ that fixes it, but it does.
>>>
>>>If the prototype says that __pthread_mutex_unlock() is weak, then
>>>__uclibc_mutex_unlock() never gets called (I've stuck write(2,blah)
>>>commands in it and they don't happen).  Instead I get a segfault on exit. 
>>>But if I take the weak off, then it's called four times (and the call 
> 
> makes
> 
>>>it down to __pthread_return_0().)
>>>
>>>I'm not quite sure what's going on here.  If __pthread_mutex_unlock() is
>>>_not_ prototyped as a weak symbol, _then_ it winds up calling
>>>__pthread_return_0(); I'm confused.  (This is gcc 4.1.1 with binutils 2.17
>>>building for armv4l.)
>>
>>Sounds like something is unconditionally calling __pthread_mutex_unlock() 
>>without making sure it is pulled into the binary (calling a weak symbol that 
>>is not defined will cause a segfault).
> 
> 
> I stuck a write(2,"woot\n",5); in __pthread_return_0(); and when I removed 
> weak_function from __pthread_mutex_unlock() it printed out 4 times at the end 
> of the program.
> 
> It doesn't seem to have anything to do with the printf().  I added a second 
> printf() and they both happened even in the segfault case.  It's something 
> happening after the return 0; from main().
> 
> I tried today's version (svn 16946) and the plain version gave me the 
> segfault, but removing weak_function from __pthread_mutex_unlock() made the 
> segfault go away.  So the fix still applies to svn, I'd just like to know 
> _why_ it's fixing the problem I'm seeing, and why other architectures aren't 
> seeing it.
> 
> If somebody would like my test reproduction sequence, it's based on building 
> everything from source and testing it under qemu.  Later today I'll probably 
> upgrade my build script to use last night's uClibc snapshot with a patch to 
> fix this one issue, and then I can point people at it my thing and go "remove 
> the patch and watch the segfault".

Perhaps you could run the program in gdb and get a stack trace at the 
SIGSEGV to see who the caller is.  Then, as Paul suggested, figure out 
why the proper linking is not happening.

David Daney