Sketch causes segfault on one computer but not another

[openBrain]

I've attached the output from valgrind sans -v.

Had a quick look. Not a lot of information but may explain why it behaves differently between both computers. The segmentation fault is triggered by a stack overflow :

Code: Select all

==18200== Process terminating with default action of signal 11 (SIGSEGV)
==18200==  Access not within mapped region at address 0x1FFE800CB8
==18200== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==18200==    at 0x6F9CA2E: QTextEngine::itemize() const (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.12.8)
==18200==  If you believe this happened as a result of a stack
==18200==  overflow in your program's main thread (unlikely but
==18200==  possible), you can try to increase the size of the
==18200==  main thread stack using the --main-stacksize= flag.
==18200==  The main thread stack size used in this run was 8388608.
==18200== Stack overflow in thread #1: can't grow stack to 0x1ffe801000

As indicated in the latest lines, you can try to increase the stack size to check if it solves the issue.

The crash is 10's of MB...

Trace can be caught with gdb

Code: Select all

gdb FC_EXECUTABLE -c COREFILE

Then in gdb, run 'bt' command

[chrisb]

How about using a plain vanilla config with no addons on both systems?

[drmacro]

...
As indicated in the latest lines, you can try to increase the stack size to check if it solves the issue.

The crash is 10's of MB...

Trace can be caught with gdb

Code: Select all

gdb FC_EXECUTABLE -c COREFILE

Then in gdb, run 'bt' command

I saw the stack errors and wondered about that.

And, how is the stack effected by a change in the units?

I.e. no stack issue when using MKS, but stack issues when using Standard?




And, gdb says "/var/crash/_usr_lib_freecad-daily_bin_freecad-python3.1000.crash" is not a core dump.

[openBrain]

And, gdb says "/var/crash/_usr_lib_freecad-daily_bin_freecad-python3.1000.crash" is not a core dump.

Yep, crash files from Apport need to be unpacked to extract the core dump :https://askubuntu.com/questions/434431/ ... -var-crash

[drmacro]

...
Yep, crash files from Apport need to be unpacked to extract the core dump :https://askubuntu.com/questions/434431/ ... -var-crash

Ok, so did all that.

gdb on the valgrind crash file produced nothing other than to say it was a seg fault.

Is this because the executable is a release build?

Do I just change:

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release ~/freecad-source

To:

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Debug ~/freecad-source

[openBrain]

And, how is the stack effected by a change in the units?

QTextEngine::itemize() is implied in font rendering. So changing the unit can change the display of the dimensional constraints and affect a crash happening.
It is probably also due to GFX chipset, screen resolution, ...
Internet is full of such cases (just search 'QTextEngine itemize crash') but in all cases they aren't reproducible and I didn't find any evidence that Qt did something to fix it (yes, it is very probably a crash that happens deep in Qt).
Though I saw few interesting clues :
* You're not the first that see that in FC : https://forum.freecadweb.org/viewtopic.php?t=8162 In this case setting the MDI view to 'Cascade' rather than full solved the issue. I guess 'Tiled' mode or even reducing a bit the window size may also have an effect.
* In this forum topic (https://openclassrooms.com/forum/sujet/ ... show-38716), while the solution isn't applicable here, it was found the culprit to be 'setFont()' function. I had a quick search and found 2 occurences in Sketcher.

More investigation later, but ATM running out of time for other activities.

Do I just change:

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release ~/freecad-source

To:

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Debug ~/freecad-source

I'm not a cmake expert, but should be something like this. You can also use cmake-gui to change the parameter value then generate/configure.