Created attachment 1577643 [details] A simple SVG file I'm not sure if this is a Fedora problem, an upstream FreeCAD problem, a Qt problem, or somebody else's problem. So I figured I'd start here. If I attempt to open a simple SVG file as geometry, FreeCAD crashes immediately. It will import as a drawing without issues, though I'm not sure if I can use that for what I want to do (a simple extrusion that I can send to a 3D printer). I've tested on both Fedora 29 (freecad-0.18.2-3.fc29.x86_64) and 30 (freecad-0.18-2.fc30.x86_64), though for F30 you have to install python2-pivy from F29 to get far enough to try to import from SVG. Basically just start FreeCAD (from the console to see the backtrace), select File -> Open..., choose a simple SVG file (I'll attach one) and select "SVG as geometry (importSVG). For me it crashes immediately with the following backtrace: Program received signal SIGSEGV, Segmentation fault. #0 /lib64/libc.so.6(+0x38600) [0x7f9df3920600] #1 /lib64/libexpat.so.1(XML_SetHashSalt+0x23) [0x7f9decf0ede3] #2 /usr/lib64/python3.7/lib-dynload/pyexpat.cpython-37m-x86_64-linux-gnu.so(+0x7610) [0x7f9d1e39e610] #3 /lib64/libpython3.7m.so.1.0(_PyMethodDef_RawFastCallKeywords+0x25c) [0x7f9df4e2b69c] #4 /lib64/libpython3.7m.so.1.0(_PyCFunction_FastCallKeywords+0x20) [0x7f9df4e2b820] #5 /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x5c1a) [0x7f9df4e97f1a] #6 /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallKeywords+0x10a) [0x7f9df4e2ac4a] #7 /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x5d4) [0x7f9df4e928d4] #8 /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallKeywords+0x10a) [0x7f9df4e2ac4a] #9 /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x5d4) [0x7f9df4e928d4] #10 /lib64/libpython3.7m.so.1.0(_PyFunction_FastCallKeywords+0x10a) [0x7f9df4e2ac4a] #11 /lib64/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x50a9) [0x7f9df4e973a9] #12 /lib64/libpython3.7m.so.1.0(_PyEval_EvalCodeWithName+0x2f8) [0x7f9df4de29f8] #13 /lib64/libpython3.7m.so.1.0(PyEval_EvalCodeEx+0x43) [0x7f9df4de3903] #14 /lib64/libpython3.7m.so.1.0(PyEval_EvalCode+0x1b) [0x7f9df4de392b] #15 /lib64/libpython3.7m.so.1.0(+0x2399c2) [0x7f9df4f099c2] #16 /lib64/libpython3.7m.so.1.0(PyRun_StringFlags+0x7d) [0x7f9df4f09a5d] #17 0x7f9df51e0c18 in Base::InterpreterSingleton::runString[abi:cxx11](char const*) from /usr/lib64/freecad/lib/libFreeCADBase.so+0xd8 #18 0x7f9df68a036f in Gui::Command::doCommand(Gui::Command::DoCmd_Type, char const*, ...) from /usr/lib64/freecad/lib/libFreeCADGui.so+0x185 #19 0x7f9df67898eb in Gui::Application::open(char const*, char const*) from /usr/lib64/freecad/lib/libFreeCADGui.so+0x1f9 #20 0x7f9df68ad57a in StdCmdOpen::activated(int) from /usr/lib64/freecad/lib/libFreeCADGui.so+0x822 #21 0x7f9df689f9eb in Gui::Command::invoke(int) from /usr/lib64/freecad/lib/libFreeCADGui.so+0x8b #22 0x7f9df6892a57 in Gui::Action::onActivated() from /usr/lib64/freecad/lib/libFreeCADGui.so+0x21 #23 /usr/lib64/freecad/lib/libFreeCADGui.so(+0xb9d9e4) [0x7f9df68979e4] #24 0x7f9df3e2fb00 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) from /lib64/libQtCore.so.4+0x6e0 #25 0x7f9df4226cd6 in QAction::triggered(bool) from /lib64/libQtGui.so.4+0x46 #26 0x7f9df422808f in QAction::activate(QAction::ActionEvent) from /lib64/libQtGui.so.4+0xbf #27 /lib64/libQtGui.so.4(+0x6c4774) [0x7f9df4658774] #28 /lib64/libQtGui.so.4(+0x6c8d01) [0x7f9df465cd01] #29 0x7f9df4281748 in QWidget::event(QEvent*) from /lib64/libQtGui.so.4+0x3e8 #30 0x7f9df46607ff in QMenu::event(QEvent*) from /lib64/libQtGui.so.4+0x5f #31 0x7f9df422cae0 in QApplicationPrivate::notify_helper(QObject*, QEvent*) from /lib64/libQtGui.so.4+0x80 #32 0x7f9df423371c in QApplication::notify(QObject*, QEvent*) from /lib64/libQtGui.so.4+0x38c #33 0x7f9df686813b in Gui::GUIApplication::notify(QObject*, QEvent*) from /usr/lib64/freecad/lib/libFreeCADGui.so+0xff #34 0x7f9df3e1b36f in QCoreApplication::notifyInternal(QObject*, QEvent*) from /lib64/libQtCore.so.4+0x6f #35 0x7f9df4232e3b in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) from /lib64/libQtGui.so.4+0x18b #36 /lib64/libQtGui.so.4(+0x315bc6) [0x7f9df42a9bc6] #37 0x7f9df42a8390 in QApplication::x11ProcessEvent(_XEvent*) from /lib64/libQtGui.so.4+0xb50 #38 /lib64/libQtGui.so.4(+0x33b7fe) [0x7f9df42cf7fe] #39 /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x15d) [0x7f9dee0ec06d] #40 /lib64/libglib-2.0.so.0(+0x4f438) [0x7f9dee0ec438] #41 /lib64/libglib-2.0.so.0(g_main_context_iteration+0x30) [0x7f9dee0ec4d0] #42 0x7f9df3e496f9 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) from /lib64/libQtCore.so.4+0x79 #43 /lib64/libQtGui.so.4(+0x33b98b) [0x7f9df42cf98b] #44 0x7f9df3e19b23 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) from /lib64/libQtCore.so.4+0x43 #45 0x7f9df3e19dfe in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) from /lib64/libQtCore.so.4+0x11e #46 0x7f9df3e1f33e in QCoreApplication::exec() from /lib64/libQtCore.so.4+0x9e #47 0x7f9df679279a in Gui::Application::runApplication() from /usr/lib64/freecad/lib/libFreeCADGui.so+0x24a2 #48 FreeCAD(main+0xa17) [0x408033] #49 /lib64/libc.so.6(__libc_start_main+0xf3) [0x7f9df390c413] #50 FreeCAD(_start+0x2e) [0x4074ee] It appears that freecad has its own crash handler so there's no core in coredumpctl that I can poke at. I haven't yet looked into whether I can disable that. For now I'm off to see if I can do what I need to do in openscad, but I'm willing to test anything if you have ideas.
Turns out (from talk on IRC) this is pretty well known and involves some brokenness down in libCoin and expat. Here's a relevant Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874727 So this isn't really something that can easily be solved. Supposedly this would be fixed if Coin4 would ever come out, but I don't know if there's any reasonable solution besides just packaging a prerelease. That's what Debian seems to be doing (which is an unusual step for them, and points to the lack of any other useful workaround).
To do so correctly would take a new Review Request for the proposed "Coin" package. I would be against calling it Coin4 since usually adding versions to package names are reserved for older / compatibility packages. I don't have the time to work on that at the moment however.
Technically it would not take a new review request; there is a blanket exception for packages which are just different versions of existing packages. So all you'd really have to do is fedpkg request-repo and pass the --exception flag. (And create the package, of course, in a way that doesn't conflict with the existing Coin packages, which is where all the work is.) The package should also be 'coin' instead of 'Coin' but I guess that ship has long since sailed.
So I'm now facing a situation where I really do need to be able to import SVG files into FreeCAD. I've begun work on making a 'coin' package containing the prerelease of version 4 of coin. I've ended up totally rewriting the specfile as the build process is now cmake based and totally different, so I'm mainly referencing the current Debian packaging instead. (They package version 4 snapshots purely to get around the crashing issue with FreeCAD.) If I can get it all working, I will let you know but I don't know if I will attempt to make this available for general consumption. Trying to get all of the various coin packages to coexist is not entirely fun.
Ok, let me know when you have something potentially usable. I don't have a ton of time right now but I can review the package.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
Is this still a problem with the current 1.18.3 release?
Just tried... Importing as a drawing worked, but not at geometry.
Yes, I trued myself and drawing import works while geometry does not. This is a well-known issue upstream, and the solution is to get coin to build without an old bundled version expat. And that's only possible with the unreleased coin version 4. (Or at least it was unreleased when last I looked at it.) Personally I'm just using the freecad appimage. It would be nice to use the distro version but that would seem to require significant effort.
I looks like Coin4 was finally released. I'm working on building the package but I'm not quite there yet. Also I'm trying to make sure it uses the system expat.
Working on it but all the dependencies need to be rebuilt or updated to work with Coin4... For posterity: OpenSceneGraph-libs-0:3.4.1-9.fc30.x86_64 SIMVoleon-0:2.0.1-30.fc30.x86_64 SoQt-0:1.5.0-26.fc30.x86_64 freecad-1:0.18.3-1.fc30.x86_64 python3-pivy-0:0.6.5-0.1.fc30.x86_64
I've got pretty much everything building with Coin4 except Pivy... It's being difficult.
Update... I finally have FreeCAD building EXCEPT something changed with thread management in Python 3.8 so I'm stuck there at this time. If I can't build for Rawhide I can't build for F30/31...
I have what I think is a workaround for the Python 3.8 issue but building FreeCAD in Rawhide is broken for dependency issues (vtk) right now which will hopefully be fixed soon. I also have just completed the review request process for Coin 4 so I will be building it soon. Until all of that is completed, can you test freecad from my COPR? *** CAUTION *** It does replace packages in Fedora. In it I moved SoQt, SIMVoleon, python-pivy, and OpenSceneGraph over to Coin 4. So if you need to back out of it then just disable the repo and run a "dnf distro-sync". https://copr.fedorainfracloud.org/coprs/hobbes1069/FreeCAD_NEXT/
Ok, I tested the FreeCAD from my COPR and importing as Geometry worked!
So I'm not getting any consensus whether to update F31/F30 because of the major library updates so my plan is to keep the fixed version in my COPR for F30/31.
I think that's fair, though too bad about missing F31. At least it will get better in the future.
I won't rehash the discussion on the devel list, but the current maintainer of the Coin3D stack was none-to-happy about me moving all the dependencies to Coin4, even in rawhide. If I get some feedback later I will consider updating F31 but at this point I don't think F30 will happen.
*** Bug 1768118 has been marked as a duplicate of this bug. ***
Just an FYI but I plan to back down to Coin3 for F30/31. There's too many problems with the mixed Coin3/Coin4 packages. Once I get a new update submitted I'll do a pure Coin4 build in my COPR.