C::B crashes when I try to a big data structure by moving pointer on it.

[Kaijun]

I am using C::B ver. 10.5, when I debug my code and display a big data structure by moving pointer on it. It crashes immediately. Is there any way to avoid it, e.g. tune buffer size in the C::B?

[oBFusCATed]

Try the latest debugger's branch nightly...

[Kaijun]

Try the latest debugger's branch nightly...

It seems there is no nightly for linux. I am using Fedora 13.

[oBFusCATed]

Read this: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux

[Kaijun]

Read this: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux

I followed the steps as said, I got build errors, svn info

Path: .
URL: svn://svn.berlios.de/codeblocks/trunk
Repository Root: svn://svn.berlios.de/codeblocks
Repository UUID: 98b59c6a-2706-0410-b7d6-d2fa1a1880c9
Revision: 7028
Node Kind: directory
Schedule: normal
Last Changed Author: pecan
Last Changed Rev: 7028
Last Changed Date: 2011-02-24 18:02:27 +0000 (Thu, 24 Feb 2011)


In file included from ./src/advprops.cpp:56:
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:134:1: warning: "wxPGVariant_EmptyString" redefined
In file included from ./src/advprops.cpp:52:
/opt/wx/2.9/include/wx-2.9/wx/propgrid/propgrid.h:113:1: warning: this is the location of the previous definition
In file included from ./src/advprops.cpp:56:
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:135:1: warning: "wxPGVariant_Zero" redefined
In file included from ./src/advprops.cpp:52:
/opt/wx/2.9/include/wx-2.9/wx/propgrid/propgrid.h:114:1: warning: this is the location of the previous definition
In file included from ./src/advprops.cpp:56:
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:136:1: warning: "wxPGVariant_MinusOne" redefined
In file included from ./src/advprops.cpp:52:
/opt/wx/2.9/include/wx-2.9/wx/propgrid/propgrid.h:115:1: warning: this is the location of the previous definition
In file included from ./src/advprops.cpp:56:
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:137:1: warning: "wxPGVariant_True" redefined
In file included from ./src/advprops.cpp:52:
/opt/wx/2.9/include/wx-2.9/wx/propgrid/propgrid.h:116:1: warning: this is the location of the previous definition
In file included from ./src/advprops.cpp:56:
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:138:1: warning: "wxPGVariant_False" redefined
In file included from ./src/advprops.cpp:52:
/opt/wx/2.9/include/wx-2.9/wx/propgrid/propgrid.h:117:1: warning: this is the location of the previous definition
In file included from ./src/advprops.cpp:56:
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:18: error: aggregate ‘WXDLLIMPEXP_PG wxArrayEditorDialog’ has incomplete type and cannot be defined
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:32: error: variable ‘WXDLLIMPEXP_PG wxPGGlobalVarsClass’ has initializer but incomplete type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:32: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:34: error: expected primary-expression before ‘public’
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:34: error: expected ‘}’ before ‘public’
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:34: error: expected ‘,’ or ‘;’ before ‘public’
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:37: error: expected class-name before ‘(’ token
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:61: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:62: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:63: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:64: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:65: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:66: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:67: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:69: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:72: error: ‘wxPGVariantDataClassInfo’ does not name a type
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:102: error: non-member function ‘int HasExtraStyle(int)’ cannot have cv-qualifier
../../../src/sdk/wxpropgrid/include/wx/propgrid/propdev.h:107: error: expected declaration before ‘}’ token
make[3]: *** [advprops.lo] Error 1
make[3]: Leaving directory `/home/tang/Projects/CodeBlocks/src/sdk/wxpropgrid'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tang/Projects/CodeBlocks/src/sdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tang/Projects/CodeBlocks/src'
make: *** [all-recursive] Error 1

[stahta01]

I strongly suggest using wxWidgets 2.8 instead of the development version 2.9.
IIRC, 2.8.10 is the normal version of wxWidgets being used.

Tim S.

[Kaijun]

I strongly suggest using wxWidgets 2.8 instead of the development version 2.9.
IIRC, 2.8.10 is the normal version of wxWidgets being used.

Tim S.

Thanks! I got it work on wxWidgets 2.8.11. But it still crashes.  I got errors from xterm,

Gdk-ERROR **: The program 'codeblocks' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 782010 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...


When debugging, another issue is that some source files in the stack window display the paths under the project dir. But they are in different paths. They are compiled into shared libs. What is interesting is other files which are compiled into the static libs, then into the shared libs can show absolute paths, That makes impossible to open these files from the stack.

[oBFusCATed]

Can you provide a sample project, which crashes C::B?

When debugging, another issue is that some source files in the stack window display the paths under the project dir. But they are in different paths. They are compiled into shared libs. What is interesting is other files which are compiled into the static libs, then into the shared libs can show absolute paths, That makes impossible to open these files from the stack.

A sample project will be helpful, too.

[Kaijun]

Can you provide a sample project, which crashes C::B?

When debugging, another issue is that some source files in the stack window display the paths under the project dir. But they are in different paths. They are compiled into shared libs. What is interesting is other files which are compiled into the static libs, then into the shared libs can show absolute paths, That makes impossible to open these files from the stack.

A sample project will be helpful, too.

I debug on omap3530. You can try mplayer or ffmpeg in linux on PC. There are some big data structures in codecs in ffmpeg. They are available from http://www.mplayerhq.hu/design7/dload.html.

[oBFusCATed]

No, no big projects, the bug can be reproduce with simple sample...
You can make the sample by copying the data structure causing the crashes in a single source file and populating it with data to make C::B crash.
Making the sample increases the chances for fixing the bug, else you should wait me to encounter it, so I have a way to reproduce it.  :lol:

[Kaijun]

No, no big projects, the bug can be reproduce with simple sample...
You can make the sample by copying the data structure causing the crashes in a single source file and populating it with data to make C::B crash.
Making the sample increases the chances for fixing the bug, else you should wait me to encounter it, so I have a way to reproduce it.  :lol:

I don't have simple project, I attach a header file where MpegEncContext may have 100 elements. you include it in your test file and define a
data structure.

[Jenna]

If included the header, commented out everything but MpegEncContext, for all unknown types I added a #define <typ> int except for MAX_LEVEL and MAX_RUN ( I defined them as 1 and 2).
If I hover over a variable of type MpegEncContext in my test app, it does not crash. I am not able to see everything, because the struct is too large, but no crash.
Adding it as watch works also.

After reading your error-message above, I think it might be a graphics problem.

so my system setup

debian 64 bit (unstable/experimental)
core2duo with 3.2 GB usable ram

ati mobility x1400 with radeon-driver 1.6.14 and kms enabled
wxWidgets 2.8.10
kernel 2.6.38
xserver-xorg 1:7.6-3, xserver-xorg-core 2:1.9.99.902-3

no compiz

[oBFusCATed]

Another option is to build C::B in debug mode (--enable-debug in the configure script) and debug C::B inside gdb, then when it crashes past the full backtrace (bt full command).