#440 memory access broken when trace/watch point(s) are active

v2.4
closed-fixed
nobody
None
Monitor
2016-02-27
2013-06-15
Saxxon
No

I was using the official 2.4-x64 build (msvc), and also a 2.4.1-x86 build (gcc), both were exhibiting the same issue. I was not able to reproduce it in 2.4.4-x86, but was encouraged to submit this ticket anyway. These are all Windows builds. I am running this on Windows 8 x64.

Using default settings in Vice, all I have to do is this (in this order):
- When BASIC loads up, enter the Monitor.
- Use the command "BREAK STORE". Any address will suffice.
- Close the Monitor.
- Attempt any floating-point arithmetic.

This happens on x64, x64sc, x128, xcbm2, xcbm5x0, xpet, xplus4, and xvic. It does not happen on x64dtv.

A hard reset does not fix it. The application itself needs to be restarted. If you save the state and then reload the state in a new instance of the program, the bug is also gone. Because the bug does not persist through save state, I did not include one.

Discussion

  • Saxxon

    Saxxon - 2013-06-15

    I used the command "BREAK STORE DFFF" the most to test this, but I have confirmed that other addresses work. Just in case you need the exact actions I've taken.

     
  • gpz

    gpz - 2013-06-16
    • Port: --> Windows
    • Group: v2.4 - Windows --> v2.4
     
  • gpz

    gpz - 2013-06-16
    • Category: --> x64
     
  • derrick inksley

    derrick inksley - 2013-06-16

    I have reproduced the bug on WinVICE 2.4.4 x86 compiled with mingw/gcc - so it definitely still exists.

     
    Last edit: derrick inksley 2013-06-16
  • gpz

    gpz - 2013-06-16

    reproduced on trunk (linux/64bit) too - WEIRD

     
  • gpz

    gpz - 2013-06-16
    • status: open --> open-accepted
    • Port: Windows -->
     
  • gpz

    gpz - 2013-06-17
    • Category: x64 --> Monitor
     
  • gpz

    gpz - 2013-06-17

    this one is seriously weird ... since it shows in x64sc but not x64dtv the problem is likely not related in the cpu core... shrug

    i traced it down to c64mem.c:mem_toggle_watchpoints ... for some strange reason the "store_watch" function does not work properly as a substitution, if you replace "_mem_write_tab_ptr = mem_write_tab_watch;" by "_mem_write_tab_ptr = mem_write_tab[vbank][mem_config];" where it is changed when watchpoints are active, then the bug will disappear (however, that also effectively disables the watchpoints). i am really puzzled at the moment, as this should really work and x64dtv does basically do the same too.... eh

     
  • gpz

    gpz - 2013-06-18
    • summary: x64: floating point arithmetic bug --> memory access broken when trace/watch point(s) are active
     
  • gpz

    gpz - 2013-06-18

    so indeed somehow the wrong value is read, i made logs, capturing the following basic line: POKE56333,127:?1.5+2.0 ... diff shows where its going wrong (second log is after placing watchpoint).

    i dont know either the cpu core nor this memory mapping code very well, someone step up... soci? =)

     
  • gpz

    gpz - 2013-06-19
    • status: open-accepted --> pending-fixed
     
  • gpz

    gpz - 2013-06-19

    ok so, fixed in r27445 :) what was wrong is that when watchpoints are enabled, indexed zeropage adressing was broken (indexing would leave zeropage and not wrap around).

    thanks for reporting! this may also fix some of the other strange problems related to breakpoints in zeropage infact :)

     
  • Marco van den Heuvel

    • status: pending-fixed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks