FreeCAD 0.19_pre Crashes (SIGSEGV) on MacOS; Triggered by kicadStepUp

[berka]

When using the "add tracks" feature of kicadStepUp add-on, I get a FreeCAD crash (Segmentation Fault). I've reproduced it on 0.19.23074, but not on 0.18.4. Another user confirms the crash on 0.19.23141.
I first reported this on kicadStepUp, but the developer also thinks this is a FreeCAD bug:
https://github.com/easyw/kicadStepUpMod/issues/64
I tried isolating the responsible features in the kicad-pcb (input) file, but I was unsuccessful. Without isolation, I can't share the whole design.
I didn't find any recent related crash here. The closest (involving getNAmeInDocument) was claimed fixed in September.
Where do you want this reported?

The top of the stack at crash is:

Code: Select all

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   libFreeCADApp.dylib           	0x000000010855f070 App::DocumentObject::getNameInDocument() const + 16
1   libFreeCADGui.dylib           	0x000000010735a1f2 Gui::DocumentItem::getViewProvider(App::DocumentObject*) + 50
2   libFreeCADGui.dylib           	0x000000010735a864 Gui::TreeWidget::_slotDeleteObject(Gui::ViewProviderDocumentObject const&, Gui::DocumentItem*) + 1460
3   libFreeCADGui.dylib           	0x00000001070f0bd0 boost::signals2::detail::slot_call_iterator_t<boost::signals2::detail::variadic_slot_invoker<boost::signals2::detail::void_type, Gui::ViewProviderDocumentObject const&>, std::__1::__list_iterator<boost::shared_ptr<boost::signals2::detail::connection_body<std::__1::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot<void (Gui::ViewProviderDocumentObject const&), boost::function<void (Gui::ViewProviderDocumentObject const&)> >, boost::signals2::mutex> >, void*>, boost::signals2::detail::connection_body<std::__1::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot<void (Gui::ViewProviderDocumentObject const&), boost::function<void (Gui::ViewProviderDocumentObject const&)> >, boost::signals2::mutex> >::dereference() const + 80
4   libFreeCADGui.dylib           	0x00000001070f0951 boost::signals2::detail::signal_impl<void (Gui::ViewProviderDocumentObject const&), boost::signals2::optional_last_value<void>, int, std::__1::less<int>, boost::function<void (Gui::ViewProviderDocumentObject const&)>, boost::function<void (boost::signals2::connection const&, Gui::ViewProviderDocumentObject const&)>, boost::signals2::mutex>::operator()(Gui::ViewProviderDocumentObject const&) + 673
5   libFreeCADGui.dylib           	0x00000001071354d6 Gui::Document::slotDeletedObject(App::DocumentObject const&) + 422
6   libFreeCADApp.dylib           	0x000000010854aff0 boost::signals2::detail::slot_call_iterator_t<boost::signals2::detail::variadic_slot_invoker<boost::signals2::detail::void_type, App::DocumentObject const&>, std::__1::__list_iterator<boost::shared_ptr<boost::signals2::detail::connection_body<std::__1::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot<void (App::DocumentObject const&), boost::function<void (App::DocumentObject const&)> >, boost::signals2::mutex> >, void*>, boost::signals2::detail::connection_body<std::__1::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot<void (App::DocumentObject const&), boost::function<void (App::DocumentObject const&)> >, boost::signals2::mutex> >::dereference() const + 80
7   libFreeCADApp.dylib           	0x000000010854ab21 boost::signals2::detail::signal_impl<void (App::DocumentObject const&), boost::signals2::optional_last_value<void>, int, std::__1::less<int>, boost::function<void (App::DocumentObject const&)>, boost::function<void (boost::signals2::connection const&, App::DocumentObject const&)>, boost::signals2::mutex>::operator()(App::DocumentObject const&) + 673
8   libFreeCADApp.dylib           	0x00000001084d4671 App::Document::removeObject(char const*) + 817
9   libFreeCADApp.dylib           	0x00000001085b86eb App::DocumentPy::removeObject(_object*) + 107
...

