[Crash] Sketcher: Trimming slot results in crasher

[plaes]

Managed to crash again (with Fedora nightly - 0.19.pre_23660):

1. Create a slot (and make sure the slot anchor points constrained onto the Axis line)
2. Attempt to trim:

slot-trim.png (16.22 KiB) Viewed 565 times

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
<class 'ValueError'>: Not able to trim curve with the given index: 1
App.getDocument('Unnamed').getObject('Sketch').trim(1,App.Vector(51.692898,5.974813,0))
Failed to trim edge: Not able to trim curve with the given index: 1
Program received signal SIGSEGV, Segmentation fault.
#0  /lib64/libc.so.6(+0x3da60) [0x7f9f77a0ea60]
#1  /lib64/libstdc++.so.6(__dynamic_cast+0x11) [0x7f9f77c5fcd1]
#2  0x7f9ea89c0d3d in SketcherGui::ViewProviderSketch::drawConstraintIcons() from /usr/lib64/freecad/lib64/SketcherGui.so+0xa77
#3  0x7f9ea89b1649 in SketcherGui::ViewProviderSketch::mouseMove(SbVec2s const&, Gui::View3DInventorViewer*) from /usr/lib64/freecad/lib64/SketcherGui.so+0x17d1
#4  0x7f9f7b9c6cd2 in Gui::ViewProvider::eventCallback(void*, SoEventCallback*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x4d4
#5  0x7f9f775ca0bb in SoEventCallback::handleEvent(SoHandleEventAction*) from /lib64/libCoin.so.80+0xbb
#6  0x7f9f773f1e15 in SoAction::traverse(SoNode*) from /lib64/libCoin.so.80+0x65
#7  0x7f9f7758c978 in SoChildList::traverse(SoAction*, int, int) from /lib64/libCoin.so.80+0x168
#8  0x7f9f775d3a20 in SoGroup::doAction(SoAction*) from /lib64/libCoin.so.80+0x50
#9  0x7f9f775e893c in SoSeparator::doAction(SoAction*) from /lib64/libCoin.so.80+0x2c
#10  0x7f9f7b8770e7 in Gui::SoFCUnifiedSelection::handleEvent(SoHandleEventAction*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x51
#11  0x7f9f773f1e15 in SoAction::traverse(SoNode*) from /lib64/libCoin.so.80+0x65
#12  0x7f9f7758c978 in SoChildList::traverse(SoAction*, int, int) from /lib64/libCoin.so.80+0x168
#13  0x7f9f775d3a20 in SoGroup::doAction(SoAction*) from /lib64/libCoin.so.80+0x50
#14  0x7f9f775e893c in SoSeparator::doAction(SoAction*) from /lib64/libCoin.so.80+0x2c
#15  0x7f9f773f1e15 in SoAction::traverse(SoNode*) from /lib64/libCoin.so.80+0x65
#16  0x7f9f773fb8cb in SoHandleEventAction::beginTraversal(SoNode*) from /lib64/libCoin.so.80+0xab
#17  0x7f9f773f2467 in SoAction::apply(SoNode*) from /lib64/libCoin.so.80+0xc7
#18  0x7f9f775a1cf1 in SoEventManager::actuallyProcessEvent(SoEvent const*) from /lib64/libCoin.so.80+0x71
#19  0x7f9f7b927d90 in SIM::Coin3D::Quarter::QuarterWidget::processSoEvent(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x56
#20  0x7f9f7b930991 in SIM::Coin3D::Quarter::SoQTQuarterAdaptor::processSoEvent(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x195
#21  0x7f9f7b97fb83 in Gui::View3DInventorViewer::processSoEventBase(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x23
#22  0x7f9f7b942fcd in Gui::NavigationStyle::processSoEvent(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x1c7
#23  0x7f9f7b94917d in Gui::CADNavigationStyle::processSoEvent(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x1073
#24  0x7f9f7b942d7a in Gui::NavigationStyle::processEvent(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x1be
#25  0x7f9f7b97fb58 in Gui::View3DInventorViewer::processSoEvent(SoEvent const*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x15c
#26  0x7f9f7b9204f4 in SIM::Coin3D::Quarter::EventFilter::eventFilter(QObject*, QEvent*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0x188
#27  0x7f9f78020995 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) from /lib64/libQt5Core.so.5+0xa5
#28  0x7f9f78ab7eb2 in QApplicationPrivate::notify_helper(QObject*, QEvent*) from /lib64/libQt5Widgets.so.5+0x72
#29  0x7f9f78abeeeb in QApplication::notify(QObject*, QEvent*) from /lib64/libQt5Widgets.so.5+0x4ab
#30  0x7f9f7b571201 in Gui::GUIApplication::notify(QObject*, QEvent*) from /usr/lib64/freecad/lib64/libFreeCADGui.so+0xff
#31  0x7f9f78020bd8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) from /lib64/libQt5Core.so.5+0x128
#32  0x7f9f78abdefa in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) from /lib64/libQt5Widgets.so.5+0x1da

