More on the armv4l segfault.

[Joakim Tjernlund]

> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Rob Landley
> Sent: den 15 december 2006 16:16
> To: Paul Brook
> Cc: uclibc at uclibc.org
> Subject: Re: More on the armv4l segfault.
> 
> 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".
 
Rob, found this link that might explain your problem:
 http://sourceware.org/ml/binutils/2005-10/msg00107.html

 Jocke