Bug 197888 - devel/codeblocks: Crashes on startup with coredump when compiled with Clang (-O2)
Summary: devel/codeblocks: Crashes on startup with coredump when compiled with Clang (...
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Andriy Voskoboinyk
URL: http://newscentral.exsees.com/item/bc...
Keywords: crash, needs-qa, patch
: 214452 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-22 01:02 UTC by Roosevelt
Modified: 2018-01-18 17:52 UTC (History)
11 users (show)

See Also:
lbartoletti: maintainer-feedback+
koobs: merge-quarterly?


Attachments
Disable optimizations for wxPGProperty::Init(const wxString&, const wxString&) (480 bytes, patch)
2016-09-07 19:18 UTC, Andriy Voskoboinyk
no flags Details | Diff
Remove null references in wxPGProperty (2.92 KB, patch)
2016-10-09 23:55 UTC, Dimitry Andric
koobs: maintainer-approval? (lbartoletti)
Details | Diff
Switch to wxWidgets 3.0 (2.93 KB, patch)
2016-10-10 12:18 UTC, Andriy Voskoboinyk
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roosevelt 2015-02-22 01:02:15 UTC
Environment:
FreeBSD Current 11 amd64

Description:
codeblocks after successful compilation crashes on startup with the following output: 
Initialize EditColourSet .....
Initialize EditColourSet: done.
Abort (core dumped)

Here is the output of gdb:
(no debugging symbols found)...Initialize EditColourSet .....
Initialize EditColourSet: done.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80bc06400 (LWP 100253/codeblocks)]
0x0000000802ce80f0 in wxStringBase::operator= ()
   from /usr/local/lib/libwx_baseu-2.8.so.0
(gdb) 

How to repeat:
Install Codeblocks in any environment.

Fix:
None at this time.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2015-02-22 04:42:55 UTC
Fix Summary and notify maintainer.
Comment 2 Loïc Bartoletti freebsd_committer 2015-02-25 19:54:23 UTC
I can't reproduce it with a minimal installation (FreeBSD 10.1 xorg and codeblocks only).

It's maybe a problem with wxwidgets. Can you try to reinstall all wxwidgets?

Regards
Comment 3 Roosevelt 2015-02-26 07:25:48 UTC
Installing wxgtk28 still causes the crash. I belive wxgtk28-unicode is the problem. libwx_baseu-2.8.so
Comment 4 otacilio.neto 2016-08-07 12:31:34 UTC
I'm running codeblocks on this machine:

[ota@xareu /usr/home/ota]$ uname -a
FreeBSD xareu 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 09:52:35 UTC 2016     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

wx28-gtk2-2.8.12_6             The wxWidgets GUI toolkit with GTK+ bindings
wx28-gtk2-common-2.8.12_6      The wxWidgets GUI toolkit (common files)
virtualbox-ose-additions-4.3.38 VirtualBox additions for FreeBSD guests

and works OK.

On this another machine codeblocks crash exactly like report previously.

FreeBSD nostromo 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 29 02:27:28 UTC 2016     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

wx28-gtk2-2.8.12_6             The wxWidgets GUI toolkit with GTK+ bindings
wx28-gtk2-common-2.8.12_6      The wxWidgets GUI toolkit (common files)
wx30-gtk2-3.0.2_4              The wxWidgets GUI toolkit with GTK+ bindings
virtualbox-ose-additions-5.0.26 VirtualBox additions for FreeBSD guests

I have removed wx30-gtk2-3.0.2_4 and installed again wx28-gtk2-2.8.12_6 wx28-gtk2-common-2.8.12_6 but codeblocks still crashing on FreeBSD11 amd64. 

Both machines are guest on virtualbox.
Comment 5 Walter Schwarzenfeld freebsd_triage 2016-08-07 17:43:35 UTC
Found this, don't know if this is helpful:

http://newscentral.exsees.com/item/bcc4f53972bb272dbcfd58aae2ad52f9-ee85796e6de489d6bae1df1250ca5863
Comment 6 Daniel 2016-08-12 09:37:02 UTC
This Bug is now over one year old and i am still affected.
This port should get fixed or removed.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-12 09:48:56 UTC
This fell through the cracks because: "Can't be In Progress without a (real) Assignee" and the maintainers feedback wasn't requested

