Red Hat Bugzilla – Bug 974295
[abrt] mate-media-1.6.0-2.fc19: mate_volume_control_track_free: Process /usr/bin/mate-volume-control was killed by signal 11 (SIGSEGV)
Last modified: 2014-06-21 12:48:14 EDT
Version-Release number of selected component: mate-media-1.6.0-2.fc19 Additional info: reporter: libreport-2.1.4 backtrace_rating: 4 cmdline: mate-volume-control crash_function: mate_volume_control_track_free executable: /usr/bin/mate-volume-control kernel: 3.9.4-301.fc19.x86_64 runlevel: N 5 uid: 1000 xsession_errors: ** (mate-volume-control-applet:1772): WARNING **: Connection failed, reconnecting... Truncated backtrace: Thread no. 1 (10 frames) #0 mate_volume_control_track_free at track.c:585 #1 mate_volume_control_element_change at element.c:332 #2 window_change_mixer_element at window.c:162 #3 g_cclosure_marshal_VOID__STRINGv at gmarshal.c:1004 #4 _g_closure_invoke_va at gclosure.c:840 #7 g_settings_real_change_event at gsettings.c:288 #8 ffi_call_unix64 at ../src/x86/unix64.S:76 #9 ffi_call at ../src/x86/ffi64.c:522 #10 g_cclosure_marshal_generic_va at gclosure.c:1550 #11 _g_closure_invoke_va at gclosure.c:840 Potential duplicate: bug 890267
Created attachment 760968 [details] File: backtrace
Created attachment 760969 [details] File: cgroup
Created attachment 760970 [details] File: core_backtrace
Created attachment 760971 [details] File: dso_list
Created attachment 760972 [details] File: environ
Created attachment 760973 [details] File: limits
Created attachment 760974 [details] File: maps
Created attachment 760975 [details] File: open_fds
Created attachment 760976 [details] File: proc_pid_status
Created attachment 760977 [details] File: var_log_messages
Can you describe a little more detailed what's happend? Does this error ocours frequently?
(In reply to Wolfgang Ulbrich from comment #11) > Can you describe a little more detailed what's happend? > Does this error ocours frequently? For me, when I try to open mate-volume-control for the first time, if I select either of the ""playback: pulseaudio"" devices, it crashes. Then, if I try to reopen it, it crashes instantly. Oddly, approximately 1 out of 10 times it doesn't crash instantly upon opening, but if I try to interact with it, e.g select a device, it crashes. After issuing this command ""dconf reset /org/mate/volume-control/active-element"" I can reopen it again without crashing instantly, but as before if I select either of those pulseaudio devices then we're back to crash-loop. [shawn@localhost ~]$ mate-volume-control ** (mate-volume-control:6505): CRITICAL **: gst_pulsemixer_list_tracks: assertion 'this->mixer != NULL' failed ** (mate-volume-control:6505): CRITICAL **: gst_pulsemixer_list_tracks: assertion 'this->mixer != NULL' failed Segmentation fault (core dumped) Please let me know if I can offer any more useful info,.. I know you are very busy, but I'd like to help :)
I guess it happens on the alsa ones too: [shawn@localhost ~]$ mate-volume-control ** (mate-volume-control:7622): CRITICAL **: gst_alsa_mixer_element_list_tracks: assertion 'this->mixer != NULL' failed ** (mate-volume-control:7622): CRITICAL **: gst_alsa_mixer_element_list_tracks: assertion 'this->mixer != NULL' failed Segmentation fault (core dumped)
Can you attach a new backtrace, this report is quite old? Go to /var/tmp/abrt/<folder-of-issue>/ Run 'abrt-action-generate-backtrace' and check the backtrace for lines with (*). This means no debuginfo package is installed. Run debuginf-install for all packages marked with (*). Then run 'abrt-action-generate-backtrace' again. If you use pavucontrol from the menu or terminal, do you have the same issue?
Created attachment 899387 [details] backtrace as requested in comment #14
(In reply to Wolfgang Ulbrich from comment #14) > Can you attach a new backtrace, this report is quite old? > Go to /var/tmp/abrt/<folder-of-issue>/ > Run 'abrt-action-generate-backtrace' and check the backtrace for lines with > (*). This means no debuginfo package is installed. > Run debuginf-install for all packages marked with (*). > Then run 'abrt-action-generate-backtrace' again. > > If you use pavucontrol from the menu or terminal, do you have the same issue? Sorry I took a while to get this backtrace, haven't been home for a week. Ok, backtrace is posted. Yes, pavucontrol works. I am still trying to get mate-volume-control to work, though. I think this might be a duplicate of this https://bugzilla.redhat.com/show_bug.cgi?id=1045742 I will try recompiling it with these changes, unless you have any other suggestions: http://pkgs.fedoraproject.org/cgit/mate-media.git/commit/?id=874bb5bc2722e3d360704df5fa09802b9835bf88 Regarding comment #1 (on bug 1045742), is there a way to remove pulseaudio from f20 and still have sound? I asked this in the IRC channel and was told it was impossible Thank you in advance for your reply :)
Ok, mate-media f19/f20 is also compiles with 'gstmixer applet'. This cause the issue for switching sound devices with 'sound applet in systray'. For f21 i switched complete to pulse-audio which fix that, but in result of this change the 'gstmixer applet' is complete gone. I do not want the same for f19/f20 during a release cycle because i expected that a lot of other users prever using good old gstmixer. But i've 2 solutions for you. 1. install/using 'pnmixer', with that mixer systray applet you can choose which mixer backend you want to use, choose pavucontrol. Add it to autostart and disable the the normal applet in autostart. 2. Yes, it is possible to prevent pulseaudio from session start with a dirty trick ;) Edit this line. ; daemon-binary = /usr/bin/pulseaudio [root@mother rave]# cat /etc/pulse/client.conf <snip> daemon-binary = /usr/bin/pulseaudio-shit <snip> The wrong binary path did his work. And remove pulseaudio-x11 package. Than the sound comes directly from alsa and the normal mixer systray applet doesn't start, you need to add the gstreamer applet to the panel in this case. This is what i do........ PS: If you want to rebuild mate-media without gstreamer-mixer use that spec file https://dl.dropboxusercontent.com/u/49862637/Mate-desktop/Test/mate-media.spec ...maybe use a higher version to prevent updating the package from fedora.
(In reply to Wolfgang Ulbrich from comment #17) Thank you! So many solutions :) I choose to recompile it :)