[Python-bugs-list] [ python-Bugs-545410 ] corefile: python 2.1.3, zope 2.5.0

noreply@sourceforge.net noreply@sourceforge.net
Wed, 17 Apr 2002 22:44:47 -0700


Bugs item #545410, was opened at 2002-04-18 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Gerrietts (ggerrietts)
Assigned to: Nobody/Anonymous (nobody)
Summary: corefile: python 2.1.3, zope 2.5.0

Initial Comment:
I regularly get a corefile out of Zope 2.5.0, running
on RedHat 6.2 and Python 2.1.3, usually within 5 or 6
page views.

Reproducing the problem requires (for me) starting up
Zope, going to the management interface, and bouncing
around on a few of the different objects. Sometimes the
first attempt to render the page will cause a crash,
but sometimes it takes a few clicks. After the crash,
Zope dumps core and politely restarts itself.

Traceback files are largely the same from one crash to
the next, with the only variation I've noted being the
addresses of variables -- this fits with the fact that
it takes a different number of steps each time.

Traceback files (infuriatingly enough) do not show line
number information for select.so, even though
selectmodule.o was compiled with -g specified.

Examination of the traceback shows that in stack frame
2, print ((PyCFunctionObject *)func) -> m_ml -> ml_name
reveals "select". In that same frame, print ((PyObject
*)arg) -> ob_type -> tp_name yields "Cannot  access
memory at address 0x1f".

One traceback has been provided. Others, and other
info, available on request.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-04-18 07:44

Message:
Logged In: YES 
user_id=21627

In that backtrace, it is clear that arg in stackframe 2 is
bogus: 0x405d7ffc points into an area that appears to be
used for shared libraries (please do "info shared" to
support this theory).

Now, arg presumably is the return value of load_args, where
it was created through PyTuple_New. This suggests that the
memory management got corrupted; something that likely
happened much earlier.

I recommend to set MALLOC_CHECK_ before starting Python. The
documentation in malloc(3) says that setting it to 2 will
cause an abort() when an error is found; from expecting the
implementation, it appears that setting it to 3 will combine
the debug traces printed and the call to abort; please
experiment with all three values (1,2,3).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470