[SOLVED] Qt5 applications segmentation fault in Gentoo VM

[NathanZachary]

Hello,

I am running KeePassXC 2.7.1-r1 on my main workstation without any problem. However, inside of a Gentoo VirtualBox guest, I get a segfault when trying to open the GUI. Though I haven't tested all functionality, it seems like using keepassxc-cli works. I'm guessing that this could be a problem related to Qt, but I'm not certain. Has anyone else run into a similar problem with the GUI inside a VM?

Thank you.

Cheers,
Nathan Zachary
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[mike155]

Use

[NathanZachary]

Thank you for your reply. I had already run strace on it, but wasn't able to come up with any hints:

[mike155]

What does the command below return?

[NathanZachary]

I also get a lot of those blocks, and the only one that has a non-zero is right at the start of the output:

[Hu]

Although strace can help, segmentation faults are often more readily diagnosed by inspecting the core file. Is there anything useful in a gdb backtrace of the crashed process?

[NathanZachary]

Looking at the backtrace, I see:

[NathanZachary]

Okay, so it's not just KeePassXC, but Qt5 applications. As a test, I emerged app-editor/tea, which is just a simple Qt5 text editor, and it segfaults as well:

[mike155]

Thanks for the update. Now we know that it's not related to keypassxc.

The segfaults in both backtraces seem to be related to low-level graphics operations. It could be a bug in the graphics driver.

Which graphics card does your VM emulate? And which graphics driver do you use? Can you try a different version?

Do you know how gdb works? I would try to set a breakpoint at

[NathanZachary]

When stepping back after the breakpoint (using `stepi`), I get:

[Hu]

This might be easier to approach if qt5gui was built with more complete debug information, so that we could see file and line number progress as you step through it. Otherwise, you could try to map the faulting instruction to the corresponding source by hand. Either way, the goal is to understand what variable was unexpectedly null, and then find how that happened. The authors clearly expected it would never be null here; otherwise, they would have handled this gracefully.

[NathanZachary]

I enabled debugging with `-Wall -g -ggdb` added to CFLAGS, and USE="debug" for qtgui. By doing a full gdb stepi through after the break, I see the following relevant parts:

[NathanZachary]

As this problem does seem to reside within the qtgui library, I have filed the following bug for the Qt developers:

https://bugreports.qt.io/browse/QTBUG-105740
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[mike155]

Sorry for not responding earlier.

The error seems to occur here (qdrawhelper_p.h:932):

[NathanZachary]

Thank you for your response, mike155, and no worries about the delay. I wonder if it has anything to do with the problem I ran into regarding march=alderlake?:

https://forums.gentoo.org/viewtopic-t-1155713-highlight-.html
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[Hu]

Based on mike155's observation, my guess then would be that:

• This function pointer is meant to be used to point to the "best" version of the function for your CPU architecture.
• The function pointer is assumed to be always initialized to a valid value by the time it is read.
• You have found a configuration that violates that assumption, so the pointer is still nullptr (0) at the time that it is called. For reasons not yet understood, the function pointer is never written before it is used.

If you lack SSE2, this function pointer is never defined or used. If you have SSE2:

• If you lack AVX, the pointer will be set to qt_memfill32_sse2.
• If defined QT_COMPILER_SUPPORTS_AVX2 and qCpuHasFeature(ArchHaswell) succeeds, then the pointer will be set to qt_memfill32_avx2.
• Otherwise, the pointer is not written, at least by qdrawhelper.cpp. As a non-static global, it could be written from anywhere. However, I don't see any other places it is written.

[mike155]

@NathanZachary: based on Hu's analysis, please compile and run the C program "test_sse2.c" below:

[NathanZachary]

Thank you, Hu and mike155, for the suggestions. The processor definitely should have SSE2 support, but I checked just to make sure:

[Hu]

[NathanZachary]

But... but... but cats are generally useless, right? </sarcasm). Yes, it should have just been `grep sse2 /proc/cpuinfo`.

I will keep delving into the problem, and I'm also awaiting a response on the bug that I filed with the QtGUI Team. The only system on which I see this problem is a VM. All of my other systems (workstations, laptops, et cetera) do just fine with the Qt-based applications. So, it's feasible that this is a red herring and somehow tied more to a low-level graphics driver or something similar, no?

Cheers,
Nathan Zachary
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[Hu]

Based on the code I looked at before, my guess is that all of the following are true:

• Your Qt was built with __SSE2__ defined as a C preprocessor symbol, so the function pointer is used.
• Your Qt was built with __AVX2__ defined as a C preprocessor symbol, so the function pointer is not trivially set to qt_memfill32_sse2 (this is a +SSE2 -AVX2 function).
• One of:
  • Your Qt was built with QT_COMPILER_SUPPORTS_AVX2 not defined.
  • Your virtual CPU returns false for the test qCpuHasFeature(ArchHaswell).

I believe that if all those statements hold, then there will be no statements which set the function pointer to a non-nullptr value.

What is the full output of cat -n /proc/cpuinfo, as run in the guest where this library crashes?

[NathanZachary]

You absolutely may be onto something here, Hu. For this VM, I have to disable AVX2 for building Firefox (done by setting up a package.env for it). I could try building the relevant Qt packages without the AVX2 flag (just like I do for Firefox). I would imagine that is just qtcore and qtgui for this particular case, but it may also include qtsvg and qtwidgets. If you think that is worth a try, I'll give it a go as time allows.

Thanks for continuing to delve into the problem!

Cheers,
Nathan Zachary
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[Hu]

I think at this point that is your fastest option. You probably only need to rebuild the package that owns the library that is crashing.

Your other choices are to check that qCpuHasFeature(ArchHaswell) logic or wait for someone who knows this package to look at the problem. That logic appears to be in src/corelib/tools/qsimd_p.h, but you will need to chase down several layers of logic to see how it really works. That idea is also why I asked for the cpuinfo, in the hope that we could spot something that would clearly support or refute my idea about the virtual CPU failing that test.

[NathanZachary]

Okay, so I did some experimenting, and building dev-qt/qtgui without AVX2 (-mno-avx2) is what stopped the segmentation faults. Thank you very much for your help in troubleshooting.
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[NerdIII]

Thank you! This was driving me nuts trying to get a UI up and running in VirtualBox. -mno-avx2 was the solution and I can totally live with that.