On Thu, 2006-08-24 at 08:01 +0200, Mike Hommey wrote: > On Thu, Aug 24, 2006 at 05:21:33AM +0100, Simon McVittie <[EMAIL PROTECTED]> > wrote: > > I don't know why this affects PowerPC specifically, since it looks like > > a generic problem... > > > > It's "reproducible" on my PowerPC by middle-clicking many links in > > Epiphany to open background tabs (e.g. go to a packages.qa.debian.org > > page and middle-click everything in sight), and causes a hang. My stack > > trace > > matches what Yves-Alexis reported. > > > > It seems that ~nsCacheEntryDescriptor calls the nsCacheEntryDescriptor's > > Close method (frame #9 in Yves-Alexis' stack trace), which takes the > > lock nsCacheService::ServiceLock() before calling > > gService->CloseDescriptor (gService is a global nsCacheService in > > nsCacheService.cpp), passing itself as an argument. This can > > cause *another* nsCacheEntryDescriptor to be released, and if its > > refcount has reached zero, that causes the deletion of that second > > nsCacheEntryDescriptor, causing *its* Close method to be called. When the > > second invocation of Close also tries to take the > > nsCacheService::ServiceLock(), the result is a deadlock. > > > > Downgrading all the binary packages which came from xulrunner's source > > to 1.8.0.4-1 seems to solve the problem; this is weird, since the offending > > cache code doesn't seem to have changed! > > Which make me believe this might be a toolchain problem.
Hmh, yes, but why another "fresh" user on this same box can use epiphany/galeon without problem. I really don't understand this :/ > > What would definitely make it sure it is not the toolchain would be to > rebuild 1.8.0.4-1 with the same toolchain as 1.8.0.5-1 was built with. > (this requires ~2GB diskspace) I tried to rebuild 1.8.0.5-1 but didn't have enough space (and my g3 box seems dead so..) > > If you have more ideas, they are welcome. I don't have a ppc, so i'm > relying on you, reporters ;) I know the problem is on my install (because of the user which can run without problems) and that the problem comes from the futex() call, but really don't know what's happening. The futex() call is like this: futex(0x109acbf0, FUTEX_WAIT, 2, NULL Address appears nowhere before so I guess that's why futex() never returns, but I don't really know why... -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