When trying to create a simple testcase, I saw that it didn't always crash, sometimes it gave me following in the console:

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
<class 'ValueError'>: Not able to trim curve with the given index: 1
App.getDocument('Unnamed').getObject('Sketch').trim(1,App.Vector(46.292591,14.529056,0))
Failed to trim edge: Not able to trim curve with the given index: 1
Can't update constraint icons because view is not in sync with sketch
Can't update constraint icons because view is not in sync with sketch
Can't update constraint icons because view is not in sync with sketch

OS: Fedora 33 (Workstation Edition) (GNOME/gnome)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.pre_23660 (Git)
Build type: Unknown
Python version: 3.9.1
Qt version: 5.15.2
Coin version: 4.0.0a
OCC version: 7.5.0
Locale: English/United States (en_US)

[chrisb]

Moved from PartDesign module development forum. (Sketcher is not PartDesign.)

I can confirm the crash, whe clicking on an arc with tangential lines attached. They don't have to be parallel, normal crashes too. I couldn't reproduce with the lines having an arbitrary angle.

Trimming the selected arc crashes FreeCAD:

SnipScreenshot-30edf4.png (9.61 KiB) Viewed 547 times

[wmayer]

I can confirm the crash. It happens inside ViewProviderSketch::drawConstraintIcons() and the reason is that it accesses a child at an invalid position.

Code: Select all

            translationPtr = static_cast<SoTranslation *>(sep->getChild(CONSTRAINT_SEPARATOR_INDEX_SECOND_TRANSLATION));
            if(dynamic_cast<SoZoomTranslation *>(translationPtr))

The value of translationPtr is 0x1 which is a random value but the dynamic_cast then tries to access the RTTI data of the object. Because it's a dangling pointer the cast causes a segmentation fault.

Fixed with git commit 6b3936c8b

[plaes]

Cool, crash if fixed, but there's still something funky happening:

When I'm trimming any of the lines in the Sketch003:

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
<class 'ValueError'>: Not able to trim curve with the given index: 1
App.getDocument('garbage').getObject('Sketch003').trim(1,App.Vector(-12.099010,12.249093,0))
Failed to trim edge: Not able to trim curve with the given index: 1

[chrisb]

Cool, crash if fixed, but there's still something funky happening:

There is nothing to trim in a slot. What do you expect?

[davidosterberg]

There is nothing to trim in a slot. What do you expect?

Perhaps deleting the line segment would be a more sensible behavior than the current behavior. I think it would be logically more consistent, and perhaps a litttle useful, because when you do a lot of trimming it sometimes happens that you have to delete stuff with delete key afterwards.

I dunno

[plaes]

Cool, crash if fixed, but there's still something funky happening:

There is nothing to trim in a slot. What do you expect?

It shouldn't "crash" (throwing a unhandled exception) - ValueError should be handled by the caller.

[chrisb]

An error shown in report view is not a crash. A crash is, when the program all of a sudden terminates unexpectedly.

[GeneFC]

Perhaps deleting the line segment would be a more sensible behavior than the current behavior. I think it would be logically more consistent, and perhaps a litttle useful, because when you do a lot of trimming it sometimes happens that you have to delete stuff with delete key afterwards.

This seems like very bad behavior. The role of Trim is well defined in the wiki. To ask the Trim operation to take on a new undocumented role, even if it may be "useful" in some cases, is asking for trouble.

I greatly prefer that an operation used incorrectly simply throws an error message.

Gene

[davidosterberg]

This seems like very bad behavior. The role of Trim is well defined in the wiki. To ask the Trim operation to take on a new undocumented role, even if it may be "useful" in some cases, is asking for trouble.

I don't see why it would have to be undocumented, if we would decide to change it.

Also, I think the definition in the wiki is not exactly consistent with the behavior anyway:

Code: Select all

3. The line segment will be trimmed to the nearest overlapping line(s). 

Not true. In addition to overlapping lines, trim will also consider the nearest tangent point with another line, and the nearest point-on-curve location, as trim points, as long as the trim point does not lie on the end point of the curve being trimmed. If we consider point-on-curve to be overlapping, then I don't see why coincident should not be considered overlapping.

I think the current behavior is due to that this case is not handled in the code. Hence why we get an uncaught exception.