The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z

The 30 October 2011 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20111030_rev7550_DEBUGGER_BRANCH_win32.7z
  - Linux :
   none

Important changes compared to previous DEBUGGER BRANCH nightly:

* Pressing Ctrl key forces the value tooltip to be shown, if require ctrl key is enabled
* Call cbDebuggerPlugin::ExpandWatch/CollapseWatch, when a tooltip property is expanded/collapsed
* Add cbDebugInterfaceFactory::UpdateValueTooltip() method and implemented it
* Move the Expand call from the constructor of ValueTooltip to the debugger plugin
* Fixed a bug in the wxPropertyGrid's code (related to the previous commit)
* removed some unnecessary xrc files, moved the breakpoints.xrc to the gdb debugger resources
* Improved setting/resetting of the m_ProgramIsStopped. Now m_ProgramIsStopped is reset, when a continue type command is
executed and it is set to true, when the program is stopped/interrupted. This made it possible to call AddBreakpoint
in a loop.
Added new API method: IsBusy, which should return true, when the debugger is busy executing commands.
This change is done only for GDB, so probably CDB is broken!
* make sure that commands are executed only, when the program is in stopped stated, otherwise a command can be skipped.
* Fixed CDB part of the debugger plugin to correctly handle the m_ProgramIsStopped
* fixed a bug when debugger didn't finish correctly if the inferior/debuggee returns exit code != 0
* Major refactoring of the Breakpoints API;
* made cbBreakpoint an abstract base class;
* replaced all pointers to cbBreakpoint in the API, with cb::shared_ptr;
* removed all cbEVT_EDITOR_BREAKPOINT_*;
* detect if a temporary breakpoint is reached and removed it from the list of active breakpoints;
* reimplemented the breakpoint functions in DebuggerState, removed the unnecessary once;
* removed the array with the breakpoints data from the DebuggerGDB class, now there is only one place where we store the breakpoints, which will make it less buggy;
* added API for enabling/disabling the breakpoints;
* added editor markers for enabled/disabled breakpoints;
* added icons for the editor markers;
* added icons in the breakpoints dialog;
* added enable/disable context menu items in the context menu for the breakpoints dialog;
* made the list ctrl in the breakpoints dialog multi select one;
* added enable/disable menu items in the context menu of the editor (the one which shows when the user right clicks the margin);
* moved the editbreakpointsdlg.h/cpp into the debuggergdb's folder, so now every plugin will be responsible for the GUI;
* reoderer the markers in the editor a bit, now they all should be visible;
* added a setting which controls if the temp breakpoints are visible in the breakpoints dlg;
* Revisit the usage of pointers/references/smart pointers in the Debugger API - replaced references with cb::shared_ptr for stack frames and threads
* Breakpoint::GetLocation() now returns the original passed path, instead of the path used with the debugger
* debugger_branch:
* replaced all pointers to cbWatch with cb::shader_ptr<cbWatch>, this requires new version for the SDK
* fixed a crash in WatchesDlg::DeleteProperty
* fixed the debuggergdb plugin to use the new API
* fixed the debugger test project (all tests pass)
* removed cbWatch::SetParent
* made cbWatch::AddChild to be static (required to set the m_parent weak_ptr)
* added std::tr1::weak_ptr to namespace cb
* kill gdb if the child pid is 0 (linux only for now, should test on Windows)
* all updates that occurred on trunk


Note: Watch parsing prints an error message in the watches window if the parsing fails. If you see this string please report it as a bug.

THIS IS A SPECIAL TEST BUILD OF REFACTORINGS CARRIED OUT ON THE DEBUGGER BRANCH IN OUR SVN.
FOCUS IS ON ENHANCED DEBUGGING USABILITY.

Give your feedback on this version only in this thread, don't mix it with the regular nightly please. If you feel it is however not
related to the debugger functionality itself, then it might be better to report it the corresponding regular nightly build thread.

Once we don't have any blockers on this version,we will merge the changes into trunk and it will be part of the regular nightlies.

[Jenna]

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

If you want to use apt (or dselect, synaptic or whatever) you need to add the following entries to /etc/apt/sources.list :

Code

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg

and remove entries for the normal nightlies.

Alternatively you can download the deb's directly from http://apt.jenslody.de/pool/dbg/c/codeblocks/ .

Revision is 7549, 7550 is unrelated to debugger-branch.

[ollydbg]

