search tab segfault

Logged In: YES
user_id=52562

I'm putting this in group "v0.5". I'll post to mnet-devel
about it.

Logged In: YES
user_id=335935

What version of wxPython do you have?

Where did you get that version?

If you can try out the "2.3.3 preview" release from
"http://sourceforge.net/project/showfiles.php?group_id=10718"

I believe this is actually a wxPython bug, so I need to pass
the buck to them.

Logged In: YES
user_id=52562

Putting it in group "v0.6", which means that in my humble
opinion we should not hold off on v0.5-STABLE release
because of this bug, but we should hold off on v0.6-STABLE
release because of this bug.

Feel free to change this setting if you think it ought to be
changed.

Logged In: YES
user_id=52562

If I start a search (optionally (?) wait for it to finish),
then start a second search, and then click the "close"
button on the first search's pane while the second search is
in-progress, then the GUI locks up.

wx versions:
MAIN pion:~$ dpkg --list '*wx*' | grep ^\.i
hi libwxgtk2.3 2.3.3.2 wxWindows Cross-platform
C++ GUI toolkit
hi libwxgtk2.3-py 2.3.3.2 wxWindows Cross-platform
C++ GUI toolkit

Mnet versions:

2002-10-30_21:56:35 () protocol version: 0.9991
2002-10-30_21:56:35 () pyutil library version: 0.0.4.4-UNSTABLE
2002-10-30_21:56:35 () broker version: 0.6.0, nano version
85, flags UNSTABLE
2002-10-30_21:56:35 () python version: 2.2.2 (#4, Oct 15
2002, 04:21:28)
: [GCC 2.95.4 20011002 (Debian prerelease)]
2002-10-30_21:56:35 () Crypto++ version: 5.0

Logged In: YES
user_id=52562

This doesn't happen all the time. I'm moving it to v0.6.1
group.

Logged In: YES
user_id=335935

I cannot get this to replicate. Even if I did it would be a
bug in wxPython or wxWindows.

Logged In: YES
user_id=642335

can't reproduce this under windows. os specific?

tested:

060-151 wxp 2342 w32 pack

061-158 wxp 2342 w32 pack

061-173 wxp 2402 w32 from cvs

or only happens with older wxpython?

Logged In: YES
user_id=52562

I can reproduce this again under Linux, Python 2.3 alpha
home-compiled and wxPython 2.4.0.2 home-compiled. I'm
trying to get it to crash under valgrind so I can have a
nice stack trace.

Logged In: YES
user_id=52562

Myers says that this is a bug in wxPython -- that the
wxPython tab object doesn't, uh, actually I don't understand
the bug. The thing is that the underlying wxWindows tab
object has disappeared (since it was closed) and then a
search result comes back, and we try to append text to the
tab pane, and I guess the bug is that instead of
segfaulting, wxPython should raise an exception.

Hopefully Myers will come explain this better so that I can
then give wxPython hackers the URL to this bug report.

It seems like we could workaround it by setting a
"searchpaneclosed" flag in the "close button clicked" event
(before passing that event onto wxWindows and telling it to
destroy the pane), and then checking that flag before
posting any search results.

Logged In: YES
user_id=52562

Assigning to me.

Logged In: YES
user_id=52562

Okay I see that Myers has already attempted my suggested fix.

Hrm.

Logged In: YES
user_id=52562

So I think the bug in wxPython is: if the panel has been
destroyed, and then someone invokes a method of the Python
wxPanel object, then they should get some kind of exception
instead of a seg fault.

Then we can catch that exception and do the right thing.
(Which is, actually, ignore it.)

Logged In: YES
user_id=52562

Bumping to v0.6.2 as Myers is right: this will require help
from wxPython developers.

Logged In: YES
user_id=52562

My current understanding of how this seg fault happens has
just been destroyed.

I thought it happened when a callback from a search came to
a panel that had been closed, but then it wouldn't happen
when you click "close", it would happen at some point after
that.

I just closed three panels in a row for searches that I
launched more than 20 minutes ago. On the third "close"
button I got the seg fault.