When the Debugger Lies

(danielmangum.com)

24 points | by hasheddan 2 days ago

3 comments

  • zavec 26 minutes ago
    Very cool! I love reading about details like this.
  • Loren_SL 1 day ago
    Nice writeup. WinDbg has the same stale-cache trap on live Windows targets.
  • LoganDark 30 minutes ago
    Once upon a time I had to figure out an issue where I forgot a `return` statement at the end of a non-`void` function, so the C++ compiler happily omitted both RETs for some reason and let the program go straight into illegal instructions. That was fun to debug (not fun, I practically had to single-step through the entire program) because every time this happened the debugger was incredibly confused about what the fuck was going on and nothing made any sense.
    • VorpalWay 10 minutes ago
      It makes no sense to me that C and C++ didn't require a diagnostic for this, rather you hit UB.

      I know that at least modern GCC and Clang will warn and/or error for this (not sure which as I use -Werror), but still, this is pointless UB to have.

      And no, in this case I don't buy that a C90 compiler would have been unable to check this.

      • LoganDark 1 minute ago
        I think I was using C++14 at the time...
    • StilesCrisis 25 minutes ago
      Real
      • LoganDark 14 minutes ago
        Another issue that happened in the same project is that for some reason whenever I compiled it with a regular C++ compiler, field writes were disappearing into the abyss. I think I actually never figured that out because it was literally the same object at the same memory address, there were no other threads and yet when a subroutine returned after writing the field, the write disappeared?? The strangest thing is that Emscripten's C++-to-WASM cross-compiler worked perfectly fine with the exact same routines. I wonder if the compiler I used simply had fuckass issues, it was an oldish (by modern standards) Apple clang from like probably macOS 10.14 or so.
        • VorpalWay 6 minutes ago
          That or you hit some UB elsewhere that caused the compiler to assume things that you didn't follow.

          Trying UBSAN and ASAN might have been worth it. I don't think comparing debug and release builds would have helped: could be buggy optimisations or UB in your code regardless of what the outcome of that test was.

          • LoganDark 0 minutes ago
            In this case I was reading memory with a debugger and could see that it literally was the same object at the same memory address, but what I did not know was whether or not different parts of the code had different views of that field for some reason, or any number of other things that could have been causing the issue. Either way, it was super weird and frustrating.