Created attachment 41061 [details]
File Okular crashes on when opening it

rpm -q poppler-qt4 
?

Confirmed crash using poppler-0.12.4, and having switched to phonon-xine backend.  (no crash using -gstreamer)

My poppler version is 0.12.4, not that I think it matters.

Having others (e.g. Rex) try opening the PDF the data suggests that the crash might only happen with the xine backend for Phonon, but not with the GStreamer backend. I'm CC'ing Martin just in case.

Interesting.

The sequence, triggering the crash, and including QPixmap::grabWidget (starting from #22) is similar to several crash reports in the new "animated" oxygen style. 
Some of them I was not able to fix so far. I wonder if this does not point to some lower level (Qt) race condition ...
Anyway. Adding myself in cc.

*** Bug 228456 has been marked as a duplicate of this bug. ***

Gah, pulse crap running a local event loop...

*** Bug 230979 has been marked as a duplicate of this bug. ***

Can some phonon guy please take a look at the pulse crap stuff, pretty please?

Yeah I feel really motivated to help because you've been so respectful. If you are seeking help from people on an issue, insulting their work is generally not the most stellar of approaches...

Anyway, it's clearly a bug I've introduced somewhere. I can replicate via:
 1. Use Xine *or* GStreamer backend.
 2. Stop PA.
 3. Start any phonon client.
or simply by leaving PA running and:
 1. PHONON_PULSEAUDIO_DISABLE=1 kcm

I certainly tested this use case when I developed the integration, so I'm not quite sure what has caused this regression, but I suspect the latest few changes I did in libphonon introduced this behaviour (in a bid to make the code more friendly to backends that did not support PA integration).

I'm surprised I've not had more reports of this as this code has been in Mandriva for a long time. I guess most folks are sticking with our default PA-based setup these days....

I'll take a look ASAP.

(In reply to comment #10)
> Yeah I feel really motivated to help because you've been so respectful. If you
> are seeking help from people on an issue, insulting their work is generally not
> the most stellar of approaches...

I call pulseaudio "pulse crap" for my reasons, not the phonon work (even if it's still buggy, but that's another story).
Fair enough, don't help if you don't feel it to.

All calm down please, like it's the first time someone introduces a regression somewhere, if you didn't introduce a new bug in a KDE release you're not really a KDE developer yet.

That said, Colin i'd like you to please have a look at it, tell me if there's anything we can do from the Okular side.

> Anyway, it's clearly a bug I've introduced somewhere. I can replicate via:
>  1. Use Xine *or* GStreamer backend.
>  2. Stop PA.
>  3. Start any phonon client.
> or simply by leaving PA running and:
>  1. PHONON_PULSEAUDIO_DISABLE=1 kcm

It is great news that this bug has been pinpointed and is being worked on. In the meantime, is there a workaround ? A way to disable sound entirely ? A way to make phonon believe there is a pulseaudio running ? A way to have pulseaudio running only for phonon ?

I really hate the way phonon sucks CPU cycles and don't want to install it again.

Are you sure you're in the right bug report, Éric? This is about an Okular crash, not sucking CPU cycles.

Let's stay on the issue.

Sorry, I didn't see bug #230979. Thanks to Albert for pointing it out on IRC :).

Just wanted to prevent the thread from becoming yet another anti-PA flame-fest, the "sucking CPU cycles" bit kinda triggered a mental alert there.

Colin: I have PulseAudio installed and running with PA integration enabled, btw, and it's crashing.

OK, some updates:

I was able to reproduce an issue here (Mandriva Cooker) whereby the simple command:
  PHONON_PULSEAUDIO_DISABLE=1 kcmshell4 kcm_phonon
would hang indefinitely. If you use pulseaudio and this environment variable bypasses the whole autodetection of PA and assumes it's not there. With this variable set, the event loop for PA detection does not fire and it doesn't start *any* main loop. If you do not set this variable, but do not run PA (nor have it configured for autospawn), then the mainloop will startup but should exit soon after.

I could demonstrate the same issue with running okular with the PDF file but the above seemed simpler.


So while investigating this, when starting up kcm_phonon, I noticed a fairly significant delay and some mention of:
kcmshell(2636) DevicePreference::updateAudioCaptureDevices:
Connecting to Coherence... 

After a while I got:
kcmshell(2346)/phonon (KDE plugin): QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") 


When running with PA the GUI appeared at this point. When running sans PA the GUI never showed up and the DBus error repeated several times if I left it long enough.

So I checked our packages and reverted the coherence stuff, namely this patch:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kdelibs4/current/SOURCES/kdelibs-4.4.1-sync-solid-with-trunk.patch?view=log

And things worked fine, without any delay in both cases \o/

Now all that said, I'm now no longer sure I'm getting the same bug as this one! I definitely had an issue, that much is certain, but I wonder if there is more at play!

Can someone who is seeing the crash please try:

PHONON_PULSEAUDIO_DEBUG=3 kcmshell4 kcm_phonon
 and
PHONON_PULSEAUDIO_DEBUG=3 PHONON_PULSEAUDIO_DISABLE=1 kcmshell4 kcm_phonon

and let me know if it's failing for them. If someone does use PA and suffers a crash that would be interesting too. I'm not really seeing much in the backtrace that highlights an obvious problem.


Also in my tests I just got hangs, not actual crashes. I couldn't make okular crash at all no matter how much I tried. Hang, yes, but not crash. Without being able to reproduce myself it's pretty tricky to work out what is going on :s

As a wild stab in the dark that some okularites may be able to know off hand, could there be some calls to libxml2's xmlCleanupParser() function anywhere? If so this is most likely the problem...


In the meantime I'll try and diagnose the coherence problem but i'll try not to pollute this bug with that info just now unless it turns out to be relevant.

PS meant to say feel free to ping me on IRC about this if you like: coling on #phonon, #pulseaudio or #mandriva-kde (and several others but these are vaguely relevant :D)

(In reply to comment #16)
> Connecting to Coherence... 

This is trunk-specific stuff, irrelevant for KDE 4.4.0 (was not even developed at the time KDE 4.4.0 was released).

> Can someone who is seeing the crash please try:

As side note, it seems all the bug reporters use Fedora.

> As a wild stab in the dark that some okularites may be able to know off hand,
> could there be some calls to libxml2's xmlCleanupParser() function anywhere? If
> so this is most likely the problem...

http://lxr.kde.org/search?filestring=&string=xmlCleanupParser
How can LibXml2 be the issue when this is clearly PA-stuff crashing?
See the backtraces: they show you are running a local even loop, which is something to be done *very* carefully (for example in okular we had issues in the past due to that in the chm backend); a suggestion could be limit the events processed by that (see its apidox).
(Also note that every time you call ->exit() on that event loop, you reset its pointer to 0, leaking the event loop object.)

(In reply to comment #18)
> (In reply to comment #16)
> > Connecting to Coherence... 
> 
> This is trunk-specific stuff, irrelevant for KDE 4.4.0 (was not even developed
> at the time KDE 4.4.0 was released).

Yeah I realise that the issue I was initially seeing is actually most likely irrelevant. Todo++ tho' :s

> > Can someone who is seeing the crash please try:
> 
> As side note, it seems all the bug reporters use Fedora.

Yeah I've also noticed this while chatting on IRC about 5mins ago :)
 
> > As a wild stab in the dark that some okularites may be able to know off hand,
> > could there be some calls to libxml2's xmlCleanupParser() function anywhere? If
> > so this is most likely the problem...
> 
> http://lxr.kde.org/search?filestring=&string=xmlCleanupParser
> How can LibXml2 be the issue when this is clearly PA-stuff crashing?

Calling that function when not exiting the app can quite easily crash libraries that are making use of libxml2 like libpulse. It's a pretty major flaw in libxml2 TBH. More info:
http://0pointer.de/blog/projects/beware-of-xmlCleanupParser.html
http://lists.fedoraproject.org/pipermail/devel/2010-January/129117.html

> See the backtraces: they show you are running a local even loop, which is
> something to be done *very* carefully (for example in okular we had issues in
> the past due to that in the chm backend); a suggestion could be limit the
> events processed by that (see its apidox).

Interesting, I'll take a look. I basically need to allow the glib eventloop to run in order to attempt the connection to PA (as it's all async I need to allow it to process events) If there are nicer ways to do that I'm certainly open to suggestions :) I wonder if I can do something at the libpulse end... I'll look.

> (Also note that every time you call ->exit() on that event loop, you reset its
> pointer to 0, leaking the event loop object.)

Hmm, yeah :s I'm not sure it's a good idea to delete it after I call ->exit() on it as it's within the context of a callback triggered when running the eventloop itself. I'm sure I can figure something out to work around this tho'. It wont leak too much, but it certainly still needs addressing.

Oh and PHONON_PULESAUDIO_DISABLE=1 does seem to avoid the problem (according to tests by Rex), so as a work around just add this to your .bashrc or something.

OK, I think I know how I can rework the connection test to be a little nicer and avoid the QEventLoop, but it'll take me a while to test implement it. Should hopefully have something to test in a day or two but depends on work commitments. Not 100% sure it'll solve the issue but it should be a tidyup anyway

Created attachment 41703 [details]
Rework the connection logic to block and test + reconnect

Here is a quick and dirty patch that I've really not tested all that much.

I wont release this as it currently stands but this does totally rework the connection to PA to avoid the use of a QEventLoop. It starts off by trying to connect and does so in a blocking fashion. If that fails it bails out and falls back to non-PA mode. If it succeeds, it disconnects and then reconnects via a nicely integrated glib main loop.

The one problem with this is that when running on top of PA the devices themselves don't actually get read until slightly after the pulse support object is created and thus a little popup message is displayed to the user to let them know it's "falling back" to a working device.

In order to fix that regression I'd presumably need to process the main loop events until the initialisation stuff is complete... I do wonder if this process will ultimately trigger the same bug tho' :s

Anyway, if someone could test to see if this fixes the crash in okular that would be helpful. It would at least help pinpoint the problem on the QMainLoop stuff. It should be applied against libphonon.

Created attachment 41709 [details]
Update connection logic

OK, here is an updated patch.

The connection logic is still a two phase affair but during the probing phase we do our initial read of the info we need. This way we:
 1) Try and connect to PA.
 2) If it succeeds:
  a) Read device info
  b) Exit.
  c) Reconnect via non-blocking (i.e. glib) main loop
  After some iterations of the loop we will ultimately:
  d) Setup subscriptions to be informed when device info changes.
  e) Re-read device info.
 3) If it fails to connect during probe we just skip the whole affair and everything should be as if PA is not enabled at all.

