Bug 231101 - System Settings crashed when trying to configure multimedia setting
Summary: System Settings crashed when trying to configure multimedia setting
Status: RESOLVED DUPLICATE of bug 220071
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: Xine backend (show other bugs)
Version: 4.3.1 (KDE 4.4)
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: Matthias Kretz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-17 15:05 UTC by Frode Tennebø
Modified: 2010-08-14 11:40 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frode Tennebø 2010-03-17 15:05:49 UTC
Application: systemsettings (1.0)
KDE Platform Version: 4.4.00 (KDE 4.4.0)
Qt Version: 4.6.2
Operating System: Linux 2.6.32.9-70.fc12.i686.PAE i686
Distribution: "Fedora release 12 (Constantine)"

-- Information about the crash:
I have no additional information about what caused this.

 -- Backtrace:
Application: System Settings (systemsettings), signal: Aborted
[Current thread is 1 (Thread 0xb77417a0 (LWP 4580))]

Thread 4 (Thread 0xb1e45b70 (LWP 4581)):
#0  0x0052a416 in __kernel_vsyscall ()
#1  0x00804614 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x032e06b5 in metronom_sync_loop (this=<value optimized out>) at metronom.c:870
#3  0x007ffb65 in start_thread () from /lib/libpthread.so.0
#4  0x0072620e in clone () from /lib/libc.so.6

