Python/Tkinter crash.

[Hendrik van Rooyen]

Hi,

I get the following:

hvr@LINUXBOXMicrocorp:~/Controller/lib> python display.py
UpdateStringProc should not be invoked for type font
Aborted

and I am back at the bash prompt - this is most frustrating, as there is no
friendly traceback to help me guess where its coming from.

And what is worse, the script runs for a varying time before it simply exits
like this.

What can I do to dig deeper to try to find a clue? - I don't even know if its
Python, Tkinter or Linux...

Some background:

The application is a prototype gui for a controller of an injection moulding
machine.
It has two rows of five buttons across the top, and a canvas containing various
objects over the rest of the screen.
Extensive use is made of configure to change the text of the buttons, as well as
their command bindings,
to keep "the state of the system" current - its quite a hack at this time, as I
am still experimenting with getting the interface intuitive.
On the canvas, there are multiple instances of a Meter class to show things like
temperatures and pressures,
as well as a schematic representation of the machine, created out of polygons
and lines.
The schematic, as well as the Meters, are crudely animated by deleting and
redrawing the objects repetitively with slightly different parameters in
response to button presses. This is done by starting different threads to
implement the various motions, which repetitively call kill and draw methods in
the main app, after which they (the threads) commit seppoku by returning.

Everything seems to work fine. - there is a thread that runs to move the meter
values around continuously, and this has been stable for some time now, and I
can get the various "machine" parts to move around the screen by pushing the
buttons.
The trouble occurs when I put the "machine" into Auto mode, simulating the
various motions in a loop, - it runs for anything from a few tens to a few
hundreds of cycles before handing in its dinner pail like this.

Any Ideas on what to do next to find the culprit?

- Hendrik

 

[James Stroud]

Hi,

I get the following:

hvr@LINUXBOXMicrocorp:~/Controller/lib> python display.py
UpdateStringProc should not be invoked for type font
Aborted

and I am back at the bash prompt - this is most frustrating, as there is no
friendly traceback to help me guess where its coming from.

And what is worse, the script runs for a varying time before it simply exits
like this.

What can I do to dig deeper to try to find a clue? - I don't even know if its
Python, Tkinter or Linux...

Some background:

The application is a prototype gui for a controller of an injection moulding
machine.
It has two rows of five buttons across the top, and a canvas containing various
objects over the rest of the screen.
Extensive use is made of configure to change the text of the buttons, as well as
their command bindings,
to keep "the state of the system" current - its quite a hack at this time, as I
am still experimenting with getting the interface intuitive.
On the canvas, there are multiple instances of a Meter class to show things like
temperatures and pressures,
as well as a schematic representation of the machine, created out of polygons
and lines.
The schematic, as well as the Meters, are crudely animated by deleting and
redrawing the objects repetitively with slightly different parameters in
response to button presses. This is done by starting different threads to
implement the various motions, which repetitively call kill and draw methods in
the main app, after which they (the threads) commit seppoku by returning.

Everything seems to work fine. - there is a thread that runs to move the meter
values around continuously, and this has been stable for some time now, and I
can get the various "machine" parts to move around the screen by pushing the
buttons.
The trouble occurs when I put the "machine" into Auto mode, simulating the
various motions in a loop, - it runs for anything from a few tens to a few
hundreds of cycles before handing in its dinner pail like this.

Any Ideas on what to do next to find the culprit?

- Hendrik

Minimal source code to reproduce this error would help tremendously.

 

[Hendrik van Rooyen]

Minimal source code to reproduce this error would help tremendously.

I was hoping for some advice as to how to choose the broken stuff out of the
approximately 1400 lines of code - what do I keep in, and what do I leave out -
If I knew in which area the thing was cracking up, or if I could form a theory
of why it is breaking, I could choose better, and maybe reproduce it - as it is,
to produce the strace that I submitted took most of the morning, and I am
frankly no further along the road...

- Hendrik

 

[Eric Brunel]

Hi,

I get the following:

hvr@LINUXBOXMicrocorp:~/Controller/lib> python display.py
UpdateStringProc should not be invoked for type font
Aborted

