Bug 78640 - artsd sometimes crashes on startup if NAS output is used
Summary: artsd sometimes crashes on startup if NAS output is used
Status: CLOSED UNMAINTAINED
Alias: None
Product: arts
Classification: Unmaintained
Component: artsd (other bugs)
Version First Reported In: 1.2.1
Platform: Gentoo Packages Linux
: NOR crash
Target Milestone: ---
Assignee: Stefan Westerfeld
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-28 21:40 UTC by Anonymous Coward
Modified: 2008-11-19 23:37 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
first attemp at patch (2.54 KB, patch)
2004-03-29 13:05 UTC, Anonymous Coward
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anonymous Coward 2004-03-28 21:40:53 UTC
Version:           1.2.1 (using KDE KDE 3.2.1)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7 
OS:          Linux

artsd often doesn't start up properly is NAS output method is used, it usually crashes and I have to relaunch it to succeed (sometimes several times). I tracked it down to the following description:
1. AudioIONAS::open() is called, NAS library initialized, events handling set up
2. The last call in open() is call to "AuHandleEvents(aud);", which triggers call to Arts::eventHandler()
3. eventHandler calls AudioSubSystem::the()->handleIO()
4. AudioSubSystem::handleIO(). At this point, no data are in the buffer, so it tries to fill it by calling producer->needMore(); Sometimes, producer==NULL, so it prompty crashes. If I add code to return from the function in such case, NAS will complain because it won't have audio data available, and my knowledge of NAS & aRts is not (yet) good enough to know how to handle that.

If I add "sleep(1);" call just before AuHandleEvents call from 2., it no longer crashes, so I suspect some kind of race condition in AudioSubSystem -- it doesn't expect that handleIO will be called from output's open(). Is this explanation possible? Sorry there's no patch attached, I couldn't figure out how to properly fix this...

Full-duplex is not set, I force sampling rate to 44kHz/16bits (otherwise arts would pick 11kHz, I didn't investigate why).
Comment 1 Anonymous Coward 2004-03-29 13:05:24 UTC
Created attachment 5458 [details]
first attemp at patch

I'm now (after upgrade of kernel to 2.4.25) always getting the crash,
regardless of sleep() call. The real problem seems to be that
AudioSubSystem::check() was called with producer==NULL. Attached patch fixes
the bug by delaying AuHandleEvents call (which triggers handleIO call) in
AudioIONAS class. It's done by setting up a timer that will call AuHandleEvents
as soon as AudioSubSystem::running() returns true -- i.e. when it is safe to
call handleIO. The timer will shut down itself immediately afterwards.

There's a problem, though: with this patch applied, audio will be skipping and
sound unusable unless the buffer is very small (like 4 fragments of 1024
bytes). It's the worse the larger the buffer is. Any idea what could be causing
this? I must be missing something important about arts here because the patch
looks harmless to me...
Comment 2 Matt Rogers 2008-11-19 23:37:40 UTC
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