| Summary: | Disconnecting VPortConnections results in port getting connected twice | ||
|---|---|---|---|
| Product: | [Unmaintained] arts | Reporter: | Michael Chalvatzis <glykos> |
| Component: | knotify | Assignee: | Multimedia Developers <kde-multimedia> |
| Status: | CLOSED UNMAINTAINED | ||
| Severity: | normal | CC: | bastian, DAcash18, gsheward, info, jens.zurheide, kdebugs, peter.ruskin, qberk25, robert, sux, th.hoffmann |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
this patch fixes arts crash
Backtrace of crash with the patch extra debug output Correct backtrace with connect() assert std stream outputs from running artsd as suggested Artsd stderr/out output when run alone Debug output captured from stdout/err extra debug output (improved) Output from the latest patch patch to workaround the crash Debugging output with the patch |
||
|
Description
Michael Chalvatzis
2003-12-10 18:22:48 UTC
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. *** *** 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 |