Opened 16 years ago
Closed 14 years ago
#2762 closed bug (fixed)
media player consistently crashes
Reported by: | kvdman | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/MediaPlayer | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I've been testing mainly wav and mp3s through media player. It crashes since about 1 week.
See attached picture.
Attachments (1)
Change History (9)
by , 16 years ago
comment:1 by , 16 years ago
follow-up: 3 comment:2 by , 16 years ago
Owner: | changed from | to
---|
My only thoughts looking at the method shown is why the BAutoLock is casting "this" in PlayerCount when it doesn't in NewWindow which is the 2 places that are protecting fPlayerCount variable.
BWindow* MainApp::NewWindow() {
BAutolock _(this); fPlayerCount++; return new MainWin();
}
int32 MainApp::PlayerCount() const {
BAutolock _(const_cast<MainApp*>(this)); return fPlayerCount;
}
comment:3 by , 16 years ago
Replying to dlmcpaul:
My only thoughts looking at the method shown is why the BAutoLock is casting "this" in PlayerCount when it doesn't in NewWindow which is the 2 places that are protecting fPlayerCount variable.
PlayerCount() is const, so you couldn't use BAutoLock without casting.
comment:4 by , 16 years ago
'looks like #2759, so it happens with any file, it seems... '
I haven't tried video, but basically any audio file I through at it would crash media player.
comment:5 by , 16 years ago
I think I've found the problem, but I don't have any idea on how to solve this correctly. Basically, what happens is that The window thread starts (sometimes) before the MainApp constructor returns, and receives a B_WINDOW_ACTIVATED message from the app_server. Then, the WindowActivated() code calls Controller::PlayerActivated(), which in turn dereferences gMainApp. gMainApp isn't yet initialized, since the MainApp constructor hasn't returned yet. I've fixed the crash by initializing gMainApp in the MainApp constructor, like this:
gMainApp = be_app
and moving the creation of the window after that line. But again, I'm not sure it's a good solution. Maybe we should, in some way, delay the activation of the window after the BApplication has been run.
comment:6 by , 16 years ago
I used the same workaround in hrev27764 but indeed it's not clean, so the ticket should remain open until it's fixed.
comment:8 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The fix is not actually a work-arround, but is a completely valid fix for a race-condition. There is nothing unclean about it.
looks like #2759, so it happens with any file, it seems...