- --
Viewing Issue Advanced Details
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
08818 | Crash/Freeze | Critical (emulator) | Always | Feb 10, 2024, 03:20 | Feb 21, 2024, 03:51 |
Tester | Roberto Fresca | View Status | Public | Platform | MAME (Self-compiled) |
Assigned To | AJR | Resolution | Fixed | OS | Windows 10/11 (64-bit) |
Status [?] | Resolved | Driver | |||
Version | 0.258 | Fixed in Version | 0.263 | Build | 64-bit |
Fixed in Git Commit | 9d36a10 | Github Pull Request # | |||
Summary | 08818: magicrde: PIC16F54 debug problems | ||||
Description |
The problem is if you try to use watchpoints on the SFR's (special function registers) range. WPoint (w) on register 0, breaks MAME going directly to a segfault. Also putting WPoints for R or W on registers 1 to 8 have no effect, since they don't stop the execution once reached. |
||||
Steps To Reproduce |
Run MAME -d magicrde Once in the debugger, press F6 to execute to the PIC. Once in the PIC, write: wpd 0, 1, w g This will crash MAME with a segfault. but... wpd 1, 8, w wpd 1, 8, r These don't work, at all. The WP is not stopping if these registers are read or written. |
||||
Additional Information | |||||
Github Commit | |||||
Flags | |||||
Regression Version | |||||
Affected Sets / Systems | magicrde | ||||
Attached Files
|
|||||
Relationships
There are no relationship linked to this issue. |
Notes
3
No.21958
Robbbert Senior Tester
Feb 10, 2024, 04:13
|
Crash confirmed. ----------------------------------------------------- Exception at EIP=00007ff790fba547 (pic16c5x_device::execute_run()+0x00a7): ACCESS VIOLATION While attempting to read memory at 0000000000000003 ----------------------------------------------------- RAX=0000000000000000 RBX=000001e1d59ae490 RCX=000001e1dab2db40 RDX=0000000000000000 RSI=00007ff79dc14d20 RDI=000001e1d59b1fe8 RBP=00007ff79dc14ba0 RSP=0000004838b099b0 R8=000001e1d59ae490 R9=0000000000000102 R10=0000000000000001 R11=00001ffe49b7681c R12=0000000000000028 R13=000000000000003b R14=00007ff79d8a5520 R15=0000004838b09db0 ----------------------------------------------------- Stack crawl: 0000004838b09a00: 00007ff790fba547 (pic16c5x_device::execute_run()+0x00a7) 0000004838b09a70: 00007ff78fe7ebcd (device_scheduler::timeslice()+0x05fd) 0000004838b09bf0: 00007ff78fe7b8ff (running_machine::run(bool)+0x01bf) 0000004838b0f120: 00007ff79365daab (mame_machine_manager::execute()+0x024b) 0000004838b0f510: 00007ff797855736 (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&)+0x03e6) 0000004838b0f7f0: 00007ff797855d5b (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> > > >&)+0x007b) 0000004838b0f850: 00007ff793658269 (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> > > >&)+0x0029) 0000004838b0fc10: 00007ff7994fd6d3 (luaopen_lfs+0xc284d3) 0000004838b0fce0: 00007ff78b5413b1 (__tmainCRTStartup+0x0231) 0000004838b0fd10: 00007ff78b5414e6 (mainCRTStartup+0x0016) 0000004838b0fd40: 00007fffff657344 (BaseThreadInitThunk+0x0014) 0000004838b0fdc0: 00007ff8006626b1 (RtlUserThreadStart+0x0021) |
---|---|
No.21959
hap Developer
Feb 12, 2024, 11:12
edited on: Feb 12, 2024, 11:14 |
Yup, I confirmed with hh_pic16.cpp "touchme" (easier to reproduce since it has a single CPU). The not-functional but not-crashing watchpoint issue could be a different cause. |
No.21960
AJR Developer
Feb 13, 2024, 01:19
edited on: Feb 13, 2024, 01:22 |
I remember MAME's pic16c5x and pic16c62x cores handling register file accesses in a particularly ugly and bad way. I began a WIP to clean them up many years ago, but it only actually covered the latter core, was never tested properly, and ended up being lost when my old computer died. There's a good argument that wpd 0, 1, w *shouldn't* do anything useful here (though it also shouldn't crash), because MAME's watchpoints are designed to trap physical memory addresses and INDF is "not a physical register" as Microchip's manuals consistently state. In my pic17 and rii CPU cores, I translate INDF0 and INDF1 references before attempting to access internal memory. |