User forums > Help

Issues with GDB and C::B

<< < (2/2)

nore:
The build policy has debugging symbols enabled... I even tried using the DWARF optimizations for the compiler I am using (i686-ucrt-posix-dwarf).

Pecan:

--- 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).

--- End quote ---

Try using the -O0 (oh,zero) flag to see if optimization is a factor.

nore:

--- 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).

--- End quote ---

Try using the -O0 (oh,zero) flag to see if optimization is a factor.

--- End quote ---

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.

nore:
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

Navigation

[0] Message Index

[*] Previous page