Thread 3 (Thread 0xb1444b70 (LWP 4584)):
#0  0x0081c076 in clock_gettime () from /lib/librt.so.1
#1  0x024a40cb in qt_gettime () at kernel/qcore_unix.cpp:111
#2  0x024a87b6 in QTimerInfoList::updateCurrentTime (this=0xb0901a34) at kernel/qeventdispatcher_unix.cpp:340
#3  0x024a87fb in QTimerInfoList::timerWait (this=0xb0901a34, tm=...) at kernel/qeventdispatcher_unix.cpp:443
#4  0x024a7088 in timerSourcePrepareHelper (src=<value optimized out>, timeout=0xb144404c) at kernel/qeventdispatcher_glib.cpp:136
#5  0x00873120 in IA__g_main_context_prepare (context=<value optimized out>, priority=<value optimized out>) at gmain.c:2280
#6  0x008734d9 in g_main_context_iterate (context=0xb09004e8, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2571
#7  0x008739e4 in IA__g_main_context_iteration (context=0xb09004e8, may_block=<value optimized out>) at gmain.c:2654
#8  0x024a6e7f in QEventDispatcherGlib::processEvents (this=0xb0900468, flags=...) at kernel/qeventdispatcher_glib.cpp:414
#9  0x0247d2da in QEventLoop::processEvents (this=0xb1444210, flags=...) at kernel/qeventloop.cpp:149
#10 0x0247d61a in QEventLoop::exec (this=0xb1444210, flags=...) at kernel/qeventloop.cpp:201
#11 0x02386909 in QThread::exec (this=0x85ff5d0) at thread/qthread.cpp:487
#12 0x010e708b in Phonon::Xine::XineThread::run (this=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/xinethread.cpp:143
#13 0x02388cdf in QThreadPrivate::start (arg=0x85ff5d0) at thread/qthread_unix.cpp:248
#14 0x007ffb65 in start_thread () from /lib/libpthread.so.0
#15 0x0072620e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb0638b70 (LWP 4585)):
#0  0x0052a416 in __kernel_vsyscall ()
#1  0x00801b9b in __pthread_mutex_lock_full () from /lib/libpthread.so.0
#2  0x02109952 in pa_mutex_lock (m=0x848e810) at pulsecore/mutex-posix.c:90
#3  0x022fb6bd in poll_func (ufds=0xb0700c38, nfds=2, timeout=-1, userdata=0x848e810) at pulse/thread-mainloop.c:76
#4  0x022e84da in pa_mainloop_poll (m=0x86b4738) at pulse/mainloop.c:879
#5  0x022e9d54 in pa_mainloop_iterate (m=0x86b4738, block=1, retval=0x0) at pulse/mainloop.c:961
#6  0x022e9e34 in pa_mainloop_run (m=0x86b4738, retval=0x0) at pulse/mainloop.c:979
#7  0x022fb5a4 in thread (userdata=0x85f2220) at pulse/thread-mainloop.c:94
#8  0x0210a863 in internal_thread_func (userdata=0x8645568) at pulsecore/thread-posix.c:72
#9  0x007ffb65 in start_thread () from /lib/libpthread.so.0
#10 0x0072620e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb77417a0 (LWP 4580)):
[KCrash Handler]
#6  0x0052a416 in __kernel_vsyscall ()
#7  0x00672c91 in raise () from /lib/libc.so.6
#8  0x0067455a in abort () from /lib/libc.so.6
#9  0x0210983b in pa_mutex_unlock (m=0x848e810) at pulsecore/mutex-posix.c:108
#10 0x022fb871 in pa_threaded_mainloop_unlock (m=0x85f2220) at pulse/thread-mainloop.c:186
#11 0x00b9080b in open_plugin (class_gen=<value optimized out>, data=<value optimized out>) at audio_pulse_out.c:826
#12 0x032e9244 in _load_audio_driver (this=<value optimized out>, id=<value optimized out>, data=<value optimized out>) at load_plugins.c:1740
#13 xine_open_audio_driver (this=<value optimized out>, id=<value optimized out>, data=<value optimized out>) at load_plugins.c:1808
#14 0x0110095c in Phonon::Xine::AudioOutput::createPort (this=<value optimized out>, deviceDesc=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/audiooutput.cpp:138
#15 0x01101cde in Phonon::Xine::AudioOutput::xineEngineChanged (this=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/audiooutput.cpp:313
#16 0x010e582d in Phonon::Xine::SinkNode::downstreamEvent (this=<value optimized out>, e=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/sinknode.cpp:139
#17 0x010fec56 in Phonon::Xine::AudioOutput::downstreamEvent (this=<value optimized out>, e=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/audiooutput.cpp:350
#18 0x010e6913 in Phonon::Xine::SourceNode::downstreamEvent (this=<value optimized out>, e=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/sourcenode.cpp:111
#19 0x01103878 in Phonon::Xine::MediaObject::downstreamEvent (this=<value optimized out>, e=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/mediaobject.cpp:704
#20 0x01107e84 in Phonon::Xine::MediaObject::upstreamEvent (this=<value optimized out>, e=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/mediaobject.cpp:675
#21 0x010e52f8 in Phonon::Xine::SinkNode::upstreamEvent (this=<value optimized out>, e=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/sinknode.cpp:89
#22 0x010e52ad in Phonon::Xine::SinkNode::findXineEngine (this=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/sinknode.cpp:102
#23 0x01111903 in Phonon::Xine::Backend::endConnectionChange (this=<value optimized out>, nodes=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/backend.cpp:480
#24 0x0334ed04 in ~ConnectionTransaction (this=<value optimized out>, disconnections=<value optimized out>, connections=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/path.cpp:46
#25 Phonon::PathPrivate::executeTransaction (this=<value optimized out>, disconnections=<value optimized out>, connections=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/path.cpp:351
#26 0x0335035d in Phonon::Path::reconnect (this=<value optimized out>, source=<value optimized out>, sink=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/path.cpp:197
#27 0x033504e6 in Phonon::createPath (source=<value optimized out>, sink=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/path.cpp:432
#28 0x0060b91b in DevicePreference::on_testPlaybackButton_toggled (this=<value optimized out>, down=<value optimized out>) at /usr/src/debug/kdebase-runtime-4.4.0/phonon/kcm/devicepreference.cpp:570
#29 0x0060de80 in DevicePreference::qt_metacall (this=<value optimized out>, _c=<value optimized out>, _id=<value optimized out>, _a=<value optimized out>)
    at /usr/src/debug/kdebase-runtime-4.4.0/i686-redhat-linux-gnu/phonon/kcm/moc_devicepreference.cpp:99
