Splitting debugger in two - specific debugger and common GUI

[oBFusCATed]

You're reporting this for the second time.

About the first one, can you state your exact version of the compiler and does it happen when running on windows 7 x64 bit?

[ollydbg]

Ok - here comes another issue... ;-)

- consider this code:

Code Select Expand

#include <iostream>

void funca()
{
   std::cout << "Hello!" << std::endl;
}

int main()
{
   funca();
   return 0;
}

- place a BP at the line "funca();"
- continue to step through it with Next (F7)
- after a few times, everything comes to a halt.

It works fine here xunxun's gcc 4.6.3 and gdb cvs build my self.

Code Select Expand


[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/mortenr2012-01-15/main.cpp:10"
[debug]Breakpoint 2 at 0x401697: file E:\code\cb\test_code\mortenr2012-01-15\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: E:\code\cb\test_code\mortenr2012-01-15\bin\Debug\mortenr2012-01-15.exe
[debug]gdb: windows_init_thread_list

Child process PID: 5332

[debug][New Thread 5332.0x1178]
[debug]Breakpoint 2, main () at E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10:101:beg:0x401697
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:11:115:beg:0x40169c
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:11

[debug]> next
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:12:130:beg:0x4016a1
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:12

[debug]> next
[debug]0x0040146d in __tmainCRTStartup ()
[debug]>>>>>>cb_gdb:

In __tmainCRTStartup () ()

[debug]> bt 30
[debug]#0  0x0040146d in __tmainCRTStartup ()
[debug]#1  0x7c817077 in RegisterWaitForInputIdle () from C:\WINDOWS\system32\kernel32.dll
[debug]#2  0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]Single stepping until exit from function __tmainCRTStartup,
[debug]which has no line number information.
[debug][Inferior 1 (process 5332) exited normally]
[debug]>>>>>>cb_gdb:

[Inferior 1 (process 5332) exited normally]

[debug]> quit

Debugger finished with status 0


[oBFusCATed]

ollydbg: That's why I've asked for the exact compiler version. This happens when the libc is build with debug symbols or at least happens on my centos/ubuntu.

[MortenMacFly]

You're reporting this for the second time.

Really? In fact, I can't remember. :-[ - Which one of the two reports do you mean?

Anyways...

About the first one, can you state your exact version of the compiler and does it happen when running on windows 7 x64 bit?

The compiler if GCC-TDM 4.6.1 (32 bit) and I am on Windows 7, 64 bit, but using a 32 bit compiled version of C::B.

[MortenMacFly]

Something completely different: Do you think I should switch to the GDB/MI plugin? I know you have less interest in fixing the current plugin - I just wonder if the GDB/MI one is already usable?!

BTW: SVN access to this plugin is not possible for me anymore ("Unknown host: smrt.is-a-geek.org"). Did you move it?

[oBFusCATed]

BTW: SVN access to this plugin is not possible for me anymore ("Unknown host: smrt.is-a-geek.org"). Did you move it?

I've lost the domain name and now I use different one cmpt.benbmp.org.
I doubt it is usable in production, thought. I've tried to build it on centos, but failed, so I don't use it actively at the moment.
And unfortunately I can't find enough time and concentration to work on it.

[cbexaminr]

... I had the weird idea to run C::B with only the debugger plugin and see how well C::B would work as debugger front end.

Morten - FWIW - I was _not_ running debugger plugin only (AsFarAsIKnow), but I think I did have such functionality working in the stuff presented back around and/or prior to this post:
http://forums.next.codeblocks.org/index.php/topic,10908.msg98311.html#msg98311

as I wanted/needed such functionality (and would _still_ like to have it within C::B).  My efforts at that time were not, however, accepted and applied. 

If you're interested in such functionality, you might look at the patches I submitted then against their related source control versions, and find whatever changes I made at that time.

So far, "nothing" without a project works, and loading a project without an active compiler plugin is rejected. (:-\) But what also does not work is attaching to a process. Then I see this message:
---------------------------
Error
---------------------------
This project is configured to use an invalid debugger.
The operation failed...
---------------------------
OK   
---------------------------
However, that is not correct, because there is no need for a project and the debugger is setup correctly. Maybe you see a chance to make this work... ;-)

[MortenMacFly]

... I had the weird idea to run C::B with only the debugger plugin and see how well C::B would work as debugger front end.

http://forums.next.codeblocks.org/index.php/topic,10908.msg98311.html#msg98311

Well this patch embeds not only one, but many changes. Is it possible, that for each change you create an own patch (that's how it always should be).

[MortenMacFly]

Well this patch embeds not only one, but many changes. Is it possible, that for each change you create an own patch (that's how it always should be).

Sorry, to say this, but my trials to apply the patch on trunk of the debugger's branch failed miserably. I guess w/o an update (you might have continued to use it in your local copy) it will be hard to see if that's what I had in mind...

[oBFusCATed]

The patch won't apply, because the GetCommandLine has been change. But if you read, my comments about the patch, you'll see that I'm pretty much against it.
This a plugin specific feature, which should not be required by all other plugins implementing a debugger.

[oBFusCATed]

About attaching:
As far as I can see attaching to a running program works even if there is no loaded project.
The only requirement is that you should not use the "Use active target's debugger" option in the "Debug->Active debuggers".
If you have a non working case for attaching, please report the details.

[Pecan]

SVN 7916 (shows in debugger as 7904)
svn build  rev 7904 (2012-03-19 21:48:48)   gcc 4.3.1 Windows/unicode - 32 bit

When aborting a Hello World compile and run, CB gets hung up. The compiler buttons are disabled and the system "says" the compiler is in use.

The only way out (I've found) is just to kill CB.

[oBFusCATed]

Please post the exact steps to reproduce this.
Does it happen every time or it is a random thing?

[Pecan]

Please post the exact steps to reproduce this.
Does it happen every time or it is a random thing?

1) Using the wizard, create a default console hello world project
2) build the project
3) run the project
4) use the little red [ x ] to kill the running console window.
5) CB is hung. Always happens

svn build  rev 7904 (2012-03-19 21:48:48)   gcc 4.3.1 Windows/unicode - 32 bit

[oBFusCATed]

Does this happen with the trunk's version?