User forums > Nightly builds
The 30 October 2011 build (7550) DEBUGGER BRANCH version is out.
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. ;D
Cheers,
Tobias
oBFusCATed:
--- Quote from: flederwiesel on January 07, 2012, 02:00:49 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.
--- End quote ---
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.
--- Quote from: flederwiesel on January 07, 2012, 02:00:49 pm ---(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.
--- End quote ---
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.
--- Quote from: flederwiesel on January 07, 2012, 02:00:49 pm ---(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...
--- End quote ---
Can you provide a simple example? Does it work with command line GDB?
--- Quote from: flederwiesel on January 07, 2012, 02:00:49 pm ---(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:
--- End quote ---
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:
--- Quote from: oBFusCATed on January 07, 2012, 02:35:45 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.
--- End quote ---
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....
--- Quote ---Does it work with command line GDB?
--- End quote ---
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.
--- End quote ---
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...
--- End quote ---
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...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version