#693 closed defect
ALL: crash on windows when using internal MIDI
| Reported by: | SF/doc_wagon | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Port: Win32 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Just compiled ScummVM from CVS. ScummVM crashes right after starting any game (except for Sam'n'Max) with a null pointer acces. Here are some details: SDL 1.2.6 from CVS MAD 0.14.2b (latest tarball) ScummVM from CVS All checked out and compiled today with MSVC 7. When I start ScummVM with "-e windows" everything works.
Here are some more details of the crash: Crash in fmopl.cpp line 1002: (ams = ams_table[(amsCnt+=amsIncr)>>AMS_SHIFT];) ams_table is 0x00000000
Stack Trace: SoundMixer::onGenerateSamples(...) SoundMixer::mix(...) MidiDriver_ADLIB::premix_proc(...) MidiDriver_ADLIB::generate_samples(...) YM3812UpdateOne(...)
If you need more info just tell me. I'm also ocassionally on IRC as Dark-Star.
Happy bughunting ;-) --Darkstar
Ticket imported from: #683544. Ticket imported from: bugs/693.
Change History (8)
comment:1 by , 22 years ago
comment:2 by , 22 years ago
To process your bug report appropriately, we need you to provide the following additional information:
* ScummVM version (scummvm -v) * Bug details, including instructions on reproducing it * Language of game (English, German, etc) * Version of game (Talkie, Floppy...) * Platform and Compiler (Win32, Linux, MacOS, etc) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!
comment:3 by , 22 years ago
To process your bug report appropriately, we need you to provide the following additional information:
* ScummVM version (scummvm -v) * Bug details, including instructions on reproducing it * Language of game (English, German, etc) * Version of game (Talkie, Floppy...) * Platform and Compiler (Win32, Linux, MacOS, etc) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!
comment:4 by , 22 years ago
I think this loop is buggy (fmopl.c, OPLBuildTables()):
for (i=0; i < (int)sizeof(SL_TABLE_SEED); i++) SL_TABLE[i] = SC_SL(SL_TABLE_SEED[i]);
it should be:
for (i=0; i < (int)sizeof(SL_TABLE_SEED)/sizeof(uint); i++) SL_TABLE[i] = SC_SL(SL_TABLE_SEED[i]);
instead, since SL_TABLE_SEED and SL_TABLE are uint[16] and sizeof(SL_TABLE_SEED) == 16 * sizeof(uint) so this loop writes waaay out of array-bounds.
Anyway, fixing this still crashes on me, so there seem to be more bugs hidden ...
--Darkstar
comment:5 by , 22 years ago
To process your bug report appropriately, we need you to provide the following additional information:
* ScummVM version (scummvm -v) * Bug details, including instructions on reproducing it * Language of game (English, German, etc) * Version of game (Talkie, Floppy...) * Platform and Compiler (Win32, Linux, MacOS, etc) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!
comment:6 by , 22 years ago
Fixed (I think). The two loops in OPLBuildTables() need to be changed to:
for (i=0; i < (int)sizeof(KSL_TABLE_SEED)/sizeof(double); i++) KSL_TABLE[i] = SC_KSL(KSL_TABLE_SEED[i]);
for (i=0; i < (int)sizeof(SL_TABLE_SEED)/sizeof(uint); i++) SL_TABLE[i] = SC_SL(SL_TABLE_SEED[i]);
Seems to run fine now.
--Darkstar
comment:7 by , 22 years ago
| Status: | new → closed |
|---|
comment:8 by , 6 years ago
| Component: | --Unset-- → Port: Win32 |
|---|
I did investigate the crash a bit, here's some more info: The crash was triggered by ams_table and AMS_TABLE being NULL pointers. I quickly found out that OPLOpenTable, which is the only function to setup AMS_TABLE, is not being called anywhere before the crash. Since OPL_LockTable is the only function to call OPLOpenTable, the problem must be in there, and it indeed is: num_lock is not zero but 268435456 upon the first entry into that function.So the question is: Why is num_lock overwritten? The solution: The second loop in OPLBuildTables seems to corrupt the memory by writing out of some array bounds. At least that's where my breakpoint on num_lock triggered, while i=34 or so. Other data in memory (static int RATE_0 for example) is also overwritten by that loop.
--Darkstar