| Summary: | artsd crashes playing system sounds with reduced volume | ||
|---|---|---|---|
| Product: | [Unmaintained] arts | Reporter: | Stefan Rompf <sux> |
| Component: | artsd | Assignee: | Stefan Westerfeld <stefan> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | cirrus, twl6 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Stefan Rompf
2003-11-19 21:09:11 UTC
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
|