DevHeads.net

Weird libprojectM C++ segfaults

Two crash backtraces in this mail. Does anyone have an idea what might be
wrong there?

Simply linking any Audacious plugin with -lprojectM leads to a segfault on
application exit. In other words, even if the library is not used but just
linked with, app exit segfaults. That's an indication that something in
the library, which is initialized when the run-time linker binds the app
with the library, gets destroyed on exit and then crashes in the
std::basic_string destructor. Building the packages for Fedora 13, it's
reproducible. Audacious upstream (uses Ubuntu and/or Debian) cannot
reproduce it, however.

$ audacious
[quit]
Segmentation fault (core dumped)

(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00000038ace9d3b9 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /usr/lib64/libstdc++.so.6
#2 0x000000389fa3636d in __cxa_finalize (d=0x7fffebd54420)
at cxa_finalize.c:56
#3 0x00007fffebb52ee6 in __do_global_dtors_aux ()
from /usr/lib64/audacious/Visualization/projectm-1.0.so
#4 0x0000000000000034 in ?? ()
#5 0x00007fffffffd300 in ?? ()
#6 0x00007fffebb53c41 in _fini ()
from /usr/lib64/audacious/Visualization/projectm-1.0.so
#7 0x00007fffffffd300 in ?? ()
#8 0x000000389f613d9e in _dl_close_worker (map=<value optimized out>)
at dl-close.c:271
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Fedora 13's ABRT (Automatic Bug Reporting Tool) doesn't manage to catch
these crashes. If I just link an arbitrary Audacious plugin with
-lprojectM (and really without doing any API calls), the backtrace
is a bit different:

#0 0x0000000000000000 in ?? ()
#1 0x00007fffe601437d in ~_Rb_tree (this=<value optimized out>, __in_chrg=<value optimized out>)
at /usr/include/c++/4.4.4/bits/stl_tree.h:614
#2 std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Func*, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Func*> > >::~map (this=<value optimized out>, __in_chrg=<value optimized out>)
at /usr/include/c++/4.4.4/bits/stl_map.h:87
#3 0x000000389fa35fd2 in __run_exit_handlers (status=0) at exit.c:78
#4 exit (status=0) at exit.c:100
#5 0x0000000000411d53 in aud_quit () at main.c:376
#6 0x00000038a1e0b98e in IA__g_closure_invoke (closure=0xa2c3a0, return_value=0x0, n_param_values=1, param_values=
0xc87e20, invocation_hint=0x7fffffffd640) at gclosure.c:767
#7 0x00000038a1e1f947 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0xa3aad0,
emission_return=0x0, instance_and_params=0xc87e20) at gsignal.c:3248
#8 0x00000038a1e20de6 in IA__g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>,
detail=<value optimized out>, var_args=0x7fffffffd830) at gsignal.c:2981
#9 0x00000038a1e213a3 in IA__g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>,
detail=<value optimized out>) at gsignal.c:3038
#10 0x00007fffece01efe in ?? ()
#11 0x0000000000a39a00 in ?? ()
#12 0x00000038a1e0b98e in IA__g_closure_invoke (closure=0xa3aad0, return_value=0x0, n_param_values=1, param_values=
0xbee300, invocation_hint=0x7fffffffda50) at gclosure.c:767
#13 0x00000038a1e1f228 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0xa3aad0,
emission_return=0x0, instance_and_params=0xbee300) at gsignal.c:3178
#14 0x00000038a1e20de6 in IA__g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>,
detail=<value optimized out>, var_args=0x7fffffffdc40) at gsignal.c:2981
#15 0x00000038a1e213a3 in IA__g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>,
detail=<value optimized out>) at gsignal.c:3038
#16 0x00007fffece01f9a in ?? ()
#17 0x00000000008df5c0 in ?? ()
#18 0x0000000000a3aad0 in ?? ()
#19 0x00000000008df5c0 in ?? ()
#20 0x00007fffffffdf00 in ?? ()
#21 0x00000000008df5c0 in ?? ()
#22 0x00000038a9351003 in _gtk_marshal_BOOLEAN__BOXED (closure=0xa394d0, return_value=0xa3aad0,
n_param_values=<value optimized out>, param_values=0xe22f80, invocation_hint=<value optimized out>,
marshal_data=<value optimized out>) at gtkmarshalers.c:84
#23 0x00000038a1e0b98e in IA__g_closure_invoke (closure=0x8df5c0, return_value=0x7fffffffdf00, n_param_values=2,
param_values=0xe22f80, invocation_hint=0x7fffffffdec0) at gclosure.c:767
#24 0x00000038a1e1f59c in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0xa3aad0,
emission_return=0x7fffffffe050, instance_and_params=0xe22f80) at gsignal.c:3286
#25 0x00000038a1e20c29 in IA__g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>,
detail=<value optimized out>, var_args=0x7fffffffe0b0) at gsignal.c:2991
#26 0x00000038a1e213a3 in IA__g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>,
detail=<value optimized out>) at gsignal.c:3038
#27 0x00000038a948190f in gtk_widget_event_internal (widget=0xa3aad0 [UiSkinnedButton], event=0xbe7190)
at gtkwidget.c:4958
#28 0x00000038a9347d63 in IA__gtk_propagate_event (widget=0xa3aad0 [UiSkinnedButton], event=0xbe7190) at gtkmain.c:2442
#29 0x00000038a9348f2b in IA__gtk_main_do_event (event=0xbe7190) at gtkmain.c:1647
#30 0x00000038a726039c in gdk_event_dispatch (source=<value optimized out>, callback=<value optimized out>,
user_data=<value optimized out>) at gdkevents-x11.c:2372
#31 0x00000038a123bd02 in g_main_dispatch (context=0x8a5740) at gmain.c:1960
#32 IA__g_main_context_dispatch (context=0x8a5740) at gmain.c:2513
#33 0x00000038a123fae8 in g_main_context_iterate (context=0x8a5740, block=1, dispatch=1, self=<value optimized out>)
at gmain.c:2591
#34 0x00000038a123fff5 in IA__g_main_loop_run (loop=0x9cbaf0) at gmain.c:2799
#35 0x00000038a93493c7 in IA__gtk_main () at gtkmain.c:1219
#36 0x00007fffecdf571a in ?? ()
#37 0x0000000000967820 in ?? ()
#38 0x00007fffed02f980 in ?? ()
#39 0x0000000000000001 in ?? ()
#40 0x0000000000000000 in ?? ()

