Summary: | Kmix crash on change volume of system notifies and on startup kde | ||
---|---|---|---|
Product: | [Applications] kmix | Reporter: | Vova <vova7890> |
Component: | Backend: Pulseaudio | Assignee: | Colin Guthrie <colin> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | esken |
Priority: | NOR | ||
Version: | 4 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Vova
2012-03-19 12:33:20 UTC
This should not happen. i will be null iff eol = 1. Is eol not checked first? (In reply to comment #1) > Is eol not checked first? Yes, eol is checked first. If pulseaudio ever supplies a null sink input pointer then there is a bug at the PA end, however I've not heard of this before and I would have expected a *lot* more bug reports upstream about this (I am upstream PA maintainer btw!) What version of PA are you using? Sorry for waiting, here my version of pulse [vova7890@localhost ~]$ pulseaudio --version pulseaudio 1.1 > i will be null iff eol = 1.
eol checked as
if (eol < 0)
it did not check for value 1
if (eol == 1) { dec_outstanding(c); /*if (s_mixers.contains(KMIXPA_PLAYBACK)) s_mixers[KMIXPA_PLAYBACK]->triggerUpdate();*/ return; } if (eol < 0) { if (pa_context_errno(c) == PA_ERR_NOENTITY) return; kWarning(67100) << "Sink callback failure"; return; } make like this, and this work! :) Original code, double check for eol < 0. May be this a bug? if (eol < 0) { if (pa_context_errno(c) == PA_ERR_NOENTITY) return; kWarning(67100) << "Sink callback failure"; return; } if (eol > 0) { dec_outstanding(c); if (s_mixers.contains(KMIXPA_PLAYBACK)) s_mixers[KMIXPA_PLAYBACK]->triggerUpdate(); return; } When i`m change kde notifies volume, with fix of check "eol == 1", it not changing, and scroll back to own place. Then press exit of kmix, and it crash on function(mixer_backend.cpp:105) void Mixer_Backend::readSetFromHW() at state: (line 155) kDebug() << "start controlChanged()"; // this I`m added for debug emit controlChanged(); kDebug() << "end controlChanged()"; log: kmix(12640) KMixWindow::saveViewConfig: Config (View) saving done kmix(12640) KMixWindow::saveVolumes: About to save config (Volume) kmix(12640) Mixer::volumeSave: Mixer::volumeSave() kmix(12640) Mixer_Backend::readSetFromHW: ---tick--- QTime("21:40:25") kmix(12640) Mixer_Backend::readSetFromHW: start controlChanged() KCrash: Application 'kmix' crashing... I think it falls because of the sound temporarily playing with the question "Close Kmix?" and adds a new sound slider, then disappears when kmix trying to refresh volume. The original check for "if (eol > 0)" should be sufficient. Clearly its the triggerUpdate() call that ultimately causes the problem. Smells to me it's just KMix generally not handling this nicely sadly, not a simple bug. A lot of re factoring recently has made it a lot more unstable in this regard. I think your original report is actually completely mis-representitive of the underlying problem. Can you get a backtrace from an unmodified version? I suspect you're falling into the same problem as others have recently relating to the viewDock stuff. Here back trace Application: KMix (kdeinit4), signal: Segmentation fault Using host libthread_db library "/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f9707d03780 (LWP 1254))] Thread 2 (Thread 0x7f96e44f6700 (LWP 1304)): #0 0x00007f970531a183 in poll () from /lib/libc.so.6 #1 0x00007f9702243996 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f9702243ac4 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f970696d126 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #4 0x00007f970693ce52 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #5 0x00007f970693d0a7 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0x00007f970683dd17 in QThread::exec() () from /usr/lib/libQtCore.so.4 #7 0x00007f970691cc9f in ?? () from /usr/lib/libQtCore.so.4 #8 0x00007f9706840d3b in ?? () from /usr/lib/libQtCore.so.4 #9 0x00007f96f7ef5454 in ?? () from /usr/lib/libGL.so.1 #10 0x00007f97065b0daa in start_thread () from /lib/libpthread.so.0 #11 0x00007f970532209d in clone () from /lib/libc.so.6 Thread 1 (Thread 0x7f9707d03780 (LWP 1254)): [KCrash Handler] #6 0x0000000000000000 in ?? () #7 0x00007f96f2d4e6c2 in MDWSlider::update (this=0x144cab0) at /media/fa63a191-fc8a-467c-b4ab-24a9e81ecb9d/kmix/kdemultimedia-4.8.1/kmix/gui/mdwslider.cpp:1001 #8 0x00007f96f2d4a079 in ViewDockAreaPopup::refreshVolumeLevels (this=<optimized out>) at /media/fa63a191-fc8a-467c-b4ab-24a9e81ecb9d/kmix/kdemultimedia-4.8.1/kmix/gui/viewdockareapopup.cpp:168 #9 0x00007f9706951f11 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #10 0x00007f9706951f11 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #11 0x00007f96f2d29808 in Mixer_Backend::readSetFromHW (this=0x14b9980) at /media/fa63a191-fc8a-467c-b4ab-24a9e81ecb9d/kmix/kdemultimedia-4.8.1/kmix/backends/mixer_backend.cpp:155 #12 0x00007f96f2d382d7 in sink_cb (c=<optimized out>, i=0x0, eol=<optimized out>) at /media/fa63a191-fc8a-467c-b4ab-24a9e81ecb9d/kmix/kdemultimedia-4.8.1/kmix/backends/mixer_pulse.cpp:191 #13 0x00007f96f75d5a94 in ?? () from /usr/lib/libpulse.so.0 #14 0x00007f96f43b5303 in ?? () from /usr/lib/libpulsecommon-1.1.so #15 0x00007f96f43b5673 in pa_pdispatch_run () from /usr/lib/libpulsecommon-1.1.so #16 0x00007f96f75cc1ed in ?? () from /usr/lib/libpulse.so.0 #17 0x00007f96f43b9f19 in ?? () from /usr/lib/libpulsecommon-1.1.so #18 0x00007f96f73b8ac3 in ?? () from /usr/lib/libpulse-mainloop-glib.so.0 #19 0x00007f970224363a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #20 0x00007f9702243a00 in ?? () from /usr/lib/libglib-2.0.so.0 #21 0x00007f9702243ac4 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #22 0x00007f970696d0bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #23 0x00007f9705b50f8e in ?? () from /usr/lib/libQtGui.so.4 #24 0x00007f970693ce52 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #25 0x00007f970693d0a7 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #26 0x00007f9706941c05 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #27 0x00007f96f2d3bcd8 in kdemain (argc=1, argv=0x10c0ce0) at /media/fa63a191-fc8a-467c-b4ab-24a9e81ecb9d/kmix/kdemultimedia-4.8.1/kmix/apps/main.cpp:76 #28 0x00000000004083e4 in _start () Yup, the viewdockarea features in the backtrace as suspected. I think this is a dupe. *** This bug has been marked as a duplicate of bug 290742 *** |