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)

media.jpg (254.3 KB ) - added by kvdman 16 years ago.

Download all attachments as: .zip

Change History (9)

by kvdman, 16 years ago

Attachment: media.jpg added

comment:1 by jackburton, 16 years ago

looks like #2759, so it happens with any file, it seems...

comment:2 by dlmcpaul, 16 years ago

Owner: changed from marcusoverhagen to stippi

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;

}

in reply to:  2 comment:3 by jackburton, 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 kvdman, 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 jackburton, 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 mmu_man, 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:7 by jackburton, 14 years ago

What do we do about this ?

comment:8 by stippi, 14 years ago

Resolution: fixed
Status: newclosed

The fix is not actually a work-arround, but is a completely valid fix for a race-condition. There is nothing unclean about it.

Note: See TracTickets for help on using tickets.