Comments

Re: Weird libprojectM C++ segfaults

By Orcan Ogetbil at 07/23/2010 - 13:38

On Fri, Jul 23, 2010 at 12:57 PM, Michael Schwendt wrote:
Can you tell us what nvr of libprojectM you are using? There was a
bug I fixed in 2.0.1-7, which caused crashes due to wrong font paths
set in the code. Since we are not bundling fonts with regular
packages, the code needed to point to system fonts. I asked this build
to put in buildroot override at
<a href="https://fedorahosted.org/rel-eng/ticket/3899" title="https://fedorahosted.org/rel-eng/ticket/3899">https://fedorahosted.org/rel-eng/ticket/3899</a>

Your backtrace looks quite different though. Might a different bug
since you are not even using the API. It would help if you give the
involved nvrs, and links to your audacious SRPMs that crash with
libprojectM.

Orcan

Re: Weird libprojectM C++ segfaults

By Michael Schwendt at 07/23/2010 - 14:25

Meanwhile, it's 2.0.1-7.fc13 (just fetched from updates-testing).

<a href="http://mschwendt.fedorapeople.org/audacious-plugins-2.2-34.fc13.projectMlinked.src.rpm" title="http://mschwendt.fedorapeople.org/audacious-plugins-2.2-34.fc13.projectMlinked.src.rpm">http://mschwendt.fedorapeople.org/audacious-plugins-2.2-34.fc13.projectM...</a>

That's the current F-13 package with only a minor modification:
Pulse Audio output plugin is linked with -lprojectM and doesn't use
the API in any way:

$ audacious
[CTRL+Q]
Segmentation fault (core dumped)

$ sudo rm /usr/lib64/audacious/Output/pulse_audio.so
$ audacious
[CTRL+Q]
$

Re: Weird libprojectM C++ segfaults

By Michael Schwendt at 07/23/2010 - 14:40

Hmmm, building the same pkgs on Rawhide, the problem is not reproducible.

gcc-c++ or libstdc++ issue in F-13? I originally discovered the segfault
on June 13th on Rawhide.