[ZODB-Dev] new FileStorage pack and POSKeyError

[Dieter Maurer]

Tim Peters wrote at 2003-5-13 15:27 -0400:
 > ...
 > 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
 > """
 > 
 > The duplicate line there is a bit of a mystery.
 > 
 > """
 > #1  0x400ea4b8 in free () from /lib/libc.so.6
 > #2  0x405ef29d in PermissionRole_dealloc (self=0x4051fbf0)
 >     at AccessControl/cAccessControl.c:1536
 > """
 > 
 > PermissionRole_dealloc() is dying here:
 > 
 > static void PermissionRole_dealloc(PermissionRole *self) {
 > 
 > 	Py_XDECREF(self->__name__);
 > 
 > 	Py_XDECREF(self->_p);
 > 
 > 	Py_XDECREF(self->__roles__);
 > 
 > 	Py_XDECREF(self->ob_type);	/* Extensionclass init incref'd */
 > 
 > 	PyMem_DEL(self);  ****** THIS IS THE LINE THAT'S DYING ******
 > }
 > 
 > If self were a bogus pointer, the segfault would have occurred on an earlier
 > line.  Instead it looks very vanilla:  the last reference to an object of
 > this type went away, and that's how we get into an xyz_dealloc() function.
 > PyMem_DEL(self) expands to free(self), and then the platform free() calls
 > the platform pthread_mutex_lock() (presumably to lock its own internal data
 > structures), and pthread_mutex_lock() blows up.
 > 
 > 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.

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.


Dieter