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

Mike Frysinger vapier at gentoo.org
Thu May 15 14:02:58 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 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).

> 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 ?
-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/f974daa3/attachment-0002.pgp 


More information about the uClibc-cvs mailing list