Crash with BSoundPlayer

[Max-Might]

Hello.

I am porting an application and I used the BSoundPlayer class to play sounds. The application feeds it a stream of data and it just plays it. It used to work pretty fine. But since some time there is a problem. When I close the application it crashes somewhere in the media kit code. I have not made any changes in the sound-related code so it must be a regression.

Attached is the crash hreport. The only audio-related code is located in this file: ​https://github.com/Max-Might/godot/blob/master/platform/haiku/audio_driver_media_kit.cpp

[pulkomandy]

I think you need to stop your player before deleting, the destructor won't safely delete a running player. Not sure if this can be fixed on our side, maybe with a wait_for_thread?

[Barrett]

The player is automatically stopped by the destructor. The bug here is related to the ControlLoop() which fails to detect the deletion in certain situations. I *might* have a fix locally but need to look at it a bit more, thanks for reporting. In the meantime the situation should be better if you instantiate a BApplication somewhere.

[Max-Might]

Barrett, I retested with hrev50064 and the bug is still there.

If you want to reproduce it I have a WIP recipe ​here.

[Barrett]

What is the situation under hrev50071?

[Max-Might]

Just tested with hrev50072. It crashed again but this time it seems the stack trace is different. I will attach the report.

[Max-Might]

There is a Godot recipe in haikuports now. You can install it by running hp godot_x86.

[smallstepforman]

I'm working on a video editor for Haiku, and I experience a similar error, with a segment violation due to BSoundPlayer inclusion. First some scenarios:

Scenario #1: No inclusion of BSoundPlayer. Code runs fine, no errors on cleanup. Happy days.

Scenario #2: Create/Destroy BSoundPlayer

AudioManager::AudioManager(...) {

fSoundPlayer = new BSoundPlayer(...)

} AudioManager::~AudioManager() {

fSoundPlayer->Stop(); delete fSoundPlayer;

}

When the application EXITS, I will get an unrelated memory trampoline crash (and typically KDL on my XHCI unstable box). the exact memory trampoline varies with code size. If I'm lucky, there are code sizes which do not crash, but eventually adding unrelated code will trigger this bug.

Scenario #3 Create BSoundPlayer, but dont delete it. The following stack trace is produced (which seems similar to the original reported error)

BPrivate::SharedBufferList::Lock() segment violation.

BPrivate::SharedBufferList::RequestBuffer()

BBufferGroup::RequestBuffer()

BPrivate::SoundPlayNode::FillNextBuffer()

BPrivate::SoundPlayNode::SendNewBuffer()

BPrivate::SoundPlayNode::HandleEvent()

BMediaEventLooper::DispatchEvent

...

Scenario #4 Get rid of calls to new/delete BSoundPlayer, and all crashes disappear.

[smallstepforman]

Also, the system Mixer has many instances of my application listed, even though it has been killed many times. BMediaRoster not releasing resources?

[Barrett]

The issue is definitely related to the release of the memory at application quit. It's a long story to explain, but the original design is really flawed and has some big problems.

I am almost certain this happens when the BApplication quit. Replying to your second question, it is just a different story, it happens when apps crash and it is a relic of the reference counting system in the media_server (the bug has no functional issues itself).

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed