segmentation fault in gentoo linux

Hello,

I have somewhat of a vague question, but I’m hoping that someone can give me a hint anyway. Some time ago I wrote a program with a lot of help from this email list using wxpython. Basically it was a gui for some of the features of matplotlib. I wrote it on Linux Mint and it worked fine. Unfortunately that machine died, so I got a new one. I decided to install gentoo linux on it and recently tried to run the same program. It runs all the way to the end (I know that because the last line in the program is saving the plotted figure, and the file is created with the figure in it being just fine), however it crashes after every time it runs and I get the message “Segmentation fault”. I don’t think it is matplotlib itself, because when I run matplotlib from the command line it works fine. So I’m guessing it is a problem with wxpython. Can someone give me advice how to fix that. For starters, I would like to get a little bit more detailed information on what causes the error, because the current message is a bit short.

Here are some details about my installation:
Python 2.7.3
wxpython 2.8.12.1
(please let me know if you need any further info)

Thanks a lot in advance.

Best wishes,
George

If you're not getting a core file then you can use the ulimit command to turn that on. Then a core file (memory dump) will be produced the next time you get a segfault. You can load that in gdb and do a backtrace command. If your binaries were built with sufficient debug info then you should see a stack trace showing where the crash occurred and also the function calls leading up to the crash.

···

On 8/8/12 1:51 PM, G. Nikiforov wrote:

Hello,

I have somewhat of a vague question, but I'm hoping that someone can
give me a hint anyway. Some time ago I wrote a program with a lot of
help from this email list using wxpython. Basically it was a gui for
some of the features of matplotlib. I wrote it on Linux Mint and it
worked fine. Unfortunately that machine died, so I got a new one. I
decided to install gentoo linux on it and recently tried to run the same
program. It runs all the way to the end (I know that because the last
line in the program is saving the plotted figure, and the file is
created with the figure in it being just fine), however it crashes after
every time it runs and I get the message "Segmentation fault". I don't
think it is matplotlib itself, because when I run matplotlib from the
command line it works fine. So I'm guessing it is a problem with
wxpython. Can someone give me advice how to fix that. For starters, I
would like to get a little bit more detailed information on what causes
the error, because the current message is a bit short.

--
Robin Dunn
Software Craftsman

I have somewhat of a vague question, but I’m hoping that someone can
give me a hint anyway. Some time ago I wrote a program with a lot of
help from this email list using wxpython. Basically it was a gui for
some of the features of matplotlib. I wrote it on Linux Mint and it
worked fine. Unfortunately that machine died, so I got a new one. I
decided to install gentoo linux on it and recently tried to run the same
program. It runs all the way to the end (I know that because the last
line in the program is saving the plotted figure, and the file is
created with the figure in it being just fine), however it crashes after
every time it runs and I get the message “Segmentation fault”. I don’t
think it is matplotlib itself, because when I run matplotlib from the
command line it works fine. So I’m guessing it is a problem with
wxpython. Can someone give me advice how to fix that. For starters, I
would like to get a little bit more detailed information on what causes
the error, because the current message is a bit short.

If you’re not getting a core file then you can use the ulimit command to
turn that on. Then a core file (memory dump) will be produced the next
time you get a segfault. You can load that in gdb and do a backtrace
command. If your binaries were built with sufficient debug info then
you should see a stack trace showing where the crash occurred and also
the function calls leading up to the crash.

Thanks a lot for your reply! I’ll give it a go.

Best wishes,
George

I have somewhat of a vague question, but I’m hoping that someone can
give me a hint anyway. Some time ago I wrote a program with a lot of
help from this email list using wxpython. Basically it was a gui for
some of the features of matplotlib. I wrote it on Linux Mint and it
worked fine. Unfortunately that machine died, so I got a new one. I
decided to install gentoo linux on it and recently tried to run the same
program. It runs all the way to the end (I know that because the last
line in the program is saving the plotted figure, and the file is
created with the figure in it being just fine), however it crashes after
every time it runs and I get the message “Segmentation fault”. I don’t
think it is matplotlib itself, because when I run matplotlib from the
command line it works fine. So I’m guessing it is a problem with
wxpython. Can someone give me advice how to fix that. For starters, I
would like to get a little bit more detailed information on what causes
the error, because the current message is a bit short.

