[Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 15 Sep 2000 13:21:18 -0700
Bug #111403, was updated on 2000-Aug-08 11:26
Here is a current snapshot of the bug.
Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 1.6b1 dumps core dereferencing a NULL tstate
Details:
This is from an embeded python. I've not yet been
able to reproduce this with a small example. But
perhaps this stacktrace will be of some help. The
problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back.
This pointer is dereferenced in PyFrame_New() later
on which causes the core dump. The documentation
seems to say that PyThreadState_GET() should never
return NULL. So, there must be a bug in there
somewhere. Here is the stack trace:
#0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378,
locals=0x0) at frameobject.c:120
120 PyFrameObject *back = tstate->frame;
(gdb) bt
#0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378,
locals=0x0) at frameobject.c:120
#1 0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0,
args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0,
owner=0x925d2e8) at ceval.c:397
#2 0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0)
at ceval.c:2521
#3 0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0,
kw=0x0) at ceval.c:2359
#4 0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0)
at abstract.c:1370
#5 0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80)
at DrawingArea.C:971
#6 0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027
#7 0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169
#8 0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1)
at ./tclUnixNotfy.c:405
#9 0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444
#10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747
#11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0)
at ./_tkinter.c:1794
#12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0)
at ceval.c:2396
#13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0,
kw=0x0) at ceval.c:2361
#14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0,
args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4,
defcount=1, owner=0x0) at ceval.c:1680
#15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0,
args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0,
defcount=0, owner=0x92c6238) at ceval.c:1579
#16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0,
args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0,
defcount=0, owner=0x0) at ceval.c:1579
#17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038,
locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0) at ceval.c:1579
#18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038,
locals=0x8eb0038) at ceval.c:290
#19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "<string>",
globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885
#20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "<string>",
globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870
#21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n",
start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847
#22 0x867ce4e in PyRun_SimpleString (
command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589
#23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248
#24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30
Mike Romberg (romberg@fsl.noaa.gov)
Follow-Ups:
Date: 2000-Aug-10 10:23
By: none
Comment:
Followup: This only happens when python is built
--with-threads. There appears to be no problem when
threads are not enabled. It should be noted that our
embeded application uses no threads of any kind (python or
pthreads from C++). But it may be the case that our code
(C++) is not doing the right thing.
It should be noted that our application works fine
with python-1.5.2 compiled --with-threads.
-------------------------------------------------------
Date: 2000-Aug-25 07:37
By: jhylton
Comment:
Mike -- Can you provide any more information about this bug?
-------------------------------------------------------
Date: 2000-Aug-25 09:59
By: romberg
Comment:
My guess (and this is just a guess) is that this may have something
to do with the interaction of python threads and Tkinter. Since most of
our embeded (and non threaded) python application works fine except
for one specific area, maybe that is thre problem with python 1.6. Let me
attempt to explain what is going on since it may take some work to
produce a small test case to reproduce the problem.
Our application uses Tkinter for most of the UI. We do open a second
connection to the X server using Xlib. This connection is used to
render complex images into windows. Tkinter's canvas is just not fast
enough. I am getting X events from these Xlib created windows via
the Tcl/Tk FileEventHandler (as seen on the stack trace). I am using the
Tcl/Tk C API to register for these events.
The case which seems to cause the crash in python comes when I get
a ButtonDown event on my second (non Tkinter) Display. This event
is delivered from Tcl/Tk to some of our C++ code. Now for the interesting
bit which I suspect might cause the problem.
Our C++ code then releases the grab and calls into the python interpreter
for it to post a popup menu (using Tkinter). This is seen on the stack
as the most recent PyObject_CallObject(). This code attempts to post
the Tkinter popuip menu but dies trying.
This works fine under python-1.5.2 when it is built --with-thread and
without. It works fine with python-1.6b2 as long as python is built
without threads. But when it is built with threads I get this crash. Is it possible that the Tkinter layer is doing something different threadwise
when python is built --with-threads?
-------------------------------------------------------
Date: 2000-Aug-28 11:28
By: none
Comment:
Another followup. I've compiled python-1.6b1 on HP-UX-10.20 and
linked the whole thing with purify. Purify does not show any errors
and everything runs fine when python is built --without-thread. I was
unable to get python to build on HP-UX --with-thread. I suspect that
this might have something to do with the DCE threads HPUX uses.
But in any case. The extra code linked into our embeded interpreter, is
not doing anything funny with pointers (as far as purify could find).
Mike (romberg@fsl.noaa.gov)
-------------------------------------------------------
Date: 2000-Aug-30 10:46
By: gvanrossum
Comment:
Looks like just another example of HP-UX build problems. (esp. w. threads?)
-------------------------------------------------------
Date: 2000-Aug-30 10:56
By: none
Comment:
Yea. I'm not really interested in the HP platform for use with
threads (they are a mess). I was just using it because that is the
only platform I have access to which can run purify.
The real problem is under linux (redhat-6.2) when threads are
enabled. I just wanted to make sure that there were not any funny
memory problems caused by the python extensions we have
added to our embeded python.
Purify (on HPUX-10.20) seems to give a clean bill of health. So, I'm
guessing that whattever is causing the core dump under linux is
specific to the thread support in python.
-------------------------------------------------------
Date: 2000-Sep-15 11:42
By: jhylton
Comment:
Another question for you Mike: Have you tried your application on RH 6.2 with 2.0b1? Does the problem still exist there? If it is limited to the HP UX platform, which you say you're not actually interested in, I'm going to close this bug report; other people are working on HPUX threading issues.
-------------------------------------------------------
Date: 2000-Sep-15 12:45
By: romberg
Comment:
Yes. I've tried things with both 1.6 (final) and 2.0b1 on RH6.2. For
both versions of python, things work fine as long as --without-thread is
used to build python. The HPUX issue is not really important to me.
I only tried building things on it to use Purify (to verify that there were
no memory related problems with the code). I understand that the threads
on HPUX-10.20 are a real mess. I don't really care much about getting
python threads working on HPUX.
But I would like to use them on linux (so we can use things like Zope).
So, at this time the symptoms are still that things work fine using
python-1.5.2 (with and without threads). But, die when threads are
enabled. None of our code is using any kind of threads (pthreads or
python threads). I'm not using any part of the python C API which
deals with threads (maybe I should now be doing so?). So, the only
thing I can think of is that there is now some kind of thread thing going
on in _tkinter which was not in python-1.5.2. Since the core dump
seems to happen after our C++ code is woken up from a Tcl filehandler and then calls back into python. This is just a guess :).
-------------------------------------------------------
Date: 2000-Sep-15 13:21
By: romberg
Comment:
This bug is about the crash on linux with the threads enabled. The
stack trace comes from a linux system. 2.0b1 crashes with a very
similar looking stack. I probably made a mistake in bringing up the
trouble I was having with the HPUX threads in the discussion of this
linux bug.. If you would like, I could start another bug report. But
it would be more or less the same as this one. The stack trace after
the crash is identical.
I am willing to do some poking around to help figure out what is
going on here. It would probably be helpful to have some more
details about what is going on after the point my code calls PyObject_CallObject(). I could put in some PyObject_Print()s or
something if that would help. I just don't know enough about how
the python internals are supposed to work to know what to do next.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470