svn commit: branches/uClibc-nptl/libc/misc/dirent

Mike Frysinger vapier at gentoo.org
Thu May 15 15:03:00 UTC 2008


On Thursday 15 May 2008, Carmelo AMOROSO wrote:
> Mike Frysinger wrote:
> > On Thursday 15 May 2008, Carmelo AMOROSO wrote:
> >> Mike Frysinger wrote:
> >>> On Thursday 15 May 2008, Carmelo AMOROSO wrote:
> >>>> Mike Frysinger wrote:
> >>>>> On Wednesday 05 December 2007, carmelo at uclibc.org wrote:
> >>>>>> Author: carmelo
> >>>>>> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007)
> >>>>>> New Revision: 20626
> >>>>>>
> >>>>>> Log:
> >>>>>> Fix opendir problem when statically linked due to a missing
> >>>>>> initialization of the mutex field within DIR struct.
> >>>>>> When linked dynamically instead, __pthread_mutex_init will
> >>>>>> initialize the mutex itself. Without this fix, any call to
> >>>>>> readdir will stuck forever trying to acquire the mutex.
> >>>>>
> >>>>> sorry, but i dont follow.  we call __pthread_mutex_init() on the
> >>>>> dd_lock member of the dirent structure which should initialize the
> >>>>> mutex just fine. you cant assume that zeroing the structure is the
> >>>>> same as initializing the mutex.  that is why we have these
> >>>>> initializer functions in the first place. are you suggesting that the
> >>>>> __pthread_mutex_init() function is not doing its job ?
> >>>>
> >>>> yes exactly... but only if statically linked. I suspect that in this
> >>>> case the __pthread_mutex_init is a nop...
> >>>> likely due to weak aliasing... however, glibc does exactly the same
> >>>> call to memset
> >>>> and it uses
> >>>>
> >>>> #ifndef NOT_IN_libc
> >>>>  __libc_lock_init (dirp->lock);
> >>>> #endif
> >>>>
> >>>> instead of  __pthread_mutex_init(&(ptr->dd_lock), NULL);
> >>>
> >>> can you provide a test case ?  i'd like to fix the real problem ...
> >>> adding a memset() just ignores the larger issue with every function
> >>> that does something similar.
> >>
> >> below there is the test used by an our customer that reported the error.
> >> You can simplify it as you like.
> >
> > unfortunately, it isnt hanging for me.  but i'm testing Blackfin here. 
> > if i checkout uClibc trunk at the rev just before your commit and build
> > it for sh4, that should be able to reproduce the issue, right ?  (i have
> > sh4 hardware i can test on).
>
> It should, even if the problem appeared on nptl port, but, from this
> point of view, you know, the code is
> the same. Anyway I have now a uclibc-linuxthreads for my sh4 target, I
> can check it.

if you can verify the hang is still there, i can debug it.  ive been debugging 
pthread issues the last few days, so i dont mind going a bit further.

> >> Anyway, regarding this issue, I was thinking in the past to review the
> >> use of pthread dor locking
> >> within the libc and use instead something like glibc (libc_lock)... any
> >> comments about this ?
> >
> > i'm not terribly familiar with how glibc does internal locking, but i
> > dont see how it'd be any different from the locking we already have with
> > uClibc_mutex.h.  could you elaborate ?
>
> I need to review this... it is something I was looking at times ago.
> Give me some time.

np.  start a new thread once you have something we can meat over :).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/uclibc-cvs/attachments/20080515/300187c2/attachment-0002.pgp 


More information about the uClibc-cvs mailing list