Author Topic: C::B becomes unresponsive, when watching big data structure on debug session  (Read 8097 times)

Offline sophron

  • Single posting newcomer
  • *
  • Posts: 7
It has been an issue since the new debugger branch merged into the C::B code base.  :-\
For example, when debugging a simple OpenCV Application below, C::B freezes after unfolding the "*pImg" data structure and scroll down to the image data portion in the watches window (on Windows XP SP3 EN).

Code: [Select]
#include <stdio.h>
using namespace std;

#include <cv.h>
#include <cxcore.h>
#include <highgui.h>

int main( int argc, char** argv )
{
    IplImage* pImg; //declare image pointer

    //Load the image
    if( argc == 2 && (pImg = cvLoadImage( argv[1], 1)) != 0 )
    {
        cvNamedWindow( "Image", CV_WINDOW_AUTOSIZE );
        cvShowImage( "Image", pImg ); //show the image

        cvWaitKey(0); //pause

        cvDestroyWindow( "Image" );
        cvReleaseImage( &pImg );
        return 0;
    }

    printf("Error: Couldn't open the image file.\n");
    return -1;
}
« Last Edit: September 16, 2012, 04:42:21 pm by sophron »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Quote
C::B freezes after unfolding the "*pImg" data structure
Did you use gdb?
If you does not limit the element of a buffer, the whole data buffer of the pImg will be show which cause the lag.
Try to set the element number by enter the command "set print elements 200" (this means only show the first 200 elements if the buffer is too large) in the debugger's initial command.
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 sophron

  • Single posting newcomer
  • *
  • Posts: 7
Yes, the debugger is GDB.
But it is obvious that setting "show print elements 200" may stop the whole elements of a large array from being displayed.
And what is also different from the former debugger plug-in of C::B is that the watches window does not display local variables and "this" pointer automatically when stepping into a certain scope. (other GDB initialization commands needed?)
Anyway, the merging of the new debugger plug-in seems slapdash.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Anyway, the merging of the new debugger plug-in seems slapdash.
I hope you're joking here.
The watches in the old plugin where useless and badly broken. You can go back to 10.05 and play with them, I'm sure you won't like them.
Yes there are locals and function args, but they are broken when showing complex variables and classes.
The backtrace window was broken.
Many other things were broken.

If you want to watch the this pointer put it in the watches. Simple as this.

But it is obvious that setting "show print elements 200" may stop the whole elements of a large array from being displayed.
So, you prefer to see a list with 20000 elements in there?

(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: 9508
But it is obvious that setting "show print elements 200" may stop the whole elements of a large array from being displayed.
So, you prefer to see a list with 20000 elements in there?
Harhar... some people make really weird debugging... :-)
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 O-san

  • Multiple posting newcomer
  • *
  • Posts: 25
    • OddGames
Sorry to reply to such an old thread but this is an excellent tip. I was getting pretty annoyed when the gdb tried printing a rather large buffer.. this trick saved me a ton of headache :)