On Sat, 11 Nov 2006 18:28:13 +0100 <[EMAIL PROTECTED]> wrote: > 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...
I meant threads obviously ... > > > > 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. No it's not SMP. Maybe something has changed in glibc? > > 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 ? To simplify the code and workaround the bug in glibc. I wrote a small patch when I reported this bug. It seems to work, in the sense that I can install packages again, but I haven't really tested it further. I'm really very busy right now. I'll see If I can make some time to look at it again at the end of the week. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
