0.266 (mame0261-2041-g7eb725763ec), single driver build
System information
MacOS 14.5 M1 Pro.
MAME used is a single driver build using SOURCES=src/mame/msx/,src/mame/nintendo/gb.cpp
INI configuration details
No response
Emulated system/software
megaduck, hx10
Incorrect behaviour
Open MAME with debugger active (-debug -window megaduck), place cursor above the debugger above and (very) quickly scroll down (swiping with 2 fingers on the touchpad) towards/past the end of the debugger log, then the application will crash with message: "libc++abi: terminating due to uncaught exception of type std::length_error: vector"
If I scroll down slowly or normally then no crash occurs only when attempting to scroll quickly.
It does not happen when scrolling up (towards/past the start of the debugger log), nor does it happen in our debugger views as far ass I could see.
The crash happens with multiple drivers, so I assume it is a generic issue.
I do not know if a similar crash can happen on other OSes.
Backtrace from lldb:
libc++abi: terminating due to uncaught exception of type std::length_error: vector
Process 66712 stopped
MAME version
0.266 (mame0261-2041-g7eb725763ec), single driver build
System information
MacOS 14.5 M1 Pro. MAME used is a single driver build using SOURCES=src/mame/msx/,src/mame/nintendo/gb.cpp
INI configuration details
No response
Emulated system/software
megaduck, hx10
Incorrect behaviour
Open MAME with debugger active (-debug -window megaduck), place cursor above the debugger above and (very) quickly scroll down (swiping with 2 fingers on the touchpad) towards/past the end of the debugger log, then the application will crash with message: "libc++abi: terminating due to uncaught exception of type std::length_error: vector" If I scroll down slowly or normally then no crash occurs only when attempting to scroll quickly.
It does not happen when scrolling up (towards/past the start of the debugger log), nor does it happen in our debugger views as far ass I could see.
The crash happens with multiple drivers, so I assume it is a generic issue.
I do not know if a similar crash can happen on other OSes.
Backtrace from lldb: libc++abi: terminating due to uncaught exception of type std::length_error: vector Process 66712 stopped
__pthread_kill + 8 libsystem_kernel.dylib: -> 0x19a866a60 <+8>: b.lo 0x19a866a80 ; <+40> 0x19a866a64 <+12>: pacibsp 0x19a866a68 <+16>: stp x29, x30, [sp, #-0x10]! 0x19a866a6c <+20>: mov x29, sp Target 0: (msxd) stopped. (lldb) bt__pthread_kill + 8 frame #1: 0x000000019a89ec20 libsystem_pthread.dylibpthread_kill + 288 frame #2: 0x000000019a7aba30 libsystem_c.dylibabort + 180 frame #3: 0x000000019a855d08 libc++abi.dylibabort_message + 132 frame #4: 0x000000019a845fa4 libc++abi.dylibdemangling_terminate_handler() + 320 frame #5: 0x000000019a4e41e0 libobjc.A.dylib_objc_terminate() + 160 frame #6: 0x000000019a8550cc libc++abi.dylibstd::__terminate(void (*)()) + 16 frame #7: 0x000000019a855070 libc++abi.dylibstd::terminate() + 108 frame #8: 0x000000019a4fe2ec libobjc.A.dylibobjc_terminate + 16 frame #9: 0x000000019a6ee3fc libdispatch.dylib_dispatch_client_callout + 40 frame #10: 0x000000019a6f18ec libdispatch.dylib_dispatch_continuation_pop + 600 frame #11: 0x000000019a7057f0 libdispatch.dylib_dispatch_source_latch_and_call + 420 frame #12: 0x000000019a7043b4 libdispatch.dylib_dispatch_source_invoke + 832 frame #13: 0x000000019a6fcac8 libdispatch.dylib_dispatch_main_queue_drain + 748 frame #14: 0x000000019a6fc7cc libdispatch.dylib_dispatch_main_queue_callback_4CF + 44 frame #15: 0x000000019a9bfad4 CoreFoundationCFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16 frame #16: 0x000000019a97d258 CoreFoundation__CFRunLoopRun + 1996 frame #17: 0x000000019a97c434 CoreFoundationCFRunLoopRunSpecific + 608 frame #18: 0x00000001a512019c HIToolboxRunCurrentEventLoopInMode + 292 frame #19: 0x00000001a511ffd8 HIToolboxReceiveNextEventCommon + 648 frame #20: 0x00000001a511fd30 HIToolbox_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #21: 0x000000019e1dbd68 AppKit_DPSNextEvent + 660 frame #22: 0x000000019e9d1808 AppKit-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 frame #23: 0x0000000102115a28 msxddebugger_osx::wait_for_debugger(this=non-virtual thunk to debugger_osx::wait_for_debugger(device_t&, bool) at debugosx.mm:0 [opt] frame #25: 0x000000010213e958 msxdosd_common_t::wait_for_debugger(this=device_debug::instruction_hook(this=0x0000000137017800, curpc=<unavailable>) at debugcpu.cpp:923:19 [opt] frame #27: 0x0000000100a6bd78 msxdlr35902_cpu_device::execute_run() [inlined] device_execute_interface::debugger_instruction_hook(this=0x0000000135042600, curpc=lr35902_cpu_device::execute_run(this=0x0000000135042600) at lr35902.cpp:360:5 [opt] frame #29: 0x0000000100a717d8 msxdnon-virtual thunk to lr35902_cpu_device::execute_run() at lr35902.cpp:0 [opt] frame #30: 0x00000001020b094c msxddevice_scheduler::timeslice() [inlined] device_execute_interface::run(this=0x0000000135042600) at diexec.h:190:15 [opt] frame #31: 0x00000001020b093c msxddevice_scheduler::timeslice(this=0x000000016fdfe8a0) at schedule.cpp:460:14 [opt] frame #32: 0x00000001020441b8 msxdrunning_machine::run(this=0x000000016fdf9720, quiet=<unavailable>) at machine.cpp:333:17 [opt] frame #33: 0x00000001007a44a8 msxdmame_machine_manager::execute(this=0x0000600001c54800) at mame.cpp:288:19 [opt] frame #34: 0x000000010007decc msxdcli_frontend::start_execution(this=0x000000016fdfee98, manager=0x0000600001c54800, args=size=4) at clifront.cpp:277:22 [opt] frame #35: 0x000000010007f368 msxdcli_frontend::execute(this=0x000000016fdfee98, args=emulator_info::start_frontend(options=<unavailable>, osd=<unavailable>, args=<unavailable>) at mame.cpp:453:18 [opt] frame #37: 0x00000001021b8e6c msxdmain(argc=Expected behaviour
No more crashes.
Steps to reproduce
Start MAME with debugger active, attempt to scroll fast past the end of the log in the debugger console.
Additional details
-debug -window megaduck or -debug -window hx10