This should avoid the iteration of the mainloop and block while PA is probed, but if PA is available we'll already have populated our device info lists and no strange behaviour results from that.

Please let me know if this solves the issue. If it doesn't I think it's probably still a neater approach, but I'll have to get my thinking cap on some more.

(In reply to comment #16)

So I made the tests

          kcmshell4 kcm_phonon
or
          PHONON_PULSEAUDIO_DISABLE=1 kcmshell4 kcm_phonon
or
          PHONON_PULSEAUDIO_DEBUG=3 kcmshell4 kcm_phonon
or
          PHONON_PULSEAUDIO_DEBUG=3 PHONON_PULSEAUDIO_DISABLE=1 kcmshell4 kcm_phonon

work equally well; I can select tabs, items and click buttons. The _DEBUG=3 versions don't give more stderr output.

With the file https://bugs.kde.org/attachment.cgi?id=41688 attached to bug 230979

            okular o.pdf
or
            PHONON_PULESAUDIO_DISABLE=1 okular o.pdf

crash in the same way.
> and let me know if it's failing for them. If someone does use PA and suffers a
> crash that would be interesting too. I'm not really seeing much in the
> backtrace that highlights an obvious problem.
> 
> 
> Also in my tests I just got hangs, not actual crashes. I couldn't make okular
> crash at all no matter how much I tried. Hang, yes, but not crash. Without
> being able to reproduce myself it's pretty tricky to work out what is going on
> :s
> 
> As a wild stab in the dark that some okularites may be able to know off hand,
> could there be some calls to libxml2's xmlCleanupParser() function anywhere? If
> so this is most likely the problem...
> 
> 
> In the meantime I'll try and diagnose the coherence problem but i'll try not to
> pollute this bug with that info just now unless it turns out to be relevant.

(In reply to comment #24)
> (In reply to comment #16)
> 
> So I made the tests
...
> work equally well; I can select tabs, items and click buttons. The _DEBUG=3
> versions don't give more stderr output.

I think I confused this issue with another, unrelated one I was experiencing at the time so sadly the above are probably not relevant to this bug after all. Sorry about that but thanks all the same :D

> With the file https://bugs.kde.org/attachment.cgi?id=41688 attached to bug
> 230979
> 
>             okular o.pdf
> or
>             PHONON_PULESAUDIO_DISABLE=1 okular o.pdf
> 
> crash in the same way.

This is interesting as I think Rex said it solved the issue for him on IRC.... When it crashes can you grab the backtrace and attach it here?

Initial testing of the patch from comment #23 is a success for me.  I no longer experience crashes with the test-case pdf, and other basic phonon-related tasks/apps continue to work as expected.  Thanks Colin.

After installing the patched packages Rex made available for Fedora, Okular no longer crashes here when opening the PDF :).

Created attachment 41722 [details]
backtrace for PHONON_PULESAUDIO_DISABLE=1 okular o.pdf

Here is the backtrace you asked for, when 
running PHONON_PULESAUDIO_DISABLE=1 okular o.pdf

The backtrace without the environment variable is in bug https://bugs.kde.org/show_bug.cgi?id=230979

(In reply to comment #28)
> Created an attachment (id=41722) [details]
> backtrace for PHONON_PULESAUDIO_DISABLE=1 okular o.pdf
                          ^^
> Here is the backtrace you asked for, when 
> running PHONON_PULESAUDIO_DISABLE=1 okular o.pdf
                    ^^

Ahh crap that explains it. I typo'ed the above in comment:20. Sorry, I should have copied and pasted it... it was late and I was tired. Sorry for the wasted effort there :(

For reference the correct command is:
  PHONON_PULSEAUDIO_DISABLE=1 okular o.pdf

Anyway, seems like Pino was on the right track with the eventloop borkedness which I reworked and now seems to be sorted with the latest patch :)

(In reply to comment #29)
> > backtrace for PHONON_PULESAUDIO_DISABLE=1 okular o.pdf
>                                              ^^
> Ahh crap that explains it. I typo'ed the above in comment:20. Sorry, I should
> have copied and pasted it... it was late and I was tired. Sorry for the wasted
> effort there :(
> 
Sorry, I should have seen it. There a no longer any crash with the correct environment variable.

(In reply to comment #27)
> After installing the patched packages Rex made available for Fedora, Okular no
> longer crashes here when opening the PDF :).

What fedora packages ? Are they publicly available ?

Yes, they're in the unstable branch of kde-redhat (the KDE team's staging repository).

(In reply to comment #32)
> Yes, they're in the unstable branch of kde-redhat (the KDE team's staging
> repository).

Thanks, I found them, and okular no longer crashes (The result is visually incorrect when the video is not playing as there is a black rectangle instead of the image I asked to display, but I guess it's another bugreport.)

I have never used kde-redhat and have always relied on the official fedora package. Is it worthwhile to switch ? What are the differences between both sets of packages ?

The kde-redhat repository is sometimes used for experimental stuff like in this case, before it's send to the updates-testing repository. It also tends to have the same packages the KDE team sends to updates-testing, for KDE users who want the latest KDE updates without getting all of updates-testing. I.e. "switching" is not the right term. It's mostly a staging area for things that usually swiftly show up in your normal updates anyway.

But this is really more a topic for the fedora-kde mailing list or the #fedora-kde IRC channel :).

OK, so this patch hasn't caused anyone to shout and complain so I'll commit it :)

commit 1ffbb1a5603f8d3cbcdd7d0bcb4b9bddc1b45b24
Author: Colin Guthrie <cguthrie@mandriva.org>
Date:   Wed Mar 17 19:42:47 2010 +0000

    pulse: Rework the connection probing logic.
    
    Completely rework the connection to PA to avoid the use of a QEventLoop.
    It starts off by trying to connect via a pa_mainloop and in a blocking fashion.
    If that fails, then we simply carry on as if PA doesn't exist.
    If it succeeds, it reads in all the information about sinks/sources and then
    disconnects before reconnecting via the nicely integrated glib main loop.
    
    By avoiding the use of a QEventLoop, it fixes strange problems in some applications
    such as okular.
    
    BUG: 228324

diff --git a/phonon/pulsesupport.cpp b/phonon/pulsesupport.cpp
index e12c44f..642843f 100644
--- a/phonon/pulsesupport.cpp
+++ b/phonon/pulsesupport.cpp
@@ -135,7 +135,6 @@ static bool s_pulseActive = false;
 
 static pa_glib_mainloop *s_mainloop = NULL;
 static pa_context *s_context = NULL;
-static QEventLoop *s_connectionEventloop = NULL;
 
 
 
@@ -179,31 +178,25 @@ static void createGenericDevices()
 }
 
 #ifdef HAVE_PULSEAUDIO_DEVICE_MANAGER
-static void ext_device_manager_subscribe_cb(pa_context *, void *);
 static void ext_device_manager_read_cb(pa_context *c, const pa_ext_device_manager_info *info, int eol, void *userdata) {
     Q_ASSERT(c);
     Q_ASSERT(userdata);
 
-    // If this is our first iteration, set things up properly
-    if (s_connectionEventloop) {
-        logMessage("Exiting connection event loop (PulseAudio server found)");
-        s_connectionEventloop->exit(0);
-        s_connectionEventloop = NULL;
-        s_pulseActive = true;
-
-        pa_operation *o;
-        pa_ext_device_manager_set_subscribe_cb(c, ext_device_manager_subscribe_cb, NULL);
-        if ((o = pa_ext_device_manager_subscribe(c, 1, NULL, NULL)))
-            pa_operation_unref(o);
-    }
+    PulseUserData *u = reinterpret_cast<PulseUserData*>(userdata);
 
     if (eol < 0) {
         logMessage(QString("Failed to initialize device manager extension: %1").arg(pa_strerror(pa_context_errno(c))));
+        logMessage("Falling back to single device mode");
         createGenericDevices();
+        delete u;
+
+        // If this is our probe phase, exit now
+        if (s_context != c)
+            pa_context_disconnect(c);
+
         return;
     }
 
-    PulseUserData *u = reinterpret_cast<PulseUserData*>(userdata);
     if (eol) {
         // We're done reading the data, so order it by priority and copy it into the
         // static variables where it can then be accessed by those classes that need it.
@@ -289,6 +282,8 @@ static void ext_device_manager_read_cb(pa_context *c, const pa_ext_device_manage
         }
 
         if (s_instance) {
+            // This wont be emitted durring the connection probe phase
+            // which is intensional
             if (output_changed)
                 s_instance->emitObjectDescriptionChanged(AudioOutputDeviceType);
             if (capture_changed)
@@ -323,6 +318,11 @@ static void ext_device_manager_read_cb(pa_context *c, const pa_ext_device_manage
                 }
             }
         }
+
+        // If this is our probe phase, exit now as we're finished reading
+        // our device info and can exit and reconnect
+        if (s_context != c)
+            pa_context_disconnect(c);
     }
 
     if (!info)
@@ -374,6 +374,19 @@ static void ext_device_manager_read_cb(pa_context *c, const pa_ext_device_manage
         }
     }
 }
