Description of problem: FreeCAD does not work at all, it dumps core when trying to start. Version-Release number of selected component (if applicable): Installing FreeCAD with dnf pulls in these packages: freecad.x86_64 1:0.15-12.fc24 freecad-data.noarch 1:0.15-12.fc24 python-pyside.x86_64 1.2.2-5.fc24 How reproducible: always Steps to Reproduce: tigert@crypt0nite:~$ FreeCAD FreeCAD 0.15, Libs: 0.15R4671 (Git) © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2015 ##### #### ### #### # # # # # # # ## #### #### # # # # # #### # # # # # # # ##### # # # # #### #### # # # # # # # # # # # # # # ## ## ## # # #### #### ### # # #### ## ## ## Segmentation fault (core dumped)
Do you have all the OCE packages installed? I find it interesting that the only external dependency pulled in by the install was python-pyside. What is the output of the following? ldd /usr/lib64/freecad/bin/FreeCAD
I had no idea what those are, but looking at the pacakge descriptions, they look pretty essential :-) I was missing at least OCE-draw-0.16.1-7.fc24.x86_64.rpm, and OCE-devel (though that might not be needed for just running FreeCAD) but looks like the segfault is still there. I realized however that "FreeCADCmd" does work, it gives me the freecad python interpreter without segfaulting. Maybe the error is in the GUI code? Here's the ldd output: $ ldd /usr/lib64/freecad/bin/FreeCAD linux-vdso.so.1 (0x00007ffc37be1000) libFreeCADGui.so => /usr/lib64/freecad/lib/libFreeCADGui.so (0x00007ff9f1d18000) libFreeCADApp.so => /usr/lib64/freecad/lib/libFreeCADApp.so (0x00007ff9f197c000) libFreeCADBase.so => /usr/lib64/freecad/lib/libFreeCADBase.so (0x00007ff9f163e000) libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007ff9f1236000) libQtGui.so.4 => /lib64/libQtGui.so.4 (0x00007ff9f050a000) libQtXml.so.4 => /lib64/libQtXml.so.4 (0x00007ff9f02c3000) libQtCore.so.4 => /lib64/libQtCore.so.4 (0x00007ff9efdbf000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff9efa34000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff9ef81d000) libc.so.6 => /lib64/libc.so.6 (0x00007ff9ef44f000) libCoin.so.60 => /lib64/libCoin.so.60 (0x00007ff9ee943000) libQtOpenGL.so.4 => /lib64/libQtOpenGL.so.4 (0x00007ff9ee640000) libQtSvg.so.4 => /lib64/libQtSvg.so.4 (0x00007ff9ee3e6000) libQtWebKit.so.4 => /lib64/libQtWebKit.so.4 (0x00007ff9ebefa000) libQtNetwork.so.4 => /lib64/libQtNetwork.so.4 (0x00007ff9ebba8000) libboost_signals.so.1.60.0 => /lib64/libboost_signals.so.1.60.0 (0x00007ff9eb990000) libboost_system.so.1.60.0 => /lib64/libboost_system.so.1.60.0 (0x00007ff9eb78b000) libGL.so.1 => /lib64/libGL.so.1 (0x00007ff9eb51b000) libspnav.so.0 => /lib64/libspnav.so.0 (0x00007ff9eb317000) libX11.so.6 => /lib64/libX11.so.6 (0x00007ff9eafd6000) libshiboken-python2.7.so.1.2 => /lib64/libshiboken-python2.7.so.1.2 (0x00007ff9eadaa000) libxerces-c-3.1.so => /lib64/libxerces-c-3.1.so (0x00007ff9ea805000) libzipios.so.0 => /lib64/libzipios.so.0 (0x00007ff9ea5d7000) libm.so.6 => /lib64/libm.so.6 (0x00007ff9ea2cd000) libboost_program_options.so.1.60.0 => /lib64/libboost_program_options.so.1.60.0 (0x00007ff9ea056000) libboost_regex.so.1.60.0 => /lib64/libboost_regex.so.1.60.0 (0x00007ff9e9d49000) libz.so.1 => /lib64/libz.so.1 (0x00007ff9e9b33000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff9e9916000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff9e9712000) libutil.so.1 => /lib64/libutil.so.1 (0x00007ff9e950f000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007ff9e930c000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007ff9e8ffd000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007ff9e8dcb000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007ff9e8b1b000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007ff9e88c9000) libSM.so.6 => /lib64/libSM.so.6 (0x00007ff9e86c1000) libICE.so.6 => /lib64/libICE.so.6 (0x00007ff9e84a4000) libXi.so.6 => /lib64/libXi.so.6 (0x00007ff9e8294000) libXrender.so.1 => /lib64/libXrender.so.1 (0x00007ff9e808a000) libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007ff9e7e7e000) libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007ff9e7c78000) libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007ff9e7a6d000) libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007ff9e7869000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007ff9e7625000) libXext.so.6 => /lib64/libXext.so.6 (0x00007ff9e7413000) librt.so.1 => /lib64/librt.so.1 (0x00007ff9e720a000) /lib64/ld-linux-x86-64.so.2 (0x000055aa96c24000) libGLU.so.1 => /lib64/libGLU.so.1 (0x00007ff9e6f9c000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007ff9e6d8b000) libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007ff9e6b32000) libwebp.so.6 => /lib64/libwebp.so.6 (0x00007ff9e68d3000) libQtLocation.so.1 => /lib64/libQtLocation.so.1 (0x00007ff9e65fd000) libQtSensors.so.1 => /lib64/libQtSensors.so.1 (0x00007ff9e63c9000) libxslt.so.1 => /lib64/libxslt.so.1 (0x00007ff9e6189000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007ff9e5e1f000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007ff9e5a9a000) libgstapp-1.0.so.0 => /lib64/libgstapp-1.0.so.0 (0x00007ff9e588b000) libgstpbutils-1.0.so.0 => /lib64/libgstpbutils-1.0.so.0 (0x00007ff9e5656000) libgstvideo-1.0.so.0 => /lib64/libgstvideo-1.0.so.0 (0x00007ff9e53d2000) libgstaudio-1.0.so.0 => /lib64/libgstaudio-1.0.so.0 (0x00007ff9e5175000) libgstbase-1.0.so.0 => /lib64/libgstbase-1.0.so.0 (0x00007ff9e4f11000) libgstreamer-1.0.so.0 => /lib64/libgstreamer-1.0.so.0 (0x00007ff9e4be8000) libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007ff9e4910000) libssl.so.10 => /lib64/libssl.so.10 (0x00007ff9e4696000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007ff9e4235000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007ff9e4009000) libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007ff9e3e06000) libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007ff9e3c02000) libxcb-randr.so.0 => /lib64/libxcb-randr.so.0 (0x00007ff9e39f4000) libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007ff9e37ec000) libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007ff9e35e1000) libxcb-shape.so.0 => /lib64/libxcb-shape.so.0 (0x00007ff9e33dd000) libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007ff9e31d6000) libxshmfence.so.1 => /lib64/libxshmfence.so.1 (0x00007ff9e2fd2000) libglapi.so.0 => /lib64/libglapi.so.0 (0x00007ff9e2da3000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff9e2b7c000) libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007ff9e2978000) libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007ff9e2776000) libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007ff9e255d000) libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007ff9e2357000) libxcb.so.1 => /lib64/libxcb.so.1 (0x00007ff9e2135000) libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x00007ff9e1f2f000) libdrm.so.2 => /lib64/libdrm.so.2 (0x00007ff9e1d1f000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007ff9e1b06000) libicudata.so.56 => /lib64/libicudata.so.56 (0x00007ff9e0120000) libicui18n.so.56 => /lib64/libicui18n.so.56 (0x00007ff9dfca4000) libicuuc.so.56 => /lib64/libicuuc.so.56 (0x00007ff9df909000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007ff9df697000) libffi.so.6 => /lib64/libffi.so.6 (0x00007ff9df48f000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007ff9df28a000) libproj.so.9 => /lib64/libproj.so.9 (0x00007ff9df030000) libQtDeclarative.so.4 => /lib64/libQtDeclarative.so.4 (0x00007ff9dea69000) libQtScript.so.4 => /lib64/libQtScript.so.4 (0x00007ff9de59c000) libQtXmlPatterns.so.4 => /lib64/libQtXmlPatterns.so.4 (0x00007ff9ddf10000) libQtSql.so.4 => /lib64/libQtSql.so.4 (0x00007ff9ddccd000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff9ddaa6000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007ff9dd8a2000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007ff9dd687000) libgsttag-1.0.so.0 => /lib64/libgsttag-1.0.so.0 (0x00007ff9dd44b000) liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x00007ff9dd1ce000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007ff9dcf80000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007ff9dcc9a000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007ff9dca96000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007ff9dc863000) libXau.so.6 => /lib64/libXau.so.6 (0x00007ff9dc65f000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007ff9dc44f000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007ff9dc24b000)
Created attachment 1143196 [details] freecad log Here's the logfile from running "FreeCAD -l".
Ok, that doesn't show the problem but I've gotten one or two more bug reports that I need to consolidate here. The main problem is that for some reason library dependencies were not added to the RPM package on F24 but still appear fine on F23 and lower.
*** Bug 1323405 has been marked as a duplicate of this bug. ***
*** Bug 1323408 has been marked as a duplicate of this bug. ***
freecad-0.16-1.fc24 gmsh-2.12.0-2.fc24 netgen-mesher-5.3.1-11.fc24 smesh-6.6-1.fc24 OCE-0.17.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ccbaf49082
OCE-0.17.1-1.fc24, freecad-0.16-1.fc24, gmsh-2.12.0-2.fc24, netgen-mesher-5.3.1-11.fc24, smesh-6.6-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ccbaf49082
Hm, I still get a segfault on startup after the updates. Here's a backtrace if that helps anything. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff41daae0 in cc_memalloc_deallocate () from /lib64/libCoin.so.60 (gdb) bt #0 0x00007ffff41daae0 in cc_memalloc_deallocate () at /lib64/libCoin.so.60 #1 0x00007ffff43c66b6 in SoType::createType(SoType, SbName, void* (*)(), unsigned short) () at /lib64/libCoin.so.60 #2 0x00007ffff423bf0b in SoTransparencyElement::initClass() () at /lib64/libCoin.so.60 #3 0x00007ffff4221c6f in SoElement::initElements() () at /lib64/libCoin.so.60 #4 0x00007ffff4221dbf in SoElement::initClass() () at /lib64/libCoin.so.60 #5 0x00007ffff43b1b5e in SoDB::init() () at /lib64/libCoin.so.60 #6 0x00007ffff7408d34 in Gui::Application::runApplication() () at /usr/lib64/freecad/lib/libFreeCADGui.so #7 0x0000000000403121 in main () (gdb)
(what does bitcoin have to do with freecad?)
(oh, disregard :-) there are two libs called "libcoin", and looks like one of them actually has stuff to do with freecad)
Are you on f23 or f24? The f23 update hasn't been submitted yet.
On 24. It pulled new versions from updates-testing: [root@crypt0nite tigert]# dnf install --enablerepo=updates-testing freecad Last metadata expiration check: 0:00:20 ago on Sat Apr 16 14:26:20 2016. Dependencies resolved. ======================================================================================================================================== Package Arch Version Repository Size ======================================================================================================================================== Installing: Coin3 x86_64 3.1.3-16.fc24 fedora 2.5 M SIMVoleon x86_64 2.0.1-24.fc24 fedora 115 k SoQt x86_64 1.5.0-19.fc24 fedora 242 k freecad x86_64 1:0.16-1.fc24 updates-testing 19 M freecad-data noarch 1:0.16-1.fc24 updates-testing 82 M python-pivy x86_64 0.5.0-12.hg609.fc24 fedora 3.0 M python-pyside x86_64 1.2.2-5.fc24 fedora 4.3 M Transaction Summary ======================================================================================================================================== Install 7 Packages
I'll try to do some more testing, I'm still on f23 and haven't gotten everything built yet, long package dependency chain.
OCE-0.17.1-1.fc23 smesh-6.6-1.fc23 netgen-mesher-5.3.1-11.fc23 freecad-0.16-1.fc23 gmsh-2.10.1-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ddb35d63a8
Okay, we found the root of the problem while chatting with the Freecad developers at LibreGraphics meet: tigert@crypt0nite:~$ python Python 2.7.11 (default, Feb 5 2016, 01:53:41) [GCC 6.0.0 20160201 (Red Hat 6.0.0-0.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pivy Segmentation fault (core dumped) tigert@crypt0nite:~$
So I think this is a bug against the python Coin bindings that might need to be recompiled?
Ok, well the only CAD related libraries python-pivy depends on are Coin and SIMVoleon although you could throw SoQt in there. Are they thinking a simple rebuild of python-pivy will fix it?
That was their first thought. I will try rebuilding the python-pivy to see if that solves the problem.
I rebuilt the python-pivy library but it still segfaults when I do "import pivy" from python prompt. hrmph.
Sorry, to be more specific, I rebuilt the source RPM (python-pivy-0.5.0-12.hg609.fc24.src.rpm) from F24.
It shouldn't matter which srpm you use, I generally keep all supported releases up to date. I was waiting on the f23 package to his testing so I could: 1. See if it has the same problem 2. See if rebuilding python-pivy fixed it. I'm building local packages right now but it takes a while on my ole' AMD X3! Looks like you pretty much answered #2...
Okay. I managed to get it to work. I tried rebuilding python-pivy from the SRPM, did not work. I tried rebuilding Coin3 from the SRPM, and the rebuilding python-pivy, no luck. Then I installed the Coin3 from Fedora 23 (Coin3-3.1.3-11.fc23.x86_64.rpm) and it runs! So something in Coin3 changed between F23 and F24 that broke python-pivy.
Ok, that makes no sense whatsoever... I downloaded both packages (23 & 24) and did a pkgdiff on them: https://dl.dropboxusercontent.com/u/34775202/pkgdiff_reports/Coin3/3.1.3-11.fc23_to_3.1.3-16.fc24/changes_report.html
Perhaps a little closer, or a complete rabbit hole... I did a pkgdiff on the debuginfo packages and found that there was a change in the way freetype was included. Coin3 hasn't changed so it must be in freetype: https://dl.dropboxusercontent.com/u/34775202/pkgdiff_reports/Coin3-debuginfo/3.1.3-11.fc23_to_3.1.3-16.fc24/diffs/usr/src/debug/Coin-3.1.3/src/glue/freetype.cpp-diff.html https://dl.dropboxusercontent.com/u/34775202/pkgdiff_reports/Coin3-debuginfo/3.1.3-11.fc23_to_3.1.3-16.fc24/diffs/usr/src/debug/Coin-3.1.3/src/glue/freetype.h-diff.html These substitutions come from the freetype package, not Coin3, it only include freetype.h.
I think it was a rabbit hole.. The location of includes for freetype changed again in f23...
OCE-0.17.1-1.fc23, freecad-0.16-1.fc23, gmsh-2.10.1-5.fc23, netgen-mesher-5.3.1-11.fc23, smesh-6.6-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ddb35d63a8
Ok, I'm pretty much stumped so I've asked on the Fedora development list for help.
Jerry on the devel list mentioned I should try adding -fno-delete-null-pointer-checks to the build flags. Please try the scratch build here and let me know if anything changes: http://koji.fedoraproject.org/koji/taskinfo?taskID=13732624
Nope, I still get a segfault :-/
Here's a stack trace if that helps any? http://paste.fedoraproject.org/358117/ There seem to be debuginfo packages missing, however I tried to install those and dnf says they are already installed.
Basically because you've been installing other packages but with the same NEVR (Name, Epoch, Version, Release) dnf thinks they're there but gdb is saying the CRC's don't match because there from difference sources. Since my scratch build didn't help, try reinstalling Coin (and any other package you've replaced) with the ones from Fedora and try again.
Program received signal SIGSEGV, Segmentation fault. cc_memalloc_deallocate (allocator=0x0, ptr=ptr@entry=0x555555827470) at memalloc.cpp:187 187 newfree->next = allocator->free; and the backtrace is here: http://paste.fedoraproject.org/358119/46124321/ (sorry, I had to run so I did this very quick, will need to see whether I had some self-installed packages still there, I will try to cleanup things and check again tomorrow)
Umm... On F-23: [mockbuild@localhost ~]$ gdb --args python -c "import pivy" GNU gdb (GDB) Fedora 7.10.1-31.fc23 (gdb) break SbHash.h:303 No source file named SbHash.h. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (SbHash.h:303) pending. (gdb) r Starting program: /usr/bin/python -c import\ pivy Missing separate debuginfos, use: dnf debuginfo-install glibc-2.22-11.fc23.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, SbHash<short, char const*>::put (obj=<optimized out>, key=<optimized out>, this=0x55555582f200) at ../../src/misc/SbHash.h:226 226 this->resize(static_cast<unsigned int>( coin_geq_prime_number(this->size + 1))); (gdb) p *this $1 = {loadfactor = 0.75, size = 257, s = 193, threshold = 192, buckets = 0x555555831820, memhandler = 0x55555582f230} (gdb) p this->buckets[0] $2 = (SbHashEntry<short, char const*> *) 0x0 (gdb) p this->buckets[1] $3 = (SbHashEntry<short, char const*> *) 0x555555837960 (gdb) p *this->buckets[1] $4 = {key = 0x55555580a963 "SoGLViewingMatrixElement", obj = 183, next = 0x5555558372a0, memhandler = 0x55555582f230} On F-24: (gdb) p *this $17 = {loadfactor = 0.75, size = 257, s = 193, threshold = 192, buckets = 0x555555827e20, memhandler = 0x55555582b330} (gdb) p this->buckets[0] $18 = (SbHashEntry<short, char const*> *) 0x0 (gdb) p this->buckets[1] $19 = (SbHashEntry<short, char const*> *) 0x555555808810 (gdb) p *this->buckets[1] $20 = {key = 0x55555580f073 "SoGLViewingMatrixElement", obj = 183, next = 0x555555808150, memhandler = 0x0} So while on F-23 this->buckets[1]->memhander is set, while F-24 it is not.
This may fix this issue?? http://koji.fedoraproject.org/koji/taskinfo?taskID=13759034
Everyone involved, a big thank you. Mamoru, it indeed fixes the issue and FreeCAD runs too. \o/
(In reply to Mamoru TASAKA from comment #35) > This may fix this issue?? > http://koji.fedoraproject.org/koji/taskinfo?taskID=13759034 Can you check in the patch to master?
(In reply to Richard Shaw from comment #37) > (In reply to Mamoru TASAKA from comment #35) > > This may fix this issue?? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13759034 > > Can you check in the patch to master? Now pushed : http://pkgs.fedoraproject.org/cgit/rpms/Coin3.git/commit/?id=ca89ec7227943bdec800ee51b920f578fab87b05
Richard, for building on koji and bodhi submission, I would like to leave it to you.
How did the old code ever work? The original constructor left the memhandler uninitialized: SbHashEntry(const Key & key, const Type & obj) : key(key), obj(obj) {} Surely that should be fixed to at least set it to null.
(In reply to Mamoru TASAKA from comment #39) > Richard, for building on koji and bodhi submission, I would like to leave it > to you. No problem. Thanks for the assist!
OK, it should have been set in the operator new overload: void * operator new(size_t COIN_UNUSED_ARG(size), cc_memalloc * memhandler) { SbHashEntry<Type, Key> * entry = static_cast<SbHashEntry<Type, Key> *>( cc_memalloc_allocate(memhandler)); entry->memhandler = memhandler; return static_cast<void *>(entry); } So why was that not getting set in f24?
OK, I understand now. The operator new was setting memhandler before the constructor, and expecting the bits of the object to retain the previous value. That is undefined behaviour. GCC 6 adds a "clobber" in the constructor, which invalidates any previous value in the object's memory, so setting the memhandler before the constructor was optimized away. So the code was always broken, but appeared to work OK with previous GCC versions.
Well, I was about to write (In reply to Jonathan Wakely from comment #40) > How did the old code ever work? > > The original constructor left the memhandler uninitialized: > > SbHashEntry(const Key & key, const Type & obj) : key(key), obj(obj) {} > > Surely that should be fixed to at least set it to null. Well, I don't know the language (standard / specification) in detail, however you can see the below line in the patch (original code): > entry = new (this->memhandler) SbHashEntry<Type, Key>(key, obj); This first does placement new, and src/misc/SbHash.h (original): 75 class SbHashEntry { 76 public: 77 78 void * operator new(size_t COIN_UNUSED_ARG(size), cc_memalloc * memhandler) { 79 SbHashEntry<Type, Key> * entry = static_cast<SbHashEntry<Type, Key> *>( 80 cc_memalloc_allocate(memhandler)); 81 entry->memhandler = memhandler; <================= 82 return static_cast<void *>(entry); 83 } and once memhandler element is set. Then the constructor is called with SbHashEntry<Type, Key>(key, obj), initializing key and object. Here I am not sure how language treats "memhandler" member here. I guess language is free to choose whether to leave memhander untouched or clear memhandler anyway. Note that with -O0 the original code does not segfault. But this is explained by your following comment, thank you. (In reply to Jonathan Wakely from comment #43) > OK, I understand now. The operator new was setting memhandler before the > constructor, and expecting the bits of the object to retain the previous > value. That is undefined behaviour.
See "More aggressive optimization of -flifetime-dse" at https://gcc.gnu.org/gcc-6/porting_to.html for confirmation that this change in GCC is intended (and an option to disable the new optimization).
OCE-0.17.1-1.fc23, freecad-0.16-1.fc23, gmsh-2.10.1-5.fc23, netgen-mesher-5.3.1-11.fc23, smesh-6.6-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Fedora 23? Am I missing something, this bug was in 24..!
No, all the updates were attached to this bug through bodhi, I can change the status back but I'm still monitoring. We just need the f24 Coin3 build.
Ok, I think I'm going to go ahead and push the F24 update to stable, it won't fix anything but it doesn't break anything more and someone else needs the new OCE build for their package.
I requested the push to stable, it will close the bug again but I'll reopen it after that happens. I almost decided to try to edit the update to remove this BZ but I wasn't sure if it would reset the period required to push to stable so I opted not to.
OCE-0.17.1-1.fc24, freecad-0.16-1.fc24, gmsh-2.12.0-2.fc24, netgen-mesher-5.3.1-11.fc24, smesh-6.6-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
The new Coin3 release has been pushed to stable, can you confirm the problem is fixed?
I can confirm that FreeCAD on fc24 works now
It indeed works. Thanks everyone for your help!