Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by wandererfan »

For the lazy among us:

Code: Select all

...
testRemoval (Document.DocumentBasicCases) ... ok
testExpression (Document.DocumentExpressionCases) ... ok


testApplyFiles (Document.DocumentFileIncludeCases) ... Program received signal SIGSEGV, Segmentation fault.


#0  /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f7f331ccf20]
#1  /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyArg_ParseTupleAndKeywords+0x63) [0x7f7f35469053]
#2  0x7f7f3603f1b3 in App::Application::sOpenDocument(_object*, _object*, _object*) from /usr/local/lib/libFreeCADApp.so+0x53
#3  /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x1bb) [0x7f7f35362eab]
#4  /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x21c393) [0x7f7f35437393]
#5  /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x5170) [0x7f7f35402b70]
...
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by wandererfan »

And no, a segfault while running tests in Travis is not normal/expected.
ezzieyguywuf
Posts: 656
Joined: Tue May 19, 2015 1:11 am

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by ezzieyguywuf »

wandererfan wrote: Thu Oct 24, 2019 2:05 pm
And no, a segfault while running tests in Travis is not normal/expected.
I thought so. If the unit test fails, the Travis build should fail, right?

In this case, the seg fault caused no error. What’s more, I found a different build with a failing unit test in Path workbench , but the Travis build completed successfully.
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by wandererfan »

ezzieyguywuf wrote: Thu Oct 24, 2019 11:42 pm I thought so. If the unit test fails, the Travis build should fail, right?

In this case, the seg fault caused no error. What’s more, I found a different build with a failing unit test in Path workbench , but the Travis build completed successfully.
It looks as if the success/failure of the unit tests is based on return codes listed in a log file. Suspect the segfault in the test halts the program before the return code record is written to the log. The log checker doesn't see a bad return code, so it judges the tests to have all passed.

Looks like a bug ticket is in order.
triplus wrote:ping!
sgrogan wrote:ping!
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by sgrogan »

wandererfan wrote: Fri Oct 25, 2019 11:54 am Looks like a bug ticket is in order.
This is the first time I've seen this on Linux, it happens on Windows because we use SEH and the segfault is handled.
Bug report is good.
"fight the good fight"
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by triplus »

Until now we didn't try to fail the build if unit tests didn't pass. That should start to happen, once and if this PR gets merged:

https://github.com/FreeCAD/FreeCAD/pull/2729

BUT, now both Py3 (Clang/GCC) builds are failing, due to actually detecting the segmentation fault. ATM i don't know, if the segmentation fault happens due to toolchain or FreeCAD related issues.

Reference:
https://forum.freecadweb.org/viewtopic. ... 67#p349467
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by wmayer »

Here we are talking about two different reasons for the crash. The issue mentioned by ezzieyguywuf was fixed more than two months ago and the reason was a missing flag for the sOpenDocument function of the Python binding to support keywords.

The new crash seems to happen more or less at program start and here are the first few lines of the call stack:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
#0  /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f7a4aff2f20]
#1  /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(Py_InitModule4_64+0x2b) [0x7f7a457772eb]
#2  /usr/lib/python3/dist-packages/PySide/QtCore.cpython-36m-x86_64-linux-gnu.so(PyInit_QtCore+0x4b) [0x7f7a2e4a54cb]
#3  /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyImport_LoadDynamicModuleWithSpec+0x18c) [0x7f7a52c33dcc]
Obviously the build uses Py3 but how comes that loading a Python module pulls in Py2?

And what's also very strange is the cmake report before the build starts:

Code: Select all

==============
Summary report
==============

-- Build type:          Release
-- Compiler:            /usr/local/clang-7.0.0/bin/clang++ (7.0.0)
-- Flags:               -Wall -Wextra -Wpedantic -Wno-write-strings  -Wno-undefined-var-template
-- Python:              [/usr/bin/python3] []
-- PCL:                 not enabled
-- pybind11:            not enabled
-- Boost:               106501
-- XercesC:             [/usr/lib/x86_64-linux-gnu/libxerces-c.so] [/usr/include]
-- ZLIB:                1.2.11
-- PyCXX:               [/home/travis/build/FreeCAD/FreeCAD/src]
-- OCC:                 7.3.0 [TKFillet;TKMesh;TKernel;TKG2d;TKG3d;TKMath;TKIGES;TKSTL;TKShHealing;TKXSBase;TKBin;TKBool;TKBO;TKCDF;TKBRep;TKTopAlgo;TKGeomAlgo;TKGeomBase;TKOffset;TKPrim;TKSTEP;TKSTEPBase;TKSTEPAttr;TKHLR;TKFeat]
-- SMESH:               build internal
--  MEDFile:            [/usr/lib/x86_64-linux-gnu/libmedC.so] [/usr/include]
--  HDF5:               1.8.13
--  VTK:                7.1.1
-- NETGEN:              not enabled
-- SWIG:                3.0.12
-- Eigen3               3.3.4
-- Qt4:                 
-- QtWebKit:            found
-- Shiboken:            1.2.2 [/usr/include/shiboken]
-- PySide:              1.2.2 [/usr/include/PySide]
-- PySideTools:         [/usr/bin/pyside-uic] [/usr/bin/pyside-rcc]
-- Freetype:            2.8.1
-- OpenGLU:             /usr/lib/x86_64-linux-gnu/libGLU.so [/usr/lib/x86_64-linux-gnu/libGLU.so][/usr/include]
-- Coin3D:              [/usr/lib/x86_64-linux-gnu/libCoin.so] [/usr/include]
-- SPNAV:               [/usr/lib/libspnav.so] [/usr/include]
-- Matplotlib:          2.1.1
-- Rift:                not enabled (BUILD_VR)
-- Doxygen:             not found
=================================================
Now run 'cmake --build /home/travis/build/FreeCAD/FreeCAD/build' to build FreeCAD
This is supposed to be a Qt5 build but for some reason it seems to use Qt4 instead. You can also see that the loaded QtCore Python modules resides in /usr/lib/python3/dist-packages/PySide/ while for PySide2 & Qt5 it is here: /usr/lib/python3/dist-packages/PySide2/
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Are unit-tests enabled on travis-ci? Is this segfault normal/expected?

Post by wmayer »

Looking at the build logs to see when the crashes appear it must have happened at November, 1st. With git commit 95f18a75 all is fine but with git commit 223d41c67 it uses the wrong libraries. For the commits in between the builds were cancelled so you can't see directly the culprit.

When looking at the code changes however I have identified the culprit to be: git commit 3d7b6b354eb1f
It's this line

Code: Select all

CMAKE_OPTS="-DPYTHON_EXECUTABLE="/usr/bin/python3 -DBUILD_FEM_NETGEN=ON -DBUILD_QT5=ON"
because there are altogether three quotes and it looks like PYTHON_EXECUTABLE is set to Python3 and -DBUILD_FEM_NETGEN=ON -DBUILD_QT5=ON is used at program options. That's why CMake doesn't handle BUILD_QT5 any more.

This still doesn't explain the crash by introducing a Py2 library but that's a combination we never tested and thus I don't care about it.
Post Reply