On Wed, Oct 25, 2006 at 02:13:04PM +0200, Tim Dijkstra wrote: > Hi, > > I think this related to the following bug report to libc. Symptoms are > really the same apart from the fact that update-menu doesn't use > signals... > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=223110 > > See also red hat bug linked from the libc report, where there is a test > case with a deadlock even without threads. > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90036#c5 > > It boils down to the fact that indeed there is a race in using fork() > and signals to the parent.
Thanks for taking care of that bug! > Now I'm wondering why there're only two people seeing this problem in > update-menus. If it weren't for this fact I would up the severity of > this bug, because it makes it impossible to install new packages which > is pretty severe IMHO. Are you using SMP hardware ? The locking code has not changed since June 2003 so I wonder why problems get reported now. > I'm wondering if this signal business in update-menus is really worth > the trouble. There is only a handful of statements that would want to > print to stdout. It has been working for five years, maybe more. > Wouldn't it be OK to log all the childs output to ``stdoutfile'' > not only after the lock file is created? Probably, but to what purpose ? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
