Lights Off crashes on startup

[darkwyrm]

As of hrev28815, the version on ​Bebits crashes immediately after starting up.

#0  0x0061fdf7 in BMediaTrack::ReadFrames ()
   from /boot/beos/system/lib/libmedia.so
#1  0x0061fdd2 in BMediaTrack::ReadFrames ()
   from /boot/beos/system/lib/libmedia.so
#2  0x00498c16 in BFileGameSound::Load () from /boot/beos/system/lib/libgame.so
#3  0x00498409 in BFileGameSound::Preload ()
   from /boot/beos/system/lib/libgame.so
#4  0x0020cd49 in GridView::StartupPreferences ()
#5  0x00209dce in GridView::GridView ()
#6  0x0020d1e8 in MainWindow::MainWindow ()
#7  0x00208eb2 in MyApp::MyApp ()
#8  0x00208fb5 in main ()

[leavengood]

Drawing glitch seen in between the "light" buttons.

[leavengood]

So I was just trying to debug this issue and I discovered that if you run LightsOff from the Terminal the crash does not happen. Though there is a lot of debugging information printed (probably because I enabled DEBUG for libmedia.so.) Though the same debug build of libmedia.so seems to choke up GDB when I try to run LightsOff from Tracker and the crash happens :(

It seems very strange that there is a crash when running from Tracker and no such thing when running from Terminal.

Also there are some drawing gliches: the areas between the "light buttons" are not painted over properly so whatever was drawn previously whereever LightsOff appears is seen in those lines, including the desktop. See attached screenshot where the Haiku logo and desktop color can be seen in those lines. Not sure if this is a Haiku issue or some problem in the LightsOff code.

[pulkomandy]

The program load sounds this way :

	BEntry entry("click.wav");

This will work from terminal, but not when started from tracker, likely because the path is not relative to the app directory in that case ?

The program will blindly continue, and crash when it tries to actually open the file. Does it work under BeOS ? and does it have sound when run from tracker ?

We may avoid the crash when given a broken entry ref, that's better than nothing.

Note the crash will happen if running the app through our Debugger.

[axeld]

As in BeOS, Haiku applications will inherit the path from its parent. When you launch an application from Tracker, its path will be /boot/home IIRC, as that's what Tracker is using.

It would be interesting where it actually crashes, though, since that might very well be solvable (for example if it uses the Game Kit support classes it probably don't need to load the file itself).

[pulkomandy]

Yes, the stacktrace is in the original ticket already. Not sure where an error shoud have been raised, but basically we get an (invalid) entry_ref from the BEntry, then build a BFileGameSound from that, and this create a BMediaTrack. All of this works fine (wel the app doesn't seem to do much error checking at least) and, when we try to actually load the file, there's a crash as seen above.

[marcusoverhagen]

GridView does no error checking for BEntry and BFileGameSound it creates, and calls Preload() on them.

Preload() alls Load()

BFileGameSound::Load() calls BMediaTrack::ReadFrames() with fAudioStream->stream invalid pointer.

When a file doesn't exist, fAudioStream->stream is invalid after BFileGameSound::Init(). This Init() has some more issues as well.

Solution: fix all the bugs. There are sooo many. Quick solution: Set fAudioStream to NULL on init error, and check it in Load()

[darkwyrm]

I had a look at the GridView code and I must say that I'm not proud of it -- it was quickly written, so I'm not surprised that the code doesn't do much error checking. However, the crashes are not caused by NULL pointers in the regular program code, which my local code now checks for. The pointers in StartupPreferences are valid. My initial reason for even filing the bug was because Lights Off worked just fine under R5 and Zeta but crashed in Haiku and, not knowing anything about the Media Kit, I couldn't figure out the specific problem(s).

[marcusoverhagen]

Does it still crash with hrev42453?

[jscipione]

I tested Lights Off in BeOS R5.03PE Max Ed v4b1 in vmware. When I run the application from Tracker no sound plays, nor does the Game->How To Play menu option work (which is suppose to open up an html file found in the app directory.) However, there is no crash and no drawing glitches. If I run the app from the terminal the sound works and the Game->How To Play menu option works as well. So what pulkomandy said about relative paths is most likely correct.

[jscipione]

I also tested Lights Off in Haiku hrev42455 in Virtual Box. I started the app from Tracker and the application runs, it does not crash. Graphical glitches, however, remain as reported. Neither the sound files play nor does the Game->How To Play menu option work.

I then started the application from the Terminal and the graphical glitches remain but the sound files play and the Game->How To Play menu option works. So, this functionality is identical to BeOS 5.

So the only real bug that remains in Haiku are the graphical glitches. I will attach a file out the debug output I get for Lights Out in Terminal.

[jscipione]

Debug output generated by running Lights Off in Haiku hrev42455 after starting up and clicking some blocks.

[mmu_man]

Actually, I'm not sure the crash is fixed. At least I do have a similar stack crawl on a pure virtual exception in Sounds sometimes, as I tried to reproduce #3085...

[mmu_man]

Using some objdump -D I traced the pure virtual to this call in BMediaTrack::ReadFrames(): result = fDecoder->Decode(buffer, _frameCount, _header, info); Maybe the decoder is being deleted at the same time and already has executed part of the dtor, putting the vtable in an odd state ?

[pulkomandy]

This particular bug is fixed.

Please open a new one for the graphical glitches.

mmu_man: there are other bugs in the Media Kit. I'm going to fix what may be a variant of what you see. see you in #4893 :)