Bug#374834: I think this is a known bug in libc
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]
Bug#374834: I think this is a known bug in libc
On Sat, Nov 11, 2006 at 06:28:13PM +0100, [EMAIL PROTECTED] wrote: > Are you using SMP hardware ? The locking code has not changed since Well, I don't use SMP hardware on the problematic machine. Even more than that: it does only appear on some machines, on others I have never observed this. And as I wrote: on the machines where it appears I'm quite successful in suppressing it by running one or two while true; do bogomips; done loops. That's why I think it's a race problem. > June 2003 so I wonder why problems get reported now. > It has been working for five years, maybe more. Well, to be honest: we (my team and me) notice that since quite a long time (at least 2 years) but since we were never able to reproduce it, we never wrote a bug report for it. I immediately wrote one when I found out how to suppress it at least most of the time :) Mario -- bjmg: ja, logik ist mein fachgebiet. das liegt im gen in welchem? im zweiten X signature.asc Description: Digital signature
Bug#374834: I think this is a known bug in libc
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]
Bug#374834: I think this is a known bug in libc
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. 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. 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. Wouldn't it be OK to log all the childs output to ``stdoutfile'' not only after the lock file is created? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