+
+static void ext_device_manager_subscribe_cb(pa_context *c, void *) {
+    Q_ASSERT(c);
+
+    pa_operation *o;
+    PulseUserData *u = new PulseUserData;
+    if (!(o = pa_ext_device_manager_read(c, ext_device_manager_read_cb, u))) {
+        logMessage(QString("pa_ext_device_manager_read() failed."));
+        delete u;
+        return;
+    }
+    pa_operation_unref(o);
+}
 #endif
 
 void sink_input_cb(pa_context *c, const pa_sink_input_info *i, int eol, void *userdata) {
@@ -515,49 +528,6 @@ static void subscribe_cb(pa_context *c, pa_subscription_event_type_t t, uint32_t
 }
 
 
-static void ext_device_manager_subscribe_cb(pa_context *c, void *) {
-    Q_ASSERT(c);
-
-    pa_operation *o;
-#ifdef HAVE_PULSEAUDIO_DEVICE_MANAGER 
-    PulseUserData *u = new PulseUserData; /** @todo Make some object to receive the info... */
-    if (!(o = pa_ext_device_manager_read(c, ext_device_manager_read_cb, u))) {
-        // We need to deal with failure on first iteration
-        if (s_connectionEventloop) {
-            logMessage("Entering connection eventloop (initialisation failed)");
-            s_connectionEventloop->exit(0);
-            s_connectionEventloop = NULL;
-        }
-        logMessage(QString("pa_ext_device_manager_read() failed"));
-        return;
-    }
-    pa_operation_unref(o);
-#else
-    // If we do not have Device Manager support. We just bail out now
-    // and say we are active with our single "devices" for playback and capture
-    s_pulseActive = true;
-    logMessage("Entering connection eventloop (successfully detected PulseAudio)");
-    if (s_connectionEventloop) {
-        s_connectionEventloop->exit(0);
-        s_connectionEventloop = NULL;
-    }
-    createGenericDevices();
-#endif
-
-
-    // Register for the stream changes...
-    pa_context_set_subscribe_callback(c, subscribe_cb, NULL);
-
-    if (!(o = pa_context_subscribe(c, (pa_subscription_mask_t)
-                                   (PA_SUBSCRIPTION_MASK_SINK_INPUT|
-                                    PA_SUBSCRIPTION_MASK_SOURCE_OUTPUT), NULL, NULL))) {
-        logMessage(QString("pa_context_subscribe() failed"));
-        return;
-    }
-    pa_operation_unref(o);
-}
-
-
 static const char* statename(pa_context_state_t state)
 {
     switch (state)
@@ -581,32 +551,68 @@ static void context_state_callback(pa_context *c, void *)
     Q_ASSERT(c);
 
     logMessage(QString("context_state_callback %1").arg(statename(pa_context_get_state(c))));
-    switch (pa_context_get_state(c)) {
-        case PA_CONTEXT_UNCONNECTED:
-        case PA_CONTEXT_CONNECTING:
-        case PA_CONTEXT_AUTHORIZING:
-        case PA_CONTEXT_SETTING_NAME:
-            break;
+    pa_context_state_t state = pa_context_get_state(c);
+    if (state == PA_CONTEXT_READY) {
+        // We've connected to PA, so it is active
+        s_pulseActive = true;
 
-        case PA_CONTEXT_READY:
-            // Attempt to load things up
-            ext_device_manager_subscribe_cb(c, NULL);
-            break;
+        // Attempt to load things up
+        pa_operation *o;
+
+        // 1. Register for the stream changes (except during probe)
+        if (s_context == c) {
+            pa_context_set_subscribe_callback(c, subscribe_cb, NULL);
 
-        case PA_CONTEXT_FAILED:
-            s_pulseActive = false;
-            if (s_connectionEventloop) {
-                logMessage("Entering connection eventloop (connection failed)");
-                s_connectionEventloop->exit(0);
-                s_connectionEventloop = NULL;
+            if (!(o = pa_context_subscribe(c, (pa_subscription_mask_t)
+                                              (PA_SUBSCRIPTION_MASK_SINK_INPUT|
+                                               PA_SUBSCRIPTION_MASK_SOURCE_OUTPUT), NULL, NULL))) {
+                logMessage(QString("pa_context_subscribe() failed"));
+                return;
             }
-            break;
+            pa_operation_unref(o);
+        }
 
-        case PA_CONTEXT_TERMINATED:
-        default:
-            s_pulseActive = false;
-            /// @todo Deal with reconnection...
-            break;
+#ifdef HAVE_PULSEAUDIO_DEVICE_MANAGER
+        // 2a. Attempt to initialise Device Manager info (except during probe)
+        if (s_context == c) {
+            pa_ext_device_manager_set_subscribe_cb(c, ext_device_manager_subscribe_cb, NULL);
+            if (!(o = pa_ext_device_manager_subscribe(c, 1, NULL, NULL))) {
+                logMessage(QString("pa_ext_device_manager_subscribe() failed"));
+                return;
+            }
+            pa_operation_unref(o);
+        }
+
+        // 3. Attempt to read info from Device Manager
+        PulseUserData *u = new PulseUserData;
+        if (!(o = pa_ext_device_manager_read(c, ext_device_manager_read_cb, u))) {
+            logMessage(QString("pa_ext_device_manager_read() failed. Attempting to continue without device manager support"));
+            createGenericDevices();
+            delete u;
+
+            // If this is our probe phase, exit immediately
+            if (s_context != c)
+                pa_context_disconnect(c);
+
+            return;
+        }
+        pa_operation_unref(o);
+
+#else
+        // If we know do not have Device Manager support, we just create our dummy devices now
+        createGenericDevices();
+
+        // If this is our probe phase, exit immediately
+        if (s_context != c)
+            pa_context_disconnect(c);
+#endif
+    } else if (!PA_CONTEXT_IS_GOOD(state)) {
+        /// @todo Deal with reconnection...
+        //logMessage("Connection to PulseAudio lost");
+
+        // If this is our probe phase, exit our context immediately
+        if (s_context != c)
+            pa_context_disconnect(c);
     }
 }
 #endif // HAVE_PULSEAUDIO
@@ -645,8 +651,10 @@ PulseSupport::PulseSupport()
 
     // To allow for easy debugging, give an easy way to disable this pulseaudio check
     QString pulseenv = qgetenv("PHONON_PULSEAUDIO_DISABLE");
-    if (pulseenv.toInt())
+    if (pulseenv.toInt()) {
+        logMessage("PulseAudio support disabled: PHONON_PULSEAUDIO_DISABLE is set");
         return;
+    }
 
     // We require a glib event loop
     if (QLatin1String(QAbstractEventDispatcher::instance()->metaObject()->className())
@@ -655,24 +663,62 @@ PulseSupport::PulseSupport()
         return;
     }
 
+    // First of all conenct to PA via simple/blocking means and if that succeeds,
+    // use a fully async integrated mainloop method to connect and get proper support.
+    pa_mainloop *p_test_mainloop;
+    if (!(p_test_mainloop = pa_mainloop_new())) {
+        logMessage("PulseAudio support disabled: Unable to create mainloop");
+        return;
+    }
+
+    pa_context *p_test_context;
+    if (!(p_test_context = pa_context_new(pa_mainloop_get_api(p_test_mainloop), "libphonon-probe"))) {
+        logMessage("PulseAudio support disabled: Unable to create context");
+        pa_mainloop_free(p_test_mainloop);
+        return;
+    }
+
+    logMessage("Probing for PulseAudio...");
+    // (cg) Convert to PA_CONTEXT_NOFLAGS when PulseAudio 0.9.19 is required
+    if (pa_context_connect(p_test_context, NULL, static_cast<pa_context_flags_t>(0), NULL) < 0) {
+        logMessage(QString("PulseAudio support disabled: %1").arg(pa_strerror(pa_context_errno(p_test_context))));
+        pa_context_disconnect(p_test_context);
+        pa_context_unref(p_test_context);
+        pa_mainloop_free(p_test_mainloop);
+        return;
+    }
+
+    pa_context_set_state_callback(p_test_context, &context_state_callback, NULL);
+    for (;;) {
+        pa_mainloop_iterate(p_test_mainloop, 1, NULL);
+
+        if (!PA_CONTEXT_IS_GOOD(pa_context_get_state(p_test_context))) {
+            logMessage("PulseAudio probe complete.");
+            break;
+        }
+    }
+    pa_context_disconnect(p_test_context);
+    pa_context_unref(p_test_context);
+    pa_mainloop_free(p_test_mainloop);
+
+    if (!s_pulseActive) {
+        logMessage("PulseAudio support is not available.");
+        return;
+    }
+
+    // If we're still here, PA is available.
+    logMessage("PulseAudio support enabled");
+
+    // Now we connect for real using a proper main loop that we can forget
+    // all about processing.
     s_mainloop = pa_glib_mainloop_new(NULL);
     Q_ASSERT(s_mainloop);
     pa_mainloop_api *api = pa_glib_mainloop_get_api(s_mainloop);
 
-    // We create a simple event loop to allow the glib loop
-    // to iterate until we've connected or not to the server.
-    s_connectionEventloop = new QEventLoop;
-
-    // XXX I don't want to show up in the client list. All I want to know is the list of sources
-    // and sinks...
     s_context = pa_context_new(api, "libphonon");
     // (cg) Convert to PA_CONTEXT_NOFLAGS when PulseAudio 0.9.19 is required
-    if (pa_context_connect(s_context, NULL, static_cast<pa_context_flags_t>(0), 0) >= 0) {
-        pa_context_set_state_callback(s_context, &context_state_callback, s_connectionEventloop);
-        // Now we block until we connect or otherwise...
-        logMessage("Entering connection eventloop...");
-        s_connectionEventloop->exec();
-    }
+    if (pa_context_connect(s_context, NULL, static_cast<pa_context_flags_t>(0), 0) >= 0)
+        pa_context_set_state_callback(s_context, &context_state_callback, NULL);
 #endif
 }
 
@@ -688,11 +734,6 @@ PulseSupport::~PulseSupport()
         pa_glib_mainloop_free(s_mainloop);
         s_mainloop = NULL;
     }
-
-    if (s_connectionEventloop) {
-        delete s_connectionEventloop;
-        s_connectionEventloop = NULL;
-    }
 #endif
 }

