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