search

x13pixels / remedybg-issues

Public repository for tracking issues (bugs and features) for the RemedyBG debugger
85 stars 0 forks source link

Breakpoint that's set before program is started reliably gets skipped #312

Open scallyw4g opened 2 months ago

scallyw4g commented 2 months ago

Similar to #309, I've been experiencing this bug for multiple years. It's also intermittent, and I also seem to have a stable repro for it!

The bug is just as the title of the issue says; if I set a breakpoint before I start my program, it never gets hit. Interestingly, if I set the breakpoint after the program starts, it get's hit. As far as I can tell it always happens in code loaded from a DLL, but it does not always happen.

It does not appear to be a timing issue, at least to the extent that I can test. Putting a 1-second sleep into the code before the breakpoint does not cause the breakpoint to trigger. This is how I tested that adding the breakpoint after the program starts successfully triggers it.

Steps to reproduce:

1) Download bonsai (my game-engine side-project) 2) Checkout branch jesse/debug/remedy_repro_2 (commit 2cf28b6f648bc917e9d65381da6556a69294b1d4) 3) (optional) Run ./remedy_repro.make.sh (this runs a debug build for the targets to repro the issue) 4) Open remedy_repro.rdbg 5) Hit F5

The program should crash on an assertion in OctreeNodeNeedsToSplit. This is unrelated to the bug, it's just the thing I happened to be working on when I discovered this repro.

The bug is that there should be a breakpoint set near the start of MaintainWorldOctree (the function that calls into OctreeNodeNeedsToSplit) which is not triggered.

Also added the binaries I used on my machine to repro so you can skip the compile.

Happy to provide any additional information I can.

scallyw4g commented 2 months ago

UPDATE:

I noticed a second bug that I can also trigger here.

If I start the program and get it to stop on a breakpoint (either by timing it or by by compiling in an int 3), then try to set a breakpoint on a function name with CTRL-b, that breakpoint also fails to trigger.

@x13pixels should I open a new issue for this one, or do you just want to lump it in with this one?

x13pixels commented 2 months ago

Appreciate these fantastic reports. I'll take a look at the second bug at the same time. No need for a separate issue. Thanks again and sorry for the trouble!

scallyw4g commented 2 months ago

Appreciate these fantastic reports. I'll take a look at the second bug at the same time. No need for a separate issue. Thanks again and sorry for the trouble!

👍 👍

I noticed another clue about the behavior of these bug(s) last night. I ended up hitting this bug again and noticed that if I:

1) Set a breakpoint on first line of main() (in game_loader.cpp) 2) Start the program 3) Set a breakpoint in a function that's eventually also loaded from a DLL, for example OctreeNodeNeedsToSplit (most of the code loaded in the game DLL is also present in the game_loader.exe) 4) Continue

The breakpoint set in (3) is (sometimes) skipped

If I change the first step to:

1) Set a breakpoint after the game library is loaded on line 161 game_loader.cpp

The breakpoint set in (3) is hit.

So I guess that points to the code that registers breakpoints in newly loaded DLLs having a timing issue ..? Anywhoo, thanks again :)

scallyw4g commented 2 months ago

FWIW you can @ me in the HMN discord if you need anything from me. I might respond more quickly there than on github