CPU running at 100%, GUI locks up

[mbre...@gmail.com]

Dear all

I have wxPython GUI application that runs fine on machines I have tested so far, with the exception of one machine. The difference of this machine to the others is that it has an Intel Atom E3930 processor, whereas the others are i5/ i7 or Raspberry Pi ARM machines. On the Atom, the GUI suddenly consumes 100% of the CPU time, and therefore locks up. I have no idea where to look for the issue, or what to check. Does anyone have a hint?

Thanks for any insights!

[Tim Roberts]

I was going to blame raw performance, but the E3930 should be more
powerful than a Pi.  Is this Windows or Linux?  You should be able to
break into a debugger and figure out where its spinning.

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Matthias Brennwald]

It's on LInux.

Performance really cannot be the issue, as I have another Python program which does pretty much the same "work", using command-line user interface instead of the wxPython GUI. This CLI program consumes about 3-5% of CPU on the E3930.

I have never really worked with debuggers. Any hints or suggestions on how/where to start?

[Tim Roberts]

Matthias Brennwald wrote:

Performance really cannot be the issue, as I have another Python program which does pretty much the same "work", using command-line user interface instead of the wxPython GUI. This CLI program consumes about 3-5% of CPU on the E3930.

I have never really worked with debuggers. Any hints or suggestions on how/where to start?

Well, you can do "gdb  python xxx.py", then type "run" to start it.  When it hangs, you press Ctrl-C to break into the debugger.  "bt" gets a stack trace of the current thread.  You may need a stack trace of all threads, which is likely to be verbose: "thread apply all bt".  Email me a copy if you want some interpretation.

[Marc Tompkins]

Before jumping into gdb (which, until you learn it, will confuse the heck out of you), I recommend the "poor man's debugger" - i.e. insert lots of print() or console.log() statements throughout your code.  It's free, it's easy, you can make your statements as terse or as informative as you want, and it's the fastest way I know to narrow down your search for the culprit.  

[bht]

I'd also second Marc's comment. Relating where you are stuck within the Python ".exe" may not be easy to relate to where the problem is with your Python code. I also find it very useful to single-step through code in the Python debugger (I typically do this in Spyder) to isolate the Python statement causing a problem.

Brian

[Dietmar Schwertberger]

I would suggest to get an IDE with a debugger. E.g. Wing or PyCharm.
A good IDE boosts productivity a lot. Compared to the print approach, I
would estimate by about 50%.

Regards,

Dietmar

[Michael Eager]

Running a Python executable under GDB is likely to show you a lot about
the workings of the underlying VM and little about the Python program
that the VM is interpreting. If the problem is in the VM, then this
may help. If the problem is in the Python code, GDB is not going to
tell you where this is happening.

You can run the program using a Python debugger like PyCharm. It may
lose control when you go into your lockup, but you can use it to set
breakpoints to bracket where this is happening.

--
Michael Eager

[Dietmar Schwertberger]

P.S.: See here how a debugger / IDE helps with e.g. GUI code:
http://wxglade.sourceforge.net/docs/source_code.html#hints-and-tips

[Steve Barnes]

One "trick" that has worked well for me in the past is to  start from the wxpython demo item that is closest to what I am trying to do at the point of lock-up and try to modify it - step by step into a minimal demonstration of the problem. When doing this one of 3 things tend to happen - 1. I can isolate exactly which addition results in the problem an have something that I can share with others for help, 2. I realise the idiot thing that I was doing and so can fix the problem or 3. As  I add my functionality in the problem never appears until I have recreated my app but with the problem missing.

 

Steve Barnes

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/fbd0123d-312b-4481-94ca-5ebf5df0cda8n%40googlegroups.com.

[Matthias Brennwald]

I tried running the debugger using "gdb  python xxx.py", but that didn't work (gdb complained that my python script was not a good core dump...), so I went back to the good old method of inserting "print(...)" statements. The interesting thing is that now the problem does not occur anymore. I guess the execution of the "print(...)" statements somehow changed the code such that it does not run into the problem anymore. Hmmm.

[Steve Barnes]

It is possible that on that set of hardware a GUI operation is trying to happen before the App has finished initialising - the print statement will slow down the code enough that the initialisation has time to complete. You can try to isolate this by moving print statements a few lines (first try removing/commenting them to see if you get back the problem). It sounds like you might have a candidate for a CallAfter.

--

You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/SYUQPQ.DF29U9VEM1UX2%40gmail.com.

[James Stallings II]

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/86c7e597-ba49-47f3-f751-16392511bb00%40schwertberger.de.

Not directly related to a solution to an answer to your questions, but I have to emphatically second what Dietmar says about IDEs. 

I’ve recently taken up with PyCharm, and just it’s code folding capability allowed me to put such an amount of stable code out of my (all too easily distracted) view that I was able to drill down to problems I had been chasing in my moderately complex UI.

Further, it’s linter exposed a couple dozen serious issues I was not yet even aware of, the majority of which were readily addressed once I’d been made aware of them. I highly endorse a good IDE for whatever programming you might be doing, but when it comes to python, PyCharm is just this side of magic.

--

ॐ♲ ♥ ☸☮ ☯☰☶☯☮ ☸ ♥ ♲ॐ

[Matthias Brennwald]

On Wed, Mar 10, 2021 at 09:46, Steve Barnes <Gadge...@live.co.uk> wrote:

It is possible that on that set of hardware a GUI operation is trying to happen before the App has finished initialising - the print statement will slow down the code enough that the initialisation has time to complete. You can try to isolate this by moving print statements a few lines (first try removing/commenting them to see if you get back the problem). It sounds like you might have a candidate for a CallAfter.

I am not quite sure what you mean by "finished initialising", but the remainder is spot on. I (re)moved the extra print statements until things started to fail again. Looking at the code around the relevant print statements I found a number of calls that were a bit too involved with using CallAfter(...). I believe they were biting each others tails. I rearranged my code a bit, and the problem seems to be gone. Thanks everyone!