Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07370 Crash/Freeze Critical (emulator) Always 14 days ago 14 days ago
Tester MetalGod View Status Public Platform MAME (Official Binary)
Assigned To hap Resolution Fixed OS Windows Vista/7/8 (64-bit)
Status [?] Resolved Driver namconb1.cpp
Version 0.211 Fixed in Version 0.212GIT Build 64-bit
Summary 07370: sws95, sws96, sws97: Crash during attract mode
Description Crash during attract mode

Regression is mame 0.203

Related to 07369 (regression is the same)
Steps To Reproduce Leave attract mode for a minute aproximately. The game/emulator will crash.
Additional Information
Flags
Regression Version 0.203
Affected Sets / Systems sws95, sws96, sws97
Attached Files
txt file icon error.txt (5,811 bytes) 14 days ago Uploaded by MetalGod
[Show Content]
Relationships
There are no relationship linked to this issue.
Notes
12
User avatar
No.16604
Fujix
Administrator
14 days ago
I left sws95 and sws96 without speed throttling for 5 minutes, there was no crash at all.
User avatar
No.16607
Tafoid
Administrator
14 days ago
I, too, cannot get either 32 or 64-bit to crash at all using latest version on any machine listed.
If it is a release version, it should produce a stack crawl when the emulator exits. Can you post that?
Baring that, try installing in a fresh folder and see if that makes any difference.
User avatar
No.16608
MetalGod
Senior Tester
14 days ago
I've tested several versions of mame, all in clean installations. It happens the same issue from mame 0.203 and onwards.
I'm using windows 7 as reported
User avatar
No.16609
Tafoid
Administrator
14 days ago
Does it crash at the same place each time? Is there no stack crawl or crash information being printed to command line window?
If you try a different video mode,s does it still happen?
User avatar
No.16611
MetalGod
Senior Tester
14 days ago
User avatar
No.16612
Tafoid
Administrator
14 days ago
If you run it form a command-window, the stack crawl should be displaying in that window after the screen stays dark. When you close the program after window's dialog comes up, look for the output of the console window.

run with "mame sws95 -nothrottle -verbose"
User avatar
No.16613
MetalGod
Senior Tester
14 days ago
edited on: 14 days ago
Always at the same place. Sometimes there's a Windows error message like the one seen in the video, sometimes don't, it keeps black screen all the time with no error message and with the only solution to close the process.

Edited: I'll check that command. Just a second
User avatar
No.16614
MetalGod
Senior Tester
14 days ago
Uploaded error.txt
User avatar
No.16615
hap
Developer
14 days ago
edited on: 14 days ago
Here's a crash with sws97:

-----------------------------------------------------
Exception at EIP=038f0040 (texture_info::set_data(render_texinfo const*, unsigned int)+0x0580): ACCESS VIOLATION
While attempting to read memory at 1d228f18
-----------------------------------------------------
EAX=1ce5b5f2 EBX=00000120 ECX=1d210f18 EDX=00006000
ESI=151785c8 EDI=000000b1 EBP=1017c108 ESP=1017bf30
-----------------------------------------------------
Stack crawl:
  1017c108: 038f0040 (texture_info::set_data(render_texinfo const*, unsigned int)+0x0580)
  1017c194: 038f4f25 (d3d_texture_manager::update_textures()+0x0125)
  1017c1e4: 038f5336 (renderer_d3d9::begin_frame()+0x00b6)
  1017c234: 038f6cc8 (renderer_d3d9::draw(int)+0x00d8)
  1017c2d4: 038b9052 (win_window_info::video_window_proc(HWND__*, unsigned int, unsigned int, long)@16+0x08a2)
  1017c2f4: 038b9596 (winwindow_video_window_proc_ui(HWND__*, unsigned int, unsigned int, long)@16+0x0026)
  1017c320: 74d448eb (AddClipboardFormatListener+0x004b)
  1017c404: 74d2613c (CallWindowProcW+0x0b2c)
  1017c468: 74d258ed (CallWindowProcW+0x02dd)
  1017c498: 74d255b3 (SendMessageW+0x0123)
  1017c4c8: 038b3ad9 (win_window_info::update()+0x0109)
  1017c4f8: 038b370e (windows_osd_interface::update(bool)+0x004e)
  1017c558: 0562349d (video_manager::frame_update(bool)+0x00ad)
  1017c5b8: 055f1f25 (screen_device::vblank_begin()+0x0365)
  1017c618: 055f51c5 (screen_device::device_timer(emu_timer&, unsigned int, int, void*)+0x0345)
  1017c698: 055ed760 (device_scheduler::timeslice()+0x0190)
  1017c718: 055a6937 (running_machine::run(bool)+0x0117)
  1017f6c8: 03951446 (mame_machine_manager::execute()+0x01e6)
  1017f858: 039c0443 (cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x0453)
  1017fa98: 039c0a99 (cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x0039)
  1017fac8: 0394f1ed (emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x002d)
  1017fec8: 09ebef5a (main+0x01aa)
  1017ff68: 0040138b (__tmainCRTStartup+0x023b)
  1017ff80: 75396359 (BaseThreadInitThunk+0x0019)
  1017ffdc: 77197a94 (RtlGetAppContainerNamedObjectPath+0x00e4)
  1017ffec: 77197a64 (RtlGetAppContainerNamedObjectPath+0x00b4)


