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, [EMAIL PROTECTED] 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc