July 29, 2014, 02:42:36 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Don't forget to check the Nightly builds in the appropriate forum.
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: [1]   Go Down
  Send this topic  |  Print  
Author Topic: Code::Blocks developint hints  (Read 8623 times)
Lives here!
Offline Offline

Posts: 2283

« on: March 07, 2005, 07:45:21 am »

If you have tried to debug Code::Blocks, or have any hint related to development, please post it here.

First hint: If you add the following linker options (found experimentally), debugging under GDB shows more info than normally. This is because the linker doesn't rellocate addresses so they're available to the debugger. It's not perfect, but helps alot.

Advanced newcomer
Offline Offline

Posts: 61

« Reply #1 on: May 20, 2005, 10:30:48 pm »

Don't foget to make sure you get rid of all old plugin before recompiling coblocks unless you recompile them to =.  Some times they clash I spet my hour try find thees type of error.
Advanced newcomer
Offline Offline

Posts: 61

« Reply #2 on: May 23, 2005, 01:05:45 pm »

Be very carefule when using  the keyword delete in programs inproper use can cuase your programs to crash.

Don't foget to read the wxwidget manual when programing with wxwidgets.  It sometime tell way to prevent program crash and tell you proper use of the wxwidgets futtion, class, ect..
Lives here!
Offline Offline

Posts: 2283

« Reply #3 on: May 28, 2005, 04:23:31 pm »

NEVER, EVER add dependencies without adding the included files to CVS first!
Official tester
Offline Offline

Posts: 381

« Reply #4 on: August 23, 2005, 02:59:52 pm »

JIT debugging

cd C:\mingw\bin
drmingw -i -v
this will install drmingw as the jit debugger (drmingw -u to later uninstall)
(windbg can be installed as the jit debugger with windbg -I but it doesn't support gcc
gcc debug symbols.  it does support vc5/6/7 .pdb files and provides true source level

to test:
- create a win32 project using the gcc compiler as default
- place
  somewhere in the code
- compile & run
  gcc -g

- create a win32 project using vc++ toolkit compiler as default
- place
  __asm{ int 3 };
  somewhere in the code
- compile & run
  cl /Zi
  link /debug

windbg -
drmingw -
« Last Edit: August 23, 2005, 03:10:43 pm by grv575 » Logged
Almost regular
Offline Offline

Posts: 155

« Reply #5 on: August 24, 2005, 04:55:52 pm »

NEVER use "#define" to declare a constant or a macro, especially in header files! This could be tolerated in cpp files but it's a bad habit anyway!
Prefer either an "static const", an "enum" or a template function instead (or better, a non-template inline function)

BAD example:
#define NO_ERROR 0
#define MIN(A,B) (((A)<(B))?(A):(B))

GOOD example:
static const int NO_ERROR = 0;
template <class T> T min(T a, T b) { (a<b)?a:b; }

This will avoid the side-effect of preprocessor definitions
Advanced newcomer
Offline Offline

Posts: 71

« Reply #6 on: August 25, 2005, 12:31:00 am »

While not being a developer I would like to lend a tip or two.

Prefer either an "static const", an "enum" or a template function instead (or better, a non-template inline function)


GOOD example:
static const int NO_ERROR = 0;
template <class T> T min(T a, T b) { (a<b)?a:b; }

Why not make the template functions inline? They have no disadvantage with respect to non-template functions. (Yes, old compilers ALWAYS bloated the code before, but not anymore nowadays.) Using this kind of templates is both simple and advisable:

namespace my {
inline template<typename T> T min(T a, T b) { return a <= b ? a : b; }
inline template<typename T> T max(T a, T b) { return a >= b ? a : b; }
inline template<typename T> T sqr(T a) { return a*a; }
This will avoid the side-effect of preprocessor definitions

Please allow me to complement zieQ's coding style advice by supplying a "textbook example" of how a macro can mess up your code.
Suppose you define a macro that expands your variables to be squared, i.e.:
#define SQR(A) ((A)*(A))
Now, suppose you use this macro for a certain expression.
A natural way to write it in a given context would be for example:
int n = 5;
int m = SQR(n++);
So m should end up being equal to 25 while n finishes as 6, right? Wrong. A macro makes a _textual_ replacement of the expression in the parenthesis by  its definition. The compiler replaces what you wrote by
int m = (n++) * (n++);
So, in fact, m is equal to 30, and n is equal to 7.
You can easily conclude what might happen with complicated expressions. The consequences of systematically using macros to handle pointers can be much worse, with hard to track segmentation faults.
Needless to say, the above example, with the inline function template shown above, ( my:: sqr() ) would be parsed normally as any function, without any surprises. Type safety is a Good Thing(TM).

Another tip, though maybe not so useful, would be the use of namespaces separation for code clarity. I'd like to see further use of namespaces in the SDK, so I'm posting that as a feature request in sourceforge. Though low priority, I know.

Best regards
Official tester
Offline Offline

Posts: 381

« Reply #7 on: August 26, 2005, 03:45:41 pm »

gdb quickstart:

Some commands to try out...

file codeblocks (can use tab completion, command history)
bt - back trace
frame - list current frame
info source - info on current source file
frame 1 - switch to frame 1
up - go up a stack frame
list - list source code at current position
break - set breakpoint on current function
run - reload debugee
c - continue
break 62 - set breakpoint on line 62
break *0x12345678 - break at address
list 62 - list around line 62
list - list more
list app.cpp:297 - list around line 297 in app.cpp
enter - *** repeat last command ***
help breakpoints - help on breakpoints
info args - show arguments
info break - show breakpoints (i b)
delete 1 2 - delete breakpoints 1 & 2
disable 1 - disable breakpoint 1
info threads - show known threads for the process
info variables - show known variables
finish - execute till ret (out)
interrupt - interrupt execution
kill - kill program
attach 4080 - attach to pid 4080
info frame
info dll
info reg
cd program files
print x
disp x
undisp x
n - next (over)
s - step (into)
stepi - step one instruction
b 3 x > 5 - make breakpoint 3 conditional (when x > 5)
x - examine memory
x/s 0x0810267c - examine string at 0x0810267c
printf "%s", *0xbffff970 - printf
whatis x : whatis data type of x
jump 5 : jump to line 5 (set eip here)
« Last Edit: September 08, 2005, 11:51:28 pm by grv575 » Logged
Official tester
Offline Offline

Posts: 381

« Reply #8 on: September 03, 2005, 09:44:08 pm »

Wanted to check codeblocks for memory errors.  How to compile codeblocks against mpatrol (there's an .exe installer at mingw sourceforge):

1)  have gcc include mpatrol.h with each source file:
-include mpatrol.h

2)  specify multiple definitions of malloc(), etc are OK linker option:

3)  make sure mpatrol (mpatrolmt) libraries occur before other libraries (which define malloc(), etc):
-lmpatrolmt -limagehlp -lbfd -liberty --lwxmsw26 -lgdi32

