[haiku] Re: Sound problem causing freeze

On 2009-06-15 at 08:55:02 [+0200], j s <jsvader@xxxxxxxxx> wrote:
> Hi,
> 
> Been doing a bit more imvestigating. I managed to get it to crash without 
> locking the screen. I got a dump from the debug, but I couldn't get it 
> off the eeepc (no network -cant mount non BeFS RW).
> 
> If i disable sound, no crashing.
> 
> It crashed in PlaySound() with the previous stack element 
> FillNextBuffer(). It seems that if this crashes whilst the Locker is 
> locked (still can't work out how :) the system freezes. That is probably 
> something I can try to protect, however the crashing sound I can't.
> 
> All I ever do is:
> 
> BFileGameSound *screech = new BFileGameSound("screech.wav", true);
> 
> 
> To play the sound:
> 
> if( !screech->IsPlaying() )
> {
>     screech->StartPlaying();
> }
> 
> and visa versa when it wants to turn off
> 
> if( screech->IsPlaying() )
> {
>     screech->StopPlaying();
> }
> 
> At the moment, this is all in one thread (drawing thread). The basic flow 
> is:
> 
> drawing thread:
>   while ! quit
>     lock
>        update direct window
>     unlock
>     check inputs
>     update car physics
> 
> The directconnected uses the same lock.
> 
> I was thinking of making an input thread, however I  really need max 
> performance - I can get about 20 fps from a 630MHz eeepc at 640x480 32 
> bit on 4 million points (the map). All software rendering.

That sounds nice!

Anyway, I looked a bit at the code and fixed a race condition, but one 
which should not have been affecting you. I didn't dig as deep as looking 
at the FillBuffer() routines. In theory, the problem could also be a 
runtime loader bug that Ingo and I discovered during the weekend. This bug 
potentially causes add-on code to be mapped in memory that the application 
already allocated for other purposes. This can then cause all sorts of 
crashes. Add-ons are loaded for detecting and playback of the sound, 
without you being aware of it in your application code. In any case, I 
don't know how likely this bug is, and I also don't know how well the 
libgame.so code has been tested. It has been written before I became part 
of the project. So this may also still be a bug in the game sound code. I 
would take a closer look at the FillBuffer() routines. Maybe also check 
with other files that use a different encoding. To rule out the runtime 
loader problem, you could use area_for(void*) on the buffer memory address 
inside the FillBuffer routine. It should always return a valid area id.

If you need more help debugging this, sending a barebones version of your 
code that still reproduces the problem would be appreciated. You can also 
send the code in private, if you prefer that.

Best regards,
-Stephan

Other related posts: