Splitting debugger in two - specific debugger and common GUI

[tomjnx]

No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.

Where is the gdb/mi plugin, then?

[oBFusCATed]

tomjnx: here: svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi

Morten: autotools is the only sensible way to distribute open source software.

About the warning:
Looking at your logs, I can conclude that filtering the warnings is the only way forward. Even if "set debugevents off" was working. If would have been executed at the first breakpoint hit, which may be too late and it could cause the log to be filled with garbage.

Fill free to test the filtering and then post a patch, so I can test it, too.

Edit: I've talked to the gdb people and they suggested filing a bug report in the gdb's bugzilla. Can you do it?

[MortenMacFly]

Morten: autotools is the only sensible way to distribute open source software.

If you tell me how to compile using C::B without X11 on Linux... Distribution buildservers usually have no X11 8-)

Guys, didn't you see the smiley? I know this is not an option. However, it's hard to believe that automake is still an elegant way in the 21st century. But I also don't know a better solution as I am not into Unix/Linux that much.

Edit: I've talked to the gdb people and they suggested filing a bug report in the gdb's bugzilla. Can you do it?

Done, see/subscribe here:
http://sourceware.org/bugzilla/show_bug.cgi?id=13635

[MortenMacFly]

Fill free to test the filtering and then post a patch, so I can test it, too.

I looked into it (GDB_driver::ParseOutput) a little and I see this:
   if (!want_debug_events &&
        (output.StartsWith(_T("gdb: ")) ||
        output.StartsWith(_T("Warning: ")) ||
        output.StartsWith(_T("ContinueDebugEvent "))))
    {
        return;
    }

Notice the capital "W" in "Warning: ". Maybe it is as easy as adding another "|| output.StartsWith(_T("warning: "))"... ;-)

[oBFusCATed]

Yes, do it test and report if it is working:)

[MortenMacFly]

Yes, do it test and report if it is working:)

I'll try, but what's needed in addition is to switch off the debug events after the PID detection. as you described here:

"set debugevents on" is used only to detect the pid of the debuggee and when the pid is correctly detected "set debugevents off" should be executed.
I guess the pid reporting has changed, see the beginning of the GDB_driver::ParseOutput functions.

How/when/where would I do that best?

[oBFusCATed]

Check why the current test doesn't work. Probably the output of gdb has changed.

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

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]

Check why the current test doesn't work. Probably the output of gdb has changed.