and I am back at the bash prompt - this is most frustrating, as there is
no
friendly traceback to help me guess where its coming from.

And what is worse, the script runs for a varying time before it simply
exits
like this.

What can I do to dig deeper to try to find a clue? - I don't even know
if its
Python, Tkinter or Linux...

Neither of them: it's a tcl problem. The message you get is in the file
generic/tclObj.c in the tcl source directory.

I know the problem happens sometimes on one of my Tkinter applications,
but I never succeeded in reproducing it systematically. I've browsed the
tcl bugs, but didn't find anything. Maybe you'll be luckier than I... If
you are, I'm interested in any hint you can find.

 

[Hendrik van Rooyen]

Neither of them: it's a tcl problem. The message you get is in the file
generic/tclObj.c in the tcl source directory.

I know the problem happens sometimes on one of my Tkinter applications,
but I never succeeded in reproducing it systematically. I've browsed the
tcl bugs, but didn't find anything. Maybe you'll be luckier than I... If
you are, I'm interested in any hint you can find.

Ouch! - this is a bit the wrong answer...

What I have seen, in mucking about today, is that it seems to be related to
threading - I have a silly sort of thread that runs, updating my meters, more or
less continuously, to simulate data from the field - it just adds some values to
the seven display variables and calls the update methods that delete and redraw
the arcs representing the analogue style meters, deleting and replacing the text
objects that show the values, and then it sleeps for a while, and does it all
again.

At the same time, one other thread (other than the main thread), can be created
to move a component on the canvas around by calling its delete and draw
methods. - but this is also done more or less continuously, as a new thread is
created as soon as the previous one dies to move the next object around.

Now these two things are asynchronous with each other, so that given enough
time, they are bound to make calls to Tkinter in a re-entrant fashion, and I
suspect that it is this that is causing the problem - my "evidence" for this is
that I implemented a boolean as a sort of "lock" and had the Meter updating back
down in favour of the other animation to try and avoid any sort of re - entrancy
to the Tkinter canvas object's delete and draw methods...

Now the Jury is still out on this - it seems to have helped, as the thing has
been running for some hours now without crashing - but maybe I have just applied
a band aid to sword cut - I don't know - if it runs through the night I will
feel much better...

Will update again as soon as I have more data...

- Hendrik

 

[Russell E. Owen]

Hi,

I get the following:

hvr@LINUXBOXMicrocorp:~/Controller/lib> python display.py
UpdateStringProc should not be invoked for type font
Aborted
...
Everything seems to work fine. - there is a thread that runs to move the meter
values around continuously, and this has been stable for some time now, and I
can get the various "machine" parts to move around the screen by pushing the
buttons...

You mention threads several times in your posting. Do you have multiple
threads talking to Tkinter? If so, try recoding to avoid this (e.g. by
having the background threads communicate with the main thread via
Queues).

-- Russell

 

[Hendrik van Rooyen]

You mention threads several times in your posting. Do you have multiple
threads talking to Tkinter? If so, try recoding to avoid this (e.g. by
having the background threads communicate with the main thread via
Queues).

-- Russell

I am not sure how to do this - once I have called the Tkinter mainloop - that
main thread is essentially event driven - and figuring out how to get it to poll
a queue for content is not obvious - I suppose I could arrange some external
wake up event that I could activate to make it look at the queue - must read up
on this...

Thanks it is a good idea as it will make the interface cleaner, and as I have to
sort out inter process communication anyway it will make sense to also use a
queueing mechanism between the threads in this display process.

There is already one queue defined - but its a hack as I use it to pass the main
threads id to get around the problem of referring to a class before its
defined...

- Hendrik

 

[Eric Brunel]

Ouch! - this is a bit the wrong answer...

Sorry for that. I realize I wasn't very helpful, here...

What I have seen, in mucking about today, is that it seems to be related
to
threading - I have a silly sort of thread that runs, updating my meters,
more or
less continuously, to simulate data from the field - it just adds some
values to
the seven display variables and calls the update methods that delete and
redraw
the arcs representing the analogue style meters, deleting and replacing
the text
objects that show the values, and then it sleeps for a while, and does
it all
again.

