Opened 5 years ago

Closed 13 months ago

Last modified 9 months ago

#12606 closed bug (duplicate)

Crash with BSoundPlayer

Reported by: Max-Might Owned by: nobody
Priority: normal Milestone:
Component: Kits/Media Kit Version: R1/Development
Keywords: Cc:
Blocked By: #11213 Blocking:
Platform: All



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:

Attachments (2) (14.9 KB ) - added by Max-Might 5 years ago. (14.5 KB ) - added by Max-Might 5 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by pulkomandy, 5 years ago

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 by Barrett, 5 years ago

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 by Max-Might, 5 years ago

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 by Barrett, 5 years ago

What is the situation under hrev50071?

comment:5 by Max-Might, 5 years ago

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

comment:6 by Max-Might, 5 years ago

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

comment:7 by smallstepforman, 2 years ago

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

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;


I will get an unrelated memory trampoline crash, and typically KDL on my XHCI unstable box. the exact memory trampoline varies with code size. 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 BSoundPlayer, and all crashes disappear.

Version 0, edited 2 years ago by smallstepforman (next)

comment:8 by smallstepforman, 2 years ago

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 by Barrett, 2 years ago

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 by korli, 22 months ago

Owner: changed from Barrett to nobody
Status: newassigned

comment:11 by diver, 13 months ago

Blocked By: 11213 added
Resolution: duplicate
Status: assignedclosed

comment:12 by nielx, 9 months ago

Milestone: Unscheduled

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

Note: See TracTickets for help on using tickets.