This nightly build is really cool, especially the "press ctrl to show the debug tooltip feature"

[ollydbg]

Maybe a bug:
Set BP in plugins\codecompletion\codecompletion.cpp line 509, and add watch variable "repl", and when c::b hits BP, it shows "Parsing GDB output failed for 'repl'!"

debugger log below:

Code

> whatis repl
type = StringToStringMap
>>>>>>cb_gdb:
> output repl
std::map with 20 elements = {["BEGIN_EVENT_TABLE"] = "-END_EVENT_TABLE", ["WXDLLEXPORT"] = "", ["WXEXPORT"] = "", ["WXIMPORT"] = "", ["_GLIBCXX_BEGIN_NAMESPACE"] = "+namespace std {", ["_GLIBCXX_BEGIN_NAMESPACE_TR1"] = "namespace tr1 {", ["_GLIBCXX_BEGIN_NAMESPACE_VERSION"] = "", ["_GLIBCXX_BEGIN_NESTED_NAMESPACE"] = "+namespace std {", ["_GLIBCXX_END_NAMESPACE"] = "}", ["_GLIBCXX_END_NAMESPACE_TR1"] = "}", ["_GLIBCXX_END_NAMESPACE_VERSION"] = "", ["_GLIBCXX_END_NESTED_NAMESPACE"] = "}", ["_GLIBCXX_STD"] = "std", ["_GLIBCXX_STD_D"] = "std", ["_GLIBCXX_STD_P"] = "std", ["_GLIBCXX_VISIBILITY"] = "+", ["_STDEXT_BEGIN"] = "namespace std {", ["_STDEXT_END"] = "}", ["_STD_BEGIN"] = "namespace std {", ["_STD_END"] = "}"}>>>>>>cb_gdb:

I'm using gdb with python.

[oBFusCATed]

Ollydbg: Should be fixed in the branch, thank you for the report.

[ollydbg]

Ollydbg: Should be fixed in the branch, thank you for the report.

I can confirm this was fixed. Thank you very much for your work!!!

[xunxun]

@oBFusCATed
btw, I found that cb debugger branch use gdb output command to print the value, but the output command in archergdb has some bugs, which can't show C variable length arrays and Fortran dynamic arrays, and the print command can be used normally.
Will the debugger branch replace output with print to show the value?
Thanks.

[oBFusCATed]

@oBFusCATed
btw, I found that cb debugger branch use gdb output command to print the value, but the output command in archergdb has some bugs, which can't show C variable length arrays and Fortran dynamic arrays, and the print command can be used normally.

We do not support experimental gdbs, sorry.

Will the debugger branch replace output with print to show the value?

I don't see any reason to do it for now, but if the output command will be broken in the next official gdb, then we will change it.
For now you'll have to do it yourself and to see what break and what doesn't.
The file you're interested is gdb_commands.h in src/plugins/debuggergdb/

[ollydbg]

@OBF
I found a tiny bug. If I have such code:

Code

int main()
{
    int size;
    size = 1;
    return 0;
}

When debugging, if my mouse is hover the "size", and I press the CTRL, there is no value shown.
I guess this is because that "size" is a keyword of C++, right?
If I run command "p size" in the debugger gdb text control, it works.
Can we solve this?

[oBFusCATed]

Yes, we should remove the new c++ stl keywords

I know about the issue, most of the time I get it with count

[flederwiesel]

Hello,
first of all, I am relatively new to C::B, but I think it is a good and very intuitive and easy-to-use IDE. Thanks so far.

But there are some things I encountered (sorry, if they are a re-post, even more, if I oviously did something wrong  ):

(1) Looking for the "Set Next Statement" feature I came across this build, but it seems this is not working with XP SP3 and GNU gdb 6.5.50.20060706-cvs (cygwin-special) -- a quite old gdb, I know.... Whenever I try to Set Next Statement the debugger seems to hang, I neither gets there, nor is it possible to stop the debuggee.

(2) Another issue I found is that the watch list's columns do not always remain their size after I stop debugging. So I always have to resize them each time I restart debugging, which is also not that easy, because dragging will be interrupted, if a tooltip appears inbetween.

(3) When setting breakpoints in lexer/parser files, the program is being stopped correctly, and the debugger output window shows the file/line number as expected, but the arrow is missing...

