Opened 3 years ago

Last modified 11 days ago

#12606 assigned bug

Crash with BSoundPlayer

Reported by: Max-Might Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Kits/Media Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (2)

godot.haiku.tools.32-372-debug-18-01-2016-21-33-05.report (14.9 KB) - added by Max-Might 3 years ago.
godot.haiku.tools.32-433-debug-03-02-2016-23-16-13.report (14.5 KB) - added by Max-Might 3 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 3 years ago by 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?

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by Barrett

What is the situation under hrev50071?

comment:5 Changed 3 years ago by Max-Might

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

comment:6 Changed 3 years ago by Max-Might

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

comment:7 Changed 6 months ago by 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.

Last edited 6 months ago by smallstepforman (previous) (diff)

comment:8 Changed 6 months ago by smallstepforman

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

comment:9 Changed 6 months ago by 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).

comment:10 Changed 11 days ago by korli

Owner: changed from Barrett to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.