Hi,
I have been using Nightly Build Code::Blocks for a long time with Windows and Kubuntu. On Kubuntu I am using the http://apt.jenslody.de/stable stable main
repository
I am running Kubuntu 12.04 with the latest updates.
Right now I am experiencing an awkward crash problem when loading any workspace on Kubuntu, see attched XML report. C::B starts ok, but crashes when I try to open a workspace.
Any help appreciated..... :'(
FWIW, I just tried the same version of C::B on another Kubuntu 12.04 machine, same workspaces. It crashes out in the same way. It means I cannot get any work done until a solution is found....
Two things: you can try to disable the CodeCompletion plugin and/or you can try to use C::B from pasgui's ppa (https://launchpad.net/~pasgui/+archive/ppa/ (https://launchpad.net/~pasgui/+archive/ppa/)), because my version is built in a debian chroot and there might be binary incompatibilities with some libs (should not be, but who knows).
By the way: I thought my version is not installable on 12.04 (at least not out of the box).
...one more thing in addition: After you disabled the CC plugin, your project should load. Then, please check the settings of all your workspace/project/target compiler(s) you use in this workspace. It seems, there is an issue with CC running the compiler to obtain the compilation flags for your project(s).
Thanks for these replies... :)
jens: I disabled the CodeCompletion plugin, exited C::B, restarted C::B and opened the workspaces without any issues. Thanks, that saved my day. Apparently there is something fishy in the CodeCompletion plugin that causes the crash. If I re-enable the CC plugin and restart C::B again, the crashes return.
MortenMacFly: Be aware that my setup is a little special, perhaps it is of some relevance?
All my projects have 4 build targets
GCC_Release (currently used on linux only)
GCC_Debug (currently used on linux only)
MSVC_Release (used on Windows only)
MSVC_Debug (used on Windows only)
I am using Bazaar source control (on Windows only). For linux development, I syncronise source and project files over Samba, using Komparator (http://kde-apps.org/content/show.php?content=116039), then edit as required, compile&link. When happy, I use Komparator to sync it back over Samba, then commit to Bazaar there.
If, for some reason, the CC plugin tries to access the MSVC compiler on linux, it certainly will not succeed. If that is the issue, it should just give up, but not crash.
Quote from: cacb on October 29, 2012, 11:44:24 AM
If, for some reason, the CC plugin tries to access the MSVC compiler on linux, it certainly will not succeed. If that is the issue, it should just give up, but not crash.
It checks for the presence of the executable in a way that wxExecute (which we use) won't return success... However - I could tell you exactly if you were willing to compile C::B yourself or (maybe) provide a minimal test project for the Linux devs to reproduce. MAybe you can strip-down your project to something usable...?!
Quote from: MortenMacFly on October 29, 2012, 01:04:44 PM
Quote from: cacb on October 29, 2012, 11:44:24 AM
If, for some reason, the CC plugin tries to access the MSVC compiler on linux, it certainly will not succeed. If that is the issue, it should just give up, but not crash.
It checks for the presence of the executable in a way that wxExecute (which we use) won't return success... However - I could tell you exactly if you were willing to compile C::B yourself or (maybe) provide a minimal test project for the Linux devs to reproduce. MAybe you can strip-down your project to something usable...?!
Thanks, I have put a small (397 kB) file here (http://arnholm.org/cpde/cpde_app.zip)
It is a zip file with a Code::Blocks workspace according to the description I gave (except the project Bmp2Xpm does not have any GCC targets, but if you remove it from the workspace, C::B still crashes on Kubuntu 12.04 as explained when the CC plugin is enabled, I just tried it).
Quote from: cacb on October 29, 2012, 03:33:18 PM
Thanks, I have put a small (397 kB) file here (http://arnholm.org/cpde/cpde_app.zip)
Hopefully one of the Linux devs with debugging capabilities can pick it up...
I get this crash here too.
I will look into it.
Error is simple: nativeparser.cpp:1921
Compiler* compiler = CompilerFactory::GetCompiler(project->GetCompilerID());
cb::shared_ptr<CompilerCommandGenerator> generator(compiler->GetCommandGenerator(project));
Missing check for nullptr.
compiler is 0x0, therefore it crashes (obviously).
Question is: what to do in this case, just step out the function or ... ?
CC devs should look into it I think.
Quote from: jens on October 29, 2012, 04:25:11 PM
Question is: what to do in this case, just step out the function or ... ?
CC devs should look into it I think.
For now I would do what's attached (which avoids the crash).
Solution 1: If we don't have a compiler all project path's with macros cannot safely be resolved and are error prone. Also, CC is questionable anyways as we don't have the system headers, for example.
Solution 2: Maybe we could also iterate through the project include dirs and add them only, if they contain no macros in case no compiler is present. Also, if no compiler-related macro is needed (like a simply envvar) it could work, too. This may work nice for projects using the same compiler (GCC) on several platforms.
Solution 3: We just ignore that we cannot resolve the macros correct and use all project path's "as is".
What would be most wise??? Really not that simple. ::)
Quote from: jens on October 29, 2012, 04:25:11 PM
Error is simple: nativeparser.cpp:1921
Compiler* compiler = CompilerFactory::GetCompiler(project->GetCompilerID());
cb::shared_ptr<CompilerCommandGenerator> generator(compiler->GetCommandGenerator(project));
Missing check for nullptr.
compiler is 0x0, therefore it crashes (obviously).
Question is: what to do in this case, just step out the function or ... ?
CC devs should look into it I think.
Thanks for your nice work, that was very fast...
In this case, I guess the nullptr is for MSVC, a compiler that does not exist for the platform in question (here: Linux). I believe it must be allowed to refer to compilers that don't exist for the current platform (or are missing), as long as there are other relevant build targets with valid compilers. On Windows I have the opposite case, no GCC compiler installed, but it does not cause any crash or other problems, and it should not.
Quote from: cacb on October 29, 2012, 05:32:16 PM
On Windows I have the opposite case, no GCC compiler installed, but it does not cause any crash or other problems, and it should not.
The difference is most likely that the entry (compilerID) for the gcc compiler exists on windows, but it is (probably) not configured, but on linux no msvc compilerID exists.
I've committed a patch (slightly different to the one posted here) to trunk that should at least fix the crash bug.
Quote from: MortenMacFly on October 29, 2012, 10:20:26 PM
I've committed a patch (slightly different to the one posted here) to trunk that should at least fix the crash bug.
Dammed - that one didn't really work due to the shared pointer. Now I am unsure, how to do it.
@obfuscated: Can you have a look at the attached patch, if I can initialise a shared_ptr like that?
At least it compiled and seems to run...
I would probably use something like:
A *a=func();
shared_ptr<B> p(a ? a->makeB() : nullptr);
if (p)
...
Another option is:
shared_ptr<B> p(nullptr);
A *a=func();
if (a)
p=shared_ptr<B>(a->makeB());
if (p)
Quote from: oBFusCATed on October 29, 2012, 11:25:50 PM
A *a=func();
shared_ptr<B> p(a ? a->makeB() : nullptr);
if (p)
...
This looks like I did it, except that I used 0 and not nullptr, right? Then ti should be OK to commit to resolve the crash.
Nice work, it is much appreciated! :D
Morten: yes, if it compiles and fixes the crash :)
I have now upgraded to the latest C::B 8500 nightly under Kubuntu and can confirm that the crash problem is gone, also with CodeCompletion plugin enabled.
Thanks, guys. :)