Codeblocks crashes in command line build

[alexchen]

Hi, we recently update Code::Blocks from 13.12 (from CentOS repository) to 16 (from Code::Blocks download), and wxGTK 2.8.12 release 8 to release 20 (from CentOS repository).  But now we are experiencing code dump from codeblocks when running its command line mode. The version of CentOS is 7.2.1511.
The parameters used to run codeblocks are
 /usr/bin/codeblocks /ni /ns --debug-log --$BUILD_TYPE --target=$TARGET ${WORKSPACE}.workspace
where BUILD_TYPE is 'build' or 'rebuild', TARGET is 'debug' or 'release', and WORKSPACE is the name of a workspace file. The dump file shows the following stack trace:

$ gdb /usr/bin/codeblocks /var/crash/codeblocks.1457378583.crash.5540
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/codeblocks...Reading symbols from /usr/bin/codeblocks...(no debugging symbols found)...done.
(no debugging symbols found)...done.
[New LWP 5540]
[New LWP 7131]
[New LWP 5543]
[New LWP 5542]
[New LWP 7132]
[New LWP 7130]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/codeblocks /ni /ns --debug-log --build --target=Debug64 Draco.workspac'.
Program terminated with signal 6, Aborted.
#0  0x00007fa2fb7295f7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install codeblocks-16.01-1.el7.x86_64
(gdb) where
#0  0x00007fa2fb7295f7 in raise () at /lib64/libc.so.6
#1  0x00007fa2fb72ace8 in abort () at /lib64/libc.so.6
#2  0x00007fa2fb769317 in __libc_message () at /lib64/libc.so.6
#3  0x00007fa2fb76fea2 in malloc_consolidate () at /lib64/libc.so.6
#4  0x00007fa2fb771ea5 in _int_malloc () at /lib64/libc.so.6
#5  0x00007fa2fb7738dc in malloc () at /lib64/libc.so.6
#6  0x00007fa2fecb06d7 in wxStringBase::AllocBuffer(unsigned long) () at /lib64/libwx_baseu-2.8.so.0
#7  0x00007fa2fecb0866 in wxStringBase::AllocBeforeWrite(unsigned long) () at /lib64/libwx_baseu-2.8.so.0
#8  0x00007fa2fecb27f9 in wxString::GetWriteBuf(unsigned long) () at /lib64/libwx_baseu-2.8.so.0
#9  0x00007fa2fecb3e57 in wxString::PrintfV(wchar_t const*, __va_list_tag*) () at /lib64/libwx_baseu-2.8.so.0
#10 0x00007fa2fecb40f4 in wxString::Printf(wchar_t const*, ...) () at /lib64/libwx_baseu-2.8.so.0
#11 0x00007fa2e83d18e2 in CompilerGCC::DoRecreateTargetMenu() () at /usr/lib64/codeblocks/plugins/libcompiler.so
#12 0x00007fa2e83d2595 in CompilerGCC::UpdateProjectTargets(cbProject*) () at /usr/lib64/codeblocks/plugins/libcompiler.so
#13 0x00007fa300bcb460 in Manager::ProcessEvent(CodeBlocksEvent&) () at /lib64/libcodeblocks.so.0
#14 0x00007fa300bffa61 in ProjectManager::SetProject(cbProject*, bool) () at /lib64/libcodeblocks.so.0
#15 0x00007fa300c016a3 in ProjectManager::CloseProject(cbProject*, bool, bool) () at /lib64/libcodeblocks.so.0
#16 0x00007fa300c01786 in ProjectManager::CloseAllProjects(bool) () at /lib64/libcodeblocks.so.0
#17 0x00007fa300c019fd in ProjectManager::CloseWorkspace() () at /lib64/libcodeblocks.so.0
#18 0x00000000004a6e50 in MainFrame::OnApplicationClose(wxCloseEvent&) ()
#19 0x00007fa2fece9746 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#20 0x00007fa2fece97eb in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /lib64/libwx_baseu-2.8.so.0
#21 0x00007fa2fece9b57 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#22 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#23 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#24 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#25 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#26 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#27 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#28 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#29 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#30 0x00007fa2fece9ae0 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-2.8.so.0
#31 0x00007fa2ff6736fc in wxWindowBase::Close(bool) () at /lib64/libwx_gtk2u_core-2.8.so.0
#32 0x00000000004478d1 in CodeBlocksApp::OnInit() ()
#33 0x00007fa2fec9274c in wxEntry(int&, wchar_t**) () at /lib64/libwx_baseu-2.8.so.0
#34 0x0000000000435fb2 in main ()
(gdb)