So, goto build options
   under compiler->other options add
      -include mpatrol.h
   under linker->other link options add
   under linker->link libraries add (***before all other libraries***)
(You also need to set the linker settings for the console runner target)

So that should give something like: -lmpatrolmt -limagehlp -lbfd -liberty -lwxmsw26 -lgdi32
when it links.

That should be it.  There's a mpatrol.pdf that installs with the mpatrol installer.  Basically just run codeblocks.exe and look for a mpatrol.log afterwards.  Compiling right now, will test the results later.

Edit: looks like bfd is the wrong object file format for windows.  I'll try recompiling mpatrol and see if it works then

Edit: nevermind, it looks like mpatrol doesn't want to work.  I just tried the above flags with a simple win32gui app and then putting int* abc = new int[10]; (so that the mpatrol libs are actually linked in)

it gives:
ERROR: [ILLMEM]: illegal memory read at address 0x00000000
    0x00000000 not in heap

    call stack
0x00000000 ???
0x0041082C ???
0x0040218C ???
0x00402BF3 ???
0x0041A70F ???
0x0047176D ???
0x004715B7 ???
0x00471399 ???
0x004011E7 ???
0x00401238 ???
0x7C816D4F RegisterWaitForInputIdle+73

No matter if I delete the memory properly or not.  Looks like mpatrol just isn't working right with winxp or something.  Any other suggestions for memory checking with mingw?

Edit: OK, I finally figured out mpatrol.  Uninstall the mpatrol .exe installer.  The precompiled version on the mingw site is "broken":

"I suspect that the gcc C++ ABI has changed since
the downloaded library was built. That would
explain mysterious behavior if true. Try building
the library from source."

Edit: ignore the url below.  grab the source at the mingw site which they already patched (better too since it generates dlls).

