Codeblocks crash on linux when building single file

[Ghorgoth]

In any project on linux (tried centos5 and centos6), codeblocks instantly crashes if i right click on a single file in a project and choose "build file".
This issue is on the lastest 13.12 release but was also here in the previous (12.11 and upcoming nightlies)

Thanks,

[BlueHazzard]

some sort of crashlog would be nice....
does c::b shows a crash dialog? if yes, please post it here.
can you start c::B with -v and -d and post the console output?
can you start c::b with gdb and provide a backtrace /callstack?

greetings

[Ghorgoth]

Hi,
Unfortunately there is no crash dialog showing up,
codeblocks -v -d just outputs "segmentation fault",
here is the gdb output i get:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe3929364 in DirectCommands::DirectCommands(CompilerGCC*, Compiler*, cbProject*, int) () from /usr/lib64/codeblocks/plugins/libcompiler.so
(gdb) bt
#0  0x00007fffe3929364 in DirectCommands::DirectCommands(CompilerGCC*, Compiler*, cbProject*, int) () from /usr/lib64/codeblocks/plugins/libcompiler.so
#1  0x00007fffe38ef95a in CompilerGCC::CompileFileDefault(cbProject*, ProjectFile*, ProjectBuildTarget*) () from /usr/lib64/codeblocks/plugins/libcompiler.so
#2  0x00007fffe38eb66f in CompilerGCC::CompileFile(wxString const&) () from /usr/lib64/codeblocks/plugins/libcompiler.so
#3  0x00007fffe38e0c06 in CompilerGCC::StartCompileFile(wxFileName) () from /usr/lib64/codeblocks/plugins/libcompiler.so
#4  0x00007fffe38efeef in CompilerGCC::OnCompileFile(wxCommandEvent&) () from /usr/lib64/codeblocks/plugins/libcompiler.so
#5  0x00007fffe38f01fd in CompilerGCC::Dispatcher(wxCommandEvent&) () from /usr/lib64/codeblocks/plugins/libcompiler.so
#6  0x0000003d024e7b10 in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>)
    at ./src/common/event.cpp:1239
#7  0x0000003d024e8714 in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#8  0x0000003d024e87f7 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#9  0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#10 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
... (same from 11 to 36)
#37 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#38 0x0000003cffed5e19 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#39 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#40 0x0000003cffed5e19 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#41 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#42 0x0000003cfff01bc5 in wxScrollHelperEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/generic/scrlwing.cpp:208
#43 0x0000003cffeb3ad5 in wxMenuBase::SendEvent (this=<value optimized out>, id=<value optimized out>, checked=<value optimized out>) at ./src/common/menucmn.cpp:792
---Type <return> to continue, or q <return> to quit---
#44 0x0000003cffe4c3dc in gtk_menu_clicked_callback (widget=<value optimized out>, menu=<value optimized out>) at ./src/gtk/menu.cpp:658
#45 0x0000003cf700bb3e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#46 0x0000003cf7020e23 in ?? () from /lib64/libgobject-2.0.so.0
#47 0x0000003cf70220af in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#48 0x0000003cf70225f3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#49 0x0000003cfde7dc5e in gtk_widget_activate () from /usr/lib64/libgtk-x11-2.0.so.0
#50 0x0000003cfdd64c3d in gtk_menu_shell_activate_item () from /usr/lib64/libgtk-x11-2.0.so.0
#51 0x0000003cfdd668ea in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#52 0x0000003cfdd53f53 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#53 0x0000003cf700bb3e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#54 0x0000003cf70209ed in ?? () from /lib64/libgobject-2.0.so.0
#55 0x0000003cf7021f4a in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#56 0x0000003cf70225f3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#57 0x0000003cfde76abf in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#58 0x0000003cfdd4acca in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#59 0x0000003cfdd4be3c in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#60 0x0000003cfc45fcdc in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#61 0x0000003cf6838f0e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#62 0x0000003cf683c938 in ?? () from /lib64/libglib-2.0.so.0
#63 0x0000003cf683ca3a in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#64 0x0000003cfdd4c1d1 in gtk_main_iteration () from /usr/lib64/libgtk-x11-2.0.so.0
#65 0x0000003cffe488e5 in wxWindow::DoPopupMenu (this=<value optimized out>, menu=<value optimized out>, x=<value optimized out>, y=<value optimized out>)
    at ./src/gtk/menu.cpp:1730
#66 0x00000000004d0fea in ?? ()
#67 0x00000000004d3aa6 in ProjectManagerUI::OnTreeItemRightClick(wxTreeEvent&) ()
#68 0x0000003d024e7b10 in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>)
    at ./src/common/event.cpp:1239