So, I added the lower letter "warning" and I am not really a step further. The log now looks like this:
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[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 debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Devel/CodeBlocks/src/
[debug]>>>>>>cb_gdb:
[debug]> set args --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose --profile=foo
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 8412

[debug][New Thread 8412.0xd0c]
[debug]2.dll" at 0x72560000.
[debug][New Thread 8412.0x21bc]
[debug][New Thread 8412.0x2330]
[debug][New Thread 8412.0x2018]
[debug][New Thread 8412.0x224c]
[debug][New Thread 8412.0x23a0]
[debug][New Thread 8412.0xdd4]
[debug][New Thread 8412.0x758]
[debug][New Thread 8412.0x1c34]
[debug][New Thread 8412.0x217c]
[debug][New Thread 8412.0x2248]
[debug] in Enable(): attempt to enable an item which doesn't exist
[debug]wa
[debug]rning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]n Enable(): attempt to enable an item which doesn't exist
[debug]warn
[debug]ing: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]Enable(): attempt to enable an item which doesn't exist
[debug]warnin
[debug]g: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]able(): attempt to enable an item which doesn't exist
[debug]warning:
[debug] ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]le(): attempt to enable an item which doesn't exist
[debug]./../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug](): attempt to enable an item which doesn't exist
[debug]../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]: attempt to enable an item which doesn't exist
[debug]/src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]attempt to enable an item which doesn't exist
[debug]rc/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug][New Thread 8412.0x82c]
[debug]tempt to enable an item which doesn't exist
[debug]/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]mpt to enable an item which doesn't exist
[debug]ommon/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]t to enable an item which doesn't exist
[debug]mon/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]to enable an item which doesn't exist
[debug]n/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug] enable an item which doesn't exist
[debug]menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]nable an item which doesn't exist
[debug]nucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]ble an item which doesn't exist
[debug]cmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]e an item which doesn't exist
[debug]n.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]an item which doesn't exist
[debug]cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug] item which doesn't exist
[debug]p(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

...so you see that due to the fact that some messages are strangely interrupted (WHY btw - I think this is a bug!!!) it does not really help. I get less messages, but still too much and still the debugger freezes after some time. Maybe a low-level filtering as suggested will help...

[oBFusCATed]

Seems that a non buffered API is used to print the warnings... You'll have to hack wxwidgets to stop them.

[ollydbg]

...so you see that due to the fact that some messages are strangely interrupted (WHY btw - I think this is a bug!!!) it does not really help. I get less messages, but still too much and still the debugger freezes after some time. Maybe a low-level filtering as suggested will help...

Does this code

Code

    static wxString buffer;
    buffer << output << _T('\n');

    m_pDBG->DebugLog(output);

In the function void GDB_driver::ParseOutput(const wxString& output) cause this issue?

[MortenMacFly]

No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.

BTW: I am not sure how far you are with the plugin, bus I have found a few interesting projects that provide a parser for the GDB/MI interface, like these:

• http://sourceforge.net/projects/shabe/ --> The GDB part is very small and nice, but only for GDB 7.1/7.2
• http://sourceforge.net/projects/libmigdb/ --> I guess you know this, but it seems dead
• http://sourceforge.net/projects/gdbshellwin/ --> A complete shell
• http://sourceforge.net/projects/ccdebug/ --> a complete front-end

.,..maybe it is of help. But it seems to me that the MI is under development, and you need to take care about what version of GDB you are targeting...

[oBFusCATed]

I've looked at libmigdb, but I decided to write my parser.
I have a working parser and stepping/breakpoints/watches should work.

The good thing about gdb/mi is that the communication protocol is stable. So you always parse the messages, but you might get new fields.
And this is not as problematic as the gdb/cli output, which changes more often.
Also compiling latest gdb is not that of a problem, as it turned out.

[MortenMacFly]

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

- consider this code:

Code

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

You cannot stop/pause/continue/whats-over the debugger or C::B. You have to kill the debugger (not the debugee - that's impossible!) using the task manager.

Here is the debuggers debug log:
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 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 "mingw32".
[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.3

[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 debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\src\devel29\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/morten/Desktop/MyCon/
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/morten/Desktop/MyCon/main.cpp:10"
[debug]Breakpoint 2 at 0x401347: file C:\Users\morten\Desktop\MyCon\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 7980

[debug][New Thread 7980.0x18c]
[debug]Breakpoint 2, main () at C:\Users\morten\Desktop\MyCon\main.cpp:10
[debug]c:\users\morten\desktop\mycon\main.cpp:10:101:beg:0x401347
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:10

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:11:115:beg:0x40134c
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:11

[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:12:130:beg:0x401351
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:12

[debug]> next
[debug]250   ../mingw/crt1.c: No such file or directory.
[debug]__mingw_CRTStartup () at ../mingw/crt1.c:250
[debug]   in ../mingw/crt1.c
[debug]>>>>>>cb_gdb:

[MortenMacFly]

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

...and another one:
From time to time I see this in the debuggers log when stepping through code using F7:
[debug]> next
[debug]Cannot find bounds of current function
[debug]>>>>>>cb_gdb:
After that, the debugger plugin is frozen and nothing happens until I kill the debugger (not the debugee - that's impossible!).
I didn't find a way to reproduce, not a minimal sample, but according to this:
http://bytes.com/topic/c/answers/786078-error-cannot-find-function-bounds
...the reason is a "buffer overrun problem somewhere in an inner function".
Nasty - but this should be handled correctly.

BTW: The sample to reproduce shown there does not reproduce this problem. :-(