View Issue Details

IDProjectCategoryView StatusLast Update
0001150FreeCADBugpublic2013-06-17 09:57
Reporterdanielfalck Assigned To 
Status closedResolutionfixed 
Product Versiontrunk 
Fixed in Version0.14 
Summary0001150: Abort on startup
DescriptionI just pulled the latest from git and ran into the same issue that Yorik mentioned on the forum here:

I did a 'make clean' and rebuild and removed the .FreeCAD/ directory from my home directory and still get this while trying to start FreeCAD:

*** Abort *** an exception was raised, but no catch was found.
Additional InformationRunning Linux Mint Maya on a Lenovo laptop

FreeCAD 0.14, Libs: 0.14R2183 (Git)

TagsNo tags attached.
FreeCAD Information



2013-06-15 11:40

reporter   ~0003205

Yorik mentioned something about Qt being updated on his system- I haven't updated anything a few weeks at least on this system.


2013-06-15 11:57

administrator   ~0003207

I have this behaviour too now on an Ubuntu 12.04 64-bit. The FreeCAD version before was 10 days old and didn't show this behaviour. So, it must be a regression from the past few days...


2013-06-15 12:18

administrator   ~0003208

What are your qt versions? mine is 4.8.4...


2013-06-15 12:37

reporter   ~0003209

the culprit seems to be this commit:

I rolled back to the commit just prior to this and FreeCAD opens without aborting. When I move to this commit, it aborts with the same message as in the original not in this issue.


2013-06-15 12:38

administrator   ~0003210

Looks like the bug is produced by commit b36ffe63fd98e5cfb32f461af685c88a3339b253 from 12th of June - "Activate OSD signals on Linux". That commit just uses an OSD function "SetSignal()", and indeed in the OCC code you see that function yields exactly that error message: SIGFPE Arithmetic exception detected;a=blobdiff;f=src/OSD/OSD_signal.cxx (look for arithmetic)

A further indication is that freecad crashes at startup when a part-based workbench is set as startup workbench, but not if any other module (startup, image) is the startup module.

I couldn't really figure out what is that OSD stuff for and if we can remove it, I'll see if it works by just commenting out the lines...


2013-06-15 12:39

administrator   ~0003211

Last edited: 2013-06-15 12:43

hehe double post :)

*EDIT* Commenting out the appropriate lines in Part/AppPart.cpp makes everything work normally again...


2013-06-15 12:44

administrator   ~0003212

The culprit could be this:

The behaviour is that any module that has a dependency to Part and you load this module (e.g. PartDesign, Sketcher, Draft, ...) without having loaded Part before then it crashes. If you have Part already loaded (e.g. "import Part" or loading the workbench) there is no crash. According to the error message there must have been thrown an exception which however cannot be forwarded through a C library (namely Python). The system then says it's an unhandled exception and terminates FreeCAD.

So, the main question is by what the exception is caused and why does it happen when Part is not loaded.

Then there is another issue. The Draft module seems to load the Part module already at startup (that's why FreeCAD crashes even if e.g. Start is the default workbench). So, this by itself is not the desired behaviour.

The error message about the floating point exception inside Qt can be safely ignored.


2013-06-15 13:20

administrator   ~0003213

OSD::SetSignal() is supposed to be a nice feature of OpenCascade because it's a mechanism to convert system signals (especially SIGSEGV = segmentation fault) into C++ exceptions. This way FreeCAD won't crash any more due to critical bugs in OCC (given that it starts at all :D)

I have tested this feature on a 32-bit Linux with test cases where OCC crashes. After activating SetSignal() all the crashes didn't happen any more. My guess, is that this only happens on a 64-bit OS!?

Once I tested this on Windows 64-bit (a year ago) I also had totally undefined behaviour. But now after using 'Standard_False' as argument (which switches off the FPE stuff) everything seems to work normally.

And about the actual reason of the mysterious crash: deep inside the math module of Python a table of special values is set up, also some invalid float numbers. And this must have caused to trigger the FPE handler which throws a C++ exception inside the C library which is not a good idea (see above post).

So, you guys can try:
and check what it does.


2013-06-15 14:12

administrator   ~0003214

Indeed, using OSD::SetSignal(Standard_False); works for me... It's true, the way you show it, OSD::SetSignal() looks useful... It is anyway apparently an OCC bug. There seem to have been some work on that in OCC 6.6, looking at , but I think I'm still using a 6.5-based OCE... I'll try to upgrade and see if the problem is still there


2013-06-15 18:15

administrator   ~0003220

Today FreeCAD on 32-bit Linux crashed too. Strange that it worked a few days ago. Anyway, setting the argument to Standard_False fixes it.

With OCC 6.6 there is no change in the behaviour. All what it additionally shows is the exception itself:
*** Abort *** an exception was raised, but no catch was found.
    ... The exception is:SIGFPE Arithmetic exception detected


2013-06-15 18:27

administrator   ~0003221

git show 2dce90b should do the fix.

Issue History

Date Modified Username Field Change
2013-06-15 11:38 danielfalck New Issue
2013-06-15 11:40 danielfalck Note Added: 0003205
2013-06-15 11:57 wmayer Note Added: 0003207
2013-06-15 12:18 yorik Note Added: 0003208
2013-06-15 12:37 danielfalck Note Added: 0003209
2013-06-15 12:38 yorik Note Added: 0003210
2013-06-15 12:39 yorik Note Added: 0003211
2013-06-15 12:43 yorik Note Edited: 0003211
2013-06-15 12:44 wmayer Note Added: 0003212
2013-06-15 13:20 wmayer Note Added: 0003213
2013-06-15 14:12 yorik Note Added: 0003214
2013-06-15 18:15 wmayer Note Added: 0003220
2013-06-15 18:27 wmayer Note Added: 0003221
2013-06-17 09:57 wmayer Status new => closed
2013-06-17 09:57 wmayer Resolution open => fixed
2013-06-17 09:57 wmayer Fixed in Version => 0.14