Author Topic: see content of a vector in debugging  (Read 64184 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #45 on: June 11, 2009, 02:30:07 pm »
Do you care for the vector<vector<T> > and vector<string> cases, at the moment?
Or you want to add the simple version and later improve the parsing?

What about large vectors? vectors with -> 1 000, 10 000, 100 000 or 1000 000 items?
Do we limit the watch to the first 10,20,100?
Or there is special syntax for the watches, as in Visual C++ (  "my_var,10" will show the first 10 items)?

Also what about other classes: list, deque, map, set, unordered_map, unordered_set and the multi versions (I've never used  :lol:) ?
And the various iterators?

p.s. what will happen if I have /usr/share/codeblocks/scripts/gdb_type.script and ~/.codeblocks/share/codeblocks/scripts/gdb_types.script simultaneously, which of the two will be used?
« Last Edit: June 11, 2009, 02:32:26 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 killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: see content of a vector in debugging
« Reply #46 on: June 11, 2009, 02:37:21 pm »
we care for the others too ;-)
But I think it is best to start with 1 at a time. Try that, when OK, commit.
Then the next one, and so one, in case something might be bad, we only have to take out the bad one, and the others, the working ones, are still present.

About which script will be use, dunno, no script expert :-(

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #47 on: June 11, 2009, 02:45:40 pm »
OK, so we want to have vector<int>, vector<some_struct> and so on working on the basic level.
That is doable, I'll take a look at the item count problem tonight and clean the file, so it is ready for commit.

Can I ask some of you to sync the wxaui branch to trunk, because this way it will be easier for me (I'm using in the wxaui branch for everything)?
(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: 9595
Re: see content of a vector in debugging
« Reply #48 on: June 11, 2009, 06:38:35 pm »
Do you care for the vector<vector<T> > and vector<string> cases, at the moment?
These are the ones I personally use most. ;-)

What about large vectors? vectors with -> 1 000, 10 000, 100 000 or 1000 000 items?
Do we limit the watch to the first 10,20,100?
I'd vote for that.

Also what about other classes: list, deque, map, set, unordered_map, unordered_set and the multi versions (I've never used  :lol:) ?
And the various iterators?
Same thing... but enhancements can come with time...
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: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #49 on: June 11, 2009, 07:40:37 pm »
OK, Here is the cleaned up version. (see the attachment)

But there is one very serious performance problem:
I've modified the main.cpp file and now the v vector has 1000 elements.
This means that the string returned from the pvector command is massive (10-20k characters).
And when I put the v variable in the watches pressing f7 causes 1-5 second of delay (the debugger toolbar is inactive for that period).
Putting return _T("") at the first line of Parse_StlVector doesn't help.
Executing "pvector v 0 20" instead of "pvector v" speeds things up, but doesn't work for vectors with less than 20 elements :(

p.s. If you are using trunk version of C::B replace tostring with the wxString_ToLong
p.s.s. I'm running a q6600 @ 3.4ghz, so on slower machines the problem will be bigger :(
p.s.s.s. I'll run C::B in the debugger to see what is happening, but any hints where to look at will be very welcome

[attachment deleted by admin]
« Last Edit: June 11, 2009, 07:42:44 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 killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: see content of a vector in debugging
« Reply #50 on: June 11, 2009, 07:58:18 pm »
I know for example that MSVC debugger warns about big arrays (saying it might take some time), and asks to go ahead.

We could do a similar things, question is what is big (above 20, above 50), maybe we could allow the user to choose how much elements at that time (we can already get the number of elements from GDB).

I will apply with the current situation, it is a start. With more feedback coming we will be pushed into the right direction ;-)

Quote
p.s. If you are using trunk version of C::B replace tostring with the wxString_ToLong

the script does not contain any "tostring", am I missing something ?
« Last Edit: June 11, 2009, 08:03:29 pm by killerbot »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #51 on: June 11, 2009, 08:33:00 pm »
My mistake
replace tostring with tointeger in my post
(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #52 on: June 11, 2009, 08:43:51 pm »
Does someone has any idea, how can I profile the debugger plugin?
(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: 9595
Re: see content of a vector in debugging
« Reply #53 on: June 12, 2009, 12:56:34 pm »
OK, Here is the cleaned up version. (see the attachment)
BTW, this:
Quote
1. copy the "stl-views-1.0.3.gdb" file  to the project directory.( This directory serves as working directory as GDB.exe starts)
Should be handled differently. Nobody should need copy the file to each and every project. I suggest a setting in the debugger's options. Probably this can be done through initialisation commands, is that possible?!
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: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #54 on: June 12, 2009, 01:32:08 pm »
There is no requirement for stl-views-1.0.3.gdb to be in the project's directory.
Mine is somewhere in ~/projects/codeblocks.
We can put it in the share folder (/usr/share/codeblocks or ~/.codeblocks/share/codeblocks/ ) and put a checkbox in the debugger's options dialog to enable it ( "Debugging C++ STL classes" for example)
(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 killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: see content of a vector in debugging
« Reply #55 on: June 12, 2009, 03:32:45 pm »
Question : why would one NOT want to be able to debug STL classes.
I would have it there, and if no one complains (why do I expect a comment from Thomas here ;-)  ) leave it there.

I think it is best to put it in /usr/share/codeblocks and the same for windows.

EDIT : now it is enabled by default right ?

EDIT 2 : /usr/local/share/codeblocks
« Last Edit: June 13, 2009, 08:45:34 pm by killerbot »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9595
Re: see content of a vector in debugging
« Reply #56 on: June 12, 2009, 03:37:34 pm »
Question : why would one NOT want to be able to debug STL classes.
The only thing I can imagine is if it really takes too long and "freezes" C::B therefore for large vectors. Otherwise I'd leave it enabled by default, too.
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: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #57 on: June 12, 2009, 04:03:23 pm »
morten: It doesn't freeze the C::B, it's responsive, but the debugging UI is disabled

killerbot: The user should source the stl-views script, so it is disabled by default and watching vectors should be broken by default.

I suppose the plan should be something like:
1. adding an options which is off in the default config
2. giving it a bit of testing/improvements for couple of months
3. switching it on for all user/removing it

(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #58 on: June 12, 2009, 11:45:44 pm »
I think, I know why the watching of vector with 1000 elements is slow.

The pvector command emits a line for every element in the vector, this means that it emits 1000 + 3 (size, capacity, elem type).
I've added a logging line as follows:
Code: [Select]
void GDB_driver::ParseOutput(const wxString& output)
{
    m_pDBG->Log(wxString::Format(_("GDB_driver::ParseOutput output size: %d"), output.length()));

With this addition, when I add v as a watch, I get too many lines in the debugger pane that look the same:
Code: [Select]
GDB_driver::ParseOutput output size: 13
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15

So, we are parsing the output from the debugger line by line (emiting 1002 pipe events more that we should).
And here is the proof:

In bool PipedProcess::HasInput() we have:
Code: [Select]
    if (IsInputAvailable())
    {
        cbTextInputStream sout(*GetInputStream());

        wxString msg;
        msg << sout.ReadLine();

CodeBlocksEvent event(cbEVT_PIPEDPROCESS_STDOUT, m_Id);
        event.SetString(msg);
wxPostEvent(m_Parent, event);
// m_Parent->ProcessEvent(event);

        return true;
    }

So, the question is can we replace the ReadLine method with ReadBuffer/ReadWholeData one?
What depends on the line by line parsing and what will break if we do the replacement?

p.s. I'm not sure how fast gdb runs the pvector script though
(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12701
    • Travis build status
Re: see content of a vector in debugging
« Reply #59 on: June 13, 2009, 08:32:04 am »
Hello again,

I've done a little experiment (see the patch):
Code: [Select]
Index: src/sdk/pipedprocess.cpp
===================================================================
--- src/sdk/pipedprocess.cpp    (revision 5643)
+++ src/sdk/pipedprocess.cpp    (working copy)
@@ -94,8 +94,8 @@
                 if ( !m_input )
                     break;
 
-                if (EatEOL(c))
-                    break;
+//                if (EatEOL(c))
+//                    break;
 
                 line += c;
             }

Removing the EOL checks makes the ReadLine method to read the whole input data that is available
(the debug output shows that strings of 1000+ character are read).
And the CB is interactive again if the Parse_StlVector looks like this:

Code: [Select]
function Parse_StlVector(a_str, start)
{
     // the whole processing not commented to test its speed
     ..... ....

     // put this before the first return, so the function doesn't produce big string result
    return "test-value";
}

With this setup the CB is quite interactive (less than a second, measured with my internal human clock :) ).

p.s. I've not tested for breakage of the compiler or so... just the debugger

« Last Edit: June 13, 2009, 01:24:17 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!]