If you’re not getting a core file then you can use the ulimit command to
turn that on. Then a core file (memory dump) will be produced the next
time you get a segfault. You can load that in gdb and do a backtrace
command. If your binaries were built with sufficient debug info then
you should see a stack trace showing where the crash occurred and also
the function calls leading up to the crash.

I followed your advice and activated the core dump by the ulimit command. In order to make sure that all involved binaries were built with sufficient debug info, I added the flag -ggdb to CFLAGS in my the /etc/make.conf file. Then I recompiled python, wxpython, numpy and matplotlib so that they are built with the new flag (I don’t use any other libraries than that). When I run my script again, I get a file called core in the directory. So I tried to look at it with gdb, but there isn’t much detail (see below). I don’t have any experience with this, so any help or pointer would be appreciated.

Thanks!

$ gdb
GNU gdb (Gentoo 7.3.1 p2) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-pc-linux-gnu”.
For bug reporting instructions, please see:
http://bugs.gentoo.org/.
(gdb) core core
[New LWP 13235]
[New LWP 13245]
Core was generated by `python2.7 ./mpl_latex_plot_v2.py’.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f03e4adce4a in ?? ()
(gdb) bt
#0 0x00007f03e4adce4a in ?? ()
#1 0x00007f03e2a20b10 in ?? ()
#2 0x0000000000000000 in ?? ()

Either the -ggdb flag wasn't used during the build or the debug info was stripped. I'm not familiar with Gentoo so I don't know the procedure doing things like this.

···

On 8/21/12 4:18 AM, G. Nikiforov wrote:

> > I have somewhat of a vague question, but I'm hoping that someone can
> > give me a hint anyway. Some time ago I wrote a program with a lot of
> > help from this email list using wxpython. Basically it was a gui for
> > some of the features of matplotlib. I wrote it on Linux Mint and it
> > worked fine. Unfortunately that machine died, so I got a new one. I
> > decided to install gentoo linux on it and recently tried to run the
same
> > program. It runs all the way to the end (I know that because the last
> > line in the program is saving the plotted figure, and the file is
> > created with the figure in it being just fine), however it crashes
after
> > every time it runs and I get the message "Segmentation fault". I don't
> > think it is matplotlib itself, because when I run matplotlib from the
> > command line it works fine. So I'm guessing it is a problem with
> > wxpython. Can someone give me advice how to fix that. For starters, I
> > would like to get a little bit more detailed information on what causes
> > the error, because the current message is a bit short.
>
> If you're not getting a core file then you can use the ulimit command to
> turn that on. Then a core file (memory dump) will be produced the next
> time you get a segfault. You can load that in gdb and do a backtrace
> command. If your binaries were built with sufficient debug info then
> you should see a stack trace showing where the crash occurred and also
> the function calls leading up to the crash.

I followed your advice and activated the core dump by the ulimit
command. In order to make sure that all involved binaries were built
with sufficient debug info, I added the flag -ggdb to CFLAGS in my the
/etc/make.conf file. Then I recompiled python, wxpython, numpy and
matplotlib so that they are built with the new flag (I don't use any
other libraries than that). When I run my script again, I get a file
called core in the directory. So I tried to look at it with gdb, but
there isn't much detail (see below). I don't have any experience with
this, so any help or pointer would be appreciated.

--
Robin Dunn
Software Craftsman

I have somewhat of a vague question, but I’m hoping that someone can
give me a hint anyway. Some time ago I wrote a program with a lot of
help from this email list using wxpython. Basically it was a gui for
some of the features of matplotlib. I wrote it on Linux Mint and it
worked fine. Unfortunately that machine died, so I got a new one. I
decided to install gentoo linux on it and recently tried to run the
same
program. It runs all the way to the end (I know that because the last
line in the program is saving the plotted figure, and the file is
created with the figure in it being just fine), however it crashes
after
every time it runs and I get the message “Segmentation fault”. I don’t
think it is matplotlib itself, because when I run matplotlib from the
command line it works fine. So I’m guessing it is a problem with
wxpython. Can someone give me advice how to fix that. For starters, I
would like to get a little bit more detailed information on what causes
the error, because the current message is a bit short.

If you’re not getting a core file then you can use the ulimit command to
turn that on. Then a core file (memory dump) will be produced the next
time you get a segfault. You can load that in gdb and do a backtrace
command. If your binaries were built with sufficient debug info then
you should see a stack trace showing where the crash occurred and also
the function calls leading up to the crash.

I followed your advice and activated the core dump by the ulimit
command. In order to make sure that all involved binaries were built
with sufficient debug info, I added the flag -ggdb to CFLAGS in my the
/etc/make.conf file. Then I recompiled python, wxpython, numpy and
matplotlib so that they are built with the new flag (I don’t use any
other libraries than that). When I run my script again, I get a file
called core in the directory. So I tried to look at it with gdb, but
there isn’t much detail (see below). I don’t have any experience with
this, so any help or pointer would be appreciated.

Either the -ggdb flag wasn’t used during the build or the debug info was
stripped. I’m not familiar with Gentoo so I don’t know the procedure
doing things like this.

Thank you very much for your help anyway, Robin. I will post in another forum and if I make any progress, I will post here as well.

I have somewhat of a vague question, but I’m hoping that someone can
give me a hint anyway. Some time ago I wrote a program with a lot of
help from this email list using wxpython. Basically it was a gui for
some of the features of matplotlib. I wrote it on Linux Mint and it
worked fine. Unfortunately that machine died, so I got a new one. I
decided to install gentoo linux on it and recently tried to run the
same
program. It runs all the way to the end (I know that because the last
line in the program is saving the plotted figure, and the file is
created with the figure in it being just fine), however it crashes
after
every time it runs and I get the message “Segmentation fault”. I don’t
think it is matplotlib itself, because when I run matplotlib from the
command line it works fine. So I’m guessing it is a problem with
wxpython. Can someone give me advice how to fix that. For starters, I
would like to get a little bit more detailed information on what causes
the error, because the current message is a bit short.

If you’re not getting a core file then you can use the ulimit command to
turn that on. Then a core file (memory dump) will be produced the next
time you get a segfault. You can load that in gdb and do a backtrace
command. If your binaries were built with sufficient debug info then
you should see a stack trace showing where the crash occurred and also
the function calls leading up to the crash.

I followed your advice and activated the core dump by the ulimit
command. In order to make sure that all involved binaries were built
with sufficient debug info, I added the flag -ggdb to CFLAGS in my the
/etc/make.conf file. Then I recompiled python, wxpython, numpy and
matplotlib so that they are built with the new flag (I don’t use any
other libraries than that). When I run my script again, I get a file
called core in the directory. So I tried to look at it with gdb, but
there isn’t much detail (see below). I don’t have any experience with
this, so any help or pointer would be appreciated.

Either the -ggdb flag wasn’t used during the build or the debug info was
stripped. I’m not familiar with Gentoo so I don’t know the procedure
doing things like this.

Yes, you were right, the debug was stripped and once I enabled it, I managed to get a little bit more detailed backtrace. However I’m still not entirely sure exactly which command in my program causes the segmentation fault. I guess if someone can spot it quickly, I will be very grateful. Thank you very much in advance. Here’s the output of gdb:

$ gdb --core=core /usr/bin/python2.7
GNU gdb (Gentoo 7.3.1 p2) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-pc-linux-gnu”.
For bug reporting instructions, please see:
http://bugs.gentoo.org/
Reading symbols from /usr/bin/python2.7…Reading symbols from /usr/lib64/debug/usr/bin/python2.7.debug…done.
done.
[New LWP 7415]
[New LWP 7424]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need “set solib-search-path” or “set sysroot”?
[Thread debugging using libthread_db enabled]
Core was generated by `python2.7 ./mpl_latex_plot_v2.py’.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f3ac27a5e4a in PyObject_Call (func=, arg=0x282d4d0, kw=0x0)
at Objects/abstract.c:2527
2527 Objects/abstract.c: No such file or directory.
in Objects/abstract.c
(gdb) bt
#0 0x00007f3ac27a5e4a in PyObject_Call (func=, arg=0x282d4d0, kw=0x0)
at Objects/abstract.c:2527
#1 0x00007f3ac2837e17 in PyEval_CallObjectWithKeywords (func=0x24e78c0, arg=0x282d4d0,
kw=) at Python/ceval.c:3890
#2 0x00007f3aaee90ff8 in ?? () from /usr/lib64/python2.7/site-packages/gobject/_gobject.so
#3 0x00007f3abf1434b2 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#4 0x00007f3abf154501 in ?? () from /usr/lib64/libgobject-2.0.so.0
#5 0x00007f3abf15c48e in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#6 0x00007f3abf15c942 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#7 0x00007f3abfaaa441 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#8 0x00007f3abf990437 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#9 0x00007f3abf5e714c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#10 0x00007f3abf5e70fb in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#11 0x00007f3abf5e2116 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#12 0x00007f3abf5e42b1 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0
#13 0x00007f3abf913c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x00007f3abf5c1956 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#15 0x00007f3abee5a553 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#16 0x00007f3abee5a8a0 in ?? () from /usr/lib64/libglib-2.0.so.0
#17 0x00007f3abee5ac9a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#18 0x00007f3abf98f1c7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x00007f3ac0b24878 in wxEventLoop::Run() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#20 0x00007f3ac0b9dcab in wxAppBase::MainLoop() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#21 0x00007f3ac1256cd7 in MainLoop (this=0x21b2430) at src/helpers.cpp:215
#22 wxPyApp::MainLoop (this=0x21b2430) at src/helpers.cpp:205
#23 0x00007f3ac12b1ff7 in _wrap_PyApp_MainLoop (args=)
at src/gtk/_core_wrap.cpp:31691
#24 0x00007f3ac283d901 in ext_do_call (nk=0, na=, flags=,
pp_stack=0x7ffffc4b7d28, func=0x87d518) at Python/ceval.c:4331
#25 PyEval_EvalFrameEx (f=, throwflag=) at Python/ceval.c:2705
#26 0x00007f3ac283ee35 in PyEval_EvalCodeEx (co=, globals=,
locals=, args=, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:3253
#27 0x00007f3ac27cb5dc in function_call (func=0x8fa668, arg=0x186dad0, kw=0x0)
at Objects/funcobject.c:526
#28 0x00007f3ac27a5e63 in PyObject_Call (func=0x8fa668, arg=, kw=)
at Objects/abstract.c:2529
#29 0x00007f3ac27b4abf in instancemethod_call (func=0x8fa668, arg=0x186dad0, kw=0x0)
at Objects/classobject.c:2578
#30 0x00007f3ac27a5e63 in PyObject_Call (func=0x22f9eb0, arg=, kw=)
at Objects/abstract.c:2529
#31 0x00007f3ac283c12a in do_call (nk=, na=,
pp_stack=0x7ffffc4b8278, func=0x22f9eb0) at Python/ceval.c:4239
#32 call_function (oparg=, pp_stack=0x7ffffc4b8278) at Python/ceval.c:4044
#33 PyEval_EvalFrameEx (f=, throwflag=) at Python/ceval.c:2666
#34 0x00007f3ac283de89 in fast_function (nk=, na=1, n=,
pp_stack=0x7ffffc4b83b8, func=0x8fca28) at Python/ceval.c:4107
#35 call_function (oparg=, pp_stack=0x7ffffc4b83b8) at Python/ceval.c:4042
#36 PyEval_EvalFrameEx (f=, throwflag=) at Python/ceval.c:2666
#37 0x00007f3ac283ee35 in PyEval_EvalCodeEx (co=, globals=,
locals=, args=, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:3253
#38 0x00007f3ac283ef62 in PyEval_EvalCode (co=, globals=,
locals=) at Python/ceval.c:667
#39 0x00007f3ac2858f9c in run_mod (mod=, filename=,
globals=0x640f80, locals=0x640f80, flags=, arena=)
at Python/pythonrun.c:1353

