Bug 296349

Summary: Kmix crash on change volume of system notifies and on startup kde
Product: [Applications] kmix Reporter: Vova <vova7890>
Component: Backend: PulseaudioAssignee: 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
In function
static void sink_cb(pa_context *c, const pa_sink_info *i, int eol, void *)

sometime received NULL of pointer "const pa_sink_info *i", and it can not correctly take a value. If add at start of function (mixer_pulse.cpp:178)
[code]
    if(!i) {
        kWarning(67100) << "Sink callback failure. pa_sink_info *i == 0x0";
        dec_outstanding(c);
        return;
    }
[/code]

it not crash when changing volume of notifies and did not seem to fall at startup. A have a bug in system, volume of notify kde can not change, and when I`m moved the slider - it back in place. Perhaps this contributed to malfunction kmix.

Thanx.
Comment 1 Colin Guthrie 2012-03-19 12:38:21 UTC
This should not happen.

i will be null iff eol = 1.

Is eol not checked first?
Comment 2 Colin Guthrie 2012-03-19 12:42:01 UTC
(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?
Comment 3 Vova 2012-03-20 19:04:57 UTC
Sorry for waiting, here my version of pulse
[vova7890@localhost ~]$ pulseaudio --version
pulseaudio 1.1
Comment 4 Vova 2012-03-20 19:10:56 UTC
> i will be null iff eol = 1.

eol checked as
if (eol < 0) 

it did not check for value 1
Comment 5 Vova 2012-03-20 19:21:03 UTC
    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;
    }
Comment 6 Vova 2012-03-20 19:46:31 UTC
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...
Comment 7 Vova 2012-03-20 20:03:42 UTC
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.
Comment 8 Colin Guthrie 2012-03-23 18:41:26 UTC
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.
Comment 9 Vova 2012-03-23 19:51:21 UTC
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 ()
Comment 10 Colin Guthrie 2012-03-24 21:21:35 UTC
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 ***