Bug 228324 - Crash opening PDF document [VideoWidget::resizeEvent] (PulseAudio using a QEventLoop)
Summary: Crash opening PDF document [VideoWidget::resizeEvent] (PulseAudio using a QEv...
Status: RESOLVED FIXED
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.3.1 (KDE 4.4)
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: Colin Guthrie
URL:
Keywords:
: 213008 221215 222597 228456 230979 231636 232225 232754 233015 233731 234316 234535 242286 243801 283565 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-02-24 16:10 UTC by Eike Hein
Modified: 2015-10-10 23:23 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.4.3


Attachments
File Okular crashes on when opening it (130.82 KB, application/pdf)
2010-02-24 16:11 UTC, Eike Hein
Details
Rework the connection logic to block and test + reconnect (10.55 KB, text/plain)
2010-03-17 02:47 UTC, Colin Guthrie
Details
Update connection logic (11.99 KB, patch)
2010-03-17 10:15 UTC, Colin Guthrie
Details
backtrace for PHONON_PULESAUDIO_DISABLE=1 okular o.pdf (9.69 KB, text/plain)
2010-03-17 22:44 UTC, Éric Brunet
Details
New crash information added by DrKonqi (19.64 KB, text/plain)
2015-08-09 12:27 UTC, radek vasa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eike Hein 2010-02-24 16:10:00 UTC
Application: okular (0.10)
KDE Platform Version: 4.4.00 (KDE 4.4.0)
Qt Version: 4.6.2
Operating System: Linux 2.6.32.8-58.fc12.x86_64 x86_64
Distribution: "Fedora release 12 (Constantine)"

-- Information about the crash:
I was trying to open the PDF document retrieved from http://eprints.kfupm.edu.sa/74846/1/74846.pdf from the command line with "okular 74846.pdf". Okular immediately crashed.

I will attach the PDF.

The crash can be reproduced every time.

 -- Backtrace:
Application: Okular (okular), signal: Segmentation fault
82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
[KCrash Handler]
#5  left (this=0x221ccb0, event=0x7fff83942130) at /usr/include/QtCore/qrect.h:241
#6  VideoWidget::resizeEvent (this=0x221ccb0, event=0x7fff83942130) at /usr/src/debug/kdegraphics-4.4.0/okular/ui/videowidget.cpp:286
#7  0x0000003c61ff574c in QWidget::event (this=0x221ccb0, event=0x7fff83942130) at kernel/qwidget.cpp:8152
#8  0x0000003c61faa9dc in QApplicationPrivate::notify_helper (this=0x1495110, receiver=0x221ccb0, e=0x7fff83942130) at kernel/qapplication.cpp:4300
#9  0x0000003c61fb0aab in QApplication::notify (this=<value optimized out>, receiver=0x221ccb0, e=0x7fff83942130) at kernel/qapplication.cpp:4183
#10 0x00000032dce067a6 in KApplication::notify (this=0x7fff83945110, receiver=0x221ccb0, event=0x7fff83942130) at /usr/src/debug/kdelibs-4.4.0/kdeui/kernel/kapplication.cpp:302
#11 0x000000328055774c in QCoreApplication::notifyInternal (this=0x7fff83945110, receiver=0x221ccb0, event=0x7fff83942130) at kernel/qcoreapplication.cpp:704
#12 0x0000003c61ff476b in sendEvent (this=0x2218570, recursive=true, disableUpdates=<value optimized out>) at ../../src/corelib/kernel/qcoreapplication.h:215
#13 QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x2218570, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7086
#14 0x0000003c61ff46db in QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x2089730, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7098
#15 0x0000003c61ff46db in QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x2088080, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7098
#16 0x0000003c61ff46db in QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x2073b70, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7098
#17 0x0000003c61ff46db in QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x1601080, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7098
#18 0x0000003c61ff46db in QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x15e1f10, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7098
#19 0x0000003c61ff46db in QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x1505cd0, recursive=true, disableUpdates=<value optimized out>) at kernel/qwidget.cpp:7098
#20 0x0000003c61ff997c in QWidgetPrivate::prepareToRender (this=0x1505cd0, region=<value optimized out>, renderFlags=<value optimized out>) at kernel/qwidget.cpp:5163
#21 0x0000003c61ffe057 in QWidget::render (this=<value optimized out>, target=0x7fff83942860, targetOffset=..., sourceRegion=<value optimized out>, renderFlags=...) at kernel/qwidget.cpp:4871
#22 0x0000003c62079c3b in QPixmap::grabWidget (widget=0x152abf0, rect=...) at image/qpixmap.cpp:1092
#23 0x00007f9c8938b4f8 in QWidget::setUpdatesEnabled(bool) () at kernel/qwidget.cpp:7027
#24 0x00007f9c89386df8 in QWidget::setUpdatesEnabled(bool) () at kernel/qwidget.cpp:7027
#25 0x000000328056663e in QObject::event (this=0x20a4b40, e=0x7fff83943120) at kernel/qobject.cpp:1212
#26 0x0000003c61faa9dc in QApplicationPrivate::notify_helper (this=0x1495110, receiver=0x20a4b40, e=0x7fff83943120) at kernel/qapplication.cpp:4300
#27 0x0000003c61fb0aab in QApplication::notify (this=<value optimized out>, receiver=0x20a4b40, e=0x7fff83943120) at kernel/qapplication.cpp:4183
#28 0x00000032dce067a6 in KApplication::notify (this=0x7fff83945110, receiver=0x20a4b40, event=0x7fff83943120) at /usr/src/debug/kdelibs-4.4.0/kdeui/kernel/kapplication.cpp:302
#29 0x000000328055774c in QCoreApplication::notifyInternal (this=0x7fff83945110, receiver=0x20a4b40, event=0x7fff83943120) at kernel/qcoreapplication.cpp:704
#30 0x000000328057fe02 in sendEvent (this=0x1498e00) at kernel/qcoreapplication.h:215
#31 QTimerInfoList::activateTimers (this=0x1498e00) at kernel/qeventdispatcher_unix.cpp:603
#32 0x000000328057d374 in timerSourceDispatch (source=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:184
#33 0x000000327503920e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#34 0x000000327503cbf8 in ?? () from /lib64/libglib-2.0.so.0
#35 0x000000327503cd1a in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#36 0x000000328057d063 in QEventDispatcherGlib::processEvents (this=0x147dc50, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:412
#37 0x0000003c62049a1e in QGuiEventDispatcherGlib::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#38 0x0000003280556192 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149
#39 0x000000328055645c in QEventLoop::exec (this=0x147f950, flags=...) at kernel/qeventloop.cpp:201
#40 0x0000003c6604187a in Phonon::PulseSupport::PulseSupport (this=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/pulsesupport.cpp:668
#41 0x0000003c6604191f in Phonon::PulseSupport::getInstance () at /usr/src/debug/phonon-4.3.80/phonon/pulsesupport.cpp:620
#42 0x0000003c6602b06d in Phonon::AudioOutputPrivate::init (this=0x2218ca0, c=NoCategory) at /usr/src/debug/phonon-4.3.80/phonon/audiooutput.cpp:102
#43 0x0000003c6603aeb2 in Phonon::VideoPlayerPrivate::init (this=0x2218af0, q=0x221cc70, category=NoCategory) at /usr/src/debug/phonon-4.3.80/phonon/videoplayer.cpp:59
#44 0x0000003c6603b0b0 in Phonon::VideoPlayer::VideoPlayer (this=0x221cc70, category=NoCategory, parent=0x7fff83942130) at /usr/src/debug/phonon-4.3.80/phonon/videoplayer.cpp:75
#45 0x00007f9c87d806e2 in VideoWidget::VideoWidget (this=0x221ccb0, movieann=<value optimized out>, document=0x221d0d0, parent=<value optimized out>)
    at /usr/src/debug/kdegraphics-4.4.0/okular/ui/videowidget.cpp:171
#46 0x00007f9c87d5a38d in PageView::notifySetup (this=0x2088bd0, pageSet=<value optimized out>, setupFlags=<value optimized out>) at /usr/src/debug/kdegraphics-4.4.0/okular/ui/pageview.cpp:749
#47 0x00007f9c87a6ace3 in Okular::Document::openDocument (this=0x15f9d00, docFile=<value optimized out>, url=<value optimized out>, _mime=<value optimized out>)
    at /usr/src/debug/kdegraphics-4.4.0/okular/core/document.cpp:1677
#48 0x00007f9c87d1825c in Okular::Part::openFile (this=0x1588150) at /usr/src/debug/kdegraphics-4.4.0/okular/part.cpp:929
#49 0x00000032de221b67 in KParts::ReadOnlyPart::openUrl (this=0x1588150, url=<value optimized out>) at /usr/src/debug/kdelibs-4.4.0/kparts/part.cpp:557
#50 0x00007f9c87d0cd0a in Okular::Part::openUrl (this=0x1588150, _url=<value optimized out>) at /usr/src/debug/kdegraphics-4.4.0/okular/part.cpp:1048
#51 0x000000000040917a in Shell::openUrl (this=0x152abf0, url=...) at /usr/src/debug/kdegraphics-4.4.0/okular/shell/shell.cpp:130
#52 0x0000000000409a9c in Shell::qt_metacall (this=0x152abf0, _c=InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff83944660)
    at /usr/src/debug/kdegraphics-4.4.0/x86_64-redhat-linux-gnu/okular/shell/shell.moc:94
#53 0x000000328056a2af in QMetaObject::activate (sender=0x21ac010, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x0) at kernel/qobject.cpp:3293
#54 0x000000328056f97f in QSingleShotTimer::timerEvent (this=0x21ac010) at kernel/qtimer.cpp:308
#55 0x000000328056663e in QObject::event (this=0x21ac010, e=0x7fff83944dc0) at kernel/qobject.cpp:1212
#56 0x0000003c61faa9dc in QApplicationPrivate::notify_helper (this=0x1495110, receiver=0x21ac010, e=0x7fff83944dc0) at kernel/qapplication.cpp:4300
#57 0x0000003c61fb0aab in QApplication::notify (this=<value optimized out>, receiver=0x21ac010, e=0x7fff83944dc0) at kernel/qapplication.cpp:4183
#58 0x00000032dce067a6 in KApplication::notify (this=0x7fff83945110, receiver=0x21ac010, event=0x7fff83944dc0) at /usr/src/debug/kdelibs-4.4.0/kdeui/kernel/kapplication.cpp:302
#59 0x000000328055774c in QCoreApplication::notifyInternal (this=0x7fff83945110, receiver=0x21ac010, event=0x7fff83944dc0) at kernel/qcoreapplication.cpp:704
#60 0x000000328057fe02 in sendEvent (this=0x1498e00) at kernel/qcoreapplication.h:215
#61 QTimerInfoList::activateTimers (this=0x1498e00) at kernel/qeventdispatcher_unix.cpp:603
#62 0x000000328057d374 in timerSourceDispatch (source=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:184
#63 0x000000327503920e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#64 0x000000327503cbf8 in ?? () from /lib64/libglib-2.0.so.0
#65 0x000000327503cd1a in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#66 0x000000328057d063 in QEventDispatcherGlib::processEvents (this=0x147dc50, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:412
#67 0x0000003c62049a1e in QGuiEventDispatcherGlib::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#68 0x0000003280556192 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149
#69 0x000000328055645c in QEventLoop::exec (this=0x7fff83945060, flags=...) at kernel/qeventloop.cpp:201
#70 0x0000003280558749 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981
#71 0x0000000000408039 in main (argc=<value optimized out>, argv=<value optimized out>) at /usr/src/debug/kdegraphics-4.4.0/okular/shell/main.cpp:82

Reported using DrKonqi
Comment 1 Eike Hein 2010-02-24 16:11:18 UTC
Created attachment 41061 [details]
File Okular crashes on when opening it
Comment 2 Rex Dieter 2010-02-24 16:24:15 UTC
rpm -q poppler-qt4 
?
Comment 3 Rex Dieter 2010-02-24 16:27:43 UTC
Confirmed crash using poppler-0.12.4, and having switched to phonon-xine backend.  (no crash using -gstreamer)
Comment 4 Eike Hein 2010-02-24 16:29:26 UTC
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.
Comment 5 Hugo Pereira Da Costa 2010-02-24 16:49:58 UTC
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.
Comment 6 Pino Toscano 2010-02-25 15:29:37 UTC
*** Bug 228456 has been marked as a duplicate of this bug. ***
Comment 7 Pino Toscano 2010-02-25 15:31:38 UTC
Gah, pulse crap running a local event loop...
Comment 8 Pino Toscano 2010-03-16 15:47:05 UTC
*** Bug 230979 has been marked as a duplicate of this bug. ***
Comment 9 Pino Toscano 2010-03-16 15:48:11 UTC
Can some phonon guy please take a look at the pulse crap stuff, pretty please?
Comment 10 Colin Guthrie 2010-03-16 19:38:06 UTC
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.
Comment 11 Pino Toscano 2010-03-16 19:53:27 UTC
(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.
Comment 12 Albert Astals Cid 2010-03-16 21:02:35 UTC
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.
Comment 13 Éric Brunet 2010-03-16 23:23:45 UTC
> 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.
Comment 14 Eike Hein 2010-03-16 23:28:12 UTC
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.
Comment 15 Eike Hein 2010-03-16 23:50:39 UTC
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.
Comment 16 Colin Guthrie 2010-03-17 00:05:20 UTC
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.
Comment 17 Colin Guthrie 2010-03-17 00:22:25 UTC
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)
Comment 18 Pino Toscano 2010-03-17 00:34:37 UTC
(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.)
Comment 19 Colin Guthrie 2010-03-17 00:51:54 UTC
(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.
Comment 20 Colin Guthrie 2010-03-17 00:53:34 UTC
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.
Comment 21 Colin Guthrie 2010-03-17 01:14:47 UTC
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
Comment 22 Colin Guthrie 2010-03-17 02:47:45 UTC
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.
Comment 23 Colin Guthrie 2010-03-17 10:15:50 UTC
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.
Comment 24 Éric Brunet 2010-03-17 12:51:35 UTC
(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.
Comment 25 Colin Guthrie 2010-03-17 13:31:13 UTC
(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?
Comment 26 Rex Dieter 2010-03-17 14:04:34 UTC
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.
Comment 27 Eike Hein 2010-03-17 21:27:23 UTC
After installing the patched packages Rex made available for Fedora, Okular no longer crashes here when opening the PDF :).
Comment 28 Éric Brunet 2010-03-17 22:44:17 UTC
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
Comment 29 Colin Guthrie 2010-03-17 22:51:13 UTC
(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 :)
Comment 30 Éric Brunet 2010-03-17 23:18:05 UTC
(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.
Comment 31 Éric Brunet 2010-03-17 23:21:38 UTC
(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 ?
Comment 32 Eike Hein 2010-03-17 23:23:42 UTC
Yes, they're in the unstable branch of kde-redhat (the KDE team's staging repository).
Comment 33 Éric Brunet 2010-03-17 23:54:45 UTC
(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 ?
Comment 34 Eike Hein 2010-03-18 00:05:53 UTC
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 :).
Comment 35 Colin Guthrie 2010-03-20 13:19:00 UTC
OK, so this patch hasn't caused anyone to shout and complain so I'll commit it :)
Comment 36 Colin Guthrie 2010-03-20 13:23:43 UTC
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
 }
Comment 37 paul s. romanchenko 2010-04-02 12:42:11 UTC
*** Bug 232225 has been marked as a duplicate of this bug. ***
Comment 38 Dario Andres 2010-04-08 15:04:56 UTC
*** Bug 233731 has been marked as a duplicate of this bug. ***
Comment 39 Maksim Orlovich 2010-04-16 17:06:29 UTC
*** Bug 234535 has been marked as a duplicate of this bug. ***
Comment 40 Maksim Orlovich 2010-04-16 17:24:25 UTC
*** Bug 233015 has been marked as a duplicate of this bug. ***
Comment 41 Colin Guthrie 2010-04-24 16:06:04 UTC
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.
Comment 42 Christoph Feck 2010-08-07 21:14:58 UTC
*** Bug 232754 has been marked as a duplicate of this bug. ***
Comment 43 Christoph Feck 2010-08-07 21:16:32 UTC
*** Bug 231636 has been marked as a duplicate of this bug. ***
Comment 44 Christoph Feck 2010-08-07 21:17:37 UTC
*** Bug 221215 has been marked as a duplicate of this bug. ***
Comment 45 Christoph Feck 2010-08-07 21:20:28 UTC
*** Bug 242286 has been marked as a duplicate of this bug. ***
Comment 46 Christoph Feck 2010-08-07 21:21:56 UTC
*** Bug 234316 has been marked as a duplicate of this bug. ***
Comment 47 Christoph Feck 2010-08-07 21:22:47 UTC
*** Bug 222597 has been marked as a duplicate of this bug. ***
Comment 48 Christoph Feck 2010-08-07 21:23:46 UTC
*** Bug 243801 has been marked as a duplicate of this bug. ***
Comment 49 Christoph Feck 2010-08-07 23:35:05 UTC
*** Bug 213008 has been marked as a duplicate of this bug. ***
Comment 50 Dario Andres 2011-10-09 23:07:38 UTC
*** Bug 283565 has been marked as a duplicate of this bug. ***
Comment 51 radek vasa 2015-08-09 12:27:36 UTC
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