Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|06194||Crash/Freeze||Critical (emulator)||Always||Apr 30, 2016, 03:07||Dec 22, 2017, 19:58|
|Tester||anikom15||View Status||Public||Platform||MESS (Official Binary)|
|Assigned To||Resolution||Open||OS||Windows Vista/7/8 (64-bit)|
|Version||0.173||Fixed in Version||Build||64-bit|
|Summary||06194: cf3300 [bomber3d]: Loading DSDD Floppy into SSDD Drive Crashes MSX (CF-3300)|
UPDATE: This crash only seems to occur when a double-sided floppy is loaded into a single-sided drive. See notes for details.
I tested with bomber3d, msxdos, msxdosa, and msxdosb, all loaded from the software list. All crashed except for msxdosb, which froze. I used the National CF-3300 (cf3300) set, though I imagine it affects other MSX systems with floppy drives as well.
Here's the crash output:
Exception at EIP=0000000002A780CE (floppy_image_format_t::generate_track_from_levels(int, int, std::vector<unsigned int, std::allocator<unsigned int> >&, int, floppy_image*)+0x025e): ACCESS VIOLATION
While attempting to write memory at 0000000067655273
RAX=0000000067655273 RBX=0000000018E16120 RCX=0000000050000000 RDX=0000000000000DAC
RSI=0000000000000020 RDI=00000000500003E8 RBP=0000000000242B10 RSP=0000000000242A90
R8=00000000000186A0 R9=000000001907BB40 R10=00000000000001F4 R11=0000000000000000
R12=0000000000000000 R13=000000001901A0CC R14=0000000000000000 R15=00000000000003E8
0000000000242AA0: 0000000002A780CE (floppy_image_format_t::generate_track_from_levels(int, int, std::vector<unsigned int, std::allocator<unsigned int> >&, int, floppy_image*)+0x025e)
00000000002431D0: 0000000002A7EE89 (floppy_image_format_t::generate_track(floppy_image_format_t::desc_e const*, int, int, floppy_image_format_t::desc_s const*, int, int, floppy_image*)+0x02b9)
0000000000248640: 0000000002AD4951 (upd765_format::load(io_generic*, unsigned int, floppy_image*)+0x0631)
00000000002486D0: 0000000002338945 (floppy_image_device::call_load()+0x00c5)
0000000000248710: 000000000295B4EA (device_image_interface::finish_load()+0x00aa)
00000000002487D0: 00000000029ABCE8 (image_manager::postdevice_init()+0x00f8)
0000000000248840: 000000000298CE33 (driver_device::device_start()+0x0083)
0000000000248960: 0000000002953932 (device_t::start()+0x0422)
00000000002489C0: 00000000029CE48B (running_machine::start_all_devices()+0x006b)
0000000000248AA0: 00000000029D2C3A (running_machine::start()+0x0b7a)
0000000000248B00: 00000000029D2FFA (running_machine::run(bool)+0x00aa)
000000000024F4F0: 000000000178F2FA (mame_machine_manager::execute()+0x015a)
000000000024F960: 000000000180A9D2 (cli_frontend::execute(int, char**)+0x1092)
000000000024F9D0: 000000000178E555 (emulator_info::start_frontend(emu_options&, osd_interface&, int, char**)+0x0035)
000000000024FDF0: 00000000016F1834 (utf8_main(int, char**)+0x0124)
000000000024FE50: 0000000002E9085F (wmain+0x007f)
000000000024FF20: 000000000040140C (__tmainCRTStartup+0x025c)
000000000024FF50: 000000000040153B (mainCRTStartup+0x001b)
000000000024FF80: 00007FF9EDC72D92 (BaseThreadInitThunk+0x0022)
000000000024FFD0: 00007FF9EDF39F64 (RtlUserThreadStart+0x0034)
|Steps To Reproduce||
1. Run MAME with cf3300 bomber3d
2. MAME will stall at 'Initializing...' before crashing
1. Run MAME with cf3300 msxdosb -window -debug
2. Also crash
|Affected Sets / Systems||cf3300 [bomber3d]|
|There are no relationsihp linked to this issue.|
Apr 30, 2016, 19:36
edited on: Apr 30, 2016, 19:36
is the likely culprit - April 08, 2016
May 1, 2016, 00:41
edited on: May 1, 2016, 05:46
As the author of that commit, I don't see exactly how it could have contributed to the reported crash. In fact, on my own working OS X debug build, the driver in question loads msxdos from the softlist just fine.
Update: Well, actually, testing another MSX disk image, fatal errors do indeed occur. Sometimes the loading routine works just fine, sometimes it segfaults, sometimes it throws a std::bad_alloc exception, one time it died with a malloc error saying "incorrect checksum for freed object - object was probably modified after being freed."
Update^2: I seem to have pinpointed the source of the problem: trying to load a double-sided disk image into a 3.5" SSDD drive. It's heinous that there is no sanity checking against this! Of course, the driver's configuration of the CF-3300's floppy drive might itself be in error.
May 1, 2016, 17:06
|I do not believe that commit is the source of the problem either. Did you try bomber3d? It is single-sided.|
May 1, 2016, 17:46
|No, it isn't. The file bomber man 3d (1984)(hudson soft)(jp).dsk is 737280 bytes long, which means it's either double-sided or overdumped.|
May 1, 2016, 21:56
edited on: May 1, 2016, 21:58
That seems weird to me. But it is still not totally clear where the problem is coming from. msxdosb is single-sided, and it freezes. I run mame with -window -debug and I get a crash with ACCESS VIOLATION. Updated steps to reproduce.
May 1, 2016, 22:24
|I did some research. MSX wiki says it has 2DD drive. blueMSX says it's single sided. MAME software list has utility disk as single-sided. I found another version of utility disk as double-sided, but is likely just improperly formatted. Generation MSX says 360k floppy drive. Most likely both configurations were available. Double-sided is available as optional slot device instead of single sided. So it seems I just overlooked this when I tried to run double-sided disk. With double-sided everything works fine. I suggest having checks for this, or mimicking what hardware would do (with warning message). What would happen if you were to load a double-sided disk into a single-sided drive in real life?|
May 1, 2016, 22:53
|For the record, my observation was only based on testing "3dbomber" - I did not try the other sets.|
Dec 22, 2017, 19:58
I just realized this:
'Fatal error: Device 3.5" single-sided double density floppy drive load failed: Incompatible image format or corrupted data'
now appears. Not sure when this was fixed but this can be closed.