If possible, can anyone who can reproduce the crash, please include a (gdb) backtrace of the core file please, ideally with the port build WITH_DEBUG
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-12 09:50:44 UTC
Reproduction should be against the latest port version (at the time of writing 16.01)
Comment 9 Daniel 2016-08-12 10:41:12 UTC
gdb codeblocks
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run
Starting program: /usr/local/bin/codeblocks 
[New LWP 101275]
[New Thread 80f618000 (LWP 101275/codeblocks)]
Starting Code::Blocks Release 16.01  rev 10692 Aug 12 2016, 11:53:00 - wx2.8.12 (FreeBSD, unicode) - 64 bit
Initialize EditColourSet .....
Initialize EditColourSet: done.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80f618000 (LWP 101275/codeblocks)]
wxStringBase::operator= (this=0x80fe42018, stringSrc=@0x0) at ./src/common/string.cpp:778
778	./src/common/string.cpp: No such file or directory.
	in ./src/common/string.cpp
(gdb) bt
#0  wxStringBase::operator= (this=0x80fe42018, stringSrc=@0x0) at ./src/common/string.cpp:778
#1  0x0000000800e802e0 in wxPGProperty::wxPGProperty (this=0x80fe42000, label=@0x7fffffffd6c8, name=@0x0) at string.h:659
#2  0x0000000800ea3c98 in wxStringProperty::wxStringProperty (this=0x80fe42000, label=@0x80fe42018, name=@0x0, value=@0x7fffffffd6c0) at ./src/props.cpp:71
#3  0x00000000004f258b in WatchesDlg::WatchesDlg (this=0x810060580) at watchesdlg.cpp:146
#4  0x000000000045cfd1 in DebugInterfaceFactory::CreateWatches (this=<value optimized out>) at debugger_interface_creator.cpp:180
#5  0x0000000800c00ee8 in DebuggerManager::CreateWindows (this=0x8102b1d80) at debuggermanager.cpp:1007
#6  0x0000000800c01d42 in DebuggerManager::SetInterfaceFactory (this=0x8102b1d80, factory=0x80fe42018) at debuggermanager.cpp:983
#7  0x00000000004a2d47 in MainFrame::SetupDebuggerUI (this=0x80f64bd00) at main.cpp:831
#8  0x000000000049c2ff in MainFrame::CreateIDE (this=0x80f64bd00) at main.cpp:744
#9  0x000000000049ad3d in MainFrame::MainFrame (this=0x80f64bd00, parent=<value optimized out>) at main.cpp:602
#10 0x000000000044c9a6 in CodeBlocksApp::OnInit (this=0x80f615480) at app.cpp:489
#11 0x000000080566ea5d in wxEntry (argc=@0x80598ccc8, argv=0x80f646690) at ./src/common/init.cpp:432
#12 0x000000080566ec3c in wxEntry (argc=@0x7fffffffe0ac, argv=0x7fffffffe118) at ./src/common/init.cpp:460
#13 0x000000000044a994 in main (argc=0, argv=0x80fe42018) at app.cpp:322
(gdb)
Comment 10 otacilio.neto 2016-08-12 12:33:28 UTC
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/bin/codeblocks 
[New LWP 100246]
[New Thread 80c416000 (LWP 100246/codeblocks)]
Starting Code::Blocks Release 16.01  rev 10692 Aug 12 2016, 08:33:03 - wx2.8.12 (FreeBSD, unicode) - 64 bit
Initialize EditColourSet .....
Initialize EditColourSet: done.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80c416000 (LWP 100246/codeblocks)]
0x00000008052e1380 in wxStringBase::operator= () from /usr/local/lib/libwx_baseu-2.8.so.0
(gdb) backtrace
#0  0x00000008052e1380 in wxStringBase::operator= () from /usr/local/lib/libwx_baseu-2.8.so.0
#1  0x0000000800e802e0 in wxPGProperty::wxPGProperty (this=0x80de48a00, label=@0x7fffffffdff8, name=@0x0) at string.h:659
#2  0x0000000800ea3c98 in wxStringProperty::wxStringProperty (this=0x80de48a00, label=@0x0, name=@0x0, value=@0x7fffffffdff0)
    at ./src/props.cpp:71