#40 0x00007f3ac2859d70 in PyRun_FileExFlags (fp=0x6a2e60,
filename=0x7ffffc4ba4ea “./mpl_latex_plot_v2.py”, start=, globals=0x640f80,
locals=0x640f80, closeit=1, flags=0x7ffffc4b86e0) at Python/pythonrun.c:1339
#41 0x00007f3ac285a7ef in PyRun_SimpleFileExFlags (fp=0x6a2e60,
filename=0x7ffffc4ba4ea “./mpl_latex_plot_v2.py”, closeit=1, flags=0x7ffffc4b86e0)
at Python/pythonrun.c:943
#42 0x00007f3ac286bf25 in Py_Main (argc=, argv=)
at Modules/main.c:643
#43 0x00007f3ac21ba60d in __libc_start_main () from /lib64/libc.so.6
#44 0x000000000040091d in _start ()

Are you mixing wxPython with pygtk or some other Gnome Python extensions? Line #2 above shows that the crash is coming from a function called from the gobject extension module. There are no other wx functions being called in the stack between the MainLoop and the crash.

···

On 8/26/12 6:12 AM, G. Nikiforov wrote:

> > > > I have somewhat of a vague question, but I'm hoping that
someone can
> > > > give me a hint anyway. Some time ago I wrote a program with a
lot of
> > > > help from this email list using wxpython. Basically it was a
gui for
> > > > some of the features of matplotlib. I wrote it on Linux Mint and it
> > > > worked fine. Unfortunately that machine died, so I got a new one. I
> > > > decided to install gentoo linux on it and recently tried to run the
> > same
> > > > program. It runs all the way to the end (I know that because
the last
> > > > line in the program is saving the plotted figure, and the file is
> > > > created with the figure in it being just fine), however it crashes
> > after
> > > > every time it runs and I get the message "Segmentation fault".
I don't
> > > > think it is matplotlib itself, because when I run matplotlib
from the
> > > > command line it works fine. So I'm guessing it is a problem with
> > > > wxpython. Can someone give me advice how to fix that. For
starters, I
> > > > would like to get a little bit more detailed information on
what causes
> > > > the error, because the current message is a bit short.
> > >
> > > If you're not getting a core file then you can use the ulimit
command to
> > > turn that on. Then a core file (memory dump) will be produced the
next
> > > time you get a segfault. You can load that in gdb and do a backtrace
> > > command. If your binaries were built with sufficient debug info then
> > > you should see a stack trace showing where the crash occurred and
also
> > > the function calls leading up to the crash.
> >
> > I followed your advice and activated the core dump by the ulimit
> > command. In order to make sure that all involved binaries were built
> > with sufficient debug info, I added the flag -ggdb to CFLAGS in my the
> > /etc/make.conf file. Then I recompiled python, wxpython, numpy and
> > matplotlib so that they are built with the new flag (I don't use any
> > other libraries than that). When I run my script again, I get a file
> > called core in the directory. So I tried to look at it with gdb, but
> > there isn't much detail (see below). I don't have any experience with
> > this, so any help or pointer would be appreciated.
>
> Either the -ggdb flag wasn't used during the build or the debug info was
> stripped. I'm not familiar with Gentoo so I don't know the procedure
> doing things like this.

