[ZODB-Dev] new FileStorage pack and POSKeyError

[Tim Peters]

[Paul Winkler]
> OK, sorry i haven't done this sooner.
> I've just now tested on 2 linux boxen; on one a fresh checkout is fine,
> on the other i get a segfault when doing bin/runzope.
>
> A backtrace from gdb is attached, but first let me specify the
> 2 systems:
>
> Box A - runzope works!
> kernel: linux 2.4.20-gentoo-r2
> python: Python 2.2.2 (#1, Apr  9 2003, 02:08:36)
> [GCC 3.2.2] on linux2
> (built by doing "emerge python" on a gentoo system)
>
> summary of "python2.2 testall.py" in /usr/lib/python2.2/test:
> 2 tests failed:
>     test_nis test_sax
> 15 tests skipped:
>     test_al test_cd test_cl test_curses test_dl test_email
>     test_email_codecs test_gl test_imgfile test_socket_ssl
>     test_socketserver test_sunaudiodev test_unicode_file test_winreg
>     test_winsound
> 1 skip unexpected on linux2:
>     test_email
>
>
> Box B - runzope segfaults!
>
> 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)
>
> summary of "python2.2 testall.py" in /usr/local/lib/python2.2/test:
> 1 test failed:
>     test_nis
> 15 tests skipped:
>     test_al test_cd test_cl test_curses test_dl test_email
>     test_email_codecs test_gl test_imgfile test_linuxaudiodev
>     test_socket_ssl test_socketserver test_sunaudiodev test_winreg
>     test_winsound
> 2 skips unexpected on linux2:
>     test_email test_linuxaudiodev

It would be good to get confirmation from someone running the same combo, to
rule out local corruption of some kind.

The top of the stack trace is odd:

"""
    Core was generated by `/usr/local/bin/python2.2 /zope/usr/src/zope-
                                   cvs/Zope/lib/python/Zope/Startup/ru'.
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.