EpicGamesExt
"a bad, rare bug" hit while stepping
i was stepping through a program of mine, trying to identify a bug in my code (a tiny program compiled with vs2022), when i got the following error message:
"a bad, rare bug that Jeff found has been detected to occur - attach with debugger now".
i cant really provide reproduction steps—i cant say what i was doing more precisely than "stepping through and looking at local variables"—but for the moment i still have this session open at this message. do you want a crash dump? or should i attach vs2022 to raddbg and collect some info?
Wow, I'm glad I left that in there, it has been a long time since I've seen that! Yes, can you please .zip up a crash dump, along with the raddbg.exe you are using, and the raddbg.pdb you are using? It'd also help to see the locals window of the debugger.
The more information the better, here, so if you are okay with sending the program itself (+ PDB & RADDBG files), source code, etc., the more easily I'll be able to try and reproduce and find out what happened.
if i just hit OK on this dialog without attaching anything to it, will it save a crash dump?
No, it won't, you'll want to attach with e.g. Visual Studio and save a dump file from there.
raddbg was built with default options from 5410fac.
screenshot (showing locals); raddbg exe and pdb; all the files from the target; and crash dump saved from vs2022 are all in:
https://www.dropbox.com/scl/fi/uby37wt0izhce314g4j8v/radbug29.zip?rlkey=ddbi0bwmpfrpjv6wwgvib2032&dl=0
i still have this open and paused in vs, in case theres something i missed from the above zip that you would want?
edit: other context, in case its useful: the target was compiled with vs2022 x64, with just "cl /Zi mog.c". i had restarted the target within raddbg a couple times (as i had stepped past the point i was trying to investigate). immediately before the error, i had just stepped into lex_match_some_class(), and the "current line" cursor jumped out into parse_expression() then back into lex_match_some_class(). this confused me, but idk if its relevant.
edit 2: additionally, i think i had a breakpoint in tokenize_number() at mog.c:224, with the condition *start=='3' (which in hindsight was foolish, since that variable starts uninitialized). again, dunno if relevant.
Great, thanks. That’s probably the most I can ask for at this point—I’ll need to do a pass over this part of the control layer and prevent this sort of thing a priori. Thanks for the help!
In theory this bug should be completely resolved as of d2d72bd7aba1de731ef1a11c0dc173f809368c8f, but short of doing a mathematical proof, this is one of those things that is just a matter of seeing how the theory matches up with actual battle testing. The stepping machine is complicated, so I could've made a mistake in my theory - so please re-open this issue if you hit this again.