Author Topic: Splitting debugger in two - specific debugger and common GUI  (Read 300284 times)

Offline tomjnx

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #645 on: January 30, 2012, 10:25:57 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12239
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #646 on: January 30, 2012, 10:33:19 pm »
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?
« Last Edit: January 30, 2012, 10:43:43 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #647 on: January 31, 2012, 12:21:57 am »
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
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #648 on: January 31, 2012, 12:32:47 am »
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: "))"... ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12239
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #649 on: January 31, 2012, 12:35:04 am »
Yes, do it test and report if it is working:)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #650 on: January 31, 2012, 12:39:01 am »
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?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12239
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #651 on: January 31, 2012, 12:45:45 am »
Check why the current test doesn't work. Probably the output of gdb has changed.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #652 on: January 31, 2012, 09:07:45 pm »
... 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... ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #653 on: January 31, 2012, 09:16:44 pm »
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...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12239
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #654 on: January 31, 2012, 09:38:36 pm »
Seems that a non buffered API is used to print the warnings... You'll have to hack wxwidgets to stop them.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5251
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #655 on: February 01, 2012, 06:56:34 am »
...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: [Select]
    static wxString buffer;
    buffer << output << _T('\n');

    m_pDBG->DebugLog(output);
In the function void GDB_driver::ParseOutput(const wxString& output) cause this issue?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #656 on: February 01, 2012, 09:19:00 am »
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:
.,..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...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12239
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #657 on: February 01, 2012, 09:27:31 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #658 on: February 25, 2012, 03:42:51 pm »
Ok - here comes another issue... ;-)

- consider this code:
Code: [Select]
#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:
« Last Edit: February 25, 2012, 03:51:20 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #659 on: February 25, 2012, 03:50:10 pm »
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. :-(
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