[issue10909] thread hang, possibly related to print
New submission from Scott M : New to Python; be gentle if I've simply missed something. i'M running on Windows XP, using a recently downloaded 2.7.1. I'm running by hitting F5 in IDLE. The attached .py creates 2 threads, one which updates a Tkinter label 10 times a second forever, and one which sleeps for a second and then thrashes the CPU for ~4 seconds, forever. I wrote this to see how Python dealt with CPU-pig threads, and was pleased to see both threads got to run in a decently interleaved way, even in the face of a tight loop. But at a random point, one of the threads (which one varies) stops running. The other continues fine. The problem manifests in less then 5 minutes (often less than 1). At least once, but not ever time, the thread that stopped gave a traceback: Exception in thread Thread-1: Traceback (most recent call last): File "D:\Python27\lib\threading.py", line 530, in __bootstrap_inner self.run() File "F:\Python27\MyProjects\e.py", line 24, in run print "evil!" #<--- point 1 File "D:\Python27\lib\idlelib\rpc.py", line 595, in __call__ value = self.sockio.remotecall(self.oid, self.name, args, kwargs) File "D:\Python27\lib\idlelib\rpc.py", line 211, in remotecall return self.asyncreturn(seq) File "D:\Python27\lib\idlelib\rpc.py", line 240, in asyncreturn response = self.getresponse(seq, wait=0.05) File "D:\Python27\lib\idlelib\rpc.py", line 280, in getresponse response = self._getresponse(myseq, wait) File "D:\Python27\lib\idlelib\rpc.py", line 305, in _getresponse cvar = self.cvars[myseq] KeyError: 8680 BUT in some cases there wasn't a traceback (the last time there wasn't, it was BThread that had stopped running; the label was no longer updating.) If you comment out the print at point 2, or point 1, it seems to work fine, at least for as long as I cared to watch it. Also, I've noticed that if I close the app's window, that at least one thread keeps running and writing to the Python shell console. (One generally dies because the Tkinter label has gone away). They are both marked as daemonic; shouldn't they stop more or less instantly? -- components: Interpreter Core files: e.py messages: 126282 nosy: PythonInTheGrass priority: normal severity: normal status: open title: thread hang, possibly related to print type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file20409/e.py ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
Scott M added the comment: It hasn't failed yet when run "straight". Here's the issue, though. I'm going to be introducing Python as the scripting language of choice, to a bunch of people who are less than fluent in programming. Because debugging is not an obvious concept to them, they are going to hunt for problems by sticking in print statements everywhere, and the environment is inherently multithreaded, so it's hard for me to imagine they won't experience this bug. I hit it in my very first multithreaded experiment. And I can't possibly ask them not to use IDLE - without syntax coloring and a friendly editor to show them which line is wrong, they will never get off the ground. It would be tolerable if there was at least a traceback, but if threads vanish silently, they will not realize it's a environment problem; they will either assume that they did something inexplicably wrong and that "scripting is too hard", or it will get around that I provided a "broken" solution. So even if it's "just the IDE", it's still life and death for this project. "Won't fix" probably means I have to abandon Python. -- ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
Scott M added the comment: Moving to 3.x means redoing large swaths of the extension I just wrote. It's only a couple thousand lines, but it was my first extension and it cost me a week of my life in Google, and it does a lot with strings. I haven't pulled down the source code for Python's internals yet, but from the one trace back I did get in the failing thread test app, the problem was inside print and it looked like it was inside the mechanism where print gets redirected. I hope the problem isn't anything as fundamental as the GIL, because that throws the stability of all of 2.7 into question (and it's been solid in all my tests; I do a lot with threads in my extension, all going after the GIL and diving into Python code.) -- ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
New submission from Scott M :
Running on dual core Windows XP.
The function should draw a parabolicish shape for each click on launch. But if
you click Launch over and over, very fast, you get bizarre crashes instead:
Python.exe has encoutered a problem, yadda. tcl85.dll. It rarely takes many
clicks.
Apologies for the coding style; this has been hacked down from a larger app.
In the console window:
Exception in thread Thread-5:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
self.app.arrival_122((self.target, y, z))
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 100, in arrival_122
self.label.config(text= str(message[0])+ " " + str(message[1]))
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1202, in configure
return self._configure('configure', cnf, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1193, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: invalid command name "source C:/Python27/tcl/tk8.5/menu.tcl"
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
self.app.arrival_122((self.target, y, z))
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 125, in arrival_122
self.graph.create_line(self.trackCoordinates[tn], new_yz)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: invalid command name "line"
Also saw:
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: bad option "665.44997": must be addtag, bbox, bind, canvasx,
canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus,
gettags, icursor, index, insert, itemcget, itemconfigure, lower, move,
postscript, raise, scale, scan, select, type, xview, or yview
--
components: Tkinter
files: TkinterCrash.py
messages: 127201
nosy: PythonInTheGrass
priority: normal
severity: normal
status: open
title: Crash, 2.7.1, Tkinter and threads and line drawing
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20549/TkinterCrash.py
___
Python tracker
<http://bugs.python.org/issue11029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment: To make this more interesting, I'm trying to push for adoption of Python at a scripting tool where I work, and I uncovered this crasher in example code I was about to hand out, under the heading of "look how easy Python is". For obvious reasons I'm holding off on handing out the example; I won't get far selling Python if it crashes when drawing lines... if this is a result of something boneheaded I did, please slap me upside the head ASAP. Conversely if there's a quick fix possible, that will speed Python adoption where I work... thanks. -- ___ Python tracker <http://bugs.python.org/issue11029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment:
OK, now all calls to Tkinter are funneled to a single thread, through a queue.
(Technically there are two threads in Tkinter - one is parked in .mainloop(),
the other makes a call to Canvas.create_line and a call to Label.config.)
Different crash, but still a crash. This one seems to be mostly consistent; see
below and new attached code.
If you're going to tell me that Tkinter simply can never be called by any
thread other than the one animating mainloop - in other words, Tkinter calls
are only safe within Tkinter callbacks like a Button's command function - then
please suggest an alternative library that is sturdier. There's nothing I can
do about the fact that multiple threads produce independent data that has to go
onto a single graph.
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and
Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py", line 68, in run
self.graph.create_line(element[0], element[1], element[2], element[3])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
ValueError: invalid literal for int() with base 10: 'None'
But once I got:
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and
Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash2.py", line 68, in run
self.graph.create_line(element[0], element[1], element[2], element[3])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: can not find channel named "Nonefile13cad48"
--
Added file: http://bugs.python.org/file20576/TkinterCrash2.py
___
Python tracker
<http://bugs.python.org/issue11029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment: Alright. More digging turned up the Tkinter "after" function, aka WM_TIMER for Windowy people like me, and that plus a nonblocking queue get() gets all my drawing operations back into the mainLoop() thread. Voilà, no more crashes. Let me suggest that page one, sentence one of any Tkinter documentation should begin "Tkinter is not thread safe", with a link to an example of after() and nonblocking get(). I've changed the component to Documentation. This would save a few days for poor sods like me -- I'm used to low level Windows C++ GUI work, where any thread can call any SDK function at any time, and Windows sorts it all out. Having to force everything into a single thread, and then poll for my data (*GAG*), is something I thought died in the 80's. Is anyone looking at thread safe GUI libraries? -- assignee: -> docs@python components: +Documentation -Tkinter nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue11029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe. This is a bug.
New submission from Scott M : The more I look at GUI support in Python, the more I realize that the lack of basic thread safety in GUI support is simply a bug. I know Java's Swing has the same thread limitation, but that doesn't make it right. Xlib is thread safe. The Windows SDK is thread safe. Python is supposed to be the language that's easy to use, and there is nothing easy about teaching new programmers that they have to mess with queues and timers just to get a basic set of displays running, just because when threads are in use. I'm in the position of teaching folk with little-to-no programming experience, how to script simple applications in Python. The modules they have to use are inherently threaded, and delivery hunks of data from multiple sources to them. The most natural instinct is to put up some graphs and other widgits to display the data, and all of it is completely trivial right up until I have to explain that drawing a line isn't canvas.line(from, to), but becomes an exercise in Queue.Queue and theRoot.after(n, myself), before you even get to learn about widgits. Threading is supposed to simplify problems, not add to them. Having to hack around with special timers and polling, just to get some simple graphs up, is plain unpythonic. Please consider this a bug, a glaring misfeature, in a language that is otherwise a very reasonable choice to get technical but non-programmerish people into toolmaking self-sufficiency. -- components: Tkinter messages: 127604 nosy: PythonInTheGrass priority: normal severity: normal status: open title: Tkinter is not thread safe. This is a bug. type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe (and that's... bad)
Scott M added the comment: I don't have an opinion on 1252236. I'm not certain it would help. I have an extension that runs a bunch of (alien) threads into Python code. The threads deliver information for all sorts of real world events, asynchronously. Multiple threads are used, because people occasionally want to do blocking operations in these alien threads, but still want to be able to handle other incoming information at full speed, with the other threads. If any of these threads attempts to update a Tkinter widgit - and this is the first thing I tried to do - then tkinter will except or crash in some horrible way, sooner or later. The attached .py (in Python 2.7.1) does it without any extensions. Click on Launch quickly 10-15 times; if it doesn't crash, kill and restart. It rarely takes more than 4-5 runs to get a traceback, or occasionally python itself just crashes. Bottom line, one thread in .mainloop() and another thread calling virtually any Tkinter function, even something as simple as .after(), is an invitation a crash. -- title: Tkinter is not thread safe -> Tkinter is not thread safe (and that's... bad) Added file: http://bugs.python.org/file20630/TkinterCrash2.py ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment: I'll look into making the crash easier to reproduce this coming week. Is Tkinter's thread safety new? Because after I started getting crashes, I did my due diligence in Google and found a number of people writing about how it was necessary to use a Queue and Tkinter's after() timer, to draw from multiple threads. And in experiments in 2.7.1 on Windows, it turned out that it wasn't just the drawing calls from a thread other than the mainloop() thread, that invited a crash; even just trying to set an .after() timer from a different thread caused tracebacks, randomly. At any rate this is less of an issue now, for me at least. I'm putting together a small graphic library for my coworkers. It will have a tiny fraction of Tkinter's capabilities, it will be Windows-only and won't even have native Windows look and feel; but it will be completely, rock-solid, idiot-proof thread safe - any operation (including widget deletes), any thread, any time, with no polling or timers needed. My coworkers are not technical and will get instantly lost if I have to describe queues and timers just to draw a line on a screen. -- ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment:
The new version runs 40 parabolas, then quits. I usually have to run this
version 20 times or so to get the crash, so be patient. In general if it's
going to crash it does so in the first 6 or so parabolas. Caveat: creates up to
40 threads, so a bit of a CPU pig. You may want to change the 40 in
(self.tracks > 40) to 8.
Here's one crash. I got this by double clicking the .py file from Windows
explorer, but I can get them with F5 in IDLE too.
---
UpdateStringProc should not be invoked for type cmdName
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Exception in thread Thread-6:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "H:\PMT2\MyProjects\TkinterCrash2.py", line 47, in run
self.deliverToQueue((self.target, z, y))
File "H:\PMT2\MyProjects\TkinterCrash2.py", line 129, in arrival_122
new_yz[1])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: bad screen distance "create"
--
versions: +Python 2.7 -Python 3.3
Added file: http://bugs.python.org/file20684/TkinterCrash2.py
___
Python tracker
<http://bugs.python.org/issue11077>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment: If it helps, over the many iterations of this test code, there have been two kinds of issues: 1. pythonw.exe crashes with the Windows variant of a SEGV. No traceback, just a crash. These are rare. 2. Evidence of confusion over which string the code should be looking at, and it's always down in the create function of Tkinter. Variations of this confusion have been Int() complaining that it can't translate "None", strings like ".667748474.7464" not being recognized as parameter names... all of it sounds like Tkinter has somehow managed to be looking at the wrong string. Even when the only Tkinter call I do outside the mainloop thread is .after(), the crashes would happen when I went to draw a line. My (trivial) experience in extending Python makes me wonder if some reference count, somewhere, didn’t get mismanaged. The only times I ever got a hard crash out pythonw.exe in my own projects is when I mishandled a count. As a side note, if Tkinter is intended to be thread safe, the documentation should say so. Clearly, and in the first paragraph. Once I started having problems, I started Googling, and everything I read lead me to conclude that neither Tkinter nor wx were even intended to be thread safe, so I've started to write my own GUI code. This is a project I might have skipped if it has been clear that Tkinter is at least intended to be thread safe. -- ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33257] Race conditions in Tkinter with non-threaded Tcl
Change by Scott M : -- nosy: +PythonInTheGrass ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33257] Race conditions in Tkinter with non-threaded Tcl
Scott M added the comment: 7 years and counting... My need for a fix is long gone, but I'd like to be able to tell the original group I worked with whether it's now safe to use tkinter from threads. It looks like my original guesses were validated and a fix has been made, but I can't tell if it's universally available. What version of Python would they need to be on, and are any platforms still misbehaved "out of the box"? They will not be willing to rebuild python itself. TIA. -- ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