#30 0x024835db in QMetaObject::metacall (object=0x85ff5f0, cl=InvokeMetaMethod, idx=33, argv=0xbf931208) at kernel/qmetaobject.cpp:237
#31 0x024924af in QMetaObject::activate (sender=0x860f1f0, m=0x2fc8964, local_signal_index=4, argv=0xbf931208) at kernel/qobject.cpp:3293
#32 0x02d956ea in QAbstractButton::toggled (this=0x860f1f0, _t1=true) at .moc/release-shared/moc_qabstractbutton.cpp:213
#33 0x02aaac65 in QAbstractButton::setChecked (this=0x860f1f0, checked=true) at widgets/qabstractbutton.cpp:766
#34 0x02aaae11 in QAbstractButton::nextCheckState (this=0x860f1f0) at widgets/qabstractbutton.cpp:1020
#35 0x02b7bca8 in QToolButton::nextCheckState (this=0x860f1f0) at widgets/qtoolbutton.cpp:1145
#36 0x02aaa894 in QAbstractButtonPrivate::click (this=0x860f2c0) at widgets/qabstractbutton.cpp:528
#37 0x02aaab9e in QAbstractButton::mouseReleaseEvent (this=0x860f1f0, e=0xbf9319a0) at widgets/qabstractbutton.cpp:1121
#38 0x02b7c14d in QToolButton::mouseReleaseEvent (this=0x860f1f0, e=0xbf9319a0) at widgets/qtoolbutton.cpp:721
#39 0x02724b2d in QWidget::event (this=0x860f1f0, event=0xbf9319a0) at kernel/qwidget.cpp:7998
#40 0x02aa953f in QAbstractButton::event (this=0x860f1f0, e=0xbf9319a0) at widgets/qabstractbutton.cpp:1080
#41 0x02b7e6bb in QToolButton::event (this=0x860f1f0, event=0xbf9319a0) at widgets/qtoolbutton.cpp:1163
#42 0x026d1d2c in QApplicationPrivate::notify_helper (this=0x825f440, receiver=0x860f1f0, e=0xbf9319a0) at kernel/qapplication.cpp:4300
#43 0x026d90fe in QApplication::notify (this=0xbf93225c, receiver=0x860f1f0, e=0xbf9319a0) at kernel/qapplication.cpp:3865
#44 0x0356e58b in KApplication::notify (this=0xbf93225c, receiver=0x860f1f0, event=0xbf9319a0) at /usr/src/debug/kdelibs-4.4.0/kdeui/kernel/kapplication.cpp:302
#45 0x0247ec03 in QCoreApplication::notifyInternal (this=0xbf93225c, receiver=0x860f1f0, event=0xbf9319a0) at kernel/qcoreapplication.cpp:704
#46 0x026d7e68 in sendEvent (receiver=0x860f1f0, event=0xbf9319a0, alienWidget=0x860f1f0, nativeWidget=0x82dd1a8, buttonDown=0x2fd10f8, lastMouseReceiver=..., spontaneous=true)
    at ../../src/corelib/kernel/qcoreapplication.h:215
#47 QApplicationPrivate::sendMouseEvent (receiver=0x860f1f0, event=0xbf9319a0, alienWidget=0x860f1f0, nativeWidget=0x82dd1a8, buttonDown=0x2fd10f8, lastMouseReceiver=..., spontaneous=true)
    at kernel/qapplication.cpp:2965
#48 0x027550d0 in QETWidget::translateMouseEvent (this=0x82dd1a8, event=0xbf931ebc) at kernel/qapplication_x11.cpp:4368
#49 0x027545e3 in QApplication::x11ProcessEvent (this=0xbf93225c, event=0xbf931ebc) at kernel/qapplication_x11.cpp:3379
#50 0x027804da in x11EventSourceDispatch (s=0x82624a8, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146
#51 0x0086ff88 in g_main_dispatch (context=<value optimized out>) at gmain.c:1960
#52 IA__g_main_context_dispatch (context=<value optimized out>) at gmain.c:2513
#53 0x008738b8 in g_main_context_iterate (context=<value optimized out>, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2591
#54 0x008739e4 in IA__g_main_context_iteration (context=0x8261690, may_block=<value optimized out>) at gmain.c:2654
#55 0x024a6e46 in QEventDispatcherGlib::processEvents (this=0x823b360, flags=...) at kernel/qeventdispatcher_glib.cpp:412
#56 0x027800c6 in QGuiEventDispatcherGlib::processEvents (this=0x823b360, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#57 0x0247d2da in QEventLoop::processEvents (this=0xbf9321b4, flags=...) at kernel/qeventloop.cpp:149
#58 0x0247d61a in QEventLoop::exec (this=0xbf9321b4, flags=...) at kernel/qeventloop.cpp:201
#59 0x0247fce7 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981
#60 0x026d1dd8 in QApplication::exec () at kernel/qapplication.cpp:3579
#61 0x08055dc8 in _start ()

