getting in infinite loop

Hi,
Platform - OpenSUSE 13.1
Python 2.7.x
WxPython 2.8.12.1
This also happens on a openSUSE 12.3 box.

On my Linux box when I run my code the code gets stuck in a loop in the Class PyTimer -> Notify -> self.notify(). On any of the windows (xp-8) boxes I run the same code and it does not get stuck in a loop. This happens when I refresh the screen. I would post some sample code but everything I create seems to work correctly until I start creating a larger program.

I know this is not much info - but has anybody run into this? I can't upgrade to wxPython 3.x at this time. BTW sometimes if I wait long enough the loop breaks.

Johnf

This sounds like it may be a case of a timer re-expiring before the
processing performed within its previous call has finished - this is
not uncommon between different machines, OSs, when some hardware is
changed or even when you add some code to the “wrong” part of a
program that has worked for years. The possible strategies for dealing with it are:

···

On 11/06/14 01:50, John Fabiani wrote:

  Hi,


  Platform - OpenSUSE 13.1


  Python 2.7.x


  WxPython 2.8.12.1


  This also happens on a openSUSE 12.3 box.




  On my Linux box when I run my code the code gets stuck in a loop

in the Class PyTimer → Notify → self.notify(). On any of
the windows (xp-8) boxes I run the same code and it does not get
stuck in a loop. This happens when I refresh the screen. I
would post some sample code but everything I create seems to work
correctly until I start creating a larger program.

  I know this is not much info - but has anybody run into this?  I

can’t upgrade to wxPython 3.x at this time. BTW sometimes if I
wait long enough the loop breaks.

  Johnf
  •  It is also common in code
    

using interrupt handlers.*

  1.     Specify a minimum hardware specification that your software
    

requires, (sometimes known as the MS solution).

  1.     Minimise/Optimize the code that is running under the timer or
    

interrupt, (tuning - an element of this can be a good idea but
don’t take it too far).

  1.     Check some sort of flag at the beginning of the timer code, if
    

it is already set then skip this event, otherwise set it,
perform your processing then clear the flag. (Semaphore with
dropped frames).

  1.     Use a one-shot timer in your program rather than free running
    

and in the handler re-start it at the end of processing.
(Sliding frames).
You can diagnose this sort of problem by using some sort of
outputs at the very beginning and the end of your handler - say
print ! at the start and . at the end - if you are getting
!!!..!.. like output then this is your issue. In that case I
would recommend a combination of 2 & 4 above. Heavy
processing should ideally never be inside of a hardware event
driven process so check for that and simply changing your timer to
one shot should be easy but keep in mind that you need to make
sure that all exit points from your handler need to
restart the timer - this is one of many reasons why it is usually
a very good idea to only have one return point in a given
function.

  The other option is to try, either using a debugger or by

scattering print statements through your code, to isolate where it
gets stuck - there are significant differences between what is
going on in XP and Linux so it is possible that there is a problem
in a specific operation.

  I would also suggest looking at any exception handlers you have

in your code - make sure that they are as specific as possible and
always provide some sort of output to let you know that
they are occurring.

  The other "trick" is to run your code through pyLint and fix

any/all issues reported especially those rated warning or error
& running your code with the profiling & debug tools to
find out more about what is going on.

I know the above is a bit general but hope that it is some help!

Gadget/Steve

Wow thanks for your lengthy response. I will check out everything.
Thanks for the help.
Johnf

···

On 06/10/2014 10:27 PM, Steve Barnes
wrote:

  This sounds like it may be a case of a timer re-expiring before

the processing performed within its previous call has finished -
this is not uncommon between different machines, OSs, when some
hardware is changed or even when you add some code to the “wrong”
part of a program that has worked for years. The possible strategies for dealing with it are:

    On 11/06/14 01:50, John Fabiani

wrote:

    Hi,


    Platform - OpenSUSE 13.1

    Python 2.7.x

    WxPython 2.8.12.1

    This also happens on a openSUSE 12.3 box.



    On my Linux box when I run my code the code gets stuck in a loop

in the Class PyTimer → Notify → self.notify(). On any
of the windows (xp-8) boxes I run the same code and it does not
get stuck in a loop. This happens when I refresh the screen.
I would post some sample code but everything I create seems to
work correctly until I start creating a larger program.

    I know this is not much info - but has anybody run into this?  I

can’t upgrade to wxPython 3.x at this time. BTW sometimes if I
wait long enough the loop breaks.

    Johnf
  •    It is also
    

common in code using interrupt handlers.*

  1.       Specify a minimum hardware specification that your software
    

requires, (sometimes known as the MS solution).

  1.       Minimise/Optimize the code that is running under the timer
    

or interrupt, (tuning - an element of this can be a good idea
but don’t take it too far).

  1.       Check some sort of flag at the beginning of the timer code,
    

if it is already set then skip this event, otherwise set it,
perform your processing then clear the flag. (Semaphore with
dropped frames).

  1.       Use a one-shot timer in your program rather than free
    

running and in the handler re-start it at the end of
processing. (Sliding frames).
You can diagnose this sort of problem by using some sort of
outputs at the very beginning and the end of your handler - say
print ! at the start and . at the end - if you are getting
!!!..!.. like output then this is your issue. In that case I
would recommend a combination of 2 & 4 above. Heavy
processing should ideally never be inside of a hardware event
driven process so check for that and simply changing your timer
to one shot should be easy but keep in mind that you need to
make sure that all exit points from your handler need to
restart the timer - this is one of many reasons why it is
usually a very good idea to only have one return point in a
given function.

    The other option is to try, either using a debugger or by

scattering print statements through your code, to isolate where
it gets stuck - there are significant differences between what
is going on in XP and Linux so it is possible that there is a
problem in a specific operation.

    I would also suggest looking at any exception handlers you have

in your code - make sure that they are as specific as possible
and always provide some sort of output to let you know
that they are occurring.

    The other "trick" is to run your code through pyLint and fix

any/all issues reported especially those rated warning or error
& running your code with the profiling & debug tools to
find out more about what is going on.

    I know the above is a bit general but hope that it is some

help!

Gadget/Steve