"Try ripping out everything that is not essential to make this crash
happen"
I had somewhat of a similar problem a few months ago. My wxPython
program crashed without any error details i.e. without the usual
python traceback that enables tracing the problem to a particular line
of python code.
I eventually solved the problem; aided by numerous suggestions from
this forum. Werner was especially patient and provided a lot of tips
that helped solve the problem (wx CallAfter!)
I provide some details below on how I eventually tracked down the
problem and solved it. You can also view the details in the
discussion in this forum - the title is 'unhandled exception'.
Some disclaimers:
a) I am no expert in wxPython; and the crashing app was my first
attempt at wx. Lots of folks here are light-years ahead of me. If my
suggestions are incorrect, please feel free to correct.
b) I was running wxPython in Windows XP and did not compile to exe.
--OK here it is:
My application crashed with "Unhandled exception" being displayed.
The error seems to come from Window rather than Python, and there is
no details at all apart from the unhelpful Windows dump. Eventually,
I found that the error was caused by this:
Mouse click on a panel -> Event handler for mouse click ->
Redraw entire screen consisting of many panels, including deleting
panel that was the source of the event.
Apparently, it is not good to delete a window inside the event
handler if the window is the source of the event. I didn't know this
at the time I wrote the code, and the error didn't appear until a
few months into development; even though I had been doing this
deletion for quite a long time prior to the crash. It is
intermittent, sometimes it doesn't happen at all, sometimes it
happens within 2 or 3 clicks. But somewhere along the development as
the number of application features increased, it became frequent.
For such types of errors, print is of no help in isolating the
problem. This is because the error does not occur in python. I think
it is not even in wxPython but in the C++ code of wx widgets. And
the error in not synchronous with the code that causes the error i.e.
the timing is different. For example, the deletion of objects in C++
may be deferred and say that the error is caused by the deletion. So
this may be long after the line of code in Python that actually
issues the delete command has passed.
I didn't know this at first. I started by putting print statements
everywhere. Finally to my surprise, I saw that the print statement
at the very last line of Python code was executed, and that the crash
happened after this; i.e. after my wxpython program had already
completed processing the event that caused the crash. In fact, all the
expected logic and screen updates had completed successfully when
the crash happened. The screen and data was already changed
correctly.
I eventually solved the problem based on this suggestion from Robin:
"Try ripping out everything that is not essential to make this crash
happen"
This sounds daunting and initially I thought I could not do it. There
were a lot of code, and I couldn't easily take code out without
stuff breaking. I also thought that it would take forever to arrive
at a state where there is little code and the problem still occurs;
since it seems to occur after some sequence of events involving most
of the code. Eventually, out of lack of choice, I went ahead to do
this. It took a long time. It was several days of work - but not
forever as I thought it might be.
What is the best way to go about this? Well, the crash is in wx, so
the crash must have something to do with screen drawing or updates
or changes to wx objects. So non-wx logic can be removed e.g. the
business logic can be removed; replaced with stubs; e.g. return dummy
values. Next, you can try ripping out large sections of code at a
time and see if the error still occurs. Finally, keep track of
versions between ripping out code; so that you will know what to put
back if the error disappears. You may have to make small changes to
the code to invoke the gui functions required after removing chunks of
code.
At the end of the process, you will hopefully have a small segment of
code that is responsible for the error. At this time you may already
have figured out what it is. If not, put that code into this forum
and someone here will probably be able to tell you why.
For my case, I was eventually able to produce a very small wxPython
program that replicated the error; just 1 frame screen with 2 or 3
panels. Of course this was after I already figured it out.
I also found out that adding evt.Skip() in the event handler caused
the crash. Although I was doing something wrong - deleting a panel in
the event handler triggered by the panel, this didn't cause the
crash until I added evt.Skip() much much later into development. And
the crash was intermittent, so I didn't see it initially i.e. right
after I added the Skip(). By the time the crash came out, I couldn't
easily revert to a version that didn't crash.
In any event, keeping versions of code is useful for comparing
between when it started crashing and when it did not. After I
isolated the code that caused the problem, a code comparison between
earlier and later versions showed me the difference was evt.Skip().
I think it sounds daunting; but it is probably do-able unless your
code is really huge. Painful but doable... It would be nice if
wxWidgets can throw up at least a bit of info on the source of the
error e.g. the names of wx objects linked to the error, but it seems
like it doesn't.
Therefore this take stuff out approach for these type of crashes may
be the only available approach without use of any advanced debugger
tools - if there is any available. I don't think so.
Hope this helps.