#69 0x0000003d024e8714 in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#70 0x0000003d024e87f7 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#71 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#72 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#73 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#74 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#75 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#76 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#77 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#78 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#79 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#80 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#81 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#82 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#83 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#84 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#85 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#86 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
---Type <return> to continue, or q <return> to quit---
#87 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#88 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
(...)
#131 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
---Type <return> to continue, or q <return> to quit---
#132 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#133 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
(...)
#139 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#140 0x0000003cffed5e19 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#141 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#142 0x0000003cffed5e19 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#143 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#144 0x0000003cfff01bc5 in wxScrollHelperEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/generic/scrlwing.cpp:208
#145 0x0000003cfff147c3 in wxGenericTreeCtrl::OnMouse (this=<value optimized out>, event=<value optimized out>) at ./src/generic/treectlg.cpp:3430
#146 0x0000003d024e7b10 in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>)
    at ./src/common/event.cpp:1239
#147 0x0000003d024e8714 in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#148 0x0000003d024e87f7 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#149 0x0000003d024e8780 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#150 0x0000003cfff01bc5 in wxScrollHelperEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/generic/scrlwing.cpp:208
#151 0x0000003cffdf9bb1 in gtk_window_button_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>)
    at ./src/gtk/window.cpp:1634
#152 0x0000003cfdd53f53 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#153 0x0000003cf700bb3e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#154 0x0000003cf7020e23 in ?? () from /lib64/libgobject-2.0.so.0
#155 0x0000003cf7021f4a in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#156 0x0000003cf70225f3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#157 0x0000003cfde76abf in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#158 0x0000003cfdd4acca in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#159 0x0000003cfdd4be3c in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#160 0x0000003cfc45fcdc in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#161 0x0000003cf6838f0e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#162 0x0000003cf683c938 in ?? () from /lib64/libglib-2.0.so.0
#163 0x0000003cf683cd55 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#164 0x0000003cfdd4c327 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#165 0x0000003cffde7848 in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#166 0x0000003cffe61c98 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#167 0x0000000000447e3b in ?? ()
#168 0x0000003d02496405 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#169 0x0000000000448172 in ?? ()
#170 0x0000003cf541ecdd in __libc_start_main () from /lib64/libc.so.6
#171 0x0000000000447c69 in ?? ()
#172 0x00007fffffffe278 in ?? ()
#173 0x000000000000001c in ?? ()
#174 0x0000000000000001 in ?? ()
---Type <return> to continue, or q <return> to quit---
#175 0x00007fffffffe564 in ?? ()
#176 0x0000000000000000 in ?? ()

[oBFusCATed]

Works here unfortunately (Gentoo linux 64bit).
Do you have an example project you could share?

[Ghorgoth]

Hi,

I performed a few tests and i think i figured out where the problem is:

All my projects have 6 targets (win64 debug, win64 release, linux64 release, linux64 debug, osx64 release, osx64 debug).

- If i keep only the linux64 target (removing all the others from the xml), then the compilation works and codeblocks does not crash

- if i add one target BEFORE (in the xml), for example win64 release, then codeblocks crashes.
- If i add the same target AFTER, codeblocks does not crash.

So it seems that when building a single file, codeblocks tries to use the first target found in the xml, and not the selected one from the toolbar panel. In my case its win64 so it leads to crash on linux.

[oBFusCATed]

Can you provide simple hello world project which demonstrates the problem?

[Ghorgoth]

Sure,
here two hello world projects, one who crashes and the other who does not. (i just changed the targets order in the two projects).

Thanks,

[oBFusCATed]

Thank you. I was able to reproduce the problem.
In fact there are two problems here:

1. The crash happens because of nullptr dereference.
This patch tries to fix it

Code

Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp     (revision 9573)
+++ src/plugins/compilergcc/compilergcc.cpp     (working copy)
@@ -2913,6 +2913,14 @@ int CompilerGCC::CompileFileWithoutProject(const wxString& file)
 int CompilerGCC::CompileFileDefault(cbProject* project, ProjectFile* pf, ProjectBuildTarget* bt)
 {
     Compiler* compiler = CompilerFactory::GetCompiler(bt->GetCompilerID());
+    if (!compiler)
+    {
+        const wxString &err = wxString::Format(_("error: Cannot build file for target '%s'. Compiler '%s' cannot be found!"),
+                                               bt->GetTitle().wx_str(), bt->GetCompilerID().wx_str());
+        LogMessage(pf->relativeToCommonTopLevelPath + _(": ") + err, cltError);
+        LogWarningOrError(cltError, project, pf->relativeToCommonTopLevelPath, wxEmptyString, err);
+        return -3;
+    }

     DirectCommands dc(this, compiler, project, m_PageIndex);
     wxArrayString compile = dc.CompileFile(bt, pf);

2. The second problem is that the target points to the invalid windows target, but in the compiler toolbar I see that the linux target is selected.
    It seems that the CompilerGCC::GetBuildTargetForFile doesn't respect the non-supported target, so and it returns a windows only target on
    linux and vise-versa. The problem seems to go away with this patch:

Code

Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp     (revision 9573)
+++ src/plugins/compilergcc/compilergcc.cpp     (working copy)
@@ -2855,7 +2855,12 @@ ProjectBuildTarget* CompilerGCC::GetBuildTargetForFile(ProjectFile* pf)
         bt = m_pProject->GetBuildTarget(idx);
     }
     else // use the currently selected build target