At the same time, one other thread (other than the main thread), can be
created
to move a component on the canvas around by calling its delete and draw
methods. - but this is also done more or less continuously, as a new
thread is
created as soon as the previous one dies to move the next object around.

Now these two things are asynchronous with each other, so that given
enough
time, they are bound to make calls to Tkinter in a re-entrant fashion,
and I
suspect that it is this that is causing the problem - my "evidence" for
this is
that I implemented a boolean as a sort of "lock" and had the Meter
updating back
down in favour of the other animation to try and avoid any sort of re -
entrancy
to the Tkinter canvas object's delete and draw methods...

AFAIK, Tkinter is not thread safe. Using some kind of lock to serialize
the calls from different threads may seem to work (I never tested it
actually), but the safest way I found to use threads with Tkinter was to
call it only from the thread where the main loop executes. The only thing
that seems to work reliably in secondary threads is to generate custom
events (widget.event_generate('<<MyCustomEvent>>', when='tail')), and to
treat them in Tkinter's thread via bindings
(widget.bind('<<MyCustomEvent>>', treatment_command)). This makes things a
bit messy, but it works quite well.

Now, as I said before, someone reported that he *did* get the error you
got from time to time. So maybe the problem I have is not the same as
yours, or maybe there are some cases in my application where Tkinter stuff
still gets called directly from secondary threads. I'll try to investigate
that when I've time and I'll keep you informed.

HTH a little this time...

 

[Fredrik Lundh]

AFAIK, Tkinter is not thread safe. Using some kind of lock to serialize
the calls from different threads may seem to work (I never tested it
actually), but the safest way I found to use threads with Tkinter was to
call it only from the thread where the main loop executes.

the Tkinter binding contains some code that attempts to deal with re-
entrant calls, but I don't know/remember to what extent it's actually
supposed to work (in other words, if the observed problems are bugs or
just limitations).

