View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001150 | FreeCAD | Bug | public | 2013-06-15 11:38 | 2013-06-17 09:57 |
Reporter | danielfalck | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | trunk | ||||
Fixed in Version | 0.14 | ||||
Summary | 0001150: Abort on startup | ||||
Description | I just pulled the latest from git and ran into the same issue that Yorik mentioned on the forum here: https://sourceforge.net/apps/phpbb/free-cad/viewtopic.php?f=8&t=3984#p32520 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 Information | Running Linux Mint Maya on a Lenovo laptop FreeCAD 0.14, Libs: 0.14R2183 (Git) | ||||
Tags | No tags attached. | ||||
FreeCAD Information | |||||
|
Yorik mentioned something about Qt being updated on his system- I haven't updated anything a few weeks at least on this system. |
|
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... |
|
What are your qt versions? mine is 4.8.4... |
|
the culprit seems to be this commit: https://github.com/FreeCAD/FreeCAD_sf_master/commit/b36ffe63fd98e5cfb32f461af685c88a3339b253 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. |
|
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 http://git.dev.opencascade.org/gitweb/?p=occt.git;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... |
|
hehe double post :) *EDIT* Commenting out the appropriate lines in Part/AppPart.cpp makes everything work normally again... |
|
The culprit could be this: https://sourceforge.net/p/free-cad/code/ci/b36ffe63fd98e5cfb32f461af685c88a3339b253/#diff-2 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. |
|
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: OSD::SetSignal(Standard_False); and check what it does. |
|
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 http://files.opencascade.com/delivery/download/release_notes_660beta.pdf , 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 |
|
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 |
|
git show 2dce90b should do the fix. |
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 |