Yes, you were right, the debug was stripped and once I enabled it, I
managed to get a little bit more detailed backtrace. However I'm still
not entirely sure exactly which command in my program causes the
segmentation fault. I guess if someone can spot it quickly, I will be
very grateful. Thank you very much in advance. Here's the output of gdb:

$ gdb --core=core /usr/bin/python2.7
GNU gdb (Gentoo 7.3.1 p2) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/&gt;\.\.\.
Reading symbols from /usr/bin/python2.7...Reading symbols from
/usr/lib64/debug/usr/bin/python2.7.debug...done.
done.
[New LWP 7415]
[New LWP 7424]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Core was generated by `python2.7 ./mpl_latex_plot_v2.py'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f3ac27a5e4a in PyObject_Call (func=<optimized out>,
arg=0x282d4d0, kw=0x0)
at Objects/abstract.c:2527
2527 Objects/abstract.c: No such file or directory.
in Objects/abstract.c
(gdb) bt
#0 0x00007f3ac27a5e4a in PyObject_Call (func=<optimized out>,
arg=0x282d4d0, kw=0x0)
at Objects/abstract.c:2527
#1 0x00007f3ac2837e17 in PyEval_CallObjectWithKeywords (func=0x24e78c0,
arg=0x282d4d0,
kw=<optimized out>) at Python/ceval.c:3890
#2 0x00007f3aaee90ff8 in ?? () from
/usr/lib64/python2.7/site-packages/gobject/_gobject.so
#3 0x00007f3abf1434b2 in g_closure_invoke () from
/usr/lib64/libgobject-2.0.so.0
#4 0x00007f3abf154501 in ?? () from /usr/lib64/libgobject-2.0.so.0
#5 0x00007f3abf15c48e in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#6 0x00007f3abf15c942 in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#7 0x00007f3abfaaa441 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#8 0x00007f3abf990437 in gtk_main_do_event () from
/usr/lib64/libgtk-x11-2.0.so.0
#9 0x00007f3abf5e714c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#10 0x00007f3abf5e70fb in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#11 0x00007f3abf5e2116 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#12 0x00007f3abf5e42b1 in gdk_window_process_all_updates () from
/usr/lib64/libgdk-x11-2.0.so.0
#13 0x00007f3abf913c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x00007f3abf5c1956 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#15 0x00007f3abee5a553 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#16 0x00007f3abee5a8a0 in ?? () from /usr/lib64/libglib-2.0.so.0
#17 0x00007f3abee5ac9a in g_main_loop_run () from
/usr/lib64/libglib-2.0.so.0
#18 0x00007f3abf98f1c7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x00007f3ac0b24878 in wxEventLoop::Run() () from
/usr/lib64/libwx_gtk2u_core-2.8.so.0
#20 0x00007f3ac0b9dcab in wxAppBase::MainLoop() () from
/usr/lib64/libwx_gtk2u_core-2.8.so.0
#21 0x00007f3ac1256cd7 in MainLoop (this=0x21b2430) at src/helpers.cpp:215
#22 wxPyApp::MainLoop (this=0x21b2430) at src/helpers.cpp:205
#23 0x00007f3ac12b1ff7 in _wrap_PyApp_MainLoop (args=<optimized out>)
at src/gtk/_core_wrap.cpp:31691
#24 0x00007f3ac283d901 in ext_do_call (nk=0, na=<optimized out>,
flags=<optimized out>,

--
Robin Dunn
Software Craftsman

I have somewhat of a vague question, but I’m hoping that
someone can
give me a hint anyway. Some time ago I wrote a program with a
lot of
help from this email list using wxpython. Basically it was a
gui for
some of the features of matplotlib. I wrote it on Linux Mint and it
worked fine. Unfortunately that machine died, so I got a new one. I
decided to install gentoo linux on it and recently tried to run the
same
program. It runs all the way to the end (I know that because
the last
line in the program is saving the plotted figure, and the file is
created with the figure in it being just fine), however it crashes
after
every time it runs and I get the message “Segmentation fault”.
I don’t
think it is matplotlib itself, because when I run matplotlib
from the
command line it works fine. So I’m guessing it is a problem with
wxpython. Can someone give me advice how to fix that. For
starters, I
would like to get a little bit more detailed information on
what causes
the error, because the current message is a bit short.

If you’re not getting a core file then you can use the ulimit
command to
turn that on. Then a core file (memory dump) will be produced the
next
time you get a segfault. You can load that in gdb and do a backtrace
command. If your binaries were built with sufficient debug info then
you should see a stack trace showing where the crash occurred and
also
the function calls leading up to the crash.

I followed your advice and activated the core dump by the ulimit
command. In order to make sure that all involved binaries were built
with sufficient debug info, I added the flag -ggdb to CFLAGS in my the
/etc/make.conf file. Then I recompiled python, wxpython, numpy and
matplotlib so that they are built with the new flag (I don’t use any
other libraries than that). When I run my script again, I get a file
called core in the directory. So I tried to look at it with gdb, but
there isn’t much detail (see below). I don’t have any experience with
this, so any help or pointer would be appreciated.

Either the -ggdb flag wasn’t used during the build or the debug info was
stripped. I’m not familiar with Gentoo so I don’t know the procedure
doing things like this.

Yes, you were right, the debug was stripped and once I enabled it, I
managed to get a little bit more detailed backtrace. However I’m still
not entirely sure exactly which command in my program causes the
segmentation fault. I guess if someone can spot it quickly, I will be
very grateful. Thank you very much in advance. Here’s the output of gdb:

$ gdb --core=core /usr/bin/python2.7
GNU gdb (Gentoo 7.3.1 p2) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-pc-linux-gnu”.
For bug reporting instructions, please see:
http://bugs.gentoo.org/
Reading symbols from /usr/bin/python2.7…Reading symbols from
/usr/lib64/debug/usr/bin/python2.7.debug…done.
done.
[New LWP 7415]
[New LWP 7424]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need “set solib-search-path” or “set sysroot”?
[Thread debugging using libthread_db enabled]
Core was generated by `python2.7 ./mpl_latex_plot_v2.py’.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f3ac27a5e4a in PyObject_Call (func=,
arg=0x282d4d0, kw=0x0)
at Objects/abstract.c:2527
2527 Objects/abstract.c: No such file or directory.
in Objects/abstract.c
(gdb) bt
#0 0x00007f3ac27a5e4a in PyObject_Call (func=,
arg=0x282d4d0, kw=0x0)
at Objects/abstract.c:2527
#1 0x00007f3ac2837e17 in PyEval_CallObjectWithKeywords (func=0x24e78c0,
arg=0x282d4d0,
kw=) at Python/ceval.c:3890
#2 0x00007f3aaee90ff8 in ?? () from
/usr/lib64/python2.7/site-packages/gobject/_gobject.so
#3 0x00007f3abf1434b2 in g_closure_invoke () from
/usr/lib64/libgobject-2.0.so.0
#4 0x00007f3abf154501 in ?? () from /usr/lib64/libgobject-2.0.so.0
#5 0x00007f3abf15c48e in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#6 0x00007f3abf15c942 in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#7 0x00007f3abfaaa441 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#8 0x00007f3abf990437 in gtk_main_do_event () from
/usr/lib64/libgtk-x11-2.0.so.0
#9 0x00007f3abf5e714c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#10 0x00007f3abf5e70fb in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#11 0x00007f3abf5e2116 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#12 0x00007f3abf5e42b1 in gdk_window_process_all_updates () from
/usr/lib64/libgdk-x11-2.0.so.0
#13 0x00007f3abf913c41 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x00007f3abf5c1956 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#15 0x00007f3abee5a553 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#16 0x00007f3abee5a8a0 in ?? () from /usr/lib64/libglib-2.0.so.0
#17 0x00007f3abee5ac9a in g_main_loop_run () from
/usr/lib64/libglib-2.0.so.0
#18 0x00007f3abf98f1c7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x00007f3ac0b24878 in wxEventLoop::Run() () from
/usr/lib64/libwx_gtk2u_core-2.8.so.0
#20 0x00007f3ac0b9dcab in wxAppBase::MainLoop() () from
/usr/lib64/libwx_gtk2u_core-2.8.so.0
#21 0x00007f3ac1256cd7 in MainLoop (this=0x21b2430) at src/helpers.cpp:215
#22 wxPyApp::MainLoop (this=0x21b2430) at src/helpers.cpp:205
#23 0x00007f3ac12b1ff7 in _wrap_PyApp_MainLoop (args=)
at src/gtk/_core_wrap.cpp:31691
#24 0x00007f3ac283d901 in ext_do_call (nk=0, na=,
flags=,