Reported using DrKonqi
Comment 1 Myriam Schweingruber 2010-04-06 08:28:11 UTC
Hm, either this is a duplicate of bug 196320 or related to pulseaudio. Colin, any ideas?
Comment 2 Colin Guthrie 2010-04-06 09:52:04 UTC
It could be another case of the now infamous QEventLoop bug in the PA detection code #228324 There are two QEventLoops kicking around (different this= pointers at any rate) in the backtrace, so I'm edging towards that being the cause. Is this still valid if you install the latest phonon packages in RH? Which I believe Rex has pushed.
Comment 3 Frode Tennebø 2010-04-06 10:17:39 UTC
I was using

[root@luke ~]# rpm -q phonon
phonon-4.3.80-5.fc12.i686

with

Build Date: Thu 21 Jan 2010 09:51:28 PM CET
Install Date: Mon 01 Feb 2010 12:13:28 AM CET

I have done some tinkering and now suddenly I have three output devices, two SB Audigy 2 [SB0204][something] and one PulseAudio.  Now, only the PulseAudio options + Test gives the crash effect.  The initial report was based on only having one output device (which I believe was PulseAudio).

(PulseAudio seems to be a repeating source of problems - it appears to cause crashes in everything from Metacity to Firefox - but is frustratingly figure out.)
Comment 4 Colin Guthrie 2010-04-06 10:42:48 UTC
(In reply to comment #3)
> I was using
> 
> [root@luke ~]# rpm -q phonon
> phonon-4.3.80-5.fc12.i686
> 
> with
> 
> Build Date: Thu 21 Jan 2010 09:51:28 PM CET
> Install Date: Mon 01 Feb 2010 12:13:28 AM CET

This is from before the fixes to the PA detection code in Phonon so it will certainly have some problems.

> I have done some tinkering and now suddenly I have three output devices, two SB
> Audigy 2 [SB0204][something] and one PulseAudio.  Now, only the PulseAudio
> options + Test gives the crash effect.  The initial report was based on only
> having one output device (which I believe was PulseAudio).

It means that you are no longer running a PA daemon. Phonon no longer lists the PA option when PA is not running, but your version is a too old for that.

Either configure your system to use PA or not, but it's a bad idea to try and mix and match direct alsa and PA together... that path leads to pain!

> (PulseAudio seems to be a repeating source of problems - it appears to cause
> crashes in everything from Metacity to Firefox - but is frustratingly figure
> out.)

Well it's quite interesting really. PA development has highlighted a lot of problems with other applications - either in their alsa implementation or their inappropriate use of various third party libraries' APIs that you simply wouldn't expect (e.g. libxml2's xmlCleanupParser() or librsvg's rsvg_term() - yes these methods are dangerous!). In addition PA makes use of parts of the ALSA API that no other ALSA client has used before and that has unearthed several problems in both libasla and in the alsa drivers themselves. Some people want to group these up as "pulseaudio bugs" but in reality these bugs can be far and wide and they are just *exposed* by PA. Some people don't really care about that distinction, but I like to think that PA rollout, while painful for some, has resulted in better code all round in a number of both related and unrelated projects.
Comment 5 Frode Tennebø 2010-04-06 12:38:14 UTC
(In reply to comment #4)
> 
> This is from before the fixes to the PA detection code in Phonon so it will
> certainly have some problems.

There is no newer version in the stable repository, but in testing. It is safe enough?
 
> It means that you are no longer running a PA daemon. Phonon no longer lists the
> PA option when PA is not running, but your version is a too old for that.

So why does it crash when trying to use a service which is not running?
 
> Either configure your system to use PA or not, but it's a bad idea to try and
> mix and match direct alsa and PA together... that path leads to pain!

Sorry, I was trying to disable PulseAudio as I a) wasn't getting any sound and b) had all these strange crashes and 100% CPU usage from various processes, apparently PA related.

Somehow it is not very easy to totally disable PA...
 
> Well it's quite interesting really. PA development has highlighted a lot of
> problems with other applications - either in their alsa implementation or their
> inappropriate use of various third party libraries' APIs that you simply
> wouldn't expect (e.g. libxml2's xmlCleanupParser() or librsvg's rsvg_term() -
> yes these methods are dangerous!). In addition PA makes use of parts of the
> ALSA API that no other ALSA client has used before and that has unearthed
> several problems in both libasla and in the alsa drivers themselves. Some
> people want to group these up as "pulseaudio bugs" but in reality these bugs
> can be far and wide and they are just *exposed* by PA. Some people don't really
> care about that distinction, but I like to think that PA rollout, while painful
> for some, has resulted in better code all round in a number of both related and
> unrelated projects.