I do not know if this an issue in codeblocks or in wxGTK.  How can I turn off the message windows totally so the codeblocks does not invoke any wxGTK GUI code, if it is possible?

[stahta01]

I do not know if this an issue in codeblocks or in wxGTK.  How can I turn off the message windows totally so the codeblocks does not invoke any wxGTK GUI code, if it is possible?

No, unless you compile Code::Blocks and do a lot of code changes!!

Code

 /usr/bin/codeblocks /ni /ns --debug-log --$BUILD_TYPE --target=$TARGET ${WORKSPACE}.workspace

I suggest removing or replacing all the "/" options and see if the error goes away.
So, use "--no-splash-screen" instead of "/ns".
And, remove option "/ni" or replace it.

Tim S.

[oBFusCATed]

Reproduced... it seems it is pretty crashy when using batch at the moment...

On the gtk issue: no it is not possible to no use any gui functions at the moment and it is not something that is easy to fix.

[alexchen]

Thanks for confirming that.  This is a pretty serious issue for us because we use command line mode for automatic builds.
We encounter similar crash in version 13.12 occasionally, too, but 16.0 seems to be getting worse.

[Jenna]

Thanks for confirming that.  This is a pretty serious issue for us because we use command line mode for automatic builds.
We encounter similar crash in version 13.12 occasionally, too, but 16.0 seems to be getting worse.

I don't get a crash here with Code::blocks 16.01 with a very simple test workspace (just the hello world example in a workspace).
I suggest not to use the slashes ("/"), but a dash ("-") instead or remove the two options at all.
And/or try if not using the "--debug-log"-switch helps.

Can you try to (re-)install the release files from my copr-repo (https://copr.fedorainfracloud.org/coprs/jenslody/codeblocks-release/) ?
These are the exact same files as on our download server.

You can also install the debuginfo packages from there.

Or use a newer nightly from my nightly-copr and see if the issue is fixed in the meantime.

[oBFusCATed]

Without --debug-log it crashed for me again. I'm using a workspace with multiple projects in it. I'm using wx3.0 and the latest revision.
There are tons of asserts, too.

[stahta01]

Without --debug-log it crashed for me again. I'm using a workspace with multiple projects in it. I'm using wx3.0 and the latest revision.
There are tons of asserts, too.

Does it crash when building the Code::Blocks workspace?

Tim S.

[oBFusCATed]

Probably. I have a simpler workspace and I'll start fixing the problems soon.

[Jenna]

Without --debug-log it crashed for me again. I'm using a workspace with multiple projects in it. I'm using wx3.0 and the latest revision.
There are tons of asserts, too.

wx3.0 is irrelevant for this thread, the CentOS packages are build against wx2.8

[oBFusCATed]

I have a build with wx2.8 which crashes in a similar fashion.

[oBFusCATed]

The crash should have been fixed in rev 10806.
In 10807 I've fixed most of the asserts in wx30.

[alexchen]

Thanks for all the posts.  I was busy and did not get to see the replies until now.  Reading from the last post it seems the problem has been fixed?  Is there a RPM somewhere that I can try it out?
Thanks so much.

[Jenna]

Thanks for all the posts.  I was busy and did not get to see the replies until now.  Reading from the last post it seems the problem has been fixed?  Is there a RPM somewhere that I can try it out?
Thanks so much.

A build of actual trunc is currently building in my copr, see: https://copr.fedorainfracloud.org/coprs/jenslody/codeblocks/build/167669/

[alexchen]

There seems to be build failures in all platforms?

[Jenna]

There seems to be build failures in all platforms?

I know and I already committed some patches, that fix this.
A new build is for most platforms (including el7) has succeeded: https://copr.fedorainfracloud.org/coprs/jenslody/codeblocks/build/167732/