same crash with -video gdi:

-----------------------------------------------------
Exception at EIP=038fa5e2 (renderer_gdi::draw(int)+0x3072): ACCESS VIOLATION
While attempting to read memory at 1859afe8
-----------------------------------------------------
EAX=18582fe8 EBX=00b05bb7 ECX=004626e5 EDX=00000330
ESI=184a4950 EDI=00006000 EBP=1017c228 ESP=1017c110
-----------------------------------------------------
Stack crawl:
  1017c228: 038fa5e2 (renderer_gdi::draw(int)+0x3072)
  1017c2d4: 038b9052 (win_window_info::video_window_proc(HWND__*, unsigned int, unsigned int, long)@16+0x08a2)
  1017c2f4: 038b9596 (winwindow_video_window_proc_ui(HWND__*, unsigned int, unsigned int, long)@16+0x0026)
  1017c320: 74d448eb (AddClipboardFormatListener+0x004b)
  1017c404: 74d2613c (CallWindowProcW+0x0b2c)
  1017c468: 74d258ed (CallWindowProcW+0x02dd)
  1017c498: 74d255b3 (SendMessageW+0x0123)
  1017c4c8: 038b3ad9 (win_window_info::update()+0x0109)
  1017c4f8: 038b370e (windows_osd_interface::update(bool)+0x004e)
  1017c558: 0562349d (video_manager::frame_update(bool)+0x00ad)
  1017c5b8: 055f1f25 (screen_device::vblank_begin()+0x0365)
  1017c618: 055f51c5 (screen_device::device_timer(emu_timer&, unsigned int, int, void*)+0x0345)
  1017c698: 055ed760 (device_scheduler::timeslice()+0x0190)
  1017c718: 055a6937 (running_machine::run(bool)+0x0117)
  1017f6c8: 03951446 (mame_machine_manager::execute()+0x01e6)
  1017f858: 039c0443 (cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x0453)
  1017fa98: 039c0a99 (cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x0039)
  1017fac8: 0394f1ed (emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x002d)
  1017fec8: 09ebef5a (main+0x01aa)
  1017ff68: 0040138b (__tmainCRTStartup+0x023b)
  1017ff80: 75396359 (BaseThreadInitThunk+0x0019)
  1017ffdc: 77197a94 (RtlGetAppContainerNamedObjectPath+0x00e4)
  1017ffec: 77197a64 (RtlGetAppContainerNamedObjectPath+0x00b4)
User avatar
No.16616
Tafoid
Administrator
14 days ago
Even though I still cannot make it crash on my end, hap is a developer who can duplicate the issue and that is good enough for a confirm in my book.
User avatar
No.16617
hap
Developer
14 days ago
edited on: 14 days ago
It was an array out of bounds access. I don't think it's related to the machbrkr bug.
IMO, MAME supporting black_pen() and white_pen() on an indirect 16-bit bitmap is asking for trouble.

*edit* correction: I mean 16-bit bitmap, not palette
Removing 16-bit bitmaps is on MAME's TODO, problems like these won't happen then.
User avatar
No.16618
MetalGod
Senior Tester
14 days ago
That was fast
Good work !
;)