Sorry for sounding overly critical, and I'm sure that there are other factors involved as well.  There are really two fundamental grievances I have which doesn't really reflect on PA directly:

* Something broke with FC12 (FC8-11 was fine) regarding PA - or it could be the move to SB Audigy 2 (but it appears to be standard HW...) - but something slipped QA at Fedora Project
* The current sound infrastructure/architecture in Linux is overly complex and PA tries to solve that by adding additional abstractions.  I'm in the camp which roots for simplicity, not complexity. ;-)
Comment 6 Colin Guthrie 2010-04-06 13:21:16 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > This is from before the fixes to the PA detection code in Phonon so it will
> > certainly have some problems.
> 
> There is no newer version in the stable repository, but in testing. It is safe
> enough?

I don't know Fedora specific stuff I'm afraid. Rex may be able to say, but I guess it will be stable enough otherwise it wouldn't be ready for testing... :p


> > It means that you are no longer running a PA daemon. Phonon no longer lists the
> > PA option when PA is not running, but your version is a too old for that.
> 
> So why does it crash when trying to use a service which is not running?

This is something specific to the backend in question. If it doesn't protect against things nicely, then it will fail. With newer phonon, this will not happen with PulseAudio any more as such interaction is processed before it even reaches the backend specific stuff.

> > Either configure your system to use PA or not, but it's a bad idea to try and
> > mix and match direct alsa and PA together... that path leads to pain!
> 
> Sorry, I was trying to disable PulseAudio as I a) wasn't getting any sound and
> b) had all these strange crashes and 100% CPU usage from various processes,
> apparently PA related.
> 
> Somehow it is not very easy to totally disable PA...

You should raise this with the Fedora guys. In Mandriva we have a tick box you untick if you don't want PA. Obviously the end goal is to make 99% of users totally unaware of PA or what it is etc. and for that we need to fix cases like this.


> Sorry for sounding overly critical, and I'm sure that there are other factors
> involved as well.  There are really two fundamental grievances I have which
> doesn't really reflect on PA directly:
> 
> * Something broke with FC12 (FC8-11 was fine) regarding PA - or it could be the
> move to SB Audigy 2 (but it appears to be standard HW...) - but something
> slipped QA at Fedora Project

Creative h/w is particularly poorly supported under linux sadly. I believe the company doesn't really help very much in this regard (i.e. with specs etc.). The timer based scheduling approach of PA (the newer bit of the ALSA API mentioned in my previous comment that no other ALSA client utilises yet) exposes parts of the driver code that have not yet been tested widely and the creative drivers suffered from a lot of problems in this area as a result. Newer kernels behave better with this h/w AFAIK.

> * The current sound infrastructure/architecture in Linux is overly complex and
> PA tries to solve that by adding additional abstractions.  I'm in the camp
> which roots for simplicity, not complexity. ;-)

I can see your thinking but I disagree. If you look at the alsa library it's an abstraction of the raw kernel interface to the drivers. This is a very good thing and one of the main design benefits of an ALSA system over an OSS system. Kernel level changes can be abstracted via an updated library that (literally) every alsa client uses. This means that when the kernel interface changes we don't have to update a million applications. This level of abstraction is definitely a good thing, but it's still quite specific. e.g. an application opens a single device. There is a concept of a "default" device which helps but it's still device specific. There needs to be some kind of abstract "output sound" system that can take care of ultimately routing the audio from the application to the chosen device. Whether this system is rolled into the alsa library or done via a separate project like PA only really differs by name. The level of abstraction provided by libasound and PA is really rather small and necessary. The PA core itself is zero-copy and lock-free, providing as transparent a process as is possible for a given situation. The approach taken by libasound+PA is really rather similar to how CoreAudio works on OSX. So not all layers are unnecessary.

If you think about phonon itself, it adds another two layers on top of this too :p

Anyway this is not the place to have such discussions, so I wont debate or reason any further here on this particular topic.
Comment 8 Myriam Schweingruber 2010-08-14 11:40:03 UTC

*** This bug has been marked as a duplicate of bug 220071 ***