Red Hat Bugzilla – Bug 361891
arts: cpu overload, aborting
Last modified: 2009-12-21 23:54:32 EST
Description of problem: (no debugging symbols found) Using host libthread_db library "/lib64/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46912496332800 (LWP 3154)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [KCrash handler] #3 0x0000003ad0a7f7c5 in Arts::Dispatcher::handle () from /usr/lib64/libmcop.so.1 #4 0x0000003ad0a80567 in Arts::Connection::receive () from /usr/lib64/libmcop.so.1 #5 0x0000003ad0a8070a in Arts::SocketConnection::notifyIO () from /usr/lib64/libmcop.so.1 #6 0x0000003ad0a61994 in Arts::StdIOManager::processOneEvent () from /usr/lib64/libmcop.so.1 #7 0x0000003ad0a59676 in Arts::StdIOManager::run () from /usr/lib64/libmcop.so.1 #8 0x0000000000418b80 in virtual thunk to Arts::Object_skel::_queryInterface(std::string const&) () #9 0x0000003ac081e074 in __libc_start_main () from /lib64/libc.so.6 #10 0x000000000040eb29 in virtual thunk to Arts::Object_skel::_queryInterface(std::string const&) () #11 0x00007ffff32071b8 in ?? () #12 0x0000000000000000 in ?? () Version-Release number of selected component (if applicable): $ rpm -q arts arts-1.5.8-4.fc8 arts-1.5.8-4.fc8 (gotta love yum) How reproducible: Don't know. Comes quite often, especially when restoring desktop session. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Saying what the error is would have helped. ;-) From IRC: <Tuju> Sound server fatal error: <Tuju> cpu overload, aborting Lennart, this looks pulseaudio-related to me. This does not happen with F7 where aRts talks to ALSA dmix or directly to ALSA hardware mixing. In F8, we use the ALSA pulseaudio plugin. (We tried the ESD emulation, but that caused CPU overloads immediately, at least with full duplex enabled in aRts.)
well, it sprays so many errors and makes noice like DDR trabant so can't really say which symptoms are related to each other. :) like playing with noatun, it doesn't work. but kplayer with video works just fine (livna quality). I'll keep my eye out for that noatun and drop an another bug if that seem to be something 'stable situation/bug'.
re: noatun There's good reason it's in kdemultimedia-extras, and not installed by default.
arts cpu overload is induced when pulseaudio goes away or into a coma (which happens to me occasionally when resuming my laptop, for example). What setup are you using and at what times does arts crash?
> What setup are you using and at what times does arts crash? what you mean by that, could you be more specific? I took all pulseaudio kde stuff away (since i need audio) so if you need me to test something, I need to reinstall those.
I meant: what is going on, or what are you doing when arts crashes? Starting kde? resuming from standby/suspend? doing nothing? running your favorite music app?
opening comment: > How reproducible: > Don't know. Comes quite often, especially when restoring desktop session. so it took place when i was logging in and session manager was resuming my session. At that time pa had probably been running for a while with full cpu load and got killed.
fair nuf, let's punt this over to the kindly pa folks then.
mmm, i guess i messed here a bit (haven't got my lunch yet, running with fumes) .... so it is *arts* that dies - but without pa it works just fine. those two don't mix together, but can't say which one is the culprit.
This happens to me consistently when logging in to KDE for the first time in the day. Logging out and back in gets me past the error.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
appears for me on KDE-start. Using Fedora 10 here. artsmessage-window with: Sound server fatal error: cpu overload, aborting
No clue about KDE/arts, but can I close this bug? Running sound servers on top of sound servers doesn't strike me a particularly good idea, and I think KDE4 doesn't use arts anymore, or does it? Anyone objects if I close this now as WONTFIX given that the arts situation solved itself?
I think I've still seen this on Fedora 10. (Maybe the bug could be updated.) But I don't think it's already resolved with KDE 4.2.2 in F10.
These days aRts is used only by legacy stuff, and most of the time it isn't even running on F9 and newer (it only gets started when some legacy KDE 3 app needs it). So this is much less of an annoyance than it used to be, but it still happens once every blue moon. The big issue is, we still have no idea where the problem actually is (aRts? PulseAudio? ALSA?) and I'm not sure anyone really feels like debugging aRts given the current situation (aRts = legacy junk). What I could do as a quick&dirty hack is to make aRts just terminate without that dialog box when it detects a CPU overload. It'll get respawned anyway. Of course it doesn't really fix the problem, but it's better than just doing nothing. So, what do others think? Reassign to aRts, implement the crappy workaround and consider it closed?
Oh, KDE 4.2 is still including arts? That's awful.
Kevin I am not opposed to such a fix. I don't see myself debugging this properly either, so I think if arts still matters this might be a workable option.
Might be because there are still quite a number of KDE3-apps around (kaffeine first comes to my mind).
KDE 4.2 itself doesn't include aRts, it's part of the KDE 3 compatibility stuff.
I saw this today with kaffeine on F11-rawhide.
Kevin Kofler: Looks like your suggestion in comment #15 is the way go. Hack away! -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ping. Any movement on the hack Kevin? -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
F10 is nearing EOL. Going to rebase this to F11. Kevin are you still planning on addressing this. If not you can close as you see fit.
I committed and am now building a version for Rawhide which just shuts down quietly on CPU overload, as previously discussed (see comment #15).
arts-1.5.10-11.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/arts-1.5.10-11.fc12
arts-1.5.10-11.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/arts-1.5.10-11.fc11
arts-1.5.10-11.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update arts'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-13274
arts-1.5.10-11.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
arts-1.5.10-11.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.