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
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
@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
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 0
You can change it to
#define CC_PARSERTHREAD_DEBUG_OUTPUT 1
Now, 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.
edit: rev 9855 doesn't exhibit the same problem.
I will exam all the related changed after this revision.
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;
}
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 parser
But 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
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