Hello,

A while ago I posted about having issues with setting breakpoints in remedybg and I stumbled upon the solution while watching a handmade hero stream yesterday. I realized that Casey Muratori almost always sets breakpoints while the game is running, whereas I set the breakpoints before I start the debugging.

I do not know if what I describe below is a bug or intended or if I just plain don't know how to use debuggers. Please tell me which it is.

So here are the steps to reproduce this:

Failing breakpoint

1. Compile handmade hero such that there is a win32 executable and a dll that it loads which has the game code.
2. Open remedy and set a breakpoint in a file (like handmade.cpp) which ends up in the dll.
3. Start debugging by pressing F5.
4. The breakpoint will not be respected by remedy

Working breakpoint

1. Compile same as before
2. Start debugging by pressing F5
3. Open handmade.cpp and set a breakpoint while the program is running.
4. The breakpoint is now respected

Visual Studio

In visual studio both sequence of steps described above lead to the execution being stopped at the breakpoint.

Video Recording

I have also made a video recording of all three of the above sequence of steps if you would like to see me demonstrate the thing I'm talking about:

I just tried it and it's working on my machine. If you use subst to create a "virtual drive" maybe try to open the file using both path to see if one works ?

With what version is this? Make sure to try the latest one.

I'm not seeing this either. The video is definitely showing something strange is going on.

One thing to try would be add the breakpoint before the program starts, hit F10 so program stops at the entry point, then take a look at the breakpoint added in handmade.cpp. You should see something like (breakpoint with question mark):

indicating that the breakpoint hasn't yet been resolved (since the game DLL isn't loaded yet). It didn't seem like that was happening in the video. Also, could check the breakpoints pane in RemedyBG to make sure the breakpoint location is as expected (though that probably won't tell us much).

Looks like based on the HH code in the vid you are on around Day 66 or so? Also, what version of RemedyBG are you running?

I am on day75 in the video. And I am running v0.3.8.1 of remedybg.

I will try the steps you mentioned to see if get the question mark on the breakpoint. I will also send you a zip of the executable and the source files Im compiling if you wish, although I have hardcoded the paths to my own computer all over the place so I think you won't be able to compile it without making changes.

@Simon I didn't setup the virtual drive when working through the tutorials :P. I was just being lazy and thought I could just hardcode all the paths... which I did. I will setup the virtual drive by going back to that tutorial if the question mark thing that George Menhorn asked me to check doesn't solve it.

Also, I would like to point out that this is not causing me any huge problems. I can still use the debugger just fine, especially after realizing that it works if I put in the breakpoints later.

Using subst drive usually gives more problems that solve it. That's because if you open source file from real location, the debugger won't know if it is the same file as on subst'ed drive - and other way around too. And breakpoints won't work.

Hello,

I did as you suggested to see if I get the questionmark. But I don't see it. I have made a video again to show how I followed your steps:

Thanks.

You mentioned "I have hardcoded the paths to my own computer all over the place". Do you remember why this was necessary? The HH code should be buildable from any location on disk, right?

If you can email me a patch that I can apply to HH Day 75 I can see if I can reproduce it.

Wondering if handmade.cpp is included somehow in the EXE by mistake? In this case, the breakpoint would get added but wouldn't be code that is actually executed. At the moment, RemedyBG only adds the first resolved breakpoint it finds. If the DLL isn't yet loaded, and code from handmade.cpp is indeed part of the EXE, then it would resolve to that first. Not sure if it will tell us anything but does Visual Studio show two separate breakpoints for that location or just one?

Yes the include is exactly the problem. I do not use the files from the handmade hero preorders directly and instead have been writing them on my own. And I must have missed the part where Casey Muratori removed this include. And also didn't put it together that when its being loaded as a dll, it shouldn't be included:

I did not know that debuggers worked like this. Once I removed the handmade.cpp include from win32_handmade.cpp, the breakpoints in handmade.cpp work as expected.

Thankyou for helping me.