(4) Which seems to be more serious: When trying to set a breakpoint in a file, which exists with the same name in different folders, the debuggee will not be halted, probably due to the wrong file having been picked. The configuration under which it happend to me is as follows:

    Project 'sm' is using a custom makefile, which compiles all C files from 'sm' and 'tl' into 'sm/obj' and links to 'sm/bin'. I have a backup copy of 'tl' in 'sm' and this seems to cause the trouble! Although stated as "..\tl\tl.c" in the cbp file, the breakpoint is not set there, and stepping into a tl-function from 'sm/commgr.c' resulted in 'sm/tl/tl.c' being opened. Until I removed 'sm/tl/' from disk. It now works, but it took me some time to find out....

Directory structure:

prj/
|
+-- sm/
|   +-- bin/
|   |   \-- sm*
|   |
|   +-- obj/
|   |   |
|   |   +-- commgr.o
|   |   +-- main.o
|   |   +-- sm.o
|   |   \-- tl.o
|   |
|   +-- Makefile
|   +-- commgr.c
|   +-- main.c
|   +-- sm.c
|   +-- sm.cbp
|   +-- sm.workspace
|   |
|   \-- tl
|       |
|       +-- tl.c (stepped into)
|       \-- tl.h
|
\-- tl/
    |
    +-- tl.c (breakpoint set)
    \-- tl.h

Would be nice, if this could be fixed, and released in a new nightly very soon... really looking forward to it.

Cheers,
Tobias

[oBFusCATed]

(1) Looking for the "Set Next Statement" feature I came across this build, but it seems this is not working with XP SP3 and GNU gdb 6.5.50.20060706-cvs (cygwin-special) -- a quite old gdb, I know.... Whenever I try to Set Next Statement the debugger seems to hang, I neither gets there, nor is it possible to stop the debuggee.

Anything below 6.8 is pretty much unsupported by C::B, so you should upgrade to at least 6.8.xx, the best is to upgrade to 7.3.
Also cygwin is not well supported, because there is not active developer of C::B using it for his projects (I may be wrong here). Mingw should work better.

(2) Another issue I found is that the watch list's columns do not always remain their size after I stop debugging. So I always have to resize them each time I restart debugging, which is also not that easy, because dragging will be interrupted, if a tooltip appears inbetween.

I know about this issue, but I'm not exactly sure how it can be reproduced. I agree that it is pretty annoying. I'll look at it, but if you can give me the exact steps to reproduce it will speed things up.

(3) When setting breakpoints in lexer/parser files, the program is being stopped correctly, and the debugger output window shows the file/line number as expected, but the arrow is missing...

Can you provide a simple example? Does it work with command line GDB?

(4) Which seems to be more serious: When trying to set a breakpoint in a file, which exists with the same name in different folders, the debuggee will not be halted, probably due to the wrong file having been picked. The configuration under which it happend to me is as follows:

Check the settings and enable the debugger's debug log.
There you can inspect what gdb commands are executed and you can see what is happening.
You can execute the 'info breakpoints' command to see what is the real state of your breakpoints.
Keep in mind that it might be related to the gdb version.

[oBFusCATed]

I know about this issue, but I'm not exactly sure how it can be reproduced. I agree that it is pretty annoying. I'll look at it, but if you can give me the exact steps to reproduce it will speed things up.

I've tried again to reproduce it, but I can't. It is obscure combination of actions that causes this bug

[flederwiesel]

Thanks for the quick reply.

Attached is a small parser-skeleton. Works with bison 1.875 and flex 2.5.4 (except for the breakpoints...). Maybe this also works better with a new gdb....

Does it work with command line GDB?

Sorry, I never worked with command line gdb, so I cannot tell for now . I have been working with MSVC6 (and cygwin tools) until I started my new job.

Mingw should work better.

If you develop for Windows only, you may be right. But I did not mention that I need POSIX compliance for the parts running on Windows AND Linux also: MinGW, being Minimalist, does not, and never will, attempt to provide a POSIX runtime environment for POSIX application deployment on MS-Windows.

I will try the "Set Next Statement" as soon as I have installed a new cygwin. Concerning the watch list I think I will have a look at it again as soon as I am back at work (meaning Monday).

released in a new nightly very soon...

This was quick!

Regards,
Tobias

[flederwiesel]

(2) Seems that the grid columns collapse whenever a system message appears on the lower right. After receiving an uncaught SIGSEGV in the debuggee I received a message and after that the grid columns started to misbehave...