Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Help / Re: Issues with GDB and C::B
« Last post by nore on February 02, 2025, 11:52:32 pm »
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
52
Using Code::Blocks / Re: Hiccups while typing (continuation)
« Last post by Elena on February 02, 2025, 11:10:50 pm »
Oh what's up, a bug ?
It seems that if I close C::B and I reopen it, the "Update parser when typing" setting gets enabled again ! Can you check ?
NB svn 13598
53
Using Code::Blocks / Re: Hiccups while typing (continuation)
« Last post by Elena on February 02, 2025, 09:01:36 pm »
Hi Pecan,  thanks for your support !
Disabling Update Parser When Typing seems to have fixed the hiccups !
Re: the other two settings suggested were already 300 ms and 3
54
Help / Re: Issues with GDB and C::B
« Last post by nore on February 02, 2025, 06:57:58 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.
55
Help / Re: Issues with GDB and C::B
« Last post by Pecan on February 02, 2025, 05:41:00 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.
56
Help / Re: Issues with GDB and C::B
« Last post by 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).
57
Help / Re: Issues with GDB and C::B
« Last post by nore on February 02, 2025, 05:03:31 pm »
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.
58
Help / Re: Issues with GDB and C::B
« Last post by nore on February 02, 2025, 04:44:19 pm »
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.
59
Help / Re: Issues with GDB and C::B
« Last post by nore on February 02, 2025, 04:15:12 pm »
I've got my settings configured as usual. I will try setting up another project to see if that fixes the issue.
60
Development / Re: asm("int3"); /*trap*/ query
« Last post by Wkerry on February 02, 2025, 08:20:34 am »
Thanks.
Pages: 1 2 3 4 5 [6] 7 8 9 10