The 02 April 2011 build (7075) DEBUGGER BRANCH version is out.

[oBFusCATed]

I feel it has little advantage to push out a nightly build

No, nightly please, the code is a bit unstable on windows...

I'm not sure what should I do on windows about the autodetection:
1. Probably should do something like the compiler
2. I can hardcode c:\mingw\bin\gdb.exe
3. Get the default bin directory of gcc
4. Something else

Probably 3 is the best choice, what do you think?

[killerbot]

I guess a combination of 1) and 3)
I think 1) is just trying out a few defaults (long time since I looked at that code)

[ultimA]

Latest debugger branch (7200) crashes if I close CB after opening it.
To reproduce, open CB, do not open any project or file (only start page should be visible) and close it.
Crash log attached to this post.

[oBFusCATed]

Hm, Are you sure with compiled it correctly?

I see no crashes with r7200 on CentOS 5.5 64bit and on Windows XP.

Probably this could be something related to this crash:

Code Select Expand


(codeblocks:7830): Gtk-CRITICAL **: gtk_menu_attach_to_widget: assertion `GTK_IS_MENU (menu)' failed


What OS and compiler are you using?

[Jenna]

Works fine here on debian 64-bit.
Compiled with C::B and compiled with automake-system.

Did you run ./bootstrap before running ./configure ?
Also deleting the pch's (src/include/*.gch) manually might help.

[ultimA]

Latest debugger branch (7200) crashes if I close CB after opening it.
To reproduce, open CB, do not open any project or file (only start page should be visible) and close it.
Crash log attached to this post.

It turns out I needed to delete the old settings (.codeblocks folder in home dir), then it works. Sorry for not trying this earlier.

[Feature Request] I guess it would make sense to introduce a version number in the settings folder. Whenever an incompatible change is introduced, the number would be incremented in the app, and if the stored number is lower, CB could notify (or even better, offer) the user to reset the settings.

[oBFusCATed]

Hm, this should not happen.
Do you have the old settings, backed up?

[ultimA]

Here it is. I verified that if I copy back the old settings, the crash happens again.

[Jenna]

I can reliable make the debugger-branch cash, if I open C::B with hidden debugger toolbar and close it without making the toolbar visible.
No time to investigate deeper, but it should not be so hard to fix.

[oBFusCATed]

Jens: thanks, will look at it immediately...

[oBFusCATed]

Fixed a crash... Jens can you try the latest revision?

BTW: There is a crash in the BlockAllocator, I'll report back if it is fixed with the changes made by Loaden...

[Jenna]

Fixed a crash... Jens can you try the latest revision?

Fix confirmed !

[huliming2004]

Hi,everybody:
    I've been used Code::Blocks for serveral years. it's fantastic!!! GDB 7.2 now support python. I googled and find how it can support Qt and managed to solve the problem it cannot support to watch type of QString,QList etc. can you let the code::blocks support to debug Qt program by default. resources is in the attachment.

[huliming2004]

Hi, when i ran my compiled program, it works ok because i can set the working directory in the project "properties...". but it did not work when i began to debug it. It is because that gdb(version 7.2) doesn't start at the program working directory, my program depends on its progam's working directory.  Of course i can solve this problem with moving my data or change the envirements params. but it's not Convenient. can you given a way to start gdb with special working directory or just the same as the compiled program's working directory?
  best regards.

[oBFusCATed]

Hm, as far as I know the C::B in debugger's branch sets the working dir correctly.
Can you provide a test project which fails with the latest debugger branch?