View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004020||FreeCAD||Bug||public||2019-06-14 07:23||2019-06-14 17:16|
|Target Version||Fixed in Version|
|Summary||0004020: untrapped file error on start up.|
|Description||Due to manual changes to file ownerships, some file has become a problem when starting FreeCAD. However, the error does not seem to be trapped at the point where the file is accessed and just bubbles up to be caught as an untrapped error which is so general as to not be any help in identifying and resolving the problem |
connect failed: No such file or directory
Unhandled std::exception caught in GUIApplication::notify.
The error message is: Permission denied
An error report which stated the full file path and name would allow this to be fixed immediately.
It seems that whatever function is attempting this file access is not trapping any file access errors and assumes it always works.
While the cause in this case is outside FreeCAD, it seems it should trap any errors in file access.
|Tags||No tags attached.|
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15303 (Git)
Build type: Release
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)
@freman as required in the bug submission guidelines, could you please confirm bug is still present in the latest release version (yours is outdated) ?
If possible, could also provide a way to reproduce the issue ?
yes, still present on new build of 0.19 master today.
However, as discussed in thread, there are two things happening here. The file permissions problem disappeared after a reboot, so the cause will be undetermined unless it happens again.
the other connection message seems to be be LVM related coming from Qt. It is probably banal.
This still reflects the need for better error trapping at a lower level, though it will not be possible to work out exactly where in this case until and unless it reoccurs. It seems some file access was being attempted without the success being tested. Knowing what file it was would have enabled it being resolved in minutes instead of not detected properly after hours.
If I see it again , I will report back.