Bug 1323159 - FreeCad segfalts on startup.
Summary: FreeCad segfalts on startup.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freecad
Version: 24
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Richard Shaw
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1323405 1323408 (view as bug list)
Depends On: 1329814
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-01 12:17 UTC by Tuomas Kuosmanen
Modified: 2019-01-09 12:54 UTC (History)
6 users (show)

Fixed In Version: freecad-0.16-1.fc23 freecad-0.16-1.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-07 12:09:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
freecad log (5.68 KB, application/octet-stream)
2016-04-04 07:14 UTC, Tuomas Kuosmanen
no flags Details

Description Tuomas Kuosmanen 2016-04-01 12:17:29 UTC
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)

Comment 1 Richard Shaw 2016-04-01 12:54:41 UTC
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

Comment 2 Tuomas Kuosmanen 2016-04-04 07:09:07 UTC
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)

Comment 3 Tuomas Kuosmanen 2016-04-04 07:14:01 UTC
Created attachment 1143196 [details]
freecad log

Here's the logfile from running "FreeCAD -l".

Comment 4 Richard Shaw 2016-04-04 12:30:53 UTC
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.

Comment 5 Richard Shaw 2016-04-04 12:31:52 UTC
*** Bug 1323405 has been marked as a duplicate of this bug. ***

Comment 6 Richard Shaw 2016-04-04 12:31:58 UTC
*** Bug 1323408 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Update System 2016-04-14 14:33:35 UTC
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

Comment 8 Fedora Update System 2016-04-15 08:37:11 UTC
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

Comment 9 Tuomas Kuosmanen 2016-04-16 10:24:39 UTC
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)

Comment 10 Tuomas Kuosmanen 2016-04-16 10:26:55 UTC
(what does bitcoin have to do with freecad?)

Comment 11 Tuomas Kuosmanen 2016-04-16 10:30:26 UTC
(oh, disregard :-) there are two libs called "libcoin", and looks like one of them actually has stuff to do with freecad)

Comment 12 Richard Shaw 2016-04-16 12:27:49 UTC
Are you on f23 or f24? The f23 update hasn't been submitted yet.

Comment 13 Tuomas Kuosmanen 2016-04-16 13:27:32 UTC
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

Comment 14 Richard Shaw 2016-04-16 13:28:39 UTC
I'll try to do some more testing, I'm still on f23 and haven't gotten everything built yet, long package dependency chain.

Comment 15 Fedora Update System 2016-04-16 15:32:54 UTC
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

Comment 16 Tuomas Kuosmanen 2016-04-17 10:38:29 UTC
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:~$

Comment 17 Tuomas Kuosmanen 2016-04-17 10:39:07 UTC
So I think this is a bug against the python Coin bindings that might need to be recompiled?

Comment 18 Richard Shaw 2016-04-17 12:02:21 UTC
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?

Comment 19 Tuomas Kuosmanen 2016-04-17 13:27:50 UTC
That was their first thought. I will try rebuilding the python-pivy to see if that solves the problem.

Comment 20 Tuomas Kuosmanen 2016-04-17 13:56:41 UTC
I rebuilt the python-pivy library but it still segfaults when I do "import pivy" from python prompt. hrmph.

Comment 21 Tuomas Kuosmanen 2016-04-17 13:57:32 UTC
Sorry, to be more specific, I rebuilt the source RPM (python-pivy-0.5.0-12.hg609.fc24.src.rpm) from F24.

Comment 22 Richard Shaw 2016-04-17 14:04:43 UTC
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...

Comment 23 Tuomas Kuosmanen 2016-04-17 14:26:19 UTC
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.

Comment 24 Richard Shaw 2016-04-17 14:32:51 UTC
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

Comment 25 Richard Shaw 2016-04-17 14:59:17 UTC
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.

Comment 26 Richard Shaw 2016-04-17 19:27:52 UTC
I think it was a rabbit hole.. The location of includes for freetype changed again in f23...

Comment 27 Fedora Update System 2016-04-18 04:52:18 UTC
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

Comment 28 Richard Shaw 2016-04-20 02:51:35 UTC
Ok, I'm pretty much stumped so I've asked on the Fedora development list for help.

Comment 29 Richard Shaw 2016-04-20 13:05:55 UTC
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

Comment 30 Tuomas Kuosmanen 2016-04-21 11:05:40 UTC
Nope, I still get a segfault :-/

Comment 31 Tuomas Kuosmanen 2016-04-21 12:42:24 UTC
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.

Comment 32 Richard Shaw 2016-04-21 12:50:24 UTC
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.

Comment 33 Tuomas Kuosmanen 2016-04-21 12:54:48 UTC
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)

Comment 34 Mamoru TASAKA 2016-04-22 06:03:42 UTC
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.

Comment 35 Mamoru TASAKA 2016-04-22 08:25:44 UTC
This may fix this issue??
http://koji.fedoraproject.org/koji/taskinfo?taskID=13759034

Comment 36 Tuomas Kuosmanen 2016-04-22 10:46:09 UTC
Everyone involved, a big thank you. Mamoru, it indeed fixes the issue and FreeCAD runs too. \o/

Comment 37 Richard Shaw 2016-04-22 12:42:26 UTC
(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?

Comment 38 Mamoru TASAKA 2016-04-22 12:55:06 UTC
(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

Comment 39 Mamoru TASAKA 2016-04-22 12:57:37 UTC
Richard, for building on koji and bodhi submission, I would like to leave it to you.

Comment 40 Jonathan Wakely 2016-04-22 12:58:53 UTC
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.

Comment 41 Richard Shaw 2016-04-22 13:00:32 UTC
(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!

Comment 42 Jonathan Wakely 2016-04-22 13:02:10 UTC
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?

Comment 43 Jonathan Wakely 2016-04-22 13:09:37 UTC
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.

Comment 44 Mamoru TASAKA 2016-04-22 13:12:25 UTC
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.

Comment 45 Jonathan Wakely 2016-04-22 14:08:50 UTC
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).

Comment 46 Fedora Update System 2016-04-25 23:53:10 UTC
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.

Comment 47 Tuomas Kuosmanen 2016-04-26 06:47:33 UTC
Fedora 23? Am I missing something, this bug was in 24..!

Comment 48 Richard Shaw 2016-04-26 12:34:48 UTC
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.

Comment 49 Richard Shaw 2016-04-27 12:39:14 UTC
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.

Comment 50 Richard Shaw 2016-04-27 13:01:20 UTC
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.

Comment 51 Fedora Update System 2016-05-07 12:09:28 UTC
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.

Comment 52 Richard Shaw 2016-05-25 18:19:17 UTC
The new Coin3 release has been pushed to stable, can you confirm the problem is fixed?

Comment 53 Przemek Klosowski 2016-05-25 19:34:34 UTC
I can confirm that FreeCAD on fc24 works now

Comment 54 Tuomas Kuosmanen 2016-05-26 07:11:53 UTC
It indeed works. Thanks everyone for your help!


Note You need to log in before you can comment on or make changes to this bug.