Author Topic: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.  (Read 31771 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #1 on: October 30, 2011, 12:01:25 pm »
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #2 on: November 02, 2011, 01:21:01 pm »
This nightly build is really cool, especially the "press ctrl to show the debug tooltip feature" :D
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #3 on: November 13, 2011, 08:14:01 am »
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.

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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #4 on: November 14, 2011, 04:27:48 pm »
Ollydbg: Should be fixed in the branch, thank you for the report.
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #5 on: November 15, 2011, 02:51:28 am »
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!!!
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 xunxun

  • Almost regular
  • **
  • Posts: 187
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #6 on: November 25, 2011, 09:06:14 am »
@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.
Regards,
xunxun

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #7 on: November 25, 2011, 09:59:45 am »
@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/
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #8 on: December 05, 2011, 02:09:09 am »
@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?
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #9 on: December 05, 2011, 11:30:18 am »
Yes, we should remove the new c++ stl keywords :)

I know about the issue, most of the time I get it with count :(
(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 flederwiesel

  • Single posting newcomer
  • *
  • Posts: 3
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #10 on: January 07, 2012, 02:00:49 pm »
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. ;D

Cheers,
Tobias
* "He said he hadn't had a byte in three days. I had a short, so I split it with him."<br />-- Unsigned

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #11 on: January 07, 2012, 02:35:45 pm »
(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.
(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #12 on: January 07, 2012, 02:42:11 pm »
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 :(
(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 flederwiesel

  • Single posting newcomer
  • *
  • Posts: 3
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #13 on: January 07, 2012, 08:59:05 pm »
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....

Quote
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.

Quote
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).

Quote
released in a new nightly very soon...
This was quick!

Regards,
Tobias
* "He said he hadn't had a byte in three days. I had a short, so I split it with him."<br />-- Unsigned

Offline flederwiesel

  • Single posting newcomer
  • *
  • Posts: 3
Re: The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
« Reply #14 on: January 17, 2012, 06:12:03 pm »
(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...
* "He said he hadn't had a byte in three days. I had a short, so I split it with him."<br />-- Unsigned