So download the source:
extract to c:\ and then open an MSYS prompt and do:
cd /usr; mkdir local; ln -s "/c/MinGW/include" include; ln -s "/c/MinGW/lib" lib
vi /etc/profile
   export LD_LIBRARY_PATH = "/usr/local/lib:$LD_LIBRARY_PATH"
source /etc/profile
place the attached patch in c:\ and change to the extracted mpatrol directory:
cd /c/mpatrol
patch -p1 -i ../mpatrol-1.4.8-mingw.patch.txt
cd build/unix
make clean
make all
copy generated files to the right place
cp *.h "/c/MinGW/include/mpatrol"
mv "/c/MinGW/include/mpatrol/{mpatrol.h,mpalloc.h,mpdebug.h}" "/c/MinGW/include"
cp *.lib *.exp *.so "/c/MinGW/lib"
copy the contents of the mpatrol\doc directory to c:\MinGW\doc\mpatrol

All set.  To test build a new Win32GUI application.
int* abc = new int[10];
after the case WM_DESTROY:
(compare with later adding delete[] abc; as well.  or even just delete abc; which leaks but doesn't crash... but mpatrol catches this)
Next goto build options:
check produce debugging symbols (-g)
compiler->other options =
   -include mpatrol.h
linker->link libraries =
other link options is blank since we are linking the static libmpatrol.a (dynamic .so one requires -Wl,--allow-multiple-definition)
rebuild and then open a cmd prompt
(see the documentation...)
and run:
exit the app and then look at:
also try at the cmd prompt:

you should see...

top 2 unfreed memory entries in leak table:
       bytes   count  location
    --------  ------  --------
          60       1  ___w32_sharedptr_initialize
          40       1  main.cpp line 85
         100       2  total
cool, huh?  Shows you exactly where you put a new[] and then later never delete[]ed.

[attachment deleted by admin]
« Last Edit: September 04, 2005, 05:19:38 pm by grv575 » Logged
Official tester
Offline Offline

Posts: 381

« Reply #9 on: September 08, 2005, 06:54:26 pm »

Debugging on linux:

First, it's best to compile wxWidgets with debug info.  This provides assertions, etc (which can be turned on/off in the $(WXDIR)/lib/wx/include/gtk2-ansi-release-2.6/wx/setup.h file).

Next, also compile codeblocks with debug info.  (--enable-debug configure flag)

Turn on core dumping
edit ~/.bash_profile
ulimit -c unlimited

save and do
source ~/.bash_profile

change to the codeblocks bin directory (add2line currently needs to be in the same directory as the codeblocks binary to load debugging symbols):

cd /usr/local/bin

now when an assertion triggers, you can hit yes to stop the program.  it will dump core (also when the program crashes it dumps core...)
you can then load the core dump with all debugging symbols and stack trace information using:
gdb codeblocks core

then the usual
frame 5
print var
Official tester
Offline Offline

Posts: 381

« Reply #10 on: September 09, 2005, 04:31:01 am »

bogus file/line#s in gdb:

this is caused by having the same source file name in two different directories in the gdb source path (to see the source path type in gdb: info sources).

for example, codeblocks uses a file app.h, but there is also an app.h in wxWidgets which appears first in the source path on linux (at least for me).

so a gdb backtrace may report the wrong file/line for a stack frame in app.h (CodeBlocks one).
Advanced newcomer
Offline Offline

Posts: 34

« Reply #11 on: September 10, 2005, 06:43:25 pm »

If you are using gdb as your debugger you should really compile using -ggdb instead of -g (linux anyways).

OS: Gentoo Linux (Kernel 2.6.11 (2.6.12 is evil )   x64_x86)
WM: KDE 3.4.1
Compiler: GCC 3.4 (but of course) GLIBC: NPTL wxWidgets: 2.6.1
Lives here!
Offline Offline

Posts: 3938

« Reply #12 on: September 19, 2005, 07:36:41 pm »

The most obvious thing: Learn C++. This sounds like a really stupid tip, but hey Wink

If you think you know your Kung Fu, then have a look at and work through all 87 questions (or go to a similar site, there are a couple).
A lot of these problems look quite trivial at first glance, and a few solutions are arguable, but overall, you will probably find that you missed a significant thing in almost every other question.
If afterwards, you feel like hiding in a dark corner for all the things you didn't know, that's ok. It means you have learned a lot.

"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."
Pages: [1]   Go Up
  Send this topic  |  Print  
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!