I have an unfortunate bug where my wxpython program just crashes. I’m using Windows, and the program stops responding, prompting Windows to ask me to kill it. It stops taking any user input but also stops using any CPU.
I’m on a dual-monitor setup, and the weird thing about this bug is that it happens way more often when the frame is on my right monitor. I have two instances running, one on each monitor, and the left one will work fine while the right one crashes quite often. Then, after running the one on the right a few times, having it crash, restarting it, etc., all while the left one is fine, I drag the left one to my right monitor and pretty soon it crashes as well. I have seen the program crash while on the left monitor as well, however.
Is there any conceivable way that that makes any sense? That the monitor I am using somehow determines whether the program crashes? Either way, does anyone have any advice on how to about about debugging such a bug? It seems to happen fairly randomly. I haven’t been able to pin-point the issue yet and I have a lot of logging going on. I’m using wxpython with twisted’s wxreactor, along with an instance of pygame running in one of the panels. (Yep, I do need each of those components…)
The only thing that comes to mind is that you might be doing some
positional arithmetic somewhere along the way, and that on the right
monitor your X values might be overflowing (might need to use a long
instead of an int, or something along those lines). Can't really imagine
what that would be about, but it makes more sense to me than that wxPython
would care which monitor is which...
···
On Tue, Mar 26, 2013 at 1:47 PM, Claudiu Saftoiu <csaftoiu@gmail.com> wrote:
Is there any conceivable way that that makes any sense? That the monitor I
am using somehow determines whether the program crashes?
I have created a DockingFrame class, which does arithmetic when the parent frame moves or gets resized in order to move itself so it still sticks to the parent. These crashes don’t happen when anything is moving, though, so it doesn’t seem related to that… I’ll check it out a bit but I don’t think it’s that, thanks for the suggestion though I hadn’t thought of it.
I am running pygame in a thread, maybe the issue is related to that. I’m going to try having it run with a twisted.LoopingCall and see if that fixes the issue.
Claudiu
···
Is there any conceivable way that that makes any sense? That the monitor I am using somehow determines whether the program crashes?
The only thing that comes to mind is that you might be doing some positional arithmetic somewhere along the way, and that on the right monitor your X values might be overflowing (might need to use a long instead of an int, or something along those lines). Can’t really imagine what that would be about, but it makes more sense to me than that wxPython would care which monitor is which…
Ah this seems to have fixed it. Apparently, pygame is not really thread-safe and its functions are only supposed to be called from the main thread. I started my project with the code samples in http://wiki.wxpython.org/IntegratingPyGame , which do run pygame in a thread. This is wrong! I’m using twisted as my main loop, so I set my pygame up to use a twisted.internet.task.LoopingCall , but if I were using wxPython then I’d have to use its scheduler somehow. The code I linked to should be changed, or a warning should be written, as it is dangerously misleading (in the way that it only breaks way down the line). I also notice my animations now run much more smoothly now that pygame is running from the main thread.
Oh debugging…
Claudiu
···
Is there any conceivable way that that makes any sense? That the monitor I am using somehow determines whether the program crashes?
The only thing that comes to mind is that you might be doing some positional arithmetic somewhere along the way, and that on the right monitor your X values might be overflowing (might need to use a long instead of an int, or something along those lines). Can’t really imagine what that would be about, but it makes more sense to me than that wxPython would care which monitor is which…
Ah this seems to have fixed it. Apparently, pygame is not really
thread-safe and its functions are *only* supposed to be called from the
main thread. I started my project with the code samples in IntegratingPyGame - wxPyWiki , which do run pygame in a
thread. This is *wrong*! I'm using twisted as my main loop, so I set my
pygame up to use a twisted.internet.task.LoopingCall , but if I were
using wxPython then I'd have to use its scheduler somehow. The code I
linked to should be changed, or a warning should be written, as it is
dangerously misleading (in the way that it only breaks way down the
line). I also notice my animations now run much more smoothly now that
pygame is running from the main thread.
Feel free to modify that page and sample to correct the problems.