Versions:

Code: Select all

 kicad StepUp version 9.7.1.0

OS: macOS 10.15
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23074 (Git)
Build type: Release
Branch: master
Hash: 74b866ed3022fd1452c534dae31a721bcc668f2f
Python version: 3.8.6
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

More details at:
https://github.com/easyw/kicadStepUpMod/issues/64

[berka]

If there are no objections, I will start a Mantis bug for this. I don't have a way for devs to reproduce it, but I think there is enough backtrace for investigation.

[easyw-fc]

If there are no objections, I will start a Mantis bug for this. I don't have a way for devs to reproduce it, but I think there is enough backtrace for investigation.

I would ask you to post a file which drives the crashes to have a feedback in different environment before start a mantis bug... this will help in reducing the area to solve the issue

[berka]

I explained in the kicadStepUp bug that I tried to minimize the offending input file to help identify the issue. I was unsuccessful. Without a simplified file, I can't share my original kicad-pcb file.
One notable thing was: I deleted features until the crash stopped, then I "undo" the deletes and save file. For a few runs, I was back to the original file and no crash. Then just as mysteriously as it stopped, the crash returned, with no change to input file.
So, I don't think there's much special about the input file.

[berka]

Update: It happens on the demo.kicad-pcb too.
I've put more info on the kicadStepUp bug.
However, I think this bug really belongs with FreeCAD.

[TheBum]

I'm having the same issue with the released version of FreeCAD 0.19. Here's a link to the KiCAD PCB file I'm attempting to convert to STEP:

https://www.dropbox.com/s/x0n2xg7katzac ... d_pcb?dl=0

This is a hobby project, so it's not sensitive.

[emacsimize]

Hi

Just started a hobby project were I need to mill some small PCBs and I have crashes too , Segmentation Fault ( on Linux )

here a list:
FreeCAD_0.18-16146-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage - WORKS
FreeCAD_0.19-24291-Linux-Conda_glibc2.12-x86_64.AppImage - CRASH
FreeCAD_0.19.3-Linux-Conda_glibc2.12-x86_64.AppImage - CRASH
FreeCAD_weekly-builds-26720-Linux-Conda_glibc2.12-x86_64.AppImage - CRASH

Oddly, the stable release on Windows doesn't crash FreeCAD 0.19 with latest KiCADStepup

I'm able to provide any information you might need

[emacsimize]

Hi

Just started a hobby project were I need to mill some small PCBs and I have crashes too , Segmentation Fault ( on Linux )

here a list:
FreeCAD_0.18-16146-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage - WORKS
FreeCAD_0.19-24291-Linux-Conda_glibc2.12-x86_64.AppImage - CRASH
FreeCAD_0.19.3-Linux-Conda_glibc2.12-x86_64.AppImage - CRASH
FreeCAD_weekly-builds-26720-Linux-Conda_glibc2.12-x86_64.AppImage - CRASH

Oddly, the stable release on Windows doesn't crash FreeCAD 0.19 with latest KiCADStepup

I'm able to provide any information you might need

[berka]

I wouldn’t dismiss this as not reproducible in Windows right away. My finding was that this was not reproducible in a deterministic way.

The last I left it, it was happening for me on the demo PCB. The KiCadStepUp developer couldn’t dig in because (s)he isn’t running MacOS. I also thought the underlying issue was likely in FreeCAD rather than KiCadStepUp.
I didn’t open a FreeCAD bug because I thought it was unlikely to get traction without knowing how to reproduce on an unmodified FreeCAD installation.

[emacsimize]

Do you think it makes sense to keep this thread updated with my findings , since they are Linux related, or fork this to a new topic ?

I don"t want to stress this but I think here is an issue. MacOS and Linux are somewhat related , at least in the ancient times.