I've been using CB for a long time, many different versions, currently using the SVN version (prepackaged by jens).
The pause button ("Break Debugger") has never worked for me either on Windows or Linux. Using G++, compiling debug builds with -ggdb, etc etc. The button doesn't break execution, it just... does nothing. Is this a known problem or does CB just hate me?
Quote from: zeroth on December 09, 2013, 11:58:06 PM
Is this a known problem or does CB just hate me?
If you're running 12.11 or newer then it is not a known problem. I guess it is the hate thing :)
Can you post a full log from the debugger, so we can guess what might be happening. You have to enable the logging in the settings.
Happily!
I just enabled "Full (debug) log)" under Settings->Debugger and reproduced my problem, but am unable to locate where CB has put the log. I'm running SVN 9455
Quote from: zeroth on December 10, 2013, 05:28:31 AM
Happily!
I just enabled "Full (debug) log)" under Settings->Debugger and reproduced my problem, but am unable to locate where CB has put the log. I'm running SVN 9455
In the Debugger "tab" mostly in the bottom of your C::B window.
Thanks, here's the log and my summary of what I did:
Started the program (a debug build).
I clicked "pause" three times, nothing happened (ie, the program gept going on its merry way)
I then closed the program. The program didn't stop as it usualyl does, it seems clicking pause causes it to either break or hang when I close it.
I clicked "Continue: again assuming it would end the program. It didn't.
I then just clicked "Stop debugging."
Building to ensure sources are up-to-date
Selecting target:
lin debug
Adding source dir: /home/caibbor/proj/btech3/codeblocks/
Adding source dir: /home/caibbor/proj/btech3/
Adding file: /home/caibbor/proj/btech3/run/btech3_debug
Changing directory to: /home/caibbor/proj/btech3/run/
Set variable: LD_LIBRARY_PATH=.:
[debug]Command-line: /usr/bin/gdb -nx -fullname -quiet -args /home/caibbor/proj/btech3/run/btech3_debug
[debug]Working dir : /home/caibbor/proj/btech3/run
Starting debugger: /usr/bin/gdb -nx -fullname -quiet -args /home/caibbor/proj/btech3/run/btech3_debug
done
[debug]Reading symbols from /home/caibbor/proj/btech3/run/btech3_debug...
[debug]> set prompt >>>>>>cb_gdb:
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.6.1-ubuntu
[debug]Copyright (C) 2013 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-linux-gnu".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.6.1-ubuntu
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /home/caibbor/proj/btech3/codeblocks/
[debug]Source directories searched: /home/caibbor/proj/btech3/codeblocks:$cdir:$cwd
[debug]>>>>>>cb_gdb:
[debug]> directory /home/caibbor/proj/btech3/
[debug]Source directories searched: /home/caibbor/proj/btech3:/home/caibbor/proj/btech3/codeblocks:$cdir:$cwd
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: /home/caibbor/proj/btech3/run/btech3_debug
[debug][Thread debugging using libthread_db enabled]
[debug]Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[debug]AnimName = Wave
[debug]---- SDL Video Init ----
[debug]Startup Args:
[debug]---- Random Number Init ----
[debug]---- OpenGL Init ----
[debug]Vendor: NVIDIA Corporation
[debug]Version: 3.3.0 NVIDIA 331.20
[debug]Renderer: GeForce 9800M GS/PCIe/SSE2
[debug]Video Ram Total: 524288
[debug]Video Ram Avail: 433992
[debug]RGBA Color Bits: 8, 8, 8, 0
[debug]Depth Bits: 24
[debug]Stencil Bits: 0
[debug]Max Texture Size: 8192x8192
[debug]Max Lights: 8
[debug]Max Clip Planes: 8
[debug]Max Attribute Stacks: 16
[debug]Max Texture Stacks: 10
[debug]Max Vertex Uniforms: 4096
[debug]Max Fragment Uniforms: 2048
[debug]Extensions: 238
[debug]---- Renderer Init ----
[debug]---- SDL Audio Init ----
[debug]---- Packages ----
[debug]Loading shader: shd/gradient.vs
[debug]Loading Package: ./data/foo.zip
[debug]Loading Package: ./data/1
[debug]Loading shader: ./data/1/shd/textured2d.vs
[debug]Loading shader: ./data/1/shd/animMesh.fs
[debug]Loading shader: ./data/1/shd/colorizetex.vs
[debug]Loading shader: ./data/1/shd/multicolortex2d.vs
[debug]Loading shader: ./data/1/shd/particle.fs
[debug]Loading shader: ./data/1/shd/colorizetex2d.vs
[debug]Loading shader: ./data/1/shd/colorizetex.fs
[debug]Loading shader: ./data/1/shd/animMesh.vs
[debug]Loading shader: ./data/1/shd/gradient.vs
[debug]Loading shader: ./data/1/shd/animSkel.vs
[debug]Loading shader: ./data/1/shd/textured.vs
[debug]Loading shader: ./data/1/shd/minimal.fs
[debug]Loading shader: ./data/1/shd/multitex.vs
[debug]Loading shader: ./data/1/shd/multitex.fs
[debug]Loading shader: ./data/1/shd/multicolortex.vs
[debug]Loading shader: ./data/1/shd/textured.fs
[debug]Loading shader: ./data/1/shd/minimal.vs
[debug]Loading shader: ./data/1/shd/gradient.fs
[debug]Loading shader: ./data/1/shd/particle.vs
[debug]Error: Diffuse texture does not exist: all_white_test_ for material: ./data/1/mdl/modules/floor.mtl.
[debug]Loading Package: ./data/folder.txt
[debug]Loading Package: ./data/foo.zip
[debug]Loading Package: ./data/1
[debug]Loading Package: ./data/folder.txt
[debug]Loading Package: ./data/foo.zip
[debug]Loading Package: ./data/1
[debug]Loading Package: ./data/folder.txt
[debug]Code::Blocks is trying to interrupt process with pid: 17436; child pid: 0 gdb pid: 17436
[debug]Code::Blocks is trying to interrupt process with pid: 17436; child pid: 0 gdb pid: 17436
[debug]Code::Blocks is trying to interrupt process with pid: 17436; child pid: 0 gdb pid: 17436
[debug]Quit
Child process PID: 17444
[debug][New Thread 0xb032ab40 (LWP 17444)]
[debug][Thread 0xb032ab40 (LWP 17444) exited]
[debug][New Thread 0xb032ab40 (LWP 17445)]
[debug]>>>>>>cb_gdb:
[debug]> info frame
[debug]No stack.
[debug]>>>>>>cb_gdb:
No stack.
Continuing...
[debug]> cont
[debug]Cannot execute this command while the selected thread is running.
[debug]Continuing.
[debug]>>>>>>cb_gdb:
[debug]> info frame
[debug]No stack.
[debug]>>>>>>cb_gdb:
No stack.
[debug]> quit
Debugger finished with status 0
edit: all the shader stuff and opengl info output is from my program not the debugger.... if that's not obvious.
[debug]Code::Blocks is trying to interrupt process with pid: 17436; child pid: 0 gdb pid: 17436
[debug]Code::Blocks is trying to interrupt process with pid: 17436; child pid: 0 gdb pid: 17436
[debug]Code::Blocks is trying to interrupt process with pid: 17436; child pid: 0 gdb pid: 17436
[debug]Quit
Child process PID: 17444
[debug][New Thread 0xb032ab40 (LWP 17444)]
[debug][Thread 0xb032ab40 (LWP 17444) exited]
[debug][New Thread 0xb032ab40 (LWP 17445)]
Look, the true pid value (17444 or 17445) returned AFTER you hit the stop button, this is mostly because your program log out too many messages, which make the parser for C::B debugger parser wrong.
I'm not following... You're saying that my printf()s are causing CB to parse GDB's output incorrectly? I'm no sure what "new thread" is for, my program is not multithreaded, unless a dependency is (maybe SDL)
Quote from: zeroth on December 10, 2013, 06:55:18 AM
I'm not following... You're saying that my printf()s are causing CB to parse GDB's output incorrectly? I'm no sure what "new thread" is for, my program is not multithreaded, unless a dependency is (maybe SDL)
I'm not a Linux user, so what I said is my guess(which may be wrong)
Basically, C::B need to parse the response message from GDB to get the correct inferior(debugee) pid.
For example, when you start debugging and running the inferior(debugee), GDB will report some message like:
[New Thread 0xb032ab40 (LWP 17444)]
Then, in C::B, if it get parsed, it know the inferior pid, in the above case, it is 17444.
Now, when you want to pause the inferior, there is a function call like "Break(17444)", this will halt your inferior(debugee).
Apparently, in the log messages showed, C::B has failed to catch the inferior pid, so it can't halt the inferior.
You can try to create a simple hello world application, and test again to see whether it works. I guess the log messages from your app have affect on the C::B debugger parser.
Well, I can't create a new project because.. uh, well... that's another problem - I can't make a new project: http://img689.imageshack.us/img689/8692/j72h.png
So I removed all the printf()s and the problem persists. I can't imagine the CB team would code the interactions between CB and GDB in such a rinky-dink manner as to just interpret GDB screen output, so it seems they didn't anyway.
Any more ideas?
Quote from: ollydbg on December 10, 2013, 07:06:34 AM
I guess the log messages from your app have affect on the C::B debugger parser.
I don't see the pid in the log, sometimes this happen, because no thread is started and gdb fails to print the pid.
I have to do something about this, but I'll see I find some time.
Quote from: zeroth on December 12, 2013, 02:01:24 AM
I can't imagine the CB team would code the interactions between CB and GDB in such a rinky-dink manner as to just interpret GDB screen output, so it seems they didn't anyway.
Unfortunately this is how it works...
Quote from: zeroth on December 12, 2013, 02:01:24 AM
Well, I can't create a new project because.. uh, well... that's another problem - I can't make a new project: http://img689.imageshack.us/img689/8692/j72h.png
Do you have the Scripted Wizard plugin installed?
Quote from: Alpha on December 12, 2013, 07:28:47 PM
Quote from: zeroth on December 12, 2013, 02:01:24 AM
Well, I can't create a new project because.. uh, well... that's another problem - I can't make a new project: http://img689.imageshack.us/img689/8692/j72h.png
Do you have the Scripted Wizard plugin installed?
Looks like it wasn't enabled, I can now create new projects.
Quote from: oBFusCATed on December 12, 2013, 02:08:17 AM
Quote from: ollydbg on December 10, 2013, 07:06:34 AM
I guess the log messages from your app have affect on the C::B debugger parser.
I don't see the pid in the log, sometimes this happen, because no thread is started and gdb fails to print the pid.
I have to do something about this, but I'll see I find some time.
If it helps your investigation, it may also be along the same lines as another problem I'm having: if I set or remove breakpoints during program execution (when the debuggee is not stopped at a breakpoint), codeblocks will usually freak out and not allow me to stop the debugger once I exit the debugee, even if the process no longer exists. I will provide a debugger log if you would like.
Quote from: ollydbg on December 10, 2013, 07:06:34 AM
Quote from: zeroth on December 12, 2013, 02:01:24 AM
I can't imagine the CB team would code the interactions between CB and GDB in such a rinky-dink manner as to just interpret GDB screen output, so it seems they didn't anyway.
Unfortunately this is how it works...
Well I don't know anything about how GDB communicates with frontends, so if that's how it's gotta be done, then that's how it's gotta be done. It doesn't seem to be my problem here anyhow since I've already disabled all of my stdout/err output.
It is not the correct way. Hopefully in the future we'll use the more robust GDB/mi protocol, but for now this is how it works.
Removing all your stdout code won't help.
Aye. That's one of the features I like about CodeLite, it seemed to have better debugger integration. But don't worry, I still prefer CodeBlocks ;)
PS, I updated my previous reply.
I have the same thing. I use CB to develope the arm system. When debug use gnu arm gdb debugger to debug my code, if I don't set any breakpoint, I will can't break or stop the debugger, even the "Break Debugger" or "Stop Debugger" button.
I use the CB 13.12 RC2 now, I can't create ARM project use the wizard. Do you have the same thing?.....
Please post full build log from the debugger, so I can take a look at it.
Quote from: liss719 on December 15, 2013, 01:08:18 PM
I can't create ARM project use the wizard. Do you have the same thing?.....
Do you have the scripted wizard plugin installed and enabled?
I'm going to be regularly checking back at this thread every few days or so. This is a feature I'm really looking forward to using once it's fixed (pause debugger). If you prefer, I can submit a bug report.
edit: it seems I already posted about this a year ago and forgot about it; http://developer.berlios.de/bugs/?func=detailbug&group_id=5358&bug_id=18759
have you read the reply of oBFusCATed? also the comment on your bug report:
QuoteCan you paste the full debugger log? (see in the settings how to enable it).
Also when this happens you can kill the gdb process, which is child of C::B, not the whole C::B.
Also do older revisions work correctly in this situation? In other words is this a regression or it has been broken forever?
please reply to this posts, because we need more information...
I thought oBFusCATed's last reply in this thread was to liss719 since I had already posted a debugger log. I'll post up a fresh debugger log when I get a chance.
I didn't realize the report had been replied to until I re-discovered it. I'll copy the information I've given here over to the bug report. It'll take me a bit before I get a chance though.