Python/Tkinter crash.

[Hendrik van Rooyen]

Hi,

I get the following:

hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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]

Hendrik van Rooyen wrote:

Hi,

I get the following:

hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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]

"James Stroud" <js*****@mbi.uc la.eduwrote:

Hendrik van Rooyen wrote:

Hi,

I get the following:

hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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.

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]

On Wed, 04 Oct 2006 10:33:55 +0200, Hendrik van Rooyen
<ma**@microcorp .co.zawrote:

Hi,

I get the following:

hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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.
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz 5(17l8(%,5.Z*(9 3-965$l7+-'])"

[Russell E. Owen]

In article <ma************ *************** ************@py thon.org>,
"Hendrik van Rooyen" <ma**@microcorp .co.zawrote:

>Hi,

I get the following:

hvr@LINUXBOXMi crocorp:~/Controller/libpython display.py
UpdateStringPr oc 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]

"Eric Brunel" <er*********@de spammed.comwrot e:

On Wed, 04 Oct 2006 10:33:55 +0200, Hendrik van Rooyen
<ma**@microcorp .co.zawrote:

Hi,

I get the following:

hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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.

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

[Eric Brunel]

On Wed, 04 Oct 2006 20:02:56 +0200, Hendrik van Rooyen
<ma**@microcorp .co.zawrote:

"Eric Brunel" <er*********@de spammed.comwrot e:

>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...

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_g enerate('<<MyCu stomEvent>>', when='tail')), and to
treat them in Tkinter's thread via bindings
(widget.bind('< <MyCustomEvent> >', treatment_comma nd)). This makes thingsa
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...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz 5(17l8(%,5.Z*(9 3-965$l7+-'])"

[Fredrik Lundh]

Eric Brunel wrote:

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]

"Russell E. Owen" <ro***@cesmail. netwrote:

In article <ma************ *************** ************@py thon.org>,
"Hendrik van Rooyen" <ma**@microcorp .co.zawrote:

Hi,

I get the following:

hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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

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

[Hendrik van Rooyen]

"Hendrik van Rooyen" <ma**@microcorp .co.zawrote:

"Eric Brunel" <er*********@de spammed.comwrot e:

On Wed, 04 Oct 2006 10:33:55 +0200, Hendrik van Rooyen
<ma**@microcorp .co.zawrote:

Hi,
>
I get the following:
>
hvr@LINUXBOXMic rocorp:~/Controller/libpython display.py
UpdateStringPro c 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.

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