I just downloaded the latest cvs snapshot and did a sudo python setup.py install. This process finished cleanly, but if I use the WXAgg backend, pylab.show() causes a seg fault. How do I get more information to fix this problem? The TkAgg backend seems to work fine. I am running ubuntu Breezy Linux. Ryan
Ryan, Could you please test and see if the segfaults continue to occur when the WxAgg accelerator has been disabled? Also, short script that reproduces this problem would be appreciated. Thanks. Ken
Hey Ken,
Sorry to make more work for you. Yes, turning off the accelerator
gets rid of the seg fault:
In [7]: %hist
1: import matplotlib.backends.backend_wxagg
2: import matplotlib.backends.backend_wxagg
3: matplotlib.backends.backend_wxagg._use_accelerator(False)
4: matplotlib.__version__
5: figure(1)
6: show()
>>>after this show command an empty plot pops up with problem. Then
reactivating the accelerator leads to the seg fault:
In [8]: matplotlib.backends.backend_wxagg._use_accelerator(True)
In [9]: pylab.close('all')
In [10]: figure(1)
Segmentation fault
Let me know what to try next. Another strace?
Ryan
On 10/26/05, Ken McIvor <mc...@ii...> wrote:
> Ryan,
>
> Could you please test and see if the segfaults continue to occur when the
> WxAgg accelerator has been disabled? Also, short script that reproduces =
this
> problem would be appreciated. Thanks.
>
> Ken
>
Ryan Krauss wrote: > Sorry to make more work for you. Yes, turning off the accelerator > gets rid of the seg fault: That's what I was afraid of hearing. I haven't been able to reproduce this under Debian Sarge or Sid. > Let me know what to try next. Another strace? I'm not sure that an strace will help too much. I probably need the segfault stacktrace, which you can get by attaching GDB to the Python process. Please let me know if I shoudl send you instructions. Also, please check that your system configuration is comparable to my Sid environment, which is: Python: 2.3.5 IPython: 0.6.15 wxPython: 2.6.1.2pre matplotlib: 0.85cvs Finally, please double-triple-extra check that your wxPython header files correspond exactly to the version of wxPython you are using. If they don't, then all bets are off. Ken
Ryan, I'm afraid there isn't a Debian package for Python2.4+wxPython2.6, so I can't test that combination. Our best bet is to go for the GDB stack trace, like so: 1. Write an iPython script that reproduces the segfault: $ ipython <test-script> <snip> Segmentation fault 2. Find out where Python lives: $ which python /usr/bin/python 2. Find out where iPython lives: $ which ipython /usr/bin/ipython 3. Launch gdb: $ gdb <path-to-python> <snip> (gdb) run <path-to-ipython> <test-script> 4. Get the backtrack: Program received signal SIGSEGV, Segmentation fault. <snip> (gdb) bt #0 ... #1 ... <snip> #N ... Please email me everything that is printed by the "bt" command. You'll probably have to copy and paste several screens of backtrace. Thanks! Ken
Thanks Ken. I will try this tomorrow after I make sure I have the right wxPython.h. Ryan On 10/28/05, Ken McIvor <mc...@ii...> wrote: > Ryan, > > I'm afraid there isn't a Debian package for Python2.4+wxPython2.6, so I c= an't > test that combination. Our best bet is to go for the GDB stack trace, li= ke so: > > 1. Write an iPython script that reproduces the segfault: > $ ipython <test-script> > <snip> > Segmentation fault > 2. Find out where Python lives: > $ which python > /usr/bin/python > 2. Find out where iPython lives: > $ which ipython > /usr/bin/ipython > 3. Launch gdb: > $ gdb <path-to-python> > <snip> > (gdb) run <path-to-ipython> <test-script> > 4. Get the backtrack: > Program received signal SIGSEGV, Segmentation fault. > <snip> > (gdb) bt > #0 ... > #1 ... > <snip> > #N ... > > Please email me everything that is printed by the "bt" command. You'll > probably have to copy and paste several screens of backtrace. Thanks! > > Ken >
On 10/29/05 09:41, Ryan Krauss wrote:
> Here you go Ken. Thanks again. Let me know if I can do or try anything else:
I'm sorry it's taken so long to me to get back to you. I finally had some
time to look into things this morning, and I must confess I'm stumped...
The stack trace you sent me indicates that the segfault occurs when _wxagg.cpp
is trying to call wxPyConstructObject():
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1210517280 (LWP 10694)]
> 0xb4fa3411 in _wxagg_module::convert_agg_to_wx_bitmap (this=0x81d8108,
> args=@0xbff1ccb0) at src/_wxagg.cpp:129
> 129 PyObject *pyWxBitmap = wxPyConstructObject(bitmap,
> _T("wxBitmap"), 1---Type <return> to continue, or q <return> to
> quit---
> );
> Current language: auto; currently c++
> (gdb) bt
> #0 0xb4fa3411 in _wxagg_module::convert_agg_to_wx_bitmap (this=0x81d8108,
> args=@0xbff1ccb0) at src/_wxagg.cpp:129
This didn't make a whole lot of sense to me at first, so I did some digging.
It turns out that wxPyConstructObject() is actually a macro that invokes the
function pointer wxPyCoreAPIPtr->p_wxPyConstructObject(). This is a pretty
common idiom in Python for exposing extension module APIs to other extension
modules... Numeric and numarray both use it, for example.
So, it appears that dereferencing the either the pointer to the wxPyCoreAPIPtr
structure itself or the p_wxPyConstructObject function pointer within that
structure causes the segmentation fault. I've reviewed the code involved and
I can't come up with a plausible cause for this behavior. I think this could
be caused by a mismatch between the wxPython headers and the wxPython
extension itself, but I'm not even sure that would do it.
Could you try reinstalling the headers from the Ubuntu source package one more
time and rebuilding, just to make sure that isn't the problem? I haven't been
able to reproduce this problem under Debian, so I guess I'll need to get
Ubuntu installed somewhere and hope that I can reproduce it myself.
If anyone else has experienced similar problems while using the WxAgg
accelerator extension, has been able to reproduce this particular problem, or
has any idea what might be going on, please let me know! Thanks.
Ken