Currently, if I hit Ctrl-C in my program, 3 seconds go by and then it
quits with:
./run: line 2: 10071 Segmentation fault python -u run
What behavior do you get for Ctrl-C?
When I try with gdb, it looks like gdb itself gets the Ctrl-C,
preventing me from recreating the problem. Any ideas on how I might
approach this?
I'm on Mandrake 90 with Python 222 and wxPython 2407.
-Chuck
I've made some progress. First, I found out how to enable core files. In
~/.bashrc add:
ulimit -c unlimited
And load them into gdb:
$ gdb `which python` core.10162
The first suspicious thing going back through the stack is a timer. If I
take out the one and only timer in the app, I can still get a seg
fault, but this time the culprit is using idle events. Stack traces are
attached if you're curious.
I was hoping to hit Ctrl-C and get a Python stack trace. Has this ever
been accomplished? Or is gdb inevitable because of wxWindows and if so,
are these the right traces despite the "segmentation fault" message?
Heh. The original problem is that sometimes my app doesn't exit even
though the "shutdown" code I wrote seems to execute to completion (as
evidenced by print statements and all windows closing). I'm trying to
find out why it freezes. Maybe more gdb'ing will shed some light... But
this other Ctrl-C weirdness I'm reporting above is in the middle of
running the app.
trace1-timer.text (5.34 KB)
trace2-idle.text (6.31 KB)
On Saturday 19 April 2003 07:54 pm, Chuck Esterbrook wrote:
Currently, if I hit Ctrl-C in my program, 3 seconds go by and then it
quits with:
./run: line 2: 10071 Segmentation fault python -u runWhat behavior do you get for Ctrl-C?
When I try with gdb, it looks like gdb itself gets the Ctrl-C,
preventing me from recreating the problem. Any ideas on how I might
approach this?I'm on Mandrake 90 with Python 222 and wxPython 2407.
-Chuck
--
Chuck
http://ChuckEsterbrook.com
Chuck Esterbrook wrote:
Currently, if I hit Ctrl-C in my program, 3 seconds go by and then it
quits with:
./run: line 2: 10071 Segmentation fault python -u runWhat behavior do you get for Ctrl-C?
When I try with gdb, it looks like gdb itself gets the Ctrl-C,
preventing me from recreating the problem. Any ideas on how I might
approach this?I'm on Mandrake 90 with Python 222 and wxPython 2407.
-Chuck
I've made some progress. First, I found out how to enable core files. In ~/.bashrc add:
ulimit -c unlimitedAnd load them into gdb:
$ gdb `which python` core.10162The first suspicious thing going back through the stack is a timer. If I take out the one and only timer in the app, I can still get a seg fault, but this time the culprit is using idle events. Stack traces are attached if you're curious.
What are the handlers for those events doing? In each of the stack traces you show it is actually in the process of executing the handler...
I was hoping to hit Ctrl-C and get a Python stack trace. Has this ever been accomplished? Or is gdb inevitable because of wxWindows and if so, are these the right traces despite the "segmentation fault" message?
Well, Ctrl-C in the GUI is just going to come as a set of EVT_KEY_* events, or do you mean you are pressing Ctrl-C in the console that launched the app?
If the latter case then it may be possible that there is a global interpreter lock problem as python will aquire the GIL to do the KeyboardInterrupt exception and meanwile the timer handler is trying to aquire it to run the handler...
Heh. The original problem is that sometimes my app doesn't exit even though the "shutdown" code I wrote seems to execute to completion (as evidenced by print statements and all windows closing). I'm trying to find out why it freezes.
Is MainLoop exiting? If not then there may be some top level windows that still exist but are not shown. Do you Destroy all dialogs?
On Saturday 19 April 2003 07:54 pm, Chuck Esterbrook wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Well, Ctrl-C in the GUI is just going to come as a set of EVT_KEY_*
events, or do you mean you are pressing Ctrl-C in the console that
launched the app?If the latter case then it may be possible that there is a global
interpreter lock problem as python will aquire the GIL to do the
KeyboardInterrupt exception and meanwile the timer handler is trying to
aquire it to run the handler...
FWIW, when I hit Ctrl-C in the consol I launched a wxPython app from, it
pretty much always core dumps. Generally not until I highlight the
window of the app again, but it seems pretty reliable, but it never
bothered me.
-Chris
-- --
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
What are the handlers for those events doing? In each of the stack
traces you show it is actually in the process of executing the
handler...
The idle handlers in these cases were checking one or two self
attributes and then immediately returning. Something very simple like:
if not self.needsSomething:
return
Looks like any event will do the trick. See below.
Well, Ctrl-C in the GUI is just going to come as a set of EVT_KEY_*
events, or do you mean you are pressing Ctrl-C in the console that
launched the app?
Yes, I meant console.
If the latter case then it may be possible that there is a global
interpreter lock problem as python will aquire the GIL to do the
KeyboardInterrupt exception and meanwile the timer handler is trying
to aquire it to run the handler...
Could be. *Something* is happening and it's very consistent.
Is MainLoop exiting? If not then there may be some top level windows
that still exist but are not shown. Do you Destroy all dialogs?
I probably don't destroy all dialogs as I like to cache them. Is that
really a requirement? (** digs through docs **) Ah, maybe I can set the
app's exitOnFrameDelete to True. That makes sense for my app which has
one main window and nothing else but dialogs (if the flag works how I
hope).
I can't reproduce my mysterious "frozen exits" so we can forget that for
now.
I'm still curious about the Ctrl-C segfaults. Here it is distilled:
On Tuesday 22 April 2003 03:26 pm, Robin Dunn wrote:
-------------------------------------------
wantCrash = 1
def onLeftUp(e):
print 'onLeftUp'
from wxPython.wx import *
app = wxPySimpleApp()
frame = wxFrame(None, -1, "")
p = wxPanel(frame, -1)
p.SetBackgroundColour(wxColor(85, 255, 255))
if wantCrash:
EVT_LEFT_UP(p, onLeftUp)
frame.Show(1)
app.MainLoop()
-------------------------------------------
Steps:
1. Launch program
2. Go back to console (Alt-Tab)
3. Hit Ctrl-C
4. Go back to app (Alt-Tab)
5. Click in the window
Result: Seg fault from PyEval_EvalCodeEx()
Environment: wxPython 2407, Python 222, Mandrake Linux 90
If the LEFT_UP event is not bound, then the crash does not occur.
I conclude that events in general (whether mouse, timer or idle) seg
fault if there has been a Ctrl-C on the console.
--
Chuck
http://ChuckEsterbrook.com
This topic brought up an issue that has been in my mind lately, prompted
by a few postings in various places lately.
In general. I've found wxPython to be pretty darn stable when running
what I would call a production app. It is not nearly so stable when I'm
developing the app. What I mean by this is that if you do something
wrong in your code, it can cause a "hard" crash, resulting in a core
dump, or whatever. This is generally only mildly annoying for my uses,
as it is usually the result of an error in the code, and I can usually
at least figure out where that error is pretty quickly. However, it
really can be a problem when trying to use wxPython interactively. Here
is a quote from the Scipy-Chaco mailing list. Chaco is a scientific
plotting package, being designed to use a variety of back-ends. wxPython
has been used the most as the interactive back end. I'm not sure who to
attribute it to, but they are not the only one with the experience:
"""
Also as a datapoint of feedback, I just tried using pycrust again so
that I could really try out the wxPython code.PyCrust segfaulted on my Linux (Mandrake 9.1 wxWindowsGTK 2.4.0,
wxPythonGTK-py2.2) system after a couple of commands.That's been my general experience with using wxPython on Linux. It's
great for awhile but segfaults way too often to be usable in production.
Enthought is pretty excited about wxPython but I've seen less
enthusiasm from Linux users (if you are out there, please let me know
what I'm doing wrong...)That's the big reason I'd really like to see the tkinter interface get
better.
"""
My thoughts are that the inherent reason for this is that wxWindows
was/is not designed for use with a dynamic, interactive language, while
TK was designed that way from the beginning. What I'm wondering is if
there is some fundamental way to make wxPython less hard-crash prone. I
dont' know enough about C++ to know if this is even remotely possible,
but what I'm imagine is something akin to a try: except: wrapped around
everything wxWindows, so it just plain couldn't hard crash. In any case,
maybe there isn't a one-time solution, and it's a matter of squashing
the bugs one by one, but it would be nice if making wxPython more stable
in an interactive environment were made a priority.
Another note I recetnly saw is a letter from Edward Ream about why he
chose Tkinter over wxPython:
http://sensei.co.il/python/tk_wx.ui.html
Edward was active on this group for a while (and wx-users) as he tried
to get wxWindows/wxPython to work for him. I was very exited about his
work on setting up a wxWindows class that embedding a Python
interpreter. I later noticed that he had gone to TK for his Leo project,
and was wondering why. Now I know. Frankly, I think he is a bit off base
with that note. He is mingling the choice between C++ and Python with
the choice between wxPython and TKinter. I think he started by trying to
write a wxWindows app with an embedding Python interpreter, and ended up
writing a Python ap with TK. It does seem clear that he feels developing
with Python rather than C++ is clearly the way to go (and all of us on
this mailing list probably agree with that). He also found that the TK
text widget suited his needs better than Scintilla. What I wonder is
whether he is right about any of the rest of it.
I'm writing this mostly to help work out my thoughts about it, as I just
havn't had the same experience as he did. In fact, while I agree with
his criticism that wxPython often feels too low level, I also am
grateful that I have the low level access when I need it. I can't
imagine writing my FloatCanvas with the TK canvas..all the objects would
be cached twice, I couldn't have control over the buffering the way I do
etc., etc.
He does have some good points, and I think the discussion that has gone
on recently about what wxPython 3000 should be are on the right track.
If we can create a more native-python feeling wxPython, while not losing
the low level access, we'll have an even more fabulous tool.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
[snip]
My two cents:
When I embraced Python for all my projects a few years ago, it really
energized me. I left behind seg faults, bus errors, illegal
instructions and memory leaks. In their place I got tracebacks on all
my errors *as soon as they happened*. I love it!
Then two months ago I dove into wxPython and now I see seg faults every
two weeks; the first ones in over 3 years. I also get wxWindows
assertion panels with no traceback or particularly useful information.
Unfortunately, I think the problem is fundamental: wxWindows is a huge
heap of nasty C++ code (I've looked). Over time the bugs can be
mitigated, but it will be hard to make such a huge framework come up to
the quality level that I'm used to seeing in pure Python code.
There are also some other issues concerning overriding methods (or not),
scrolling, sizers, etc. that we've discussed before.
I think the "best" solution would be a new GUI framework written in as
much Python as possible and modeled heavily after NeXTSTEP/Mac OS X.
Unfortunately, I don't have the resources to dive into such a huge
project right now. BTW, I *am* looking for a job! 
Regarding Tk, those apps never look native, especially on the platform
where that is most important (MS Windows). And I couldn't find
something as low level as wxWindow/wxPanel which is a bad situation.
Let me sign off with what I like about wxPython:
* Great community
* Lots of useful info the docs, wiki, mailing list and demo
* It *does* work, after you've kicked your code long enough.
* I still get to use Python
On Wednesday 23 April 2003 04:52 pm, Chris Barker wrote:
This topic brought up an issue that has been in my mind lately,
prompted by a few postings in various places lately.In general. I've found wxPython to be pretty darn stable when running
what I would call a production app. It is not nearly so stable when
I'm developing the app. What I mean by this is that if you do
something wrong in your code, it can cause a "hard" crash, resulting
in a core dump, or whatever. This is generally only mildly annoying
for my uses, as it is usually the result of an error in the code, and
I can usually at least figure out where that error is pretty quickly.
However, it really can be a problem when trying to use wxPython
interactively. Here is a quote from the Scipy-Chaco mailing list.
Chaco is a scientific plotting package, being designed to use a
variety of back-ends. wxPython has been used the most as the
interactive back end. I'm not sure who to attribute it to, but they
are not the only one with the experience:"""
> Also as a datapoint of feedback, I just tried using pycrust again
> so that I could really try out the wxPython code.
>
> PyCrust segfaulted on my Linux (Mandrake 9.1 wxWindowsGTK 2.4.0,
> wxPythonGTK-py2.2) system after a couple of commands.
>
> That's been my general experience with using wxPython on Linux.
> It's great for awhile but segfaults way too often to be usable in
> production. Enthought is pretty excited about wxPython but I've
> seen less enthusiasm from Linux users (if you are out there, please
> let me know what I'm doing wrong...)
>
> That's the big reason I'd really like to see the tkinter interface
> get better."""
--
Chuck
http://ChuckEsterbrook.com
This topic brought up an issue that has been in my mind lately, prompted
by a few postings in various places lately.
[...]
What I'm wondering is if there is some fundamental way to make
wxPython less hard-crash prone. I dont' know enough about C++ to
know if this is even remotely possible, but what I'm imagine is
something akin to a try: except: wrapped around everything
wxWindows, so it just plain couldn't hard crash.
The thing about segfaults... is that (at least in unix), though they
can be caught, they typically can't really be handled in any
meaningful or useful way: after a segfault is caught and a handler
run, assuming that the handler returns, execution goes back to right
before the instruction that caused the segfault, assuming that it'll
go better this time. This means that whatever address was inaccessible
before the segfault-handler ran had better be accessible after the
handler returns, or you'll get caught in a loop. Typically, this means
that your segfault-handler had better just not return (e.g.: cause the
program to exit or restart itself). So, it's generally a better
solution to just avoid causing the segfaults in the first
place. Sometimes, though..., that's hard :\
Admittedly, I have no idea where wxPython stands relative to being
able to handle this problem....
Another note I recetnly saw is a letter from Edward Ream about why he
chose Tkinter over wxPython:
[...]
I'm writing this mostly to help work out my thoughts about it, as I just
havn't had the same experience as he did. In fact, while I agree with
his criticism that wxPython often feels too low level, I also am
grateful that I have the low level access when I need it.
Hm. Now, I find this interesting, because my view-point is pretty-much
the opposite: wxWindows is very *high-level*--excessively so, at
times.
Most of the time, I'm very glad that I don't have to go through what I
would have to with Tkinter--things like building scrollbars and
associating them with all of my windows, or implementing my own
progress-meter or other widgets. There's a great collection of
prefabricated widget-types, and they all come with all of the
amenities built-in, and I -love- that..., most of the time.
wx was especially nice when I was new to GUI-programming, but there
are now times when I think things like: the standard scrollbars are
missing something, so I'll make my own; I just need to make my
TextCtrls -without- scrollbars, and... d'oh--I can't make a TextCtrl
without scrollbars.
Various container-widgets in wx are quite constrained, compared to the
GTK+ widgets that they wrap--let's take buttons and trees, for example: in
wxWindows, buttons have textual labels, and trees-nodes are
text-labels. In GTK+, these things are generic containers--if I
wanted, I could build a button with a tree in it, or a tree full of
buttons that each contained pictures, or whatever (not that I've had
any desire to do either of those exact things, yet...). Sure, I can
put text-labels in them, but that's not because there's something
special about it.
I'm really glad that wx's TreeCtrls have built-in editable-nodes
facilities--last I looked, it didn't look like GTK+'s trees
did--it could be done, but I'd have to write the extra code to do
it. I'm really glad that I don't have to do that..., but..., I can't
get a reference for that text-input widget that's used for the
tree-node's editor, so I can't add any key-bindings or any other
interesting or useful features to it, and I can't get it handle
edit-cancels the way that I want.
Note that I didn't say `it's hard to'--I said `I can't'. So, every
once in a while, I think about switching over to GTK+ (or to Tk) and
just sucking up the `I'd have to write more code to do X' point,
because, at least it'd be -possible- to do Y. Right now, it
effectively costs me an -infinite- amount of code to do Y, so I guess
the total cost of X+Y really -isn't- less than it would be if I wasn't
using wx
So, it's interesting to see someone talking about how wx feels `too
LOW-level' 
Of course, I'm not really complaining--it's just that others are
sharing, so I thought that I'd join in
For some of these things, Robin has pointed me to wx-dev, and I have
to admit that I've yet to actually follow up because, really, I still
have other, larger problems of my own origination with which to
deal. Furthermore, if I wasn't so engrossed in those `other, larger
problems' (you know, the `oh, if I had the time...' argument), I
probably could have remedied some of my problems with wx. I admit
it--I'm a lazy bastard
All things considered, I do think that Julian and Robin and co. have
done a great job providing a toolkit that does what it does, and I
commend them..., but I'm not sure whether it's going to end up being
the right thing for me.
On Wed, Apr 23, 2003 at 04:52:27PM -0700, Chris Barker wrote:
--
"I actually started at one school and they taught C.... My other
school, when I transferred, used Scheme. Attacked `how to program'
from a completely different angle, and actually taught programming
techniques, not how to over-come syntax problems." --Anonymous