Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.2 OS: Linux When playing certain system sounds with reduced volume, artsd crashes. Reproduce: -open control panel -go to sound & multimedia, system notification -enable sounds for virtual desktop changing (KDE_Desktop?.wav) -click on player settings, reduce volume (external player should be disabled, of course) -save/apply -now change the desktop several times, and artsd will go boom Verified on SUSE 8.1/Alsa0.9.8 and Redhat 7.1/OSS. Backtrace: [New Thread 1024 (LWP 760)] 0x4078b8c9 in wait4 () from /lib/libc.so.6 #0 0x4078b8c9 in wait4 () from /lib/libc.so.6 #1 0x40806c90 in __DTOR_END__ () from /lib/libc.so.6 #2 0x40605a93 in waitpid () from /lib/libpthread.so.0 #3 0x0806705e in Arts::CrashHandler::defaultCrashHandler(int) () #4 0x4060312b in pthread_sighandler () from /lib/libpthread.so.0 #5 <signal handler called> #6 0x40717df1 in kill () from /lib/libc.so.6 #7 0x4060306d in pthread_kill () from /lib/libpthread.so.0 #8 0x406035eb in raise () from /lib/libpthread.so.0 #9 0x407194d9 in abort () from /lib/libc.so.6 #10 0x4071240f in __assert_fail () from /lib/libc.so.6 #11 0x4011c1fa in Arts::AudioPort::disconnect(Arts::Port*) () from /usr/local/kde/lib/libartsflow.so.1 #12 0x40139f58 in Arts::VPortConnection::~VPortConnection() () from /usr/local/kde/lib/libartsflow.so.1 #13 0x4013946d in Arts::VPortConnection::VPortConnection(Arts::VPort*, Arts::VPort*, Arts::VPortConnection::Style) () from /usr/local/kde/lib/libartsflow.so.1 #14 0x4013a44c in Arts::VPort::virtualize(Arts::VPort*) () from /usr/local/kde/lib/libartsflow.so.1 #15 0x4011e2aa in Arts::StdScheduleNode::virtualize(std::string const&, Arts::ScheduleNode*, std::string const&) () from /usr/local/kde/lib/libartsflow.so.1 #16 0x4013b91f in Arts::BusManager::addClient(std::string const&, Arts::BusClient*) () from /usr/local/kde/lib/libartsflow.so.1 #17 0x4013c773 in Arts::Synth_BUS_UPLINK_impl::connect() () from /usr/local/kde/lib/libartsflow.so.1 #18 0x4013c68f in Arts::Synth_BUS_UPLINK_impl::streamInit() () from /usr/local/kde/lib/libartsflow.so.1 #19 0x4011dda2 in Arts::StdScheduleNode::start() () from /usr/local/kde/lib/libartsflow.so.1 #20 0x4012ae09 in Arts::StdSynthModule::start() () from /usr/local/kde/lib/libartsflow.so.1 #21 0x4012b151 in virtual thunk to Arts::StdSynthModule::start() () from /usr/local/kde/lib/libartsflow.so.1 #22 0x40143060 in Arts::Synth_AMAN_PLAY_impl::streamInit() () from /usr/local/kde/lib/libartsflow.so.1 #23 0x401430a1 in virtual thunk to Arts::Synth_AMAN_PLAY_impl::streamInit() () from /usr/local/kde/lib/libartsflow.so.1 #24 0x4011dda2 in Arts::StdScheduleNode::start() () from /usr/local/kde/lib/libartsflow.so.1 #25 0x4012ae09 in Arts::StdSynthModule::start() () from /usr/local/kde/lib/libartsflow.so.1 #26 0x4012b151 in virtual thunk to Arts::StdSynthModule::start() () from /usr/local/kde/lib/libartsflow.so.1 #27 0x4025b787 in _dispatch_Arts_SynthModule_00(void*, Arts::Buffer*, Arts::Buffer*) () from /usr/local/kde/lib/libartsflow_idl.so.1 #28 0x404116ef in Arts::Object_skel::_dispatch(Arts::Buffer*, Arts::Buffer*, long) () from /usr/local/kde/lib/libmcop.so.1 #29 0x404095af in Arts::Dispatcher::handle(Arts::Connection*, Arts::Buffer*, long) () from /usr/local/kde/lib/libmcop.so.1 #30 0x403e38ee in Arts::Connection::receive(unsigned char*, long) () from /usr/local/kde/lib/libmcop.so.1 #31 0x40416736 in Arts::SocketConnection::notifyIO(int, int) () from /usr/local/kde/lib/libmcop.so.1 #32 0x4040cf42 in Arts::StdIOManager::processOneEvent(bool) () from /usr/local/kde/lib/libmcop.so.1 #33 0x4040d38b in Arts::StdIOManager::run() () from /usr/local/kde/lib/libmcop.so.1 #34 0x4040b1a8 in Arts::Dispatcher::run() () from /usr/local/kde/lib/libmcop.so.1 #35 0x08063db7 in main () #36 0x407064a2 in __libc_start_main () from /lib/libc.so.6 Stefan
Your backtrace mentions a failed assertion. Can you find in your output (or ~/.xsession-errors or equivalent file) the message printed by the assertion routines, which state the line number of the crash, as well as the failed condition? This would greatly help us find the problem.
artsd: gslschedule.cc:256: virtual void Arts::AudioPort::disconnect(Arts::Port*): Assertion `source' failed. AudioSubSystem::emergencyCleanup
Same problem on Fedora Core 1 with KDE 3.1.94
I've got the same problem on a pretty clean debian woody box. KDE installed from kde.org debian packages. The sound of kopete was too loud compared to the music I usually listen too, so i though to turn the volume a bit down from the control panel for system notifications. The result was crashes, which I could not ever recover from, having to do an alt-sysrq-Boot. I took me some time to pin it down to the volume changing, and I even did a kde reinstall just to discover later that this was the problem.
Same problem in KDE 3.2 (final) on Slackware 9.1 (using slackware-current official packages). This is really a bit upsetting :( Given that it was reported so early. I have the system notification volume lowered because multimedia files on that machine are really low volume, and it helps to create a nice balance. But as soon as I upgraded from KDE 3.1.4 to 3.2, artsd went into a constant crash cycle (recursive -- KDE crash notification caused a sound which caused an artsd crash which caused KDE crash notification). Took me quite some time to figure out -- even after looking at this and first dismissing it because I'd forgotten that I'd changed the volume so long ago :( This could be a major bug to a fair few people (anybody who has changed that volume it would seem). Andypoo.
I've solved this issue, at least for my case, but i really don't know what are the implications. The problem is that the contract programming used in AudioPort::disconnect is not being honored. At least, one of this pointers is NULL (source, source->parent or parent). I'm posting the AudioPort::disconnect with the changes made. ----------- Code ------------------------------- void AudioPort::disconnect(Port *psource) { assert(source); assert(source == psource->audioPort()); removeAutoDisconnect(psource); assert(sourcemodule == source->parent); sourcemodule = 0; // Verify these pointer are NULL if (source != NULL && source->parent != NULL && parent != NULL) { source->parent->_connectionCountChanged = parent->_connectionCountChanged = true; source->destcount--; } source = 0; // GSL disconnect // Verify is parent is NULL if (parent != NULL) { GslTrans *trans = gsl_trans_open(); gsl_trans_add(trans, gsl_job_disconnect(parent->gslModule, gslEngineChannel)); gsl_trans_commit(trans); } } -------------------------------------------------- So at some point someone is "cleaning" any pointer. Regards Nuno
*** This bug has been marked as a duplicate of 70028 ***