Bug 197888
| Summary: | devel/codeblocks: Crashes on startup with coredump when compiled with Clang (-O2) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Roosevelt <knowledgeispower80> | ||||||||
| Component: | Individual Port(s) | Assignee: | Andriy Voskoboinyk <avos> | ||||||||
| Status: | Closed Overcome By Events | ||||||||||
| Severity: | Affects Many People | CC: | avos, d.stoye, danfe, demelier.david, dim, jt, koobs, lbartoletti, otacilio.neto, rehcla.mail, w.schwarzenfeld | ||||||||
| Priority: | --- | Keywords: | crash, needs-qa, patch | ||||||||
| Version: | Latest | Flags: | lbartoletti:
maintainer-feedback+
koobs: merge-quarterly? |
||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| URL: | http://newscentral.exsees.com/item/bcc4f53972bb272dbcfd58aae2ad52f9-ee85796e6de489d6bae1df1250ca5863 | ||||||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212665 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221703 |
||||||||||
| Attachments: |
|
||||||||||
|
Description
Roosevelt
2015-02-22 01:02:15 UTC
Fix Summary and notify maintainer. 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 Installing wxgtk28 still causes the crash. I belive wxgtk28-unicode is the problem. libwx_baseu-2.8.so 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. Found this, don't know if this is helpful: http://newscentral.exsees.com/item/bcc4f53972bb272dbcfd58aae2ad52f9-ee85796e6de489d6bae1df1250ca5863 This Bug is now over one year old and i am still affected. This port should get fixed or removed. 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 Reproduction should be against the latest port version (at the time of writing 16.01) 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) (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
Please note that large text outputs (log/config/build files) should be provided as attachments instead of in comments Thank you for providing feedback. Dear Do you needs config and build log also? 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. 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.
This fix for me also. Thank you very much! It's ok also for me. Thanks. Poudriere 10, 11, 16 i386/amd64 OK Compatible with other changes: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212665 (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. :) 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 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). 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+). (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. (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. 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). Bug still present in FreeBSD 11.0-RELEASE-p1 amd64 I got this assertion with the last patch when debugging a program. ./include/wx/dynarray.h(838): assert "uiIndex < m_nCount" failed in Item(). 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 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.
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 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. 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 (In reply to lbartoletti from comment #31) Seems to be stable enough (but requires few patches to compile + pkg-plist differs for me). (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? *** Bug 214452 has been marked as a duplicate of this bug. *** (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. Oh sorry! I forgot to push the final version! My apologies! You can download again the ports. Regards. I compiled and run on FreeBSD 11.1 AMD64 and until now is running OK. 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/ See bug #224835, a new version of codeblocks is released. Is this problem still present in the newer version(s)? 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). Thanks, for reply. |