#3  0x00000000004f258b in WatchesDlg::WatchesDlg (this=0x80d9fce00) at watchesdlg.cpp:146
#4  0x000000000045cfd1 in DebugInterfaceFactory::CreateWatches (this=<value optimized out>) at debugger_interface_creator.cpp:180
#5  0x0000000800c00ee8 in DebuggerManager::CreateWindows (this=0x80d99d100) at debuggermanager.cpp:1007
#6  0x0000000800c01d42 in DebuggerManager::SetInterfaceFactory (this=0x80d99d100, factory=0x0) at debuggermanager.cpp:983
#7  0x00000000004a2d47 in MainFrame::SetupDebuggerUI (this=0x80c449d00) at main.cpp:831
#8  0x000000000049c2ff in MainFrame::CreateIDE (this=0x80c449d00) at main.cpp:744
#9  0x000000000049ad3d in MainFrame::MainFrame (this=0x80c449d00, parent=<value optimized out>) at main.cpp:602
#10 0x000000000044c9a6 in CodeBlocksApp::OnInit (this=0x80c4d4300) at app.cpp:489
#11 0x00000008052c2dd8 in wxEntry () from /usr/local/lib/libwx_baseu-2.8.so.0
#12 0x000000000044a994 in main (argc=0, argv=0x0) at app.cpp:322
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-12 12:36:11 UTC
Please note that large text outputs (log/config/build files) should be provided as attachments instead of in comments

Thank you for providing feedback.
Comment 12 otacilio.neto 2016-08-12 12:58:30 UTC
Dear

Do you needs config and build log also?
Comment 13 Loïc Bartoletti freebsd_committer 2016-08-21 21:28:39 UTC
It seems to be a know problem (At least for some people on various linux flavors). Maybe a conflict of versions between codeblocks and wxgtk.
Comment 14 Andriy Voskoboinyk freebsd_committer 2016-09-07 19:18:45 UTC
Created attachment 174486 [details]
Disable optimizations for wxPGProperty::Init(const wxString&, const wxString&)