-        bt = m_pProject->GetBuildTarget(m_RealTargetIndex); // pick the selected target
+    {
+        const wxString &targetName = m_Targets[m_TargetIndex];
+        if (std::find(pf->buildTargets.begin(), pf->buildTargets.end(), targetName) == pf->buildTargets.end())
+            return nullptr;
+        bt = m_pProject->GetBuildTarget(targetName);
+    }

     return bt;
 }

@devs: Please comment, because I'm not too familiar with the Compiler's plugin, so I might be doing stupid things.

[MortenMacFly]

@devs: Please comment, because I'm not too familiar with the Compiler's plugin, so I might be doing stupid things.

What about the case when the user has specified a customs build command for a single file (via file properties). Is this still working after these changes?

[oBFusCATed]

I'll need an example project and steps to help use this feature. I've never done this myself.

[oBFusCATed]

Changes pushed in SVN... please test and report if everything still works.

[MortenMacFly]

Changes pushed in SVN... please test and report if everything still works.

Single file compilation and compilation with custom build commands per-file works (on Windows)... no issues.

[Ghorgoth]

Thanks for solving this issue!
I can't compile right now for linux but i'll check as soon as i can or a nightly gets released.

[Jenna]

Thanks for solving this issue!
I can't compile right now for linux but i'll check as soon as i can or a nightly gets released.

For CentOS, Fedora and Ddebian you can find nightlies of actual trunk on my server.
See my signature for urls.

[killerbot]

I have found a side effect.

Take a regular multi target project (for example a regular debug/release) [and take one with just 1 file, eg main.cpp, doesn't matter but easier for this story]:

Ensure nothing is build yet :
- compile a single file from the project ==> compiles ok, and you see build output in the build log
- compile that single file once more (NO clean in between) ==> prints "Done" (and actually nothing to do)
   NOTE : previous build log remains visible and does not get cleared ! ==> BUG (?)
- make that file incorrect (eg remove somewhere a needed ';')
- compile single file ==> build log output, and jump to build messages with jump to offending line- compile single file again (without fixing the mistake) [leave focus in build messages] ==> retries and same failure messages [OK]
  NOTE : how the "errors" count is continuing to go up (now at 2)
- compile single file again (without fixing the mistake) [leave focus in build messages] ==> retries and same failure messages [OK]
  NOTE : how the "errors" count is continuing to go up (now at 3)
- fix the file (put back the ';' ) and compile single file
 ==> now new error message added, but in the build messages it still says 3 errors have occurred  (in the build log you see the same thing, 3 errors THOUGH the line is printed in blue)
- build your project (in my case there was only 1 file in the project)
  ==> you can see that the CB/compiler is actually DOING a compile, and now no errors ...

[oBFusCATed]

I'll take a look.

[Ghorgoth]

Thanks for solving this issue!
I can't compile right now for linux but i'll check as soon as i can or a nightly gets released.

For CentOS, Fedora and Ddebian you can find nightlies of actual trunk on my server.
See my signature for urls.

I just tried on Centos6 and it works, thanks everyone!

[oBFusCATed]

@killerbot:
The regression should be fixed in trunk.
I prefer C::B to not clear the "Build log" as long as possible, so I can see as much history as possible.
If you think this is not OK for this case please say so and I'll revert the change.

[killerbot]

confirmed that the regression is fixed.

Question : what is now the extected behavior when the build log gets cleared.

Test result :
- clean library ==> cleans
- build library ==> builds and the output of the previous clean removed
- build library again ==> outputs nothing to be done, and previous build log removed

[in that library touch 1 file]

Compile that single file :
- builds file ==> new log, AND previous log not removed
- build that file again  ===> new log, and previous logS not removed
- build that file again  ===> new log (nothing to be done), and previous logS not removed ...... and so on

Is a little bit inconsistent, so just wondering what is the new behavior/algorithm ?

[nenin]

I have similar issue on Win7 64b. Build of the single file from big project sometimes forces C::B to hung. But I can not reproduce it. This issue appeared 3 or 4 times.

[oBFusCATed]

Switch to the svn trunk build or wait for the next night build.
If the problem shows up again please report.