Re: Python/Tkinter crash.

[Hendrik van Rooyen]

"Steve Holden" <[EMAIL PROTECTED]> wrote:
> Hendrik van Rooyen wrote:
> > "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> >
> >>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.
> >>
> >>
> >
> >
> > 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 haltso 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

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



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Steve Holden]

Hendrik van Rooyen wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> 
>>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.
>>
>>
> 
> 
> 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 haltso 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
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb   http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

"Paul Rubin"  wrote:
> "Hendrik van Rooyen" <[EMAIL PROTECTED]> writes:
> > 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
> 
Thank you Paul - this shows how nicely! - Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> 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.
>
> 

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Paul Rubin]

"Hendrik van Rooyen" <[EMAIL PROTECTED]> writes:
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

 "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:
>  "Eric Brunel" <[EMAIL PROTECTED]> wrote:
>
>
> > On Wed, 04 Oct 2006 10:33:55 +0200, Hendrik van Rooyen
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > I get the following:
> > >
> > > [EMAIL PROTECTED]:~/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.
>
> 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



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

 "Russell E. Owen" <[EMAIL PROTECTED]> wrote:


> In article <[EMAIL PROTECTED]>,
>  "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:
>
> >Hi,
> >
> >I get the following:
> >
> >[EMAIL PROTECTED]:~/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

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

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



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Eric Brunel]

On Wed, 04 Oct 2006 20:02:56 +0200, Hendrik van Rooyen  
<[EMAIL PROTECTED]> wrote:
>  "Eric Brunel" <[EMAIL PROTECTED]> wrote:
>> 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_generate('<>', when='tail')), and to  
treat them in Tkinter's thread via bindings  
(widget.bind('<>', 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...
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Russell E. Owen]

In article <[EMAIL PROTECTED]>,
 "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:

>Hi,
>
>I get the following:
>
>[EMAIL PROTECTED]:~/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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

 "Eric Brunel" <[EMAIL PROTECTED]> wrote:


> On Wed, 04 Oct 2006 10:33:55 +0200, Hendrik van Rooyen
> <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I get the following:
> >
> > [EMAIL PROTECTED]:~/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.

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Eric Brunel]

On Wed, 04 Oct 2006 10:33:55 +0200, Hendrik van Rooyen  
<[EMAIL PROTECTED]> wrote:

> Hi,
>
> I get the following:
>
> [EMAIL PROTECTED]:~/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.
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

 "James Stroud" <[EMAIL PROTECTED]> wrote:
> Hendrik van Rooyen wrote:
> > Hi,
> >
> > I get the following:
> >
> > [EMAIL PROTECTED]:~/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.

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[Hendrik van Rooyen]

Not talking to myself - Added results of strace run at bottom

"Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I get the following:
>
> [EMAIL PROTECTED]:~/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

Ran it with strace - here is last bit of log:

write(3, "<\30\2\0\35\0\300\2<\0\2\0\34\0\300\0027\0\7\0\34\0\300"..., 68) = 68
select(4, [3], [], [], {0, 0})  = 0 (Timeout)
gettimeofday({1159960306, 369206}, {4294967176, 0}) = 0
futex(0x807b908, FUTEX_WAKE, 1) = 0
futex(0x80bad48, FUTEX_WAKE, 1) = 0
write(3, "5\30\4\0N\0\300\2 \0\300\2r\2\220\0F\0\5\0N\0\300\2\23"..., 900) = 900
gettimeofday({1159960306, 371171}, {4294967176, 0}) = 0
select(4, [3], [], [], {0, 0})  = 0 (Timeout)
gettimeofday({1159960306, 371386}, {4294967176, 0}) = 0
futex(0x807b908, FUTEX_WAKE, 1) = 0
select(0, NULL, NULL, NULL, {0, 2}) = 0 (Timeout)
futex(0x80bad48, FUTEX_WAIT, 0, NULL)   = 0
futex(0x80bad48, FUTEX_WAKE, 1) = 0
write(3, "<\30\2\0\34\0\300\2<\0\2\0\35\0\300\0027\0\7\0\35\0\300"..., 68) = 68
select(4, [3], [], [], {0, 0})  = 0 (Timeout)
gettimeofday({1159960306, 396232}, {4294967176, 0}) = 0
futex(0x807b908, FUTEX_WAKE, 1) = 0
futex(0x80bad48, FUTEX_WAKE, 1) = 0
write(3, "5\30\4\0N\0\300\2 \0\300\2r\2\220\0F\0\5\0N\0\300\2\23"..., 900) = 900
gettimeofday({1159960306, 398381}, {4294967176, 0}) = 0
select(4, [3], [], [], {0, 0})  = 0 (Timeout)
gettimeofday({1159960306, 398597}, {4294967176, 0}) = 0
futex(0x807b908, FUTEX_WAKE, 1) = 0
select(0, NULL, NULL, NULL, {0, 2}) = 0 (Timeout)
futex(0x80bad48, FUTEX_WAIT, 0, NULL)   = 0
futex(0x80bad48, FUTEX_WAKE, 1) = 0
futex(0x807b908, FUTEX_WAIT, 0, NULL)   = 0
write(3, "7\30\5\0\21\0\300\2:\0\300\2\4\0\0\0\377\0\0\0", 20) = 20
select(4, [3], [], [], {0, 0})  = 0 (Timeout)
gettimeofday({1159960306, 420182}, {4294967176, 0}) = 0
futex(0x807b908, FUTEX_WAKE, 1) = 0
futex(0x80bad48, FUTEX_WAIT, 0, NULL)   = 0
futex(0x80bad48, FUTEX_WAKE, 1) = 0
write(3, "5\30\4\0N\0\300\0029\0\300\2\207\0\210\0F\0\5\0N\0\300"..., 708) = 708
gettimeofday({1159960306, 421944}, {4294967176, 0}) = 0
select(4, [3], [], [], {0, 0})  = 0 (Timeout)
gettimeofday({1159960306, 422168}, {4294967176, 0}) = 0
futex(0x807b908, FUTEX_WAKE, 1) = 0
select(0, NULL, NULL, NULL, {0, 2}) = ? ERESTARTNOHAND (To be restarted)
+++ killed by SIGABRT +++




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Tkinter crash.

[James Stroud]

Hendrik van Rooyen wrote:
> Hi,
> 
> I get the following:
> 
> [EMAIL PROTECTED]:~/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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python/Tkinter crash.

[Hendrik van Rooyen]

Hi,

I get the following:

[EMAIL PROTECTED]:~/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

-- 
http://mail.python.org/mailman/listinfo/python-list