(maybe Martin's memory is better?)

anyway, I usually play it safe and make sure to use a single thread to
deal with the UI.

</F>

 

[Hendrik van Rooyen]

Ouch! - this is a bit the wrong answer...

What I have seen, in mucking about today, is that it seems to be related to
threading - I have a silly sort of thread that runs, updating my meters, more or
less continuously, to simulate data from the field - it just adds some values to
the seven display variables and calls the update methods that delete and redraw
the arcs representing the analogue style meters, deleting and replacing the text
objects that show the values, and then it sleeps for a while, and does it all
again.

At the same time, one other thread (other than the main thread), can be created
to move a component on the canvas around by calling its delete and draw
methods. - but this is also done more or less continuously, as a new thread is
created as soon as the previous one dies to move the next object around.

Now these two things are asynchronous with each other, so that given enough
time, they are bound to make calls to Tkinter in a re-entrant fashion, and I
suspect that it is this that is causing the problem - my "evidence" for this is
that I implemented a boolean as a sort of "lock" and had the Meter updating back
down in favour of the other animation to try and avoid any sort of re - entrancy
to the Tkinter canvas object's delete and draw methods...

Now the Jury is still out on this - it seems to have helped, as the thing has
been running for some hours now without crashing - but maybe I have just applied
a band aid to sword cut - I don't know - if it runs through the night I will
feel much better...

Will update again as soon as I have more data...

OK - It has run through the night and as I type it is still running, so the band
aid has helped a bit...

Eric - if you are interested and contact me, then I will comment out the "fix"
and email you the bits that you need to run this horror - if you need a reliably
failing thingy to study the problem with
It was your post yesterday or so in another thread here that prompted me to try
this style of fix... Thank you.

BTW - I am curious - in your app that exhibits the same crash - what did you do
to work around the problem ? - Is it also running a thread and calling methods
that are normally event driven commands in the main thread? Or two other
threads like me? It would be interesting to try to spot any similarities...

Is it even allowed to asynchronously call a main thread method from another
thread? - it seems to work - but I am not sure why it does - what is the main
thread's mainloop doing while this is going on? - your other comment in the
other thread here implies that it is a strict no - no... Is it safe to call
invoke from another thread? - what is the difference between calling invoke and
calling the bound method directly?

- Hendrik

 

[Paul Rubin]

I am not sure how to do this - once I have called the Tkinter
mainloop - that main thread is essentially event driven - and
figuring out how to get it to poll a queue for content is not
obvious - I suppose I could arrange some external wake up event that
I could activate to make it look at the queue - must read up on
this...

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965

 

[Hendrik van Rooyen]

the Tkinter binding contains some code that attempts to deal with re-
entrant calls, but I don't know/remember to what extent it's actually
supposed to work (in other words, if the observed problems are bugs or
just limitations).

(maybe Martin's memory is better?)

anyway, I usually play it safe and make sure to use a single thread to
deal with the UI.

</F>

I must be dense - After I have called mainloop, if I have not started another
thread to respond to events that are not generated by the user on the screen (in
this case values of variables to display from the field generated by different
processes - there is other hardware out there), how do I get control back to do
the necessary updating? - I suppose I can use the call back after some time
thingy to implement a polling loop - possibly as Russel Owen suggested - by
polling a queue - but queues are for between threads - and I have seen here
somewhere that sockets also want to be the main thread - so that leaves a
pipe - and I have had bad experiences with pipes that are unblocked, and if I
don't unblock it, then the gui will grind to a halt....so I need a thread for
the pipe between processes, and a queue between threads, and a time out based
polling loop to read the queue, it seems - is it even safe to change a main loop
variable from another thread? , or should I do it all via commands through a
queue, implementing a whole goddam serial protocol just between threads? and If
I don't have another thread to do the timing for the animation bits, then I must
base that on a timed callback too, and somehow keep state between callbacks...
now is it ok to call widget command methods from a callback in the same thread,
or do I have to use invoke?

My head is beginning to hurt... - what was a nice simple threaded implementation
is turning into a spaghetti monster of timed callbacks - you thought gotos was
bad? - you aint seen nothing yet...

- Hendrik

 

[Hendrik van Rooyen]

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965

Thank you Paul - this shows how nicely! - Hendrik

 

[Steve Holden]

I must be dense - After I have called mainloop, if I have not started another
thread to respond to events that are not generated by the user on the screen (in
this case values of variables to display from the field generated by different
processes - there is other hardware out there), how do I get control back to do
the necessary updating? - I suppose I can use the call back after some time
thingy to implement a polling loop - possibly as Russel Owen suggested - by
polling a queue - but queues are for between threads - and I have seen here
somewhere that sockets also want to be the main thread - so that leaves a
pipe - and I have had bad experiences with pipes that are unblocked, and if I
don't unblock it, then the gui will grind to a halt....so I need a thread for
the pipe between processes, and a queue between threads, and a time out based
polling loop to read the queue, it seems - is it even safe to change a main loop
variable from another thread? , or should I do it all via commands through a
queue, implementing a whole goddam serial protocol just between threads? and If
I don't have another thread to do the timing for the animation bits, then I must
base that on a timed callback too, and somehow keep state between callbacks...
now is it ok to call widget command methods from a callback in the same thread,
or do I have to use invoke?

My head is beginning to hurt... - what was a nice simple threaded implementation
is turning into a spaghetti monster of timed callbacks - you thought gotos was
bad? - you aint seen nothing yet...

See if this helps:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965

It's Jacob Hallen's description of how he solved the problem.

regards
Steve

 

[Hendrik van Rooyen]

See if this helps:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965

It's Jacob Hallen's description of how he solved the problem.

regards
Steve

Thanks Steve - It is the same one Paul Rubin pointed me to and it describes
nicely how to get the "worker" thread going, and the queue between it and the
GUI thread.

In my case, I will have a thread for input, as well as one for output to send
commands away. The bit I was complaining about above is the replacement of a
thread to do the animation timing with a "stutter" machine inside the gui
thread, where the timing is handled by callbacks.

A piece of feedback - the stutter machine animation timing is much smoother than
the timing based on threaded sleep calls.... - less jittery - looks much
better...

So I am kind of glad the thing fell over because this implementation is going to
be much better.

Thank You All.
- Hendrik