Author Topic: The 27 October 2014 build (10016) is out.  (Read 39712 times)

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 27 October 2014 build (10016) is out.
« Reply #15 on: October 31, 2014, 05:18:08 pm »
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 (and/or a newer version of Ubuntu).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #16 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
Code: [Select]
(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
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #17 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #18 on: November 02, 2014, 09:20:52 am »
Do you see the nightly version with the search command or the like?
Code: [Select]
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


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 (and/or a newer version of Ubuntu).
I have just installed Ubuntu 14.10, and it works now, thanks!
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #19 on: November 02, 2014, 09:56:15 am »
@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.

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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #20 on: November 02, 2014, 12:31:21 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #21 on: November 02, 2014, 03:04:17 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.


« Last Edit: November 02, 2014, 03:11:22 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #22 on: November 03, 2014, 12:13:28 am »
Just add a flag to the temp parser and prevent it from saving its settings.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline pluto

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 27 October 2014 build (10016) is out.
« Reply #23 on: November 03, 2014, 12:43:47 am »
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.

Ticketed here: 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):













5) The key bindings for the split and unsplit are missing

Thanks for reading :)

« Last Edit: November 03, 2014, 09:54:07 am by pluto »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #24 on: November 03, 2014, 06:25:10 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. :(
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #25 on: November 03, 2014, 06:31:13 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., it is related to ccmanager refactoring.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #26 on: November 03, 2014, 12:11:11 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.
« Last Edit: November 03, 2014, 12:15:19 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #27 on: November 03, 2014, 02:40:33 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
Code: [Select]
#define CC_PARSERTHREAD_DEBUG_OUTPUT 0You can change it to
Code: [Select]
#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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #28 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: The 27 October 2014 build (10016) is out.
« Reply #29 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