Open Jopie01 opened 2 months ago
Thanks for reporting, that's interesting to fix. Do you have some file you can share to reproduce the problem? Otherwise I can probably write a unit test to check this
Reproduced a crash with this unit test:
void TestMeasure::BRepMinDistance_TwoConfusedFaces_test()
{
const TopoDS_Face face1 = BRepBuilderAPI_MakeFace(gp_Pln(gp::XOY()));
const TopoDS_Face face2 = BRepBuilderAPI_MakeFace(gp_Pln(gp::XOY()));
try {
const MeasureDistance minDist = MeasureToolBRep::brepMinDistance(face1, face2);
QCOMPARE(minDist.value.value(), 0.);
} catch (const IMeasureError& err) {
qDebug() << QString::fromUtf8(err.message().data(), err.message().length());
}
}
In this case this is not crashing because of Standard_ConstructionError exception but by Mayo: after distance computation it checks if the OpenCascade tool used is in valid state(ie BRepExtrema_DistShapeShape::IsDone())
If not then it throws an application-level exception(IMeasureError
here)
Anyway Mayo should take care of exceptions here and report any error instead of crashing
Below a test file. Rename the extension .txt
to .step
because it's a STEP file but the extension is not supported here.
Selecting two faces will work as long as they don't overlap, but selecting a face and an edge crashes.
@Jopie01
I couldn't reproduce the crash with the test file you provided
However I pushed a change in develop
branch to handle any exception thrown by OpenCascade, so this should fix the issue
Let me know how Mayo now behaves on your side
Pulled the changes and rebuilded Mayo. Problem still exists. See attached video.
https://github.com/user-attachments/assets/629decd1-12ec-47d2-a6e7-5729dd8ced40
The error is still
terminate called after throwing an instance of 'Standard_ConstructionError'
When I open a STEP file, I also see in my terminal
TKOpenGl | Type: Other | ID: 0 | Severity: Medium | Message:
OpenGl_Window::CreateWindow: window Visual is incomplete: no depth buffer, no stencil buffer
I get the same message when using the AppImage (version 0.8.0) so I don't think it has something to do with this.
So I think I'm also waiting here for the new AppImage to see what that one does. I'm starting to suspect some graphics library which is causing trouble. Which one? No idea.
That Mayo crashes is not a huge problem (I'm just measuring things), but I wish there were an option to disable making a memory dump (is that even possible?). With bigger files this is taking quite some time and the whole PC is frozen.
Couldn't reproduce this crash on Ubuntu 20.04 with Mayo built from latest develop branch + OpenCascade 7.7.0
That would be great if you could provide here the callstack info in the memory dump
That would be great if you could provide here the callstack info in the memory dump
Problem is that I don't have any idea where that memory dump is stored. It just tells me that the program is closed and a memory dump created.
Do you have a clue where that dump possibly is stored?
This page seems to provide very useful infos: https://www.kolttonen.fi/computers_and_logic/programming/segmentation_faults_and_core_dumps_on_fedora_linux_28/segmentation_faults_and_core_dumps_on_fedora_linux_28.html
@Jopie01 There is also that page which might help you: https://askubuntu.com/questions/1349047/where-do-i-find-core-dump-files-and-how-do-i-view-and-analyze-the-backtrace-st
Try this command:
# Enable core dump files
ulimit -c unlimited
Then try to run Mayo, if it crashes it should create a core file into the same directory from where Mayo was called.
I use Mayo to open a STEP file and do some measurements and sometimes when I measure for example two faces which are parallel and exactly (I mean exactly) on each other then Mayo crashes with
Mayo can also crash when you have a face and select an edge which lies on that face and therefore the measurement is also exactly zero. Manually offsetting just a little bit (0.000001) shows 0 and doesn't crash. The quality of the BREP mesh is 'Normal'