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 (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
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 25 August 2012 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20120825_rev8248_win32.7z
- Linux :
none
Resolved Fixed:
- minor API changes in cbStatusBasr and ProgressDialog (un-used so far to my knowledge) to avoid compiler warnings
- added basic support for importing MSVC10 solutions/projects (files only for the moment)
- some further support for importing MSVC10 solutions/projects (defines, libs, includes, switches)
- speedup scrolling in wxScintilla, remove no longer needed workaround/hack to block mousewheel-events;
see: http://forums.next.codeblocks.org/index.php/topic,12164.msg112891.html#msg112891 and also: http://trac.wxwidgets.org/ticket/9057 - added fix for native applications as described here: http://forums.next.codeblocks.org/index.php/topic,16560.msg112575.html
- cleaned up the XRC mess in replace dialog
- separated editor/project hooks via namespace
- wxScintilla: implemented DrawRGBAImage
- fix memory leak : (deprecated) auto_ptr can NOT deal with arrays
- gcc 4.7 build fixes: no need to use -fpermissive compiler-flag anymore
- applied patch #3310: Fix use of numpad enter
- CC: fixed max_matches settings
* CC: moved parsing of project o DoParseOpenedProjectAndActiveEditor (in preparation)
* CC: renamed ParsingType to ParserState and moved it to namespace
* CC: separated macro parsing of GCC and MSVC
* CC: AddGCCCompilerDirs no does not need a compiler anymore -> can be moved to ParserBase for tests - CC: applied (modified) patch #3311: do not draw tooltips off the edge of the window. ignore wxSCI_C_IDENTIFIER and wxSCI_C_GLOBALCLASS in editor tooltip
- try to fix a crash at shutdown of C::B with active debugger session
- debugger: exit properly when application cannot be run (i.e. on Windows: Missing access rights)
- CC: avoid refreshing class browser if not needed
- CC: report issues with class browser updates (i.e. due to missing parser)
- CC: changed logic of how parser stores file names (they are always being converted to forward slashes for comparison) -> should be more fail-safe, i.e. with patch from here: http://forums.next.codeblocks.org/index.php/topic,16596.msg113355.html
- CC: avoid expensive calls to UnixFileName
- BrowsTracker - Add option to wrap jump entries
- applied (slightly modified) patch #3313: Improve handling of inactive preprocessor code
- added power user support for units glob feature (these are directory paths that can be specified, and all files in there will be considered as sources for the project. This can be based on a wildcard for the * file types, and can be recursive. When no wildcard is specified (empty) the default CB wildcard for adding files is used.
- applied patch #3315: Fix 018704 bug related to 'paste' into IncrementalSearch
- provided cppcheck plugin with a config panel to setup cppcheck app and args (closes some "bug" reports with deprecated options)
- applied patch #3316: SpellChecker: search harder for resources
- SpellChecker: updated hunspell to 1.3.3 (Windows only)
- applied (modified) patch #3319: Fix loading of custom colour schemes
- wxSmith: removed specialisations not required for some controls (font picker, rich text, simple html listbox), should fix the wxValidator issue reported here: http://forums.next.codeblocks.org/index.php/topic,16744.0.html
- added two new SDK events: cbEVT_PROJECT_OPTIONS_CHANGED and cbEVT_COMPILER_SETTINGS_CHANGED
Regressions/Confirmed/Annoying/Common bugs:
Hi,
The CB archive cannot be unpacked.
I'm also having the same problem as TiberiuGal. The archive is corrupt.
re-uploaded and ok now
thanks for the gift... 25th of aug is my birthday... ::) :D
Happy birthday !
Here's an interesting issue I ran into with the last couple SVN builds including the latest one: I'm using MinGW 4.7.1 with the stock GDB that comes with it (also v4.7.1). Whenever I try to debug a program that features std::string in it, if I watch a std::string object, the value is never shown correctly, and if I hover the mouse over it with the "show value" mode turned on (don't remember what this option is actually called), a SIGSEGV message will pop up. Amazingly enough this only seems to happen for strings, std::vector<int>, for instance, is shown just fine, as are all the built-in types, such as int or float. Is it something I'm doing wrong or is it something wrong with C::B? :\
Agetian:
Have your string variables being initialized?
Do you have python enabled gdb or non-python gdb?
Have you installed any pretty printers?
Can you post the full log from the debugger? (you have to enabled full logging)
Quote from: oBFusCATed on August 26, 2012, 08:41:09 PM
Agetian:
Have your string variables being initialized?
Do you have python enabled gdb or non-python gdb?
Have you installed any pretty printers?
Can you post the full log from the debugger? (you have to enabled full logging)
1) Yes, the string variables are initialized. This is easily tested even on a simple "std::string s = "Test";" line.
2) I believe it's a Python-enabled gdb (it references python27.dll), but I'm not sure how to tell you with bigger degree of certainty.
3) No, at least not that I'm aware of it - nothing out of the ordinary, just stock C::B SVN and stock MinGW/GDB, with whatever configuration they both came with. If you're interested, MinGW 4.7.1 came from this source: http://sourceforge.net/projects/mingwbuilds/
4) Sure thing, I think this is what you meant about full log, but if I'm wrong, please tell me where to obtain the correct thing:
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: D:\cppclasstest\
Adding source dir: D:\cppclasstest\
Adding file: D:\cppclasstest\bin\Debug\cppclasstest.exe
Changing directory to: D:/cppclasstest/.
[debug]PATH=.;D:\mingw-4.7.1\bin;D:\mingw-4.7.1;C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Windows Live\Shared;D:\mingw-TDD-4.6.1\bin;C:\Program Files\Calibre2;C:\D\dmd\windows\bin;C:\D\dmd2\windows\bin;C:\D\dm\bin;C:\Program Files\TortoiseSVN\bin
[debug]Command-line: D:\mingw-4.7.1\bin\gdb.exe -nx -fullname -quiet -args D:/cppclasstest/bin/Debug/cppclasstest.exe
[debug]Working dir : D:\cppclasstest
Starting debugger: D:\mingw-4.7.1\bin\gdb.exe -nx -fullname -quiet -args D:/cppclasstest/bin/Debug/cppclasstest.exe
done
[debug]> set prompt >>>>>>cb_gdb:
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
[debug]Reading symbols from D:/cppclasstest/bin/Debug/cppclasstest.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.4.1
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-w64-mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.4.1
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source D:\CB_Portable\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory D:/cppclasstest/
[debug]>>>>>>cb_gdb:
[debug]> break "D:/cppclasstest/main.cpp:15"
[debug]Breakpoint 2 at 0x401394: file D:\cppclasstest\main.cpp, line 15.
[debug]>>>>>>cb_gdb:
[debug]> run
Child process PID: 3968
[debug][New Thread 3968.0x16a4]
[debug]Breakpoint 2, main () at D:\cppclasstest\main.cpp:15
[debug]D:\cppclasstest\main.cpp:15:188:beg:0x401394
[debug]>>>>>>cb_gdb:
At D:\cppclasstest\main.cpp:15
[debug]> bt 30
[debug]#0 main () at D:\cppclasstest\main.cpp:15
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]D:\cppclasstest\main.cpp:17:214:beg:0x4013c3
[debug]>>>>>>cb_gdb:
At D:\cppclasstest\main.cpp:17
[debug]> bt 30
[debug]#0 main () at D:\cppclasstest\main.cpp:17
[debug]>>>>>>cb_gdb:
[debug]> whatis s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output &s
[debug](std::string *) 0x22fef0>>>>>>cb_gdb:
[debug]> output s.c_str()[0]@s.size()
[debug]The program being debugged was signaled while in a function called from GDB.
[debug]GDB has restored the context to what it was before the call.
[debug]To change this behavior use "set unwindonsignal off".
[debug]Evaluation of the expression containing the function
[debug](std::string::size() const) will be abandoned.
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x00412f42 in std::string::size() const ()
[debug]>>>>>>cb_gdb:
Program received signal SIGSEGV, Segmentation fault.
In std::string::size() const () ()
[debug]> whatis s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output s.c_str()[0]@s.size()
[debug]The program being debugged was signaled while in a function called from GDB.
[debug]GDB has restored the context to what it was before the call.
[debug]To change this behavior use "set unwindonsignal off".
[debug]Evaluation of the expression containing the function
[debug](std::string::size() const) will be abandoned.
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x00412f42 in std::string::size() const ()
[debug]>>>>>>cb_gdb:
[debug]> bt 30
Program received signal SIGSEGV, Segmentation fault.
[debug]> bt 30
[debug]#0 main () at D:\cppclasstest\main.cpp:17
[debug]>>>>>>cb_gdb:#0 main () at D:\cppclasstest\main.cpp:17
[debug]>>>>>>cb_gdb:
This was done with a breakpoint set on a line that said:
std::string s = "Test";
I used the "Next line (F7)" command to go over this line to ensure that "s" was initialized, and then hovered the mouse over s to get its value, upon which it segfaulted.
Putting a breakpoint on the initialization line is not a good idea.
Can you try to put a breakpoint only on the next line?
Also can you disable the watch scripts and post the log again?
Another thing to try is to execute the commands: "p s.size()" and "p s.c_str()" in the debug log window.
Quote from: oBFusCATed on August 27, 2012, 09:20:23 AM
Putting a breakpoint on the initialization line is not a good idea.
Can you try to put a breakpoint only on the next line?
Also can you disable the watch scripts and post the log again?
Another thing to try is to execute the commands: "p s.size()" and "p s.c_str()" in the debug log window.
Putting a breakpoint on the next line remedies the segfault but still doesn't resolve the problem completely:
With the watch scripts disabled, no segfault occurs and the proper value is shown when I hover the mouse over "s", but doing "p s.c_str()" and "p s.size()" both yield a strange outcome in the form of the message "Cannot evaluate function - may be inlined". Here's the full output:
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: D:\cppclasstest\
Adding source dir: D:\cppclasstest\
Adding file: D:\cppclasstest\bin\Debug\cppclasstest.exe
Changing directory to: D:/cppclasstest/.
[debug]PATH=.;D:\MinGW-4.7.1\bin;D:\MinGW-4.7.1;C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Windows Live\Shared;D:\MinGW-TDD-4.6.1\bin;C:\Program Files\Calibre2;C:\D\dmd\windows\bin;C:\D\dmd2\windows\bin;C:\D\dm\bin;C:\Program Files\TortoiseSVN\bin
[debug]Command-line: D:\MinGW-4.7.1\bin\gdb.exe -nx -fullname -quiet -args D:/cppclasstest/bin/Debug/cppclasstest.exe
[debug]Working dir : D:\cppclasstest
Starting debugger: D:\MinGW-4.7.1\bin\gdb.exe -nx -fullname -quiet -args D:/cppclasstest/bin/Debug/cppclasstest.exe
done
[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!
Setting breakpoints
[debug]Reading symbols from D:/cppclasstest/bin/Debug/cppclasstest.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.4.1
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-w64-mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.4.1
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> directory D:/cppclasstest/
[debug]>>>>>>cb_gdb:
[debug]> break "D:/cppclasstest/main.cpp:17"
[debug]Breakpoint 2 at 0x401638: file D:\cppclasstest\main.cpp, line 17.
[debug]>>>>>>cb_gdb:
[debug]> run
Child process PID: 4036
[debug][New Thread 4036.0x548]
[debug]Breakpoint 2, main () at D:\cppclasstest\main.cpp:17
[debug]D:\cppclasstest\main.cpp:17:214:beg:0x401638
[debug]>>>>>>cb_gdb:
At D:\cppclasstest\main.cpp:17
[debug]> bt 30
[debug]#0 main () at D:\cppclasstest\main.cpp:17
[debug]>>>>>>cb_gdb:
> p s.c_str()
[debug]> p s.c_str()
[debug]Cannot evaluate function -- may be inlined
[debug]>>>>>>cb_gdb:
Cannot evaluate function -- may be inlined
Cannot evaluate function -- may be inlined
> p s.size()
[debug]> p s.size()
[debug]Cannot evaluate function -- may be inlined
[debug]>>>>>>cb_gdb:
Cannot evaluate function -- may be inlined
Cannot evaluate function -- may be inlined
With the watch scripts enabled, the same thing happens with both "p s.size()" and "p s.c_str()" but also the proper value is not shown in the watch window or when hovering the mouse over "s" - instead, the message "Cannot evaluate function -- may be inlined" also shows up in the watch window. Here's the full output with watch scripts enabled:
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: D:\cppclasstest\
Adding source dir: D:\cppclasstest\
Adding file: D:\cppclasstest\bin\Debug\cppclasstest.exe
Changing directory to: D:/cppclasstest/.
[debug]PATH=.;D:\MinGW-4.7.1\bin;D:\MinGW-4.7.1;C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Windows Live\Shared;D:\MinGW-TDD-4.6.1\bin;C:\Program Files\Calibre2;C:\D\dmd\windows\bin;C:\D\dmd2\windows\bin;C:\D\dm\bin;C:\Program Files\TortoiseSVN\bin
[debug]Command-line: D:\MinGW-4.7.1\bin\gdb.exe -nx -fullname -quiet -args D:/cppclasstest/bin/Debug/cppclasstest.exe
[debug]Working dir : D:\cppclasstest
Starting debugger: D:\MinGW-4.7.1\bin\gdb.exe -nx -fullname -quiet -args D:/cppclasstest/bin/Debug/cppclasstest.exe
done
[debug]> set prompt >>>>>>cb_gdb:
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
[debug]Reading symbols from D:/cppclasstest/bin/Debug/cppclasstest.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.4.1
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-w64-mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.4.1
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source D:\CB_Portable\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory D:/cppclasstest/
[debug]>>>>>>cb_gdb:
[debug]> break "D:/cppclasstest/main.cpp:17"
[debug]Breakpoint 2 at 0x401638: file D:\cppclasstest\main.cpp, line 17.
[debug]>>>>>>cb_gdb:
[debug]> run
Child process PID: 4380
[debug][New Thread 4380.0x11b0]
[debug]Breakpoint 2, main () at D:\cppclasstest\main.cpp:17
[debug]D:\cppclasstest\main.cpp:17:214:beg:0x401638
[debug]>>>>>>cb_gdb:
At D:\cppclasstest\main.cpp:17
[debug]> bt 30
[debug]#0 main () at D:\cppclasstest\main.cpp:17
[debug]>>>>>>cb_gdb:
[debug]> whatis s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output &s
[debug](std::string *) 0x22fe80>>>>>>cb_gdb:
[debug]> output s.c_str()[0]@s.size()
[debug]Cannot evaluate function -- may be inlined
[debug]>>>>>>cb_gdb:
Cannot evaluate function -- may be inlined
> p s.c_str()
[debug]> p s.c_str()
[debug]Cannot evaluate function -- may be inlined
[debug]>>>>>>cb_gdb:
Cannot evaluate function -- may be inlined
Cannot evaluate function -- may be inlined
> p s.size()
[debug]> p s.size()
[debug]Cannot evaluate function -- may be inlined
[debug]>>>>>>cb_gdb:
Cannot evaluate function -- may be inlined
Hope this helps.
@Agetian (http://forums.next.codeblocks.org/index.php?action=profile;u=30592), I think it is a gdb bug or gcc bug, as you can see, print a value/expression does not work under the command line.
Quote from: ollydbg on August 27, 2012, 03:22:42 PM
@Agetian (http://forums.next.codeblocks.org/index.php?action=profile;u=30592), I think it is a gdb bug or gcc bug, as you can see, print a value/expression does not work under the command line.
Yeah, it might as well be - I'll retry with some older revisions of MinGW (I have old binaries for 4.5 and 4.6 series) and see if that solves the issue, I'll keep you posted. Thanks!
EDIT: Yeah, definitely works after reverting to MinGW v4.6.1 - so, could be related to some gdb bug in the 4.7 series. Looks like this is not C::B-related.
Quote from: Agetian on August 27, 2012, 03:57:42 PM
Quote from: ollydbg on August 27, 2012, 03:22:42 PM
@Agetian (http://forums.next.codeblocks.org/index.php?action=profile;u=30592), I think it is a gdb bug or gcc bug, as you can see, print a value/expression does not work under the command line.
Yeah, it might as well be - I'll retry with some older revisions of MinGW (I have old binaries for 4.5 and 4.6 series) and see if that solves the issue, I'll keep you posted. Thanks!
EDIT: Yeah, definitely works after reverting to MinGW v4.6.1 - so, could be related to some gdb bug in the 4.7 series. Looks like this is not C::B-related.
Can you provide your project (maybe put it on some web space)?
I will look into the issue to see whether its related with gcc/gdb.
Quote from: xunxun on August 27, 2012, 04:20:36 PM
Quote from: Agetian on August 27, 2012, 03:57:42 PM
Quote from: ollydbg on August 27, 2012, 03:22:42 PM
@Agetian (http://forums.next.codeblocks.org/index.php?action=profile;u=30592), I think it is a gdb bug or gcc bug, as you can see, print a value/expression does not work under the command line.
Yeah, it might as well be - I'll retry with some older revisions of MinGW (I have old binaries for 4.5 and 4.6 series) and see if that solves the issue, I'll keep you posted. Thanks!
EDIT: Yeah, definitely works after reverting to MinGW v4.6.1 - so, could be related to some gdb bug in the 4.7 series. Looks like this is not C::B-related.
Can you provide your project (maybe put it on some web space)?
I will look into the issue to see whether its related with gcc/gdb.
Sure thing, it's really a very simple test though, the entire test project that works as a test case consists of one file which is as follows:
#include <iostream>
using namespace std;
int main()
{
string s = "Test";
cout << s << endl;
return 0;
}
The breakpoint is set on the "cout << s << endl" line. I think it most surely is a gcc/gdb/mingw issue though, cause 4.6.1 works fine and 4.7.1 doesn't. I have, in addition to everything else, made double sure that I'm generating debugging symbols and that no optimizations are set, so it looks like a bug in gcc/gdb... Thanks for your desire to look into it!
Hello. Thank you for next nightly. I have a little bug in Settings->Editor...->BrowseTracker (on the picture bellow). Please can someone verify it? Thanks :)
[attachment deleted by admin]
Quote from: OsminohejTygr on August 27, 2012, 09:39:01 PM
I have a little bug in Settings->Editor...->BrowseTracker (on the picture bellow). Please can someone verify it?
I haven't such bug in my C::B installation.
Quote from: OsminohejTygr on August 27, 2012, 09:39:01 PM
Hello. Thank you for next nightly. I have a little bug in Settings->Editor...->BrowseTracker (on the picture bellow). Please can someone verify it? Thanks :)
Fixed: svn 8252
Thanks for the report.
greetings everyone.
I have built svn-8251, and when I right-click on a Headers / Sources sub-folder in Manager to remove files, it crashes.
Below you can find as an attachment the crash report.
System Specs:
OS = Windows XP SP3 [32-bit]
Compiler: TDM's GCC (the latest available)
wxWidgets = 2.8.10
Quote from: Agetian on August 27, 2012, 04:29:34 PM
Quote from: xunxun on August 27, 2012, 04:20:36 PM
Quote from: Agetian on August 27, 2012, 03:57:42 PM
Quote from: ollydbg on August 27, 2012, 03:22:42 PM
@Agetian (http://forums.next.codeblocks.org/index.php?action=profile;u=30592), I think it is a gdb bug or gcc bug, as you can see, print a value/expression does not work under the command line.
Yeah, it might as well be - I'll retry with some older revisions of MinGW (I have old binaries for 4.5 and 4.6 series) and see if that solves the issue, I'll keep you posted. Thanks!
EDIT: Yeah, definitely works after reverting to MinGW v4.6.1 - so, could be related to some gdb bug in the 4.7 series. Looks like this is not C::B-related.
Can you provide your project (maybe put it on some web space)?
I will look into the issue to see whether its related with gcc/gdb.
Sure thing, it's really a very simple test though, the entire test project that works as a test case consists of one file which is as follows:
#include <iostream>
using namespace std;
int main()
{
string s = "Test";
cout << s << endl;
return 0;
}
The breakpoint is set on the "cout << s << endl" line. I think it most surely is a gcc/gdb/mingw issue though, cause 4.6.1 works fine and 4.7.1 doesn't. I have, in addition to everything else, made double sure that I'm generating debugging symbols and that no optimizations are set, so it looks like a bug in gcc/gdb... Thanks for your desire to look into it!
I think it's a gdb issue, and I will test it on Linux or ask gdb mail list.
@Agetian: I debug your code on linux, and everything was fine (gdb 7.4, gcc 4.7). I see you have two compilers paths in your PATH variable, please make sure that you use correct one (did you disable all optimizations? ), and rebuild project.
-----
I have other problem with debugger. I changed terminal emulator from xterm to xfce-terminal, here's how c::b invoke it: "terminal -T $TITLE -x" (no quotes). I can run console project and it works fine, but when I start debugging gdb can't open terminal:
Quote
[debug]>>>>>>cb_gdb:
Can't launch console (terminal -T 'Program Console' -x sleep 80001818)
[debug]> run
[debug]Hello Test
"Hello Test" is output from my application.
How can I check how debugger invokes terminal?
Quote from: p2rkw on August 30, 2012, 12:17:39 AM
@Agetian: I debug your code on linux, and everything was fine (gdb 7.4, gcc 4.7). I see you have two compilers paths in your PATH variable, please make sure that you use correct one (did you disable all optimizations? ), and rebuild project.
I took the old compiler out of the path and made sure everything was correct as far as disabling optimizations go (and enabling debugging symbols), as well as cleaned and rebuilt the project afterwards, but it still doesn't work correctly with v4.7.1 - however, it looks like for some reason, that the mingw version I'm using doesn't produce enough debug information - I don't know why, I'm not that great with gcc/gdb yet, but the file size generated with the v4.7.1 build I'm using is only 90kb (in debug mode with -g and with no optimizations flags set), while switching back to v4.6.1 makes it bigger than a megabyte. :\ The options are exactly the same, -g is set and none of the -O or other optimization flags is set. Thanks for your desire to help!
To whom it may concern, on my Linux Debian wheezy machine I had to modify two files, Makefile.am and configure.in to make it compile.
Makefile.am
--- /svn_code/CodeBlocks/Makefile.am (revision 8281)
+++ /svn_code/CodeBlocks/Makefile.am (working copy)
@@ -12,6 +12,8 @@
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = codeblocks.pc
+ACLOCAL_AMFLAGS = -I m4
+
EXTRA_DIST = $(top_srcdir)/bootstrap \
codeblocks.spec \
codeblocks.plist \
configure.in
Index: /home/stefanos/svn_code/CodeBlocks/configure.in
===================================================================
--- /svn_code/CodeBlocks/configure.in (revision 8281)
+++ /svn_code/CodeBlocks/configure.in (working copy)
@@ -7,6 +7,9 @@
AC_CANONICAL_TARGET
AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip])
+
+AC_CONFIG_MACRO_DIR([m4])
+
AC_CONFIG_HEADER([src/include/config.h])
CODEBLOCKS_CHECK_DEBUG
Jens, I think was with you I had a conversation about it in a nightly version?
#include <iostream>
using namespace std;
int main()
{
string s = "Test";
cout << s << endl;
return 0;
}
Regarding this, I'm also using MinGWBuilds 4.7.1 32-bit building (http://sourceforge.net/projects/mingwbuilds/) with Code::Blocks 8248. I entered the above code, set a breakpoint on "return 0" Tried a watch on the variable "s" and I got the message: "Cannot evaluate function -- may be inlined" No crashes, I can resume the debugger and program after attempting to check the s variable. Other variables, like int x, I can get the proper values out of. Tried putting a "#include <string>" at the beginning of the file, tried initializing the string like "string s("Test");", no dice.
Currently successfully compiled Code::Blocks 2.9.x, SVN-8299 on Windows XP SP3 with TDM's GCC latest version available.
Unfortunately though it crashes as soon as you call it. You can see from the attached photo the reason of crash.
Quote from: stefanos_ on August 31, 2012, 10:06:24 AM
Currently successfully compiled Code::Blocks 2.9.x, SVN-8299 on Windows XP SP3 with TDM's GCC latest version available.
Unfortunately though it crashes as soon as you call it. You can see from the attached photo the reason of crash.
Continue should work here without crashing.
wx2.9 spreads tons of debug-messages.
I know theses isssues and work on fixing them.
Btw:
please report issues in the new thread I started, not in the nightlies thread.
http://forums.next.codeblocks.org/index.php/topic,16793.msg114135.html#msg114135 (http://forums.next.codeblocks.org/index.php/topic,16793.msg114135.html#msg114135)
The contrib-plugins are compilable with wx2.9, but do not (all) work without errors.
Quote from: stefanos_ on August 30, 2012, 10:15:05 PM
To whom it may concern, on my Linux Debian wheezy machine I had to modify two files, Makefile.am and configure.in to make it compile.
[...]
Jens, I think was with you I had a conversation about it in a nightly version?
I wonder why you can not compile.
I get warnings because of this, but it works flawlessly.
The cause for not changing these files is the compatibility.
If I remember correctly it breaks building (or better bootstrapping) on some distros.
Tonight I will attempt to install the latest 2.9.x svn on wheezy with the original files and I will let you know for what will complain.
Quote from: jens on August 31, 2012, 10:23:40 AM
Continue should work here without crashing.
wx2.9 spreads tons of debug-messages.
I know theses isssues and work on fixing them.
Btw:
please report issues in the new thread I started, not in the nightlies thread.
http://forums.next.codeblocks.org/index.php/topic,16793.msg114135.html#msg114135 (http://forums.next.codeblocks.org/index.php/topic,16793.msg114135.html#msg114135)
The contrib-plugins are compilable with wx2.9, but do not (all) work without errors.
Well, even if I press "Yes", "No", "Cancel", it will crash and would ask me to send report. I guess I have to wait until it stabilizes a bit with its current development.
I have download this edition, but when I run the program which has been built already at the first time, it will cost nearly 3s to output "hello world".
is there anything wrong in my installation or it's just like this?
my system is WINXP without cygwin.
install the three elements involved above.
@jens: I have compiled svn-8322 on Debian wheezy (32-bit) and crashed upon closing a project. I did not compile it with 2.9.x as I said I would, but decided to do the standard compilation process for now. I have attached the crash report and i hope it helps a bit.
Quote from: stefanos_ on September 01, 2012, 03:07:48 PM
@jens: I have compiled svn-8322 on Debian wheezy (32-bit) and crashed upon closing a project. I did not compile it with 2.9.x as I said I would, but decided to do the standard compilation process for now. I have attached the crash report and i hope it helps a bit.
I see no stack info in the crash report. :)
well, whatever the system generated, i copied it and pasted it in a .txt file and attached it here. also, as i have already stated in a previous comment, when Code::Blocks is crashing on a UNIX-like environment, it would be nice to let user save the report somewhere and not place it in tmp directory which gets deleted upon Code::Blocks's closing.
It sounds silly isn't it? Strange, but now I see a generated folder with dbgrpt name and timestamp that has the codeblocks.xml file in it.
Quote from: stefanos_ on August 29, 2012, 07:47:30 AM
greetings everyone.
I have built svn-8251, and when I right-click on a Headers / Sources sub-folder in Manager to remove files, it crashes.
Below you can find as an attachment the crash report.
System Specs:
OS = Windows XP SP3 [32-bit]
Compiler: TDM's GCC (the latest available)
wxWidgets = 2.8.10
I'm not sure which c::b did you run? To catch the bug, I suggest you can run the c::b under devel folder, because it has debug information there, so when it crashes, it will have file and line info in the backtrace report. :)
Quote from: Agetian on August 27, 2012, 04:29:34 PM
Sure thing, it's really a very simple test though, the entire test project that works as a test case consists of one file which is as follows:
#include <iostream>
using namespace std;
int main()
{
string s = "Test";
cout << s << endl;
return 0;
}
The breakpoint is set on the "cout << s << endl" line. I think it most surely is a gcc/gdb/mingw issue though, cause 4.6.1 works fine and 4.7.1 doesn't. I have, in addition to everything else, made double sure that I'm generating debugging symbols and that no optimizations are set, so it looks like a bug in gcc/gdb... Thanks for your desire to look into it!
I found the reason from gdb IRC, see below:
Quote
ollydbg I have a problem under windows: gcc 4.7.x gdb-cvs, when try to show a std::string, I enter the command: output s.c_str(), but gdb response: Cannot evaluate function -- may be inlined
ollydbg what cause this kind of problem? thanks
ollydbg For the record, if gcc 4.6.x does not have such issue.
jankratochvil Try to use this function in the program, be sure to use -O0 -g (and not -O2 -g) and try -fkeep-inline-functions.
ollydbg OK, I will try this soon
ollydbg Hi, jan, thanks, it works.
ollydbg In-fact, I'm forum Code::blocks forum, we use such script to show the std::string value: output s.c_str()[0]@s.size()
ollydbg But, if the user does not expicit call the c_str() and size() in there code, gdb will report failure in running such script.
ollydbg That's strange, does gcc changed something?
ollydbg BTW: If I enable the python pretty printer, then I have no such issue, the str::string's content shown correctly either under gcc 4.7.x or gcc 4.6.x
jankratochvil Newer gcc has more optimizations, it has the right to do these optimizations. And sure Pretty Printers do not depend on inferior function calls, so that Pretty Printers can work also on core files.
ollydbg Ok, thanks, I will forward your explanation to Code::blocks forum, many thanks.
ollydbg So, it looks like gdb pretty-printer is the most suggest way to show std::string like contents, other gdb script are not suggest because they will cause such issue.
So, I suggest you can use
gdb python pretty printer to show the value,
they work OK with gcc 4.6.x and 4.7.x.
Quote from: ollydbg on September 01, 2012, 03:40:00 PM
Quote from: stefanos_ on August 29, 2012, 07:47:30 AM
greetings everyone.
I have built svn-8251, and when I right-click on a Headers / Sources sub-folder in Manager to remove files, it crashes.
Below you can find as an attachment the crash report.
System Specs:
OS = Windows XP SP3 [32-bit]
Compiler: TDM's GCC (the latest available)
wxWidgets = 2.8.10
I'm not sure which c::b did you run? To catch the bug, I suggest you can run the c::b under devel folder, because it has debug information there, so when it crashes, it will have file and line info in the backtrace report. :)
ollydbg you must have confused my posts :) you commented for Debian wheezy issue on my Windows XP's post :D anyhow, i will try your suggestion on Monday when I will get back to work for I use Debian at home exclusively.
Quote from: ollydbg on September 01, 2012, 04:37:21 PM
I found the reason from gdb IRC, see below:
Quote
ollydbg I have a problem under windows: gcc 4.7.x gdb-cvs, when try to show a std::string, I enter the command: output s.c_str(), but gdb response: Cannot evaluate function -- may be inlined
ollydbg what cause this kind of problem? thanks
ollydbg For the record, if gcc 4.6.x does not have such issue.
jankratochvil Try to use this function in the program, be sure to use -O0 -g (and not -O2 -g) and try -fkeep-inline-functions.
ollydbg OK, I will try this soon
ollydbg Hi, jan, thanks, it works.
ollydbg In-fact, I'm forum Code::blocks forum, we use such script to show the std::string value: output s.c_str()[0]@s.size()
ollydbg But, if the user does not expicit call the c_str() and size() in there code, gdb will report failure in running such script.
ollydbg That's strange, does gcc changed something?
ollydbg BTW: If I enable the python pretty printer, then I have no such issue, the str::string's content shown correctly either under gcc 4.7.x or gcc 4.6.x
jankratochvil Newer gcc has more optimizations, it has the right to do these optimizations. And sure Pretty Printers do not depend on inferior function calls, so that Pretty Printers can work also on core files.
ollydbg Ok, thanks, I will forward your explanation to Code::blocks forum, many thanks.
ollydbg So, it looks like gdb pretty-printer is the most suggest way to show std::string like contents, other gdb script are not suggest because they will cause such issue.
So, I suggest you can use gdb python pretty printer to show the value, they work OK with gcc 4.6.x and 4.7.x.
Oh, thanks a lot for sorting this out, I'll try it out!
EDIT: Tried this out and it works perfectly! Thanks again! :)
new awkward situation with svn-8322, Debian wheezy. On "Logs & Others", I right-clicked on a line from "Build Messages", select one of the options, or press the escape button, click anywhere with the mouse, it re-pops up the . Is that behavior normal? No it's not :)
Quote from: stefanos_ on September 01, 2012, 10:34:07 PM
new awkward situation with svn-8322, Debian wheezy. On "Logs & Others", I right-clicked on a line from "Build Messages", select one of the options, or press the escape button, click anywhere with the mouse, it re-pops up the . Is that behavior normal? No it's not :)
It is not normal, but it is not a new problem.
Quote from: stefanos_ on September 01, 2012, 10:34:07 PM
new awkward situation with svn-8322, Debian wheezy.
This seems a Linux only problem. On Windows it works as expected. Maybe a wx issue, not a C::B one.
When I ran the cppcheck plugin, the results showed the too many #ifdef message. Where is it I go to configure the plugin as it is used in C::B?
Quote from: raynebc on September 04, 2012, 02:59:30 AM
Where is it I go to configure the plugin as it is used in C::B?
Settings -> Environment -> CppCheck.
If that is not available for you, you need a more recent / next nightly. This was added just recently.
Thank you, I was able to find it and configured it to suppress some checks I don't care about.
Since a few nightlies ago (I'm not sure how long this has been present) processing of #if statements appears to be inverted when using equality.
The following works fine:
#if 0
dont_do_this();
#endif
But the following highlights the code not being compiled:
#define OPT1 1
#define OPT2 2
#define OPTION OPT1
#if OPTION == OPT1
option1();
#else
dont_process_me();
#endif
On Windows XP SP3 - SVN 8248 (This nightly)
Hopefully it's a quick fix. Thanks for keeping up the good work guys, I'm using Code::Blocks every day at work for some decent size codebases. Thanks! :D
Any one see this kind of problem? (vertical horizontal scroll bar does not shown correctly)
see image below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-09-06212507.png)
Hello,
I have the Aug 25 8248 build, when debugging Watch window does not show Local Variables and Function Parameters. Both are set in Debugger->Default by default and greyed out so it's not even possible to clear these settings.
How to enable those?
Thanks.
Edit: I am on Ubuntu.
const451: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#In_latest_nightly_builds
> The automatic inclusion of local variables and function arguments have not being reimplemented.
That's inconvenient. I hope it will be added back.
where is the vertical scrolled bar?I can't see it in your image!
Quote from: havefun on September 10, 2012, 10:35:49 AM
where is the vertical scrolled bar?I can't see it in your image!
Sorry, this is a mistake, should be "horizontal scroll bar".
Why do not we use mingbuilds instead of TDM ?
mingwbuilds (NOT official ming) : http://sourceforge.net/projects/mingwbuilds/reviews/
with mingwbuilds , we can try out all the C++11 features in this release of g++.
nanyu: Who stops you to install mingw instead of TDM?
Quote from: nanyu on September 15, 2012, 11:36:15 AM
Why do not we use mingbuilds instead of TDM ?
mingwbuilds (NOT official ming) : http://sourceforge.net/projects/mingwbuilds/reviews/
with mingwbuilds , we can try out all the C++11 features in this release of g++.
I use mingwbuilds
with c::b. And you can. Just do it. :) But there are no any profit
to build c::b with mingwbuilds now: mingwbuilds uses sjlj exceptions.
Quote from: nenin on September 15, 2012, 04:07:56 PM
Quote from: nanyu on September 15, 2012, 11:36:15 AM
Why do not we use mingbuilds instead of TDM ?
mingwbuilds (NOT official ming) : http://sourceforge.net/projects/mingwbuilds/reviews/
with mingwbuilds , we can try out all the C++11 features in this release of g++.
I use mingwbuilds with c::b. And you can. Just do it. :) But there are no any profit to build c::b with mingwbuilds now: mingwbuilds uses sjlj exceptions.
but c::b build with TDM uses sjlj exceptions also?
C::B becomes unresponsive, when watching big data structure on a debug session.
It has been an issue since the new debuggers branch merged into the C::B code base.
referring to
http://forums.next.codeblocks.org/index.php/topic,16868.0.html
Quote from: nanyu on September 15, 2012, 11:36:15 AM
Why do not we use mingbuilds instead of TDM ?
mingwbuilds (NOT official ming) : http://sourceforge.net/projects/mingwbuilds/reviews/
with mingwbuilds , we can try out all the C++11 features in this release of g++.
jaj C++11 (not sarcastic, sincere joy)
I am not sure if this is new or not, but I feel the need to share.
In debug watches window, a numeric array is shown like this:
array
[0] 1 <repeats 23 times>
[1] 5
[2] 3 <repeats 4 times>
On strings this is useful, but on numeric arrays it might be a little bit confusing.
And in the debug watches window, if you want to rename a variable, you will see that the selection is not highlighted.
grooveordie:
What version of GDB is this?
I doubt it can be done anything about it, unfortunately.
About the second issue, yes this is a know issue and it is an issue of wxPropertyGrid, we are using for the watches.
When I was implementing the new watches, I've mentioned this issue to the creator of wxPropGrid and he said we will
see what can be done. But I think he is now missing. wxPropertyGrid is now merge inside wx2.9,
but I've not tried to use C::B compiled against wx2.9, so I don't know if this has been fixed there.
GDB version 7.5. It is not a big problem, or not a problem at all but it would be useful to see [24] instead of [1] in the example i think.
Excuse me for re-mentioning a known issue, I didn't have time to check before.
Quote from: oBFusCATed on September 26, 2012, 09:28:57 PM
grooveordie:
What version of GDB is this?
I doubt it can be done anything about it, unfortunately.
About the second issue, yes this is a know issue and it is an issue of wxPropertyGrid, we are using for the watches.
When I was implementing the new watches, I've mentioned this issue to the creator of wxPropGrid and he said we will
see what can be done. But I think he is now missing. wxPropertyGrid is now merge inside wx2.9,
but I've not tried to use C::B compiled against wx2.9, so I don't know if this has been fixed there.
Quote from: grooveordie on September 27, 2012, 08:59:13 AM
GDB version 7.5. It is not a big problem, or not a problem at all but it would be useful to see [24] instead of [1] in the example i think.
This is doable probably, but I don't want to waste time with it as I'm re-writing the debugger plugin to use the more IDE friendly GDB/MI interface.
So I suppose this will be a non-issue there.
Quote from: grooveordie on September 27, 2012, 08:59:13 AM
Excuse me for re-mentioning a known issue, I didn't have time to check before.
No problem, if you have time/desire you can post it in the bug tracker at berlios.de, so it won't be forgotten as it is not written anywhere.