*** Bug 232225 has been marked as a duplicate of this bug. ***

*** Bug 233731 has been marked as a duplicate of this bug. ***

*** Bug 234535 has been marked as a duplicate of this bug. ***

*** Bug 233015 has been marked as a duplicate of this bug. ***

Just for reference, we released phonon 4.4.1 which includes these fixes. I did however manage to break xine output when used in conjunction with PA. That is fixed along with another smaller fix in git master. The two patches are referenced in #235193.

*** Bug 232754 has been marked as a duplicate of this bug. ***

*** Bug 231636 has been marked as a duplicate of this bug. ***

*** Bug 221215 has been marked as a duplicate of this bug. ***

*** Bug 242286 has been marked as a duplicate of this bug. ***

*** Bug 234316 has been marked as a duplicate of this bug. ***

*** Bug 222597 has been marked as a duplicate of this bug. ***

*** Bug 243801 has been marked as a duplicate of this bug. ***

*** Bug 213008 has been marked as a duplicate of this bug. ***

*** Bug 283565 has been marked as a duplicate of this bug. ***

Created attachment 93961 [details]
New crash information added by DrKonqi

krunner (4.11.11) on KDE Platform 4.14.2 using Qt 4.8.6

- Custom settings of the application:

file:///home/radek/Dokumenty/krunner-20150809-133204.kcrash.txt

-- Backtrace (Reduced):
#14 0xb6e6c6b4 in KDialog::~KDialog (this=0xbfdb3ff8, __in_chrg=<optimized out>) at ../../kdeui/dialogs/kdialog.cpp:204
#15 0xb5cbdbda in QObjectPrivate::deleteChildren (this=this@entry=0x97abc88) at kernel/qobject.cpp:1907
#16 0xb625840c in QWidget::~QWidget (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qwidget.cpp:1679
#17 0xb6661e2f in QFrame::~QFrame (this=0x9b03648, __in_chrg=<optimized out>) at widgets/qframe.cpp:240
#18 0xb66eea8f in QAbstractScrollArea::~QAbstractScrollArea (this=0x9b03648, __in_chrg=<optimized out>) at widgets/qabstractscrollarea.cpp:521