The patch 'fixes' the problem for me (constructor tries to compare reference
address with NULL - and comparisons are optimized away, because "A reference
shall be initialized to refer to a valid object or function" and "a null
reference cannot exist in a well-defined program"); probably, it should use
pointers instead.
Comment 15 otacilio.neto 2016-09-07 20:44:56 UTC
This fix for me also. 
Thank you very much!
Comment 16 Loïc Bartoletti freebsd_committer 2016-09-30 12:44:24 UTC
It's ok also for me. Thanks.
Comment 17 Loïc Bartoletti freebsd_committer 2016-09-30 12:45:21 UTC
Poudriere 10, 11, 16 i386/amd64 OK
Compatible with other changes: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212665
Comment 18 Dimitry Andric freebsd_committer 2016-10-09 21:20:18 UTC
(In reply to Andriy Voskoboinyk from comment #14)
> Created attachment 174486 [details]
> Disable optimizations for wxPGProperty::Init(const wxString&, const
> wxString&)
> 
> The patch 'fixes' the problem for me (constructor tries to compare reference
> address with NULL - and comparisons are optimized away, because "A reference
> shall be initialized to refer to a valid object or function" and "a null
> reference cannot exist in a well-defined program"); probably, it should use
> pointers instead.

Yes, this code is full of undefined behaviour.  It seems they also ran into problems when compiling with newer versions of gcc, see:

https://sourceforge.net/p/codeblocks/code/10875/

But this workaround is pretty bad.  They should rewrite the code to use pointers, not in the least because they seem to abuse references as if they were pointers. :)
Comment 19 Dimitry Andric freebsd_committer 2016-10-09 23:55:32 UTC
Created attachment 175592 [details]
Remove null references in wxPGProperty

Since changing all the references to pointers is very invasive, here is an alternative way of fixing this.  It replaces the null references with references to a perfectly normal wxString instance.

This should also be submitted upstream, but it seems wxPropertyGrid is pretty much dead, the last update to it was in 2011.  Maybe the Code::Blocks project is interested.
Comment 20 Jan Beich freebsd_committer 2016-10-10 05:48:35 UTC
Comment on attachment 175592 [details]
Remove null references in wxPGProperty

Don't forget to bump PORTREVISION to force package rebuild.
MFH is covered by https://wiki.freebsd.org/ports-secteam#Blanket_Approval

|poudriere bulk -t| is green on
- 9.3 i386 + 9.3 amd64 (GCC 4.2.1 patched)
- 10.1 i386 + 10.3 amd64 (Clang 3.4.1)
- 11.0 i386 (Clang 3.8)

Basic runtime check - OK on 9.3 i386 + 11.0 i386 (jail).
Comment 21 Andriy Voskoboinyk freebsd_committer 2016-10-10 12:18:59 UTC
Created attachment 175598 [details]
Switch to wxWidgets 3.0

Compiles / runs on FreeBSD 12.0-CURRENT (r306907).

> but it seems wxPropertyGrid is pretty much dead, the last update to it was in 2011

because it's a part of newer wxWidgets (2.9+).
Comment 22 Dimitry Andric freebsd_committer 2016-10-10 12:37:32 UTC
(In reply to Andriy Voskoboinyk from comment #21)
> Created attachment 175598 [details]
> Switch to wxWidgets 3.0
> 
> Compiles / runs on FreeBSD 12.0-CURRENT (r306907).
> 
> > but it seems wxPropertyGrid is pretty much dead, the last update to it was in 2011
> 
> because it's a part of newer wxWidgets (2.9+).

Very nice!  If newer wxWidgets also works for 9.x, 10.x and 11.x it is better to use that.
Comment 23 David Demelier 2016-10-14 08:47:43 UTC
(In reply to Dimitry Andric from comment #18)

Well C++ is not C, there is no reasons for using pointers. However, their conditionals are full of undefined behaviour and bad practices.

It's the first time I've seen an address to a reference compared to NULL.
Comment 24 Alexey Dokuchaev freebsd_committer 2016-10-14 13:55:40 UTC
Unfortunately, this is not the first time I've seen it.  Previously I had to hack-patch `games/gtkradiant' and `games/netradiant' to fix the startup crash when build with Clang for the same reason, by casting reference to a volatile intptr_t variable (see https://svnweb.freebsd.org/ports/head/games/gtkradiant/files/patch-radiant_treemodel.cpp).
Comment 25 Claus Reheis 2016-10-24 02:10:16 UTC
Bug still present in FreeBSD  11.0-RELEASE-p1 amd64
Comment 26 otacilio.neto 2016-10-24 20:10:53 UTC
I got this assertion with the last patch when debugging a program.

./include/wx/dynarray.h(838): assert "uiIndex < m_nCount" failed in Item().
Comment 27 Kubilay Kocak freebsd_committer freebsd_triage 2016-10-25 08:16:36 UTC
Can't be In Progress without an Assignee, this has fallen through the cracks before. See comment 7

@Andriy Jan If either one of you would like to progress this to resolution, please assign yourselves.
Comment 28 Kubilay Kocak freebsd_committer freebsd_triage 2016-10-25 08:18:29 UTC
Comment on attachment 175598 [details]
Switch to wxWidgets 3.0

@lbartoletti Please approve (using the maintainer-approval flag on the attachment) whichever one of the two attachments/patches needs to be committed.
Comment 29 otacilio.neto 2016-10-25 10:24:29 UTC
I'm getting some randomly assertions fails when closing or debugging with the last patchs. All related to tests with  m_nCount. May be this is a codeblocks problem or patch problem? With previous patch I do not got this assertions fails.
Comment 30 Andriy Voskoboinyk freebsd_committer 2017-01-22 11:35:20 UTC
Comment on attachment 175598 [details]
Switch to wxWidgets 3.0

(In reply to otacilio.neto from comment #29)
Yes, there are too many assertions when it is compiled with wx 3.0 (e.g.,
in EncodingDetector::ConvertToWxString() -> wxCSConv::wxCSConv()
L"invalid encoding value in wxCSConv ctor");
looks like https://bugs.freebsd.org/bugzilla/attachment.cgi?id=175592 is the only way to fix it for now.
Comment 31 Loïc Bartoletti freebsd_committer 2017-08-06 21:48:49 UTC
I have prepared a port for the nightly build and there is no crash (11.1 amd64). This is not a resolution, but it allows to use codeblocks. Can you test?

The port:
https://gitlab.com/lbartoletti/codeblocks

Distfile:
http://download.tuxfamily.org/bartcoding/FreeBSD/codeblocks-17.07-11112.tar.gz

Package (FreeBSD 11.1 amd64, other will be available tomorrow):
http://download.tuxfamily.org/bartcoding/FreeBSD/codeblocks-devel-17.07.txz
Comment 32 Andriy Voskoboinyk freebsd_committer 2017-08-07 00:08:47 UTC
(In reply to lbartoletti from comment #31)
Seems to be stable enough (but requires few patches to compile + pkg-plist differs for me).
Comment 33 Loïc Bartoletti freebsd_committer 2017-08-07 05:21:15 UTC
(In reply to Andriy Voskoboinyk from comment #32)
It's strange I have tested with poudriere 10, 11 and 12 i386/amd64. What are the differences?
Comment 34 Kubilay Kocak freebsd_committer freebsd_triage 2017-08-07 09:22:20 UTC
*** Bug 214452 has been marked as a duplicate of this bug. ***
Comment 35 otacilio.neto 2017-08-07 12:55:49 UTC
(In reply to lbartoletti from comment #31)

I got this error:
root@nostromo:/usr/ports/devel/codeblocks2 # make
===>   codeblocks-devel-17.07 depends on executable: zip - found
===>   codeblocks-devel-17.07 depends on executable: autoconf-2.69 - found
===>   codeblocks-devel-17.07 depends on executable: autoheader-2.69 - found
===>   codeblocks-devel-17.07 depends on executable: autoreconf-2.69 - found
===>   codeblocks-devel-17.07 depends on executable: aclocal-1.15 - found
===>   codeblocks-devel-17.07 depends on executable: automake-1.15 - found
===>   codeblocks-devel-17.07 depends on executable: libtoolize - found
===>   codeblocks-devel-17.07 depends on executable: update-desktop-database - found
===>   codeblocks-devel-17.07 depends on package: pkgconf>=1.3.0_1 - found
===>   codeblocks-devel-17.07 depends on executable: update-mime-database - found
===>   codeblocks-devel-17.07 depends on executable: gtk-update-icon-cache - found
===>   codeblocks-devel-17.07 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found
===>   codeblocks-devel-17.07 depends on file: /usr/local/bin/ccache - found
===>   codeblocks-devel-17.07 depends on shared library: libboost_system.so - found (/usr/local/lib/libboost_system.so)
===>   codeblocks-devel-17.07 depends on shared library: libfontconfig.so - found (/usr/local/lib/libfontconfig.so)
===>   codeblocks-devel-17.07 depends on shared library: libfreetype.so - found (/usr/local/lib/libfreetype.so)
===>   codeblocks-devel-17.07 depends on shared library: libhunspell-1.6.so - found (/usr/local/lib/libhunspell-1.6.so)
===>   codeblocks-devel-17.07 depends on shared library: libfam.so.0 - found (/usr/local/lib/libfam.so.0)
===>   codeblocks-devel-17.07 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>   codeblocks-devel-17.07 depends on shared library: libatk-1.0.so - found (/usr/local/lib/libatk-1.0.so)
===>   codeblocks-devel-17.07 depends on shared library: libcairo.so - found (/usr/local/lib/libcairo.so)
===>   codeblocks-devel-17.07 depends on shared library: libgdk_pixbuf-2.0.so - found (/usr/local/lib/libgdk_pixbuf-2.0.so)
===>   codeblocks-devel-17.07 depends on shared library: libglib-2.0.so - found (/usr/local/lib/libglib-2.0.so)
===>   codeblocks-devel-17.07 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>   codeblocks-devel-17.07 depends on shared library: libgtk-x11-2.0.so - found (/usr/local/lib/libgtk-x11-2.0.so)
===>   codeblocks-devel-17.07 depends on shared library: libpango-1.0.so - found (/usr/local/lib/libpango-1.0.so)
===>   codeblocks-devel-17.07 depends on shared library: libwx_baseu-2.8.so - found (/usr/local/lib/libwx_baseu-2.8.so)
===>  Configuring for codeblocks-devel-17.07
aclocal-1.15: error: configure.ac:3: file 'revision.m4' does not exist
autoreconf-2.69: aclocal failed with exit status: 1
*** Error code 1

Stop.
Comment 36 Loïc Bartoletti freebsd_committer 2017-08-07 13:05:15 UTC
Oh sorry!
I forgot to push the final version!
My apologies!

You can download again the ports.

Regards.
Comment 37 otacilio.neto 2017-08-07 15:40:43 UTC
I compiled and run on FreeBSD 11.1 AMD64 and until now is running OK.
Comment 38 Loïc Bartoletti freebsd_committer 2017-08-07 21:35:31 UTC
OK thank you.
I will propose the new port soon.

For the time being, here are the packages:
http://download.tuxfamily.org/bartcoding/FreeBSD/codeblocks/
Comment 39 Loïc Bartoletti freebsd_committer 2018-01-02 06:07:20 UTC
See bug #224835, a new version of codeblocks is released.
Comment 40 Walter Schwarzenfeld freebsd_triage 2018-01-17 07:45:42 UTC
Is this problem still  present in the newer version(s)?
Comment 41 otacilio.neto 2018-01-18 17:48:11 UTC
I did a build of codeblocks-devel using ports and works fine for me
I did a build of last version of codeblocks from ports (17.12_1) and core dump goes out.

both versions works fine for me now (amd64).
Comment 42 Walter Schwarzenfeld freebsd_triage 2018-01-18 17:51:59 UTC
Thanks, for reply.