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://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc481-TDM.7z
The 27 October 2014 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2014/CB_20141027_rev10016_win32.7z
- Linux :
none
Resolved Fixed:
- CC: handle the "__declspec" qualifier when parsing the class definition, this qualifier is skipped as the same way as handling "__attribute__" qualifier.
- improve command line handling so plugins can receive commands from the command line
- SpellChecker-plugin: activate OnlineSpellChecking for VHDL block comments and strings and for verilog strings
- fix an issue with the new editorpane-layout saving/restoring, where the layout was not recreated, when the default workspace was automatically opened on application startup.
- DoxyBlocks: strip default menu keybindings that conflict core C::B shortcuts
- better build fix for the build fix for the build fix ....; some distributions (at least debian) have backported the fix to pre wx2.9.0, the wx2.8.12 tag in wxWidgets svn-repo still uses the macro without the "WX_"-prefix
- CC: fix a bug that CodeCompletion's setting don't get saved when C::B closed
- pumped (wx)Scintilla to v3.5.1 (bringing support for BibTeX lexer)
- update of astyle to v2.05
- CC: fix handling of conditional preprocessor directives.
Enhance IsMacroDefined() function, it can handle both "defined (xxx)" and "defined xxx" directives - CC: handling __declspec (xxx) in ParserThread::DoParse() function. Move handling __attribute__ keyword to the switch case statements.
- lexer: added BibTex lexer configuration files
- editor: Add menu commands for searching the selected text without opening the find-replace dialog
Regressions/Confirmed/Annoying/Common bugs:
No update of Fedora or Dedbian packages possible until end of next week, sorry.
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
Quote from: arprog on October 28, 2014, 05:36:48 PM
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)
Is it a "custom makefile" project or a normal CB project?
What version of CMake?
Edit2: What compiler is the project using?
Edit: Do you have "interpret #if, #else ..." checked?
From EditorManager::CollectDefines function in editormanager.cpp;
The function appears to require then both to be checked.
Tim S.
Quote from: stahta01 on October 28, 2014, 06:32:55 PM
Quote from: arprog on October 28, 2014, 05:36:48 PM
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)
Is it a "custom makefile" project or a normal CB project?
What version of CMake?
Edit2: What compiler is the project using?
Edit: Do you have "interpret #if, #else ..." checked?
From EditorManager::CollectDefines function in editormanager.cpp;
The function appears to require then both to be checked.
Tim S.
"interpret #if, #else ..." checked
cmake 3.0.2
mingw-w64 4.9.1
cmd: cmake -G "CodeBlocks - MinGW Makefiles"
cmake generates custom makefile project
Quote from: arprog on October 28, 2014, 10:27:39 PM
Quote from: stahta01 on October 28, 2014, 06:32:55 PM
Quote from: arprog on October 28, 2014, 05:36:48 PM
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)
Is it a "custom makefile" project or a normal CB project?
What version of CMake?
Edit2: What compiler is the project using?
Edit: Do you have "interpret #if, #else ..." checked?
From EditorManager::CollectDefines function in editormanager.cpp;
The function appears to require then both to be checked.
Tim S.
"interpret #if, #else ..." checked
cmake 3.0.2
mingw-w64 4.9.1
cmd: cmake -G "CodeBlocks - MinGW Makefiles"
cmake generates custom makefile project
FYI: Code::Blocks does NOT look into the makefile when a custom makefile is used; it only looks at the setting in the cbp file.
But, if you disable the "custom makefile" for a short time and add the defines to the correct target/project level.
Change it back to "custom makefile"; then change the project target to be built; it will grey in/out the blocks based on the defines in the CB Project. Note: It really ignores those defines in most other uses of building the project.
Tested using wxThings created project from wxCode.
cmake 3.0.2 Used the GUI tool.
Tim S.
In generated cbp, defines present...
Quote from: arprog on October 29, 2014, 03:00:23 PM
In generated cbp, defines present...
Start a new thread for your problem; and post a link to your cbp file.
Tim S.
I found!
By default selected virtual target "all", if i select my subproject works fine.
@ollydbg:
I've tried to upgrade to 10016, but there was a massive problem with code completion - it ran until it depleted all my memory (12g+4g swap)...
I've no time to debug why it breaks such badly, but reverting to 9990 fixed the problem... at least it didn't repeat the whole day.
Centos 6 64bit...
But I cant reproduce, I will check all the changed code.
Of course you won't be able to reproduce it, you need the special pattern of code that breaks it...
I don't know what breaks it and I doubt I have the time to find it.
I have a question that I want to install C::B to a Linux(ubuntu10.04 in virtualbox), I just follow the instruction here:
http://apt.jenslody.de/
As jens suggest ubuntu user should try pasgui's ppa (https://launchpad.net/~pasgui/+archive/ppa/). I have correctly configure the apt, like:Read about installing (https://launchpad.net/+help-soyuz/ppa-sources-list.html)
sudo add-apt-repository ppa:pasgui/ppa
and Then
sudo apt-get update
From Ubuntu10.04's synaptic package manager, I still see the old C::B 8.02 supply from the official ubuntu, but the nightly build version of pasgui does not shown up.
Any idea how to fix this issue? What is the minimal system requirement of pasgui's nightly build binaries? Thanks.
BTW: I have also try jens' repo before, but it has the same issue: I still don't see any nightly build version of C::B show in the synaptic package manager.
Do you see the nightly version with the search command or the like?
apt-cache search codeblocks
Quote from: ollydbg on October 31, 2014, 09:57:15 AM
From Ubuntu10.04's synaptic package manager, I still see the old C::B 8.02 supply from the official ubuntu, but the nightly build version of pasgui does not shown up.
That one only has builds for Ubuntu 14.04, try https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks (https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks) (and/or a newer version of Ubuntu).
@ollydbg:
I had the same problem with 9990.
It happens only if a specific project is selected in the workspace.
If another project is selected as default project the problem doesn't happen.
I've used only rev 9855 before 9990 and 10016.
Here is a backtrace (incomplete) when the problem happened
(gdb) bt
#0 0x00007f6a88222bd5 in TokenTree::TokenExists(wxString const&, int, short) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#1 0x00007f6a8821fd2b in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#2 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#3 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#4 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#5 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#6 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#7 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#8 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#9 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#10 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#11 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#12 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#13 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#14 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#15 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#16 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#17 0x00007f6a88222464 in Tokenizer::GetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#18 0x00007f6a88213899 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#19 0x00007f6a88216ec9 in ParserThread::HandleClass(ParserThread::EClassType) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#20 0x00007f6a88215a90 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#21 0x00007f6a8821a79e in ParserThread::Parse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#22 0x00007f6a88203769 in Parser::Parse(wxString const&, bool, bool) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#23 0x00007f6a8820d197 in ParserThread::HandleIncludes() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#24 0x00007f6a88216905 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#25 0x00007f6a8821a79e in ParserThread::Parse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#26 0x00007f6a88203769 in Parser::Parse(wxString const&, bool, bool) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#27 0x00007f6a8820d197 in ParserThread::HandleIncludes() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#28 0x00007f6a88216905 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#29 0x00007f6a8821a79e in ParserThread::Parse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#30 0x00007f6a8821b219 in ParserThread::Execute() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#31 0x00007f6aa06b1b35 in cbThreadPool::cbWorkerThread::Entry() () from /usr/lib64/libcodeblocks.so.0
#32 0x0000003073ae7021 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#33 0x00000030692079d1 in start_thread () from /lib64/libpthread.so.0
#34 0x0000003068ae886d in clone () from /lib64/libc.so.6
Another problem that is extremely annoying is that the value of the "Case sensitive matches" in the code completion settings is not save in the config file.
And I have to set it every time I start new instance of codeblocks.
Also why this is set to the non-obvious state on, I think this should be off by default.
Quote from: scarphin on October 31, 2014, 10:35:09 AM
Do you see the nightly version with the search command or the like?
apt-cache search codeblocks
Hi, thanks, here are the logs, but it looks like Alpha is correct, those binaries need a newer Ubuntu. Here is the failure log in Ubuntu10.04, I finally see the codeblocks nightly svn10016 in synaptic package manager, but installation get failed.
Quote
apt-cache search codeblocks
libcodeblocks0 - Code::Blocks shared libraries
codeblocks - Code::Blocks integrated development environment (IDE)
codeblocks-dbg - Code::Blocks debugging libraries
codeblocks-contrib - contrib plugins for Code::Blocks IDE
codeblocks-dev - Code::Blocks development libraries (SDK)
codeblocks-contrib-dbg - Debugging libraries for the Code::Blocks contrib plugins
codeblocks-common - common files for Code::Blocks IDE
codeblocks-contrib-common - common files for the contrib plugins for Code::Blocks IDE
codeblocks-headers - Code::Blocks development headers (SDK)
codeblocks-fr - French translation for codeblocks
codeblocks-wxcontrib-headers - Code::Blocks development headers for wxContribItems
codeblocks-libwxcontrib0 - Code::Blocks shared libraries for wxContribItems
codeblocks-wxcontrib-dev - Code::Blocks development libraries for wxContribItems
libpath-dispatcher-perl - flexible and extensible command-line dispatch for Perl programs
apt-cache showpkg codeblocks
Package: codeblocks
Versions:
13.12svn10016-0ubuntu1~trusty (/var/lib/apt/lists/ppa.launchpad.net_pasgui_ppa_ubuntu_dists_trusty_main_binary-i386_Packages)
Description Language:
File: /var/lib/apt/lists/ppa.launchpad.net_pasgui_ppa_ubuntu_dists_trusty_main_binary-i386_Packages
MD5: d79be8ed08e6a743818b1212de720d34
8.02-0ubuntu4 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_lucid_universe_binary-i386_Packages)
Description Language:
File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_lucid_universe_binary-i386_Packages
MD5: 23f14fed420b36ac3f02ca22fe86384e
Reverse Depends:
codeblocks-contrib,codeblocks 10.05svn7965-1
libcodeblocks0,codeblocks
libwxsmithlib0,codeblocks
libcodeblocks0,codeblocks
codeblocks-dbg,codeblocks 8.02-0ubuntu4
codeblocks-contrib,codeblocks
codeblocks-fr,codeblocks
codeblocks-common,codeblocks 13.12svn10016-0ubuntu1~trusty
codeblocks-common,codeblocks 13.12svn10016-0ubuntu1~trusty
codeblocks-contrib,codeblocks 13.12svn10016-0ubuntu1~trusty
codeblocks-dbg,codeblocks 13.12svn10016-0ubuntu1~trusty
libcodeblocks0,codeblocks
Dependencies:
13.12svn10016-0ubuntu1~trusty - libc6 (2 2.4) libcodeblocks0 (5 13.12svn10016-0ubuntu1~trusty) libgcc1 (2 1:4.1.1) libglib2.0-0 (2 2.12.0) libgtk2.0-0 (2 2.8.0) libstdc++6 (2 4.6) libwxbase2.8-0 (2 2.8.12.1+dfsg) libwxgtk2.8-0 (2 2.8.12.1+dfsg) codeblocks-common (5 13.12svn10016-0ubuntu1~trusty) xterm (0 (null)) libwxgtk2.8-dev (0 (null)) wx-common (0 (null)) codeblocks-contrib (0 (null)) gcc (16 (null)) g++ (0 (null)) gdb (0 (null))
8.02-0ubuntu4 - libcodeblocks0 (0 (null)) libatk1.0-0 (2 1.20.0) libc6 (2 2.7) libcairo2 (2 1.2.4) libfontconfig1 (2 2.4.0) libfreetype6 (2 2.2.1) libgcc1 (2 1:4.1.1) libglib2.0-0 (2 2.12.0) libgtk2.0-0 (2 2.17.11) libpango1.0-0 (2 1.14.0) libstdc++6 (2 4.1.1) libwxbase2.8-0 (2 2.8.10.1) libwxgtk2.8-0 (2 2.8.10.1) libx11-6 (0 (null)) zlib1g (2 1:1.1.4) libwxgtk2.8-dev (0 (null)) wx-common (0 (null)) codeblocks-contrib (0 (null)) gcc (16 (null)) g++ (0 (null)) gdb (0 (null)) xterm (0 (null))
Provides:
13.12svn10016-0ubuntu1~trusty -
8.02-0ubuntu4 -
Reverse Provides:
apt-get install codeblocks
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
codeblocks: Depends: libcodeblocks0 (= 13.12svn10016-0ubuntu1~trusty) but 10.05svn7965-1 is to be installed
Depends: libwxbase2.8-0 (>= 2.8.12.1+dfsg) but 2.8.12.1-0 is to be installed
Depends: libwxgtk2.8-0 (>= 2.8.12.1+dfsg) but 2.8.12.1-0 is to be installed
E: Broken packages
Quote from: Alpha on October 31, 2014, 05:18:08 PM
Quote from: ollydbg on October 31, 2014, 09:57:15 AM
From Ubuntu10.04's synaptic package manager, I still see the old C::B 8.02 supply from the official ubuntu, but the nightly build version of pasgui does not shown up.
That one only has builds for Ubuntu 14.04, try https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks (https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks) (and/or a newer version of Ubuntu).
I have just installed Ubuntu 14.10, and it works now, thanks!
Quote from: oBFusCATed on November 01, 2014, 05:37:40 PM
@ollydbg:
I had the same problem with 9990.
It happens only if a specific project is selected in the workspace.
If another project is selected as default project the problem doesn't happen.
I've used only rev 9855 before 9990 and 10016.
Here is a backtrace (incomplete) when the problem happened
...
It crashed when parsing class definition body, and I see macro expansion happens several times, but finally it crashed in m_TokenTree->TokenExists. If I see the crash in my system, I can debug it. But currently I can't.
Quote from: oBFusCATed on November 01, 2014, 09:59:38 PM
Another problem that is extremely annoying is that the value of the "Case sensitive matches" in the code completion settings is not save in the config file.
And I have to set it every time I start new instance of codeblocks.
Also why this is set to the non-obvious state on, I think this should be off by default.
It's a bug.
I did some test, if you open C::B (without opening any project), and just set the "Case sensitive matches", and close C::B, you will see those settings get saved.
But if you open C::B, and open one project, then set the "Case sensitive matches" option, and this options gets lost if you close C::B.
I will look into this.
Quote from: ollydbg on November 02, 2014, 09:56:15 AM
It crashed when parsing class definition body, and I see macro expansion happens several times, but finally it crashed in m_TokenTree->TokenExists. If I see the crash in my system, I can debug it. But currently I can't.
This is not a crash, I've just stopped it to see what is doing.
It doesn't crash but what happens is probably that it enters an infinite loop of macro expansion.
I'll try to see if this is related to a single project or the order of evaluation of project breaks it.
Quote from: ollydbg on November 02, 2014, 09:56:15 AM
Quote from: oBFusCATed on November 01, 2014, 09:59:38 PM
Another problem that is extremely annoying is that the value of the "Case sensitive matches" in the code completion settings is not save in the config file.
And I have to set it every time I start new instance of codeblocks.
Also why this is set to the non-obvious state on, I think this should be off by default.
It's a bug.
I did some test, if you open C::B (without opening any project), and just set the "Case sensitive matches", and close C::B, you will see those settings get saved.
But if you open C::B, and open one project, then set the "Case sensitive matches" option, and this options gets lost if you close C::B.
I will look into this.
Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.
When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.
The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"
When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!
I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Just add a flag to the temp parser and prevent it from saving its settings.
Hi :)
I've found some small issues that have been present for a few builds now. I'm currently using the build 10016 on Windows 7 32bit.
I'm not sure I should open tickets on SF for any these things. If I have, just tell me. I don't want to waste anyone's time :p
1) The Code Completion option "display info when hovering mouse over a token in the editor" is always active.
Even when uncheckd, it shows a tooltip. Plus it has wrong colors.
(http://s25.postimg.org/72xomhur3/cbcc1.png)
Ticketed here: https://sourceforge.net/p/codeblocks/tickets/88/ (https://sourceforge.net/p/codeblocks/tickets/88/)
2) The mouse cursor on the left margin is not mirrored or showing the left-to-right arrow. In older versions of CB it worked like that if I'm not mistaken.
3) If I put the focus on one of the dockable windows (while docked), its titlebar changes to the focused color, and that's correct.
If then I click in the editor, the cursor shows up in the editor and I can type fine, but the docked titlebar still has the focused color. To get the unfocused color I have to click on the editor tab.
I don't know if it's simply a color problem or there is some orphan window selection of sorts.
4) I use a dark theme in Windows, and so it's very visible where CB mixes system colors with custom ones, and it's very unreadable ;p
here some examples (hope they show correctly):
(http://s25.postimg.org/i57cyoe7j/cbdark1.png)
(http://s25.postimg.org/76w3ghpm7/cbdark2.png)
(http://s25.postimg.org/8n7lymsj3/cbdark3.png)
(http://s25.postimg.org/r420pg8hb/cbdark4.png)
(http://s25.postimg.org/s18fybjzj/cbdark5.png)
(http://s25.postimg.org/5voc80u0f/cbdark6.png)
5) The key bindings for the split and unsplit are missing
Thanks for reading :)
Quote from: oBFusCATed on November 03, 2014, 12:13:28 AM
Just add a flag to the temp parser and prevent it from saving its settings.
Yes can be done easily, but cause another issue. If a user open C::B (with out any C::B project opened), and change some CC settings, those settings also get unsaved. :(
Quote from: pluto on November 03, 2014, 12:43:47 AM
1) The Code Completion option "display info when hovering mouse over a token in the editor" is always active.
Even when uncheckd, it shows a tooltip.
I can confirm it, please report it in Sourceforge, thanks.
BTW: I think it is related to this post: Re: code completion settings do not take effect. (http://forums.next.codeblocks.org/index.php/topic,19732.msg134750.html#msg134750), it is related to ccmanager refactoring.
Quote from: oBFusCATed on November 02, 2014, 12:31:21 PM
This is not a crash, I've just stopped it to see what is doing.
It doesn't crash but what happens is probably that it enters an infinite loop of macro expansion.
I'll try to see if this is related to a single project or the order of evaluation of project breaks it.
@ollydbg: Can you guide me where to add logging, so I can try which file causes the problem?
I have multiple projects in a workspace and it is not a single project that causes it :(
I've in fact found the to projects that cause the problem and it is 100% reproducible. And of course I cannot share them. :(
edit: rev 9855 doesn't exhibit the same problem.
Quote from: oBFusCATed on November 03, 2014, 12:11:11 PM
Quote from: oBFusCATed on November 02, 2014, 12:31:21 PM
This is not a crash, I've just stopped it to see what is doing.
It doesn't crash but what happens is probably that it enters an infinite loop of macro expansion.
I'll try to see if this is related to a single project or the order of evaluation of project breaks it.
@ollydbg: Can you guide me where to add logging, so I can try which file causes the problem?
I have multiple projects in a workspace and it is not a single project that causes it :(
I've in fact found the to projects that cause the problem and it is 100% reproducible. And of course I cannot share them. :(
Look at the file Parserthread.cpp, there is a line
#define CC_PARSERTHREAD_DEBUG_OUTPUT 0You can change it to
#define CC_PARSERTHREAD_DEBUG_OUTPUT 1Now, you enable the log message in Parserthread.cpp.
The log messages are default to go in the "Code::Blocks Debug log" panel if you pass "--debug-log" when C::B started, you can redirect them to a file by using some option like:"--debug-log-to-file". Maybe, if you don't pass those options, the debug log messages will be shown in the terminal under Linux.
You can also enable the log message in Parser.cpp(by setting CC_PARSER_DEBUG_OUTPUT to 1) and Tokenizer.cpp(by setting CC_TOKENIZER_DEBUG_OUTPUT to 1) if you still don't find hang reason, but mostly I think only log messages in Parserthread.cpp is enough.
Quote
edit: rev 9855 doesn't exhibit the same problem.
I will exam all the related changed after this revision.
@ollydbg: I've done some bisecting and r9931 seems to be the last working revision. r9932 is broken.
My keyboard shortcuts for 'debugging windows' (namely 'alt-shift-x' where x is a digit between 0 and 9) doesn't work after I load a project. Although they are unchanged in the 'cbKeyBinder10.ini', they are not listed in settings->editor->keyboard shortcuts-> corresponding entries nor do they work. Even when I load a modified codeblocks.cbp project file, 'cbKeyBinder10.ini' changes with all the targets added to the file and 'debugging windows' shortcuts gone. I attached a zip containing 2 'cbkeybinder10.ini' files, one before any project loaded and one after codeblocks.cbp loaded. Also what is the .bak file used for?
Btw is there a way to prevent editor from editing while debugging? I often find myself trying to edit the code during a debugging session which is very frustrating. ;)
Win7 x64 SP1
I made some changes on 10/29/2014 that might fix this.
Either update your svn or wait for the next nightly.
Please let us know if the 10/29 revert fixes the problem.
What version of CB (before 10/27) worked for you?
In, any case, I'll look into it.
Could you give me the exact steps to cause the problem.
svn rev 10020 still exhibits the same problem. Unfortunately I couldn't find a working build after checking all the nightlies I have (back to rev 9673).
Steps to reproduce:
1- Launch cb, see the 'debugging windows' bindings are there before loading a project,
2- Load a project,
3- Check again to see the bindings are gone.
Some older revisions doesn't change 'cbkeybinder10.ini' file after closing cb even though the bindings are not listed on the shortcuts dialog, they don't work either. But latest nightlies change the file to add the targets of the opened project.
There is a side effect problem introduced in autorevision.cpp in svn 10011.
I have a unix machine which does not have access to internet. The file autorevision.h has been correctly set on another one, and I copy it (with many others !) on this isolated unix machine.
But when I build C::B on this isolated machine, autorevision.h is modified by the task autorevision with a svn number 0, an unknown date ....
If I reset the test at line 240 with >= as it was before svn 10011, my autorevision.h file is not modified, and it's what I need on this isolated machine.
gd_on
I can confirm this issue, either building from a git checkout or using release tar.bz2 file generated with make dist results in "svn 0" in the splashscreen.
Also, bugs in BrowseTracker_wx30.cbp and BrowseTracker_wx30_64.cbp.
ExtraCommands add manifest.xml, the folder images and a .xrc file in /devel... It should be, I think, respectively in /devel30... and /devel30_64...
With those corrections, BrowseTracker toolbar is correct. As it was, it's a too large and empty toolbar.
gd_on
Does this work better?
diff --git a/src/build_tools/autorevision/autorevision.cpp b/src/build_tools/autorevision/autorevision.cpp
index b0220b6..514ebd7 100644
--- a/src/build_tools/autorevision/autorevision.cpp
+++ b/src/build_tools/autorevision/autorevision.cpp
@@ -227,17 +227,17 @@ bool QuerySvn(const string& workingDir, string& revision, string &date)
bool WriteOutput(const string& outputFile, string& revision, string& date)
{
- string old;
- string comment("/*");
- comment.append(revision);
- comment.append("*/");
-
{
ifstream in(outputFile.c_str());
if (!in.bad() && !in.eof())
{
+ string old;
in >> old;
- if(old == comment)
+ int oldRev = 0;
+ size_t pos = old.find('*');
+ if (pos != string::npos)
+ oldRev = atoi(old.c_str() + pos + 1);
+ if(oldRev >= atoi(revision.c_str()))
{
if(be_verbose)
printf("Revision unchanged (%s). Skipping.", revision.c_str());
@@ -256,7 +256,7 @@ bool WriteOutput(const string& outputFile, string& revision, string& date)
return false;
}
- fprintf(header, "%s\n", comment.c_str());
+ fprintf(header, "/*%s*/\n", revision.c_str());
fprintf(header, "//don't include this header, only configmanager-revision.cpp should do this.\n");
fprintf(header, "#ifndef AUTOREVISION_H\n");
fprintf(header, "#define AUTOREVISION_H\n\n\n");
Same effect with less conversion, even if it should not matter much as it happens only one time:
commit e2e7ed0e50fc1843cb0ae77cafd82f07305695cb
Author: Jens Lody <jens@codeblocks.org>
Date: Thu Nov 6 22:26:28 2014 +0100
* fix for commit 10011, which could lead to revision string "0"
Index: src/build_tools/autorevision/autorevision.cpp
===================================================================
--- src/build_tools/autorevision/autorevision.cpp
+++ src/build_tools/autorevision/autorevision.cpp
@@ -237,10 +237,12 @@
if (!in.bad() && !in.eof())
{
in >> old;
- if(old == comment)
+ size_t l_old = old.length();
+ size_t l_comment = comment.length();
+ if(l_old > l_comment || ((l_old == l_comment) && old >= comment))
{
if(be_verbose)
- printf("Revision unchanged (%s). Skipping.", revision.c_str());
+ printf("Revision unchanged or older (%s). Skipping.", revision.c_str());
in.close();
return false;
}
@gd_on: the two patches are in svn now...
Quote from: oBFusCATed on November 03, 2014, 05:37:29 PM
@ollydbg: I've done some bisecting and r9931 seems to be the last working revision. r9932 is broken.
I still can't reproduce the issue in my system. :'(
As a workaround, you can just try to comment out the line "HandleMacroExpansion(id, peek);", thus disable the macro expansion for the first meet token, and see whether the issue happens again.
I have a local patch which only handles macro expansion in the Tokenizer level(low level), but not in the ParserThread level(high level), but that involves too many code changes......
@oBFusCATed : Thanks
@jens and Alpha : I tried your two patches. Both give me the "good" result on the isolated machine : svn number not modified in my autorevision.h file and this is what I expected.
So, it's up to you to choose which one is better than the other. May be jens's one is a little bit shorter... and less conversion.
gd_on
@jens, less work is generally better; go ahead and commit.
Quote from: Alpha on November 07, 2014, 04:15:26 PM
@jens, less work is generally better; go ahead and commit.
In svn (r10029).
I build the new revision and try to upload it, but it might not be possible before monday, because my provider will switch internet off this night (don't know the exact time) and I will not have any internet access until monday (at least).
I found a tiny bug, or non finished functionality.
Settings -> Compiler... -> Global Compiler Settings -> Other Settings -> Advanced Options... -> Commands:
1. Add new "Source ext.": ui
2. Field "Command" stay on "Compile single file to object file"
3. "Command line macro": $(#qt5.uic) -o "Src/GeneratedFiles/ui_$file_name.h" "$file"
4. "Generated files (to be further compiled)": Src/GeneratedFiles/ui_$file_name.h
So, when I'm add "Src/Kreator/somefile.ui" to project and make rebuild then:
a. File is generated inside right path: Src/GeneratedFiles/ui_somefile.h
b. CodeBlocks always put fixed position of "Auto-generated" path in window "Management -> Projects" to: "Src/Kreator/ui_somefile.h"
c. Because my ui_somefile.h is into "Src/GeneratedFiles/ui_somefile.h" - compiler cannot find it
(First solution) For working well I need to change:
ch.3. "Command line macro": $(#qt5.uic) -o "ui_$file_name.h" "$file"
ch.4. "Generated files (to be further compiled)": ui_$file_name.h
(Second solution) Or for alternative working well solution I need to change:
ch.3. "Command line macro": $(#qt5.uic) -o "Src\Kreator\ui_$file_name.h" "$file"
ch.4. "Generated files (to be further compiled)": Src\Kreator\ui_$file_name.h
But it is really mess when I have all generated files into main folder (first solution) or in folder of my source file Src\Kreator\* (second solution).
Auto-generated files for new extensions always put same directory as source. So first solution shouldn't work at all, but it work well :-).
So either I cannot configure this Code::Blocks functionality or it doesn't work like it should.
Quote from: ollydbg on November 02, 2014, 03:04:17 PM
Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.
When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.
The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"
When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!
I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Any plans to fix this issue? If not please say so, so I can take a look at it ... it is quite annoying...
Apologies if I have asked again in the past: is it possible to add the same feature Find declaration... with Ctrl+mouse hover hotkeys?
I use NetBeans a lot for web development (Java as well) and find this feature quite appealing; it helps tremendously while looking for certain information about a class or member function.
How difficult is it to implement it?
Khram: Please try to describe the problem with more details, so we can try to solve it. Steps to reprocude, OS? Does it happen with the previous nightly?
Quote from: oBFusCATed on November 15, 2014, 01:04:25 PM
Quote from: ollydbg on November 02, 2014, 03:04:17 PM
Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.
When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.
The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"
When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!
I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Any plans to fix this issue? If not please say so, so I can take a look at it ... it is quite annoying...
I know it's annoying. As a workaround, you can just open C::B (without any project opened), and open the setting dialog for CodeCompletion, then close C::B, all the settings should be saved.
If you do want to forbid the setting saving of the "temp parser", you can just add an parameter of the Parser's constructor, say
Parser::Parser(....., bool saveSetting = true)
{
...
}
And create a temp parser in the code
m_TempParser = new Parser(this, nullptr, false); // the last parameter means we don't want to save the setting of this temp parserBut note that this still break something, such as the workaround I said before.
Hi
Something has gone wrong in my CB svn 10032 (Ubuntu 14.04 64bits) with the watches window:
'tmpv' is a double and it'a shown OK.
'float3' is defined in the previous line to the breakpoint as float float3[3] = {0, -1.5, 8.3};
As you can see every value != 0 is splitted into two lines: the integer and the decimal parts.
Would this issue be related to localization? (I'm at Spain) It does not happen in Windows 8.1
THX
Manolo: Can you post the full log from the debugger?
I have created a new console project with this code:
#include <iostream>
using namespace std;
int main()
{
float float3[3] = {0, -1.5, 8.3};
cout << "Hello world!" << endl;
return float3[0] ? 0 : 1;
}
Put a breakpoint at "cout <<..." line. The behaviour for the watches window is still broken.
Here is the full debugger log:
Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: /home/manolo/PROGS/ConsoleMinimal/
Adding source dir: /home/manolo/PROGS/ConsoleMinimal/
Adding file: /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
Changing directory to: /home/manolo/PROGS/ConsoleMinimal/.
Set variable: LD_LIBRARY_PATH=.:/usr/lib32
[debug]Command-line: /usr/bin/gdb -nx -fullname -quiet -args /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
[debug]Working dir : /home/manolo/PROGS/ConsoleMinimal
Starting debugger: /usr/bin/gdb -nx -fullname -quiet -args /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
done
[debug]Leyendo símbolos desde /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal...
[debug]hecho.
[debug](gdb)
[debug]> set prompt >>>>>>cb_gdb:
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
[debug]>>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
[debug]Copyright (C) 2014 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 "x86_64-linux-gnu".
[debug]Type "show configuration" for configuration details.
[debug]Para las instrucciones de informe de errores, vea:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.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 disassembly-flavor intel
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Punto de captura 1 (lanzar)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /home/manolo/PROGS/ConsoleMinimal/
[debug]Source directories searched: /home/manolo/PROGS/ConsoleMinimal:$cdir:$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "/home/manolo/PROGS/ConsoleMinimal/main.cpp:8"
[debug]Punto de interrupción 2 at 0x400880: file /home/manolo/PROGS/ConsoleMinimal/main.cpp, line 8.
[debug]>>>>>>cb_gdb:
Punto de interrupción 2 at 0x400880: file /home/manolo/PROGS/ConsoleMinimal/main.cpp, line 8.
[debug]Using terminal's PID as console PID 13970, TTY /dev/pts/11
[debug]> tty /dev/pts/11
[debug]Queued:[tty /dev/pts/11]
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
[debug]Breakpoint 2, main () at /home/manolo/PROGS/ConsoleMinimal/main.cpp:8
[debug]/home/manolo/PROGS/ConsoleMinimal/main.cpp:8:94:beg:0x400880
[debug]>>>>>>cb_gdb:
At /home/manolo/PROGS/ConsoleMinimal/main.cpp:8
Hm, does this happen you start C::B from console like LC_ALL=C codeblocks?
C::B parses the output of the debugger, so a localized gdb is expected to break pretty badly.
Starting C:B from a terminal with command "LC_ALL=C codeblocks" does not show the issue.
So, it seems it's a gdb localized problem.
I haven't changed anything, just used gdb as it is right after installing it.
Should I change it or would C:B be aware of it?
THX
@Jens: Any idea how do we solve this same problem for the compiler? I've tried to search for locale setting code, but I couldn't find any.
For the compiler I added LC_ALL with the value C to "Settings -> Environment... -> Environment variables".
This might (hopefully) also work for gdb.
Are you adding this manually?
QuoteFor the compiler I added LC_ALL with the value C to "Settings -> Environment... -> Environment variables".
This might (hopefully) also work for gdb.
Doing this manually works for me.
Thank you for showing this easy solution.
Quote from: scarphin on November 04, 2014, 04:20:14 PM
My keyboard shortcuts for 'debugging windows' (namely 'alt-shift-x' where x is a digit between 0 and 9) doesn't work after I load a project. Although they are unchanged in the 'cbKeyBinder10.ini', they are not listed in settings->editor->keyboard shortcuts-> corresponding entries nor do they work. Even when I load a modified codeblocks.cbp project file, 'cbKeyBinder10.ini' changes with all the targets added to the file and 'debugging windows' shortcuts gone. I attached a zip containing 2 'cbkeybinder10.ini' files, one before any project loaded and one after codeblocks.cbp loaded. Also what is the .bak file used for?
Btw is there a way to prevent editor from editing while debugging? I often find myself trying to edit the code during a debugging session which is very frustrating. ;)
Win7 x64 SP1
fyi..
5 years later this bug persists.
i see one other post on the forum about this bug, from this same user.
is there a fix?
ca1e: The quote contains two requests. Which one is bothering you?
@ca1e: cbKeyBinder10.ini is not used by any current nightly. cbKeyBinder10.ini is only referenced to save previous versions of CB key bindings when needed.
Also, I cannot reproduce the described problem. I have no problem using Alt-Shift-0 thru 9. They work for me.
They also display correctly. See attached image.
i set hotkeys for debugging windows (memory view, registers) so i can toggle these windows on/off when debugging
after closing a workspace and re-opening it, the keys are erased
it would appear only debugging windows hotkeys are affected
Is this happening in without restarting codeblocks?
Quote from: ca1e on November 15, 2019, 05:04:53 AM
i set hotkeys for debugging windows (memory view, registers) so i can toggle these windows on/off when debugging
after closing a workspace and re-opening it, the keys are erased
it would appear only debugging windows hotkeys are affected
What version of CB are you using.
I have no problem setting DebuggerWindows hotkey on the current nightly on Windows 10.