[Idle-dev] Python Core Dump

Kurt B. Kaiser kbk at shore.net
Fri Nov 25 18:16:49 CET 2005

Fuzzyman <fuzzyman at voidspace.org.uk> writes:

> It's quite likely to just be some obscure windows oddity (unless anyone
> else can reproduce this ?). If *possible* I'll try a clean install on
> another machine with XP SP2 and see what happens. (I have to cajole my
> IT admin here to let me).
> I'm quite happy to do this tracking around - but it's up to you how much
> effort you want to put in in following up what is just one bug report.

Thanks, I can't duplicate it.  I'm trying to determine if the symptoms
point to anything that should be fixed.


> The windows crash method is always along the lines of :
>     The instruction "0x10238786" referenced memory at "0x000000c4". The
> memory
>     could not be "read".
> The location of the instruction always varies - but the "0x000000c4" is
> always the same.

That implies a bad memory location, or possibly a bad pointer
somewhere which points to that location.  Also, try loading Word or
something before you load IDLE.

> Other information ( I've copied and pasted your previous questions) :
>> Is there any indication that the subprocess died? (Check your process
>> manager, does the number of Python processes change after the crash?)
> No - two running up until the crash.
> I hit ok on the crash dialog and then both disappear together.
>> Is this Exception reproducible? How long after the crash does it
>> appear?  Are there any other symptoms to the crash?
> Happens the same every time. The exception traceback appears
> immediately I hit Ok on the crash dialog.
>> I gather you never see 'WSAStartup failed' except in this case.
> Never. I normally don't run IDLE from the console though (so wouldn't *see*
> error messages anyway).
>> Is "Got here too." always printed? 
> Yes
>> Does the ImportError always appear?
> I don't see it. The crash happens *before* the open module dialog goes.
>> Does the crash occur before or after clicking "OK" on the exception
>> dialog?
> Exception traceback occurs immediately *after* hitting ok.


>>Ah, the crash occurs while producing the ImportError dialog (which is
>>raised by the very next line of code after your print statement)?
> That's what fiddling with ``open_module`` confirms.
> Code (line 407 in EditorWindow.open_module) :
>         try:
>             print 'Got here'
>             (f, file, (suffix, mode, type)) = _find_module(name)
>             print 'Got here too.'
>         except (NameError, ImportError), msg:
>             print 'Got here three.'
>             tkMessageBox.showerror("Import error", str(msg),
> parent=self.text)
>             print 'Got here four.'
>             return
>        print 'Got here five ?'
> Output :
> C:\Documents and Settings\Voidspace>python C:\Python24\Lib\idlelib\idle.pyw
> Got here
> Got here three.
> Exception in Tkinter callback
> Traceback (most recent call last):
>   File "C:\Python24\lib\lib-tk\Tkinter.py", line 1345, in __call__
>     return self.func(*args)
>   File "C:\Python24\lib\lib-tk\Tkinter.py", line 456, in callit
>     func(*args)
>   File "C:\Python24\lib\idlelib\PyShell.py", line 493, in poll_subprocess
>     response = clt.pollresponse(self.active_seq, wait=0.05)
>   File "C:\Python24\lib\idlelib\rpc.py", line 421, in pollresponse
>     message = self.pollmessage(wait)
>   File "C:\Python24\lib\idlelib\rpc.py", line 373, in pollmessage
>     packet = self.pollpacket(wait)
>   File "C:\Python24\lib\idlelib\rpc.py", line 344, in pollpacket
>     r, w, x = select.select([self.sock.fileno()], [], [], wait)
> error: (10093, 'Either the application has not called WSAStartup, or
> WSAStartup
> failed')
> *However* - If I call tkMessageBox.showerror myself - it works fine (so
> that's not broken on my box).
> EditorWindow.test() seems to fail by the way ? :-)
>>Can you restart the subprocess by using Ctrl-F6 after the crash, or is
>>the GUI completely dead/frozen?
> The GUI is frozen until you hit Ok on the crash dialog - then the GUI
> vanishes.
>>What happens when you run IDLE w/o the subprocess by using the -n switch?
> Ah... crash but no traceback. :-)

OK, so it's likely the traceback is caused by the subprocess complaining
that the socket is no longer being serviced correctly by the dead GUI.
rpc.py is run by both the GUI and the subprocess.

No subprocess, no complaint :-)

If you want to continue playing with this (it can be instructive), I'd
always run IDLE with the -n switch.  Then run IDLE under pdb, with the
-n switch, and set a break in open_module just before the failure.  Step
into the crash and see if anything interesting shows up.  It may be a
Tcl/Tk bug of some kind.

A clean install of Python, IDLE, and Tcl/Tk might solve the problem and
might get you there faster than futzing around with the above suggestion.


More information about the IDLE-dev mailing list