[Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate

noreply@sourceforge.net noreply@sourceforge.net
Mon, 28 Aug 2000 09:06:16 -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: None
Priority: 7
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?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470