Splitting debugger in two - specific debugger and common GUI

[tomjnx]

obFus: In class GdbCmd_AddBreakpoint method ParseOutput, the Backtrace dialog is reloaded. I would have expected to reload the Breakpoints dialog. Am I missing something here?

[oBFusCATed]

Yes, it should be fixed in the branch.

[MortenMacFly]

I got another feature request:
When you compile C::B against wx 2.9.x and then debug into it using C::B you get tons of debugger warnings like:
warning: In file ../../src/msw/window.cpp at line 581: 'SetFocus' failed with error 0x00000057 (wrong parameter.).
...or:
warning: In file ..\..\include/wx/msw/private.h at line 379: 'GetWindowRect' failed with error 0x00000578 (invalid window handle).

This would be OK, but these are so many, that after roughly 30 seconds GDB and the C::B you are debugging from freezes completely. You have to kill the debugger (gdb) (not the debugee - this does not work) to get the "mother instance" of C::B back. This makes it basically impossible to debug into C::B which is compiled against wx 2.9.x.
Do you see a chance just to ignore a set of warnings, maybe even a pattern? It's done in the compiler plugin: You can skip messages with a certain pattern completely.
Alternatively: Maybe one can set a "debug log level", so that all stuff that starts with "warning" is hidden.

What do you think?

[oBFusCATed]

Who is printing the warnings? GDB or wxWidgets?

[MortenMacFly]

Who is printing the warnings? GDB or wxWidgets?

Good question. They appear in the debug log with the prefix "[debug]". So you tell me... ;-)

[oBFusCATed]

They look like wx ones, probably wx calls OutputDebugString or something like that. Can you try to disable the debugging of wxwidgets?

[MortenMacFly]

They look like wx ones, probably wx calls OutputDebugString or something like that. Can you try to disable the debugging of wxwidgets?

How do I do that? You mean *not* using --verbose? I am using the release version of the wxWidgets library btw...

[oBFusCATed]

I'm not really sure, but in 2.9+ they've change the debugging stuff for wx, probably you should check their docs, how to enable/disable debugging.

[MortenMacFly]

How do I do that? You mean *not* using --verbose? I am using the release version of the wxWidgets library btw...

OK, I tried not using --verbose.
Now I get tons of messages like:
[debug]warning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

That's basically the error I am after. However, the freeze just encounters later and I cannot make this stupid message stop, because it's created permanently on every UpdateUI loop. So this is not a solution. It basically does not allow me to debug C::B using C::B. :-(

[oBFusCATed]

Take a look here: http://docs.wxwidgets.org/2.9.3/overview_debugging.html

You can try to set wxDEBUG_LEVEL==0 or provide a null assert handler.

If this doesn't help, you can try to skip the warning line in the GDB_driver::ParseOutput

Put something like this

Code Select Expand


if (line[i].StartsWith(wxT("warning:"))
{
     m_pDBG->Log(wxT("skipped:")+lines[i]);
}

before the "else if (lines.StartsWith(_T("Error ")) ||" line

I've not tried the code, so it might cause problems.

[MortenMacFly]

You can try to set wxDEBUG_LEVEL==0 or provide a null assert handler.

Does not help and it shouldn't be an option at compile time anyways.

Code Select Expand


if (line[i].StartsWith(wxT("warning:"))
{
    m_pDBG->Log(wxT("skipped:")+lines[i]);
}


That would indeed be worth an option, but...

Meanwhile I found out, why this happens:
This GDB command:
set debugevents on
...should definitely be an option on GDB. Turning this feature off made all the messages go away. And that does make sense, because a lot applications "spit out" many of such debugging messages. But during a normal debugging session you don't always want to see them, e.g. when tracing a crash they are usually of no help.

[MortenMacFly]

This GDB command:
set debugevents on
...should definitely be an option on GDB.

BTW: I am thinking, why not putting all of these GDB initialisation commands:
[debug]> set confirm off
[debug]> set width 0
[debug]> set height 0
[debug]> set breakpoint pending on
[debug]> set print asm-demangle on
[debug]> set unwindonsignal on
[debug]> set print elements 0
[debug]> set debugevents on
[debug]> set disassembly-flavor att
[debug]> catch throw

...in a GDB script which you can edit through the debugger config. Then, you save the script to the application folder and source/use it as you do with "stl-views-1.0.3.gdb", too... What do you think?

[oBFusCATed]

Some of them are controlled by options in the settings (catch throw, set disassembly-flavor att) and some of the others should not be user edited, because they will break debugging. (width, height, confirm)

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

[MortenMacFly]

"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'm afraid it doesn't really work. The messages are less, but still a lot of these warnings make it through... I was wrong because I was pointing at a menu and then the messages are "turned off". That sucks. I guess I'll implement the filter as you suggested finally... Not really "nice" but it should work.

[oBFusCATed]

So, you're saying that calling "set debugevents off" doesn't remove the messages?