Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06194 Crash/Freeze Critical (emulator) Always Apr 30, 2016, 03:07 May 2, 2016, 17:32
Tester anikom15 View Status Public Platform MESS (Official Binary)
Assigned To Resolution Open OS Windows Vista/7/8 (64-bit)
Status [?] Confirmed Driver msx.cpp
Version 0.173 Fixed in Version Build 64-bit
Summary MESS-specific 06194: cf3300 [bomber3d]: Loading DSDD Floppy into SSDD Drive Crashes MSX (CF-3300)
Description 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
Stack crawl:
  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
Additional Information
Regression Version 0.173
Affected Sets / Systems cf3300 [bomber3d]
Attached Files
There are no relationsihp linked to this issue.
User avatar
Apr 30, 2016, 19:36
edited on: Apr 30, 2016, 19:36
is the likely culprit - April 08, 2016

User avatar
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.

User avatar
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.
User avatar
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.
User avatar
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.

User avatar
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?
User avatar
May 1, 2016, 22:53
For the record, my observation was only based on testing "3dbomber" - I did not try the other sets.