Hello all,
I seem to be having trouble with Code::Blocks tonight after working to implement text-field highlighting in an OpenGL-based system. It seems that my debugger will only recognize breakpoints that are placed *before* starting the program--it will not recognize breakpoints placed during runtime as it usually does. I also noticed that the red 'x' icon used normally to stop the debugger and program execution does not work as usual. I only recall this happening once before. Does anyone have any suggestions as to what might be the cause of this strange error?
-nore
Quote from: nore on February 02, 2025, 05:27:34 AM
Hello all,
I seem to be having trouble with Code::Blocks tonight after working to implement text-field highlighting in an OpenGL-based system. It seems that my debugger will only recognize breakpoints that are placed *before* starting the program--it will not recognize breakpoints placed during runtime as it usually does. I also noticed that the red 'x' icon used normally to stop the debugger and program execution does not work as usual. I only recall this happening once before. Does anyone have any suggestions as to what might be the cause of this strange error?
-nore
This usually happens to me when I've set the default debugger to the wrong debugger config.
Check that the MainMenu>Debug>Active debugger is set as you expect.
Check that MainMenu>Settings>Debugger of the Active debugger (above) is as you expect.
I've got my settings configured as usual. I will try setting up another project to see if that fixes the issue.
Even rebuilding the project and configuring the compiler, linker, and debug settings as project settings rather than global settings seems to result in the same issue. I remember this error occurring maybe six weeks ago and it was solved by building the project using global compiler settings rather than project-local compiler settings. Run-time breakpoints are still ignored as if the debugger is not running.
Looking at the Debugger Log in Code::Blocks I see that the executable attempts to interrupt the process as usual--nothing "funny" shows up in the log; and placing a breakpoint before launching, then removing the breakpoint in real-time seems to stop the Debugger from crashing in with its useful tools at function call--but trying to *place* a breakpoint during real-time/run-time does not seem to catch the Debugger's attention, as is evident in this screenshot where I try to evoke the debugger using a breakpoint on the frequently-called "draw()" function in my program.
The build policy has debugging symbols enabled... I even tried using the DWARF optimizations for the compiler I am using (i686-ucrt-posix-dwarf).
Quote from: nore on February 02, 2025, 05:08:16 PM
The build policy has debugging symbols enabled... I even tried using the DWARF optimizations for the compiler I am using (i686-ucrt-posix-dwarf).
Try using the -O0 (oh,zero) flag to see if optimization is a factor.
Quote from: Pecan on February 02, 2025, 05:41:00 PM
Quote from: nore on February 02, 2025, 05:08:16 PM
The build policy has debugging symbols enabled... I even tried using the DWARF optimizations for the compiler I am using (i686-ucrt-posix-dwarf).
Try using the -O0 (oh,zero) flag to see if optimization is a factor.
No luck--the build window looks excessively plain as the program is launched using the debugger--the call stack does not report anything yet; but GDB does not break on breakpoints placed during run-time. I read somewhere about someone having an issue with parent/child process-forking (some sort of locality-type issue where the debugger would handle one scope but not the other) and so I thought that perhaps my initial call to win32's AllocConsole() (for manual debugging and such) might be an issue but this is not the case.
EDIT: Trying to close the debugger using the red 'x' button also results in the same message as placing a run-time breakpoint: "Trying to interrupt process..." in the log window without any response.
I moved from the nightly build to a the 32-bit release (20.03) and everything is working now--only now the resolution of the application seems to be much lower... At least from the perspective of my laptop's DPI--investigation continues.
-nore