Version: 1.5.94 (using KDE KDE 3.1.94) Installed from: Compiled From Sources Compiler: gcc 3.2.3 OS: Linux This is the bugtrace if it crashes: [New Thread 16384 (LWP 1268)] 0x406095c9 in waitpid () from /lib/libpthread.so.0 #0 0x406095c9 in waitpid () from /lib/libpthread.so.0 #1 0x0806709e in Arts::CrashHandler::defaultCrashHandler(int) () #2 0x40607c45 in __pthread_sighandler () from /lib/libpthread.so.0 #3 <signal handler called> #4 0x40752ac1 in kill () from /lib/libc.so.6 #5 0x406049ed in pthread_kill () from /lib/libpthread.so.0 #6 0x40604d0b in raise () from /lib/libpthread.so.0 #7 0x407526fa in raise () from /lib/libc.so.6 #8 0x40754127 in abort () from /lib/libc.so.6 #9 0x4074bd6a in __assert_fail () from /lib/libc.so.6 #10 0x4011fdfa in Arts::AudioPort::disconnect(Arts::Port*) () from /mica/local/kde/lib/libartsflow.so.1 #11 0x4013dce8 in Arts::VPortConnection::~VPortConnection() () from /mica/local/kde/lib/libartsflow.so.1 #12 0x4013d1fd in Arts::VPortConnection::VPortConnection(Arts::VPort*, Arts::VPort*, Arts::VPortConnection::Style) () from /mica/local/kde/lib/libartsflow.so.1 #13 0x4013e1dc in Arts::VPort::virtualize(Arts::VPort*) () from /mica/local/kde/lib/libartsflow.so.1 #14 0x40121eaa in Arts::StdScheduleNode::virtualize(std::string const&, Arts::ScheduleNode*, std::string const&) () from /mica/local/kde/lib/libartsflow.so.1 #15 0x4013f6f0 in Arts::BusManager::addClient(std::string const&, Arts::BusClient*) () from /mica/local/kde/lib/libartsflow.so.1 #16 0x40140533 in Arts::Synth_BUS_UPLINK_impl::connect() () from /mica/local/kde/lib/libartsflow.so.1 #17 0x4014044f in Arts::Synth_BUS_UPLINK_impl::streamInit() () from /mica/local/kde/lib/libartsflow.so.1 #18 0x401219a2 in Arts::StdScheduleNode::start() () from /mica/local/kde/lib/libartsflow.so.1 #19 0x4012eba9 in Arts::StdSynthModule::start() () from /mica/local/kde/lib/libartsflow.so.1 #20 0x4012eef1 in virtual thunk to Arts::StdSynthModule::start() () from /mica/local/kde/lib/libartsflow.so.1 #21 0x40146ed0 in Arts::Synth_AMAN_PLAY_impl::streamInit() () from /mica/local/kde/lib/libartsflow.so.1 #22 0x40146f11 in virtual thunk to Arts::Synth_AMAN_PLAY_impl::streamInit() () from /mica/local/kde/lib/libartsflow.so.1 #23 0x401219a2 in Arts::StdScheduleNode::start() () from /mica/local/kde/lib/libartsflow.so.1 #24 0x4012eba9 in Arts::StdSynthModule::start() () from /mica/local/kde/lib/libartsflow.so.1 #25 0x4012eef1 in virtual thunk to Arts::StdSynthModule::start() () from /mica/local/kde/lib/libartsflow.so.1 #26 0x4025f8a7 in _dispatch_Arts_SynthModule_00(void*, Arts::Buffer*, Arts::Buffer*) () from /mica/local/kde/lib/libartsflow_idl.so.1 #27 0x404003cf in Arts::Object_skel::_dispatch(Arts::Buffer*, Arts::Buffer*, long) () from /mica/local/kde/lib/libmcop.so.1 #28 0x403f808f in Arts::Dispatcher::handle(Arts::Connection*, Arts::Buffer*, long) () from /mica/local/kde/lib/libmcop.so.1 #29 0x403d16ce in Arts::Connection::receive(unsigned char*, long) () from /mica/local/kde/lib/libmcop.so.1 #30 0x40405576 in Arts::SocketConnection::notifyIO(int, int) () from /mica/local/kde/lib/libmcop.so.1 #31 0x403fbb72 in Arts::StdIOManager::processOneEvent(bool) () from /mica/local/kde/lib/libmcop.so.1 #32 0x403fbfbb in Arts::StdIOManager::run() () from /mica/local/kde/lib/libmcop.so.1 #33 0x403f9c88 in Arts::Dispatcher::run() () from /mica/local/kde/lib/libmcop.so.1 #34 0x08063e17 in main () #35 0x4073ed06 in __libc_start_main () from /lib/libc.so.6
This is well outside of kmail's scope, as far as I can tell. Doesn't look like a knotify problem either. Assigning to arts.
I can confirm this bug. I have the same backtrace with arts-1.2.0 and KDE-3.2.
This happens for me as well. It happens while noatun is playing and about two more sounds are meant to be played by artsd. Kopete and many incoming messages can make this scenario happen quite often, in case anybody else wants to reproduce.
I hope this additional info will be useful. I rebuilt artsd with enabled VPORT_DEBUG. Take a look at the output before it crashed: emit a connection consumer = Arts::Synth_BUS_UPLINK.right, producer = Arts::StereoVolumeControl.outright ~VPortConnection done ** (process:9157): CRITICAL **: file gslopmaster.c: line 248 (master_process_job): assertion `node->inputs[istream].src_node == NULL' failed ** (process:9157): CRITICAL **: file gslopmaster.c: line 248 (master_process_job): assertion `node->inputs[istream].src_node == NULL' failed virtualize ... source (producer) is Arts::Synth_BUS_UPLINK.left dest (consumer) is Arts::Synth_MULTI_ADD.invalue ~VPortConnection delete connection Arts::Synth_BUS_UPLINK.left -> Arts::StereoVolumeControl.outleft ~VPortConnection done ~VPortConnection delete connection Arts::Synth_BUS_UPLINK.left -> Arts::StereoVolumeControl.outleft artsd: gslschedule.cc:256: virtual void Arts::AudioPort::disconnect(Arts::Port*): Assertion `source' failed. AudioSubSystem::emergencyCleanup Note that the same VPortConnection is deleted twice that caused failed assertion.
Created attachment 4767 [details] this patch fixes arts crash I removed all assertions from AudioPort::disconnect() to prevent arts from crashing and now it works fine to me. I'd be grateful for any feedback.
Looks good so far. Every combination of events that triggered a crash or freeze before works smoothly now. Good work.
Shouldn't this patch be commited? The bug is still there in arts-1.2.1 and I for one am not overly thrilled about the prospect of having to patch every release. Pretty please?
*** Bug 73910 has been marked as a duplicate of this bug. ***
*** Bug 74720 has been marked as a duplicate of this bug. ***
*** Bug 75205 has been marked as a duplicate of this bug. ***
Note http://bugs.kde.org/show_bug.cgi?id=75205 comment #3
*** Bug 68601 has been marked as a duplicate of this bug. ***
It looks like AudioPort gets connected twice, which is really not supposed to happen. (See also MultiPort) Can someone who experiences this problem add assert(source == 0) to the top of void AudioPort::connect(Port *psource) like this: void AudioPort::connect(Port *psource) { assert(source == 0); source = psource->audioPort(); assert(source); Does it now crash on that assert? Can you post a backtrace?
Roman: I'm concerned about the part that says: ** (process:9157): CRITICAL **: file gslopmaster.c: line 248 master_process_job): assertion `node->inputs[istream].src_node == NULL' failed That suggests that something goes wrong before the disconnect already. It looks like AudioPort gets connected twice, which is really not supposed to happen. (See also MultiPort) Can someone who experiences this problem add assert(source == 0) to the top of void AudioPort::connect(Port *psource) like this: void AudioPort::connect(Port *psource) { assert(source == 0); source = psource->audioPort(); assert(source); Does it now crash on that assert? Can you post a backtrace?
Created attachment 5270 [details] Backtrace of crash with the patch Applied the suggested patch, putting the assert at the top of connect(). Here's the backtrace of the resulting crash.
I have the same binaries running on two systems. One crashes, one doesn't. It is perhaps significant that the one which crashes has an emu10k sound driver, which is a multi-open driver (i.e. even if one process/thread opens /dev/dsp for writing, other processes can still open it for writing, and the resulting two or more streams will be mixed and played). The system which does not crash is a Neomagic, single-open driver, only one process at a time can hold /dev/dsp open for writing. Given the comments about multiple connects and disconnects, this might be relevant.
The backtrace of #15 doesn't seem to hit the assert in connect() so appearantly it doesn't get connected twice. The fault then presumably lies in the disconnection logic.
Created attachment 5276 [details] extra debug output Could you apply the patch that adds extra debug out and report the output that it generates?
The following data appeared in ~/.x-errors (the place where console output from my xdm session is sent) with the debugging patch in place: ** (process:10171): CRITICAL **: file gslopmaster.c: line 248 (master_process_job): assertion `node->inputs[istream].src_node == NULL' failed ** (process:10171): CRITICAL **: file gslopmaster.c: line 248 (master_process_job): assertion `node->inputs[istream].src_node == NULL' failed artsd: gslschedule.cc:256: virtual void Arts::AudioPort::disconnect(Arts::Port*): Assertion `source' failed. AudioSubSystem::emergencyCleanup unix_connect: can't connect to server (unix:/tmp/mcop-neufeld/londo_cneufeld_ca-48ed-405a6e83) (The previous message was repeated 1 times.) file flowsystem.cc: line 100 (virtual void Arts::RemoteScheduleNode::start()): assertion failed: (!remoteFs.isNull()) file flowsystem.cc: line 120 (virtual void Arts::RemoteScheduleNode::connect(const std::string&, Arts::ScheduleNode*, const std::string&)): assertion failed: (!fs.isNull()) file flowsystem.cc: line 120 (virtual void Arts::RemoteScheduleNode::connect(const std::string&, Arts::ScheduleNode*, const std::string&)): assertion failed: (!fs.isNull()) (The previous message was repeated 3 times.) unix_connect: can't connect to server (unix:/tmp/mcop-neufeld/londo_cneufeld_ca-27bb-405b017e) Launched ok, pid = 10175 There are already artsd objects registered, looking if they are active... ... cleaned 5 unused mcop global references.
Created attachment 5277 [details] Correct backtrace with connect() assert Sorry, I just realized that my earlier backtrace did not, in fact, incorporate the new assert(). I just re-ran the test, and this time the assertion did fail in connect(). Here's the backtrace.
I notice that you still don't have debug output, can you start artsd from a terminal like: artsd -F 10 -S 4096 -s 60 -m artsmessage -c drkonqi -l 0 -f The "-l 0" should enable the debug output. That you hit the assert on the connect is interesting indeed. Hopefully the debug output will be able to shed a bit of light on what is going on.
Created attachment 5278 [details] std stream outputs from running artsd as suggested Here is the std out/err output from running: artsd -F 10 -S 4096 -s 60 -m artsmessage -c drkonqi -l 0 -f with the debugging patch applied. I've inserted two lines of text between '<<< >>>' markers. The first marker shows the end of the startup transient, the output generated before the system had stabilized, and before it attempted to produce any sounds. Following this, I turned down the system volume and generated some sound. I got 6 immediate crashes in a row, with no accompanying output in the debugging output. Then, I hit CTRL-C, and generated several pages of output during shutdown. The 6 crashes are consistent with the 6 assertion failures in my latest .x-errors file: artsd: gslschedule.cc:256: virtual void Arts::AudioPort::disconnect(Arts::Port*): Assertion `source' failed. AudioSubSystem::emergencyCleanup unix_connect: can't connect to server (unix:/tmp/mcop-neufeld/londo_cneufeld_ca-082f-405b105e) (The previous message was repeated 1 times.) file flowsystem.cc: line 100 (virtual void Arts::RemoteScheduleNode::start()): assertion failed: (!remoteFs.isNull()) file flowsystem.cc: line 120 (virtual void Arts::RemoteScheduleNode::connect(const std::string&, Arts::ScheduleNode*, const std::string&)): assertion failed: (!fs.isNull()) file flowsystem.cc: line 120 (virtual void Arts::RemoteScheduleNode::connect(const std::string&, Arts::ScheduleNode*, const std::string&)): assertion failed: (!fs.isNull()) (The previous message was repeated 3 times.)
Huh, how can you get artsd output in .x-errors if you have redirected stdout/stderr to a file? Can you make sure that the artsd that you start manually is the only one running?
I assumed that some of the information winds up in .x-errors because artsd communicates with previously-spawned programs, and those programs send the output there. You're right, it does appear as if multiple incarnations of artsd were running. When I try to run it alone, KDE appears not to want to talk to it, and starts its own version. I've tried replacing /usr/local/kde/bin/artsd with a shell script which runs .../artsd.2, the real binary, but the error behaviour is different, I get messages about failure to communicate with the sound server over DCOP. Anyway, I will attach the output from this method, it may still be useful.
Created attachment 5280 [details] Artsd stderr/out output when run alone As noted, the sound system generates different errors, though it still plays sounds and still makes crashes when invoked this way, I get additional MCOP error dialogues which I don't see otherwise. I'm going to patch up artsd so that it ignores the passed value of the "-l" switch, and substitutes "-l 0" instead. In the mean time, here's what I've got.
Created attachment 5281 [details] Debug output captured from stdout/err I think this is a more reliable test than the last one, so I'm obsoleting that attachment. I patched the artsd binary to believe it was always being called with "-l 0", then let KDE restart it. The debugging output ends up in .x-errors, here is everything from the moment I turned down the volume and started generating crashes to the moment I turned it back up to maximum and the crashes stopped.
The artsd output in #25 seems to have captured the problem nicely, unfortunately it misses some stuff in the debug output, I will attach a new debug patch.
Created attachment 5282 [details] extra debug output (improved)
Created attachment 5284 [details] Output from the latest patch Re-ran with the latest debugging patch.
Ok, I now sort of see what is happening, but I'm not sure I understand: Glossary: APO: Arts::audiofilePlayObject SAP: Arts::Synth_AMAN_PLAY SMA: Arts::Synth_MULTI_ADD SVC: Arts::StereoVolumeControl #nnn is reference to line number nnn of attachment 5284 [details] All references are to left channel only. #417 virtualize SBU to SMA.invalue #418 SBU connects to SMA.invalue #451 connect port outleft to left #452 SVC.out connects to SAP #458 +--> resulting in SVC.out to SMA.invalue connection #561 +--> resulting in SVC.out to SMA._invalue1 connection #507 connect port left to left #508 APO connects to SAP #514 +--> resulting in APO to SMA.invalue connection #517 +--> resulting in APO to SMA._invalue2 connection #571 devirtualize SBU to SMA .... +--> resulting in a lot of reshuffling #630 +--> resulting in SVC.out to SBU connection #636 +--> resulting in APO to SBU connection #713 disconnect port left and left #714 APO disconnects from SAP #730 +--> the connection from #636 is now changed into a SVC.out to SBU connection, but that fails because such connection was already created in #630 (this condition was caught in bug-comment #20) The overall problem seems to be here that although both SVC.out and APO get connected to SMA.in, this results in two distinct connections to SMA._invalue1 and SMA._invalue2 and when #517 devirtualizes SBU -> SMA they are no longer recognized as being distinct. I'm inclined to think that the SBU->SMA devirtualisation should happen later, after the APO->SAP and SVC->SAP disconnect.
More glossary: SBU: Arts::Synth_BUS_UPLINK
Created attachment 5355 [details] patch to workaround the crash Can you try and see if the attached patch fixes your problem? Can you send me the debug output with this patch applied? (First 2000 lines or so)
Created attachment 5356 [details] Debugging output with the patch Applied the patch of attachment 5355 [details], as well as the debugging patch of attachment 5282 [details]. The artsd did not crash under the conditions which formerly always caused a crash, so this patch does seem to have stopped the crashes. Attached are the first 1150 lines of the debug output. Subsequent lines seem just to repeat blocks from the earlier lines, so they are not included.
I have committed patch 5355, so this problem should no longer bother people. It doesn't fix the underlying problem that happens when the VPortConnections are being disconnected though, so I leave the bugreport open.
*** Bug 87765 has been marked as a duplicate of this bug. ***
*** Bug 75996 has been marked as a duplicate of this bug. ***
*** Bug 96793 has been marked as a duplicate of this bug. ***
*** Bug 97378 has been marked as a duplicate of this bug. ***
*** Bug 67033 has been marked as a duplicate of this bug. ***
*** Bug 104093 has been marked as a duplicate of this bug. ***
*** Bug 74871 has been marked as a duplicate of this bug. ***
Arts is no longer developed and has been unmaintained for quite some time - more than 2 years. With phonon as the replacement for arts in KDE4, we're closing out all the arts bugs in Bugzilla since there is no chance of them being fixed. Thanks