Are you mixing wxPython with pygtk or some other Gnome Python
extensions? Line #2 above shows that the crash is coming from a
function called from the gobject extension module. There are no other
wx functions being called in the stack between the MainLoop and the crash.

Dear Robin, thank you so much! I finally figured out what the problem was and it was not to do with wxPython. As far as I know I was not using pygtk in my program per se, however I was using the default matplotlib backend, which in my matplotlibrc file was set to GTKAgg.
http://matplotlib.sourceforge.net/users/customizing.html#customizing-matplotlib
I changed that to WXAgg, and now everything is working like a charm! I’m not quite sure why GTKAgg is causing a segmentation fault though, maybe it requires some extra package, which I have not installed. Maybe when I have a bit more time in the future I’ll take a look at it. But for now I’m all set.
Anyway, I just wanted to thank you one more time for your amazing work with wxPython as well as with supporting users - you alone do more work than most entire technical support divisions in large software companies!
Best wishes,
George

You can also do it like this:

import matplotlib as mpl
mpl.use('wxagg')

I think that it has been recommended by MPL to use the wxagg backend over the wx backend for a long time now.

···

On 10/11/12 3:05 PM, Jared Kibele wrote:

I was having a very similar problem on Ubuntu 11.10. I was also running
a matplotlib graph from within a wxPython GUI and was getting a
segmentation fault right after the graph got drawn. I changed the
matplotlib backend to WXAgg and everything works fine again. I changed
the backend dynamically like so:

    import matplotlib as mpl
    mpl.rcParams['backend'] = 'WXAgg'

--
Robin Dunn
Software Craftsman