RE: [ZODB-Dev] Race condition in basestorage commit locks?

2005-10-07 Thread Tim Peters
[Christian Theune] It looks like we have been bitten by a bug in a C-Module for MySQL access. Sometimes it led to a segfault, a halt, or the hang. We can't reproduce it after switching that C-Module anymore. Any theory for how that could make all four threads appear to be blocked on an attempt

RE: [ZODB-Dev] Race condition in basestorage commit locks?

2005-10-07 Thread Christian Theune
Am Freitag, den 07.10.2005, 14:44 -0400 schrieb Tim Peters: [Christian Theune] It looks like we have been bitten by a bug in a C-Module for MySQL access. Sometimes it led to a segfault, a halt, or the hang. We can't reproduce it after switching that C-Module anymore. Any theory for how

RE: [ZODB-Dev] Race condition in basestorage commit locks?

2005-10-05 Thread Tim Peters
[Christian Theune] this is nasty. We detected a couple of hangs with a Zope 2.7.7 final and (using the DeadlockDebugger) we found this situation in every of the four threads: (See attached file for complete listing of all threads) And there are 4 threads each stuck at

RE: [ZODB-Dev] Race condition in basestorage commit locks?

2005-10-05 Thread Christian Theune
Hi Tim, Am Mittwoch, den 05.10.2005, 13:26 -0400 schrieb Tim Peters: I wouldn't call this a race, because nothing here appears to be timing-dependent. This is the code: Right. I mixed up terminology. Sorry. raises an exception. The code does seem to implicitly assume that neither of those

RE: [ZODB-Dev] Race condition in basestorage commit locks?

2005-10-05 Thread Tim Peters
[Tim] The code does seem to implicitly assume that neither of those _will_ raise an exception, and I agree the commit lock release belongs in the `finally` clause instead. I'll change that, but doubt it will make a difference to you: if either of those did raise an exception, I expect you