[ZODB-Dev] new FileStorage pack and POSKeyError

[Tim Peters]

[Tim, on the
    Program terminated with signal 11, Segmentation fault.
    #0  0x40033d87 in pthread_mutex_lock () from /lib/libpthread.so.0
    #0  0x40033d87 in pthread_mutex_lock () from /lib/libpthread.so.0
    #1  0x400ea4b8 in free () from /lib/libc.so.6
    #2  0x405ef29d in PermissionRole_dealloc (self=0x4051fbf0)
stack trace]

>> ...
>> This kind of thing is *usually* a bug in the platform thread
>> implementation, or a mismatch between the thread implementation a
>> platform C library was compiled for and the one it actually finds.
>> It's possible that errant C code in Python or Zope is doing a wild
>> store that just happens to corrupt pthread internal storage, but
>> it's not likely.

[Dieter Maurer]
> Not necessarily:
>
>   I have seen similar behaviour for memory corruption of the heap
>   strutures. If the heap uses local locks (rather than a global
>   one) then overwriting heap memory may destroy the lock structure
>   causing SIGSEGV when the structure is accessed.

Sure.  I don't expect that changes anything, though:  (1) there's simply not
enough info in the stack trace to decide the issue; (2) it's still not
likely that errant C code in Python or Zope is doing a wild store that's
scribbling over heap structures; (3) it's still usually a bug in "the
platform" (this kind of thing has come up many times in Python development,
and of those I've seen resolved the ultimate credit most often fell on
gcc -O bugs and mismatching C library pieces); and, (4) it would still be
helpful if someone could independently reproduce the problem under Paul's
configuration, to rule out local problems on his box:

    kernel - Linux  2.4.7-10smp  (red hat)
    python: Python 2.2.2 (#1, Jan 30 2003, 19:06:58)
    [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
    (i built this from the python 2.2.2 source tarball)