Running Qt GUI Application on VNC cause Segmentation Fault with error message - qt

I'm trying to run a Qt 5.8 GUI application in vncviewer and I'm getting a segmentation fault.
System Configuration
Qt 5.8
Ubuntu 17.04
vncserver
Xvnc Free Edition 4.1.1 - built Feb 25 2015 23:02:21
vncviewer
TigerVNC Viewer 64-bit v1.7.0
VNC xstartup script contents:
#!/bin/sh
export XKL_XMODMAP_DISABLE=1
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
xfce4-panel &
xfsettingsd &
xfwm4 &
xfdesktop &
pcmanfm &
xfce4-terminal &
Error Message:
$ ./MyApp
QXcbConnection: Failed to initialize XRandr
Segmentation fault (core dumped)
Core Dump
Note: Had to change some paths, app names, and omissions for brevity.
(gdb) run
Starting program: $HOME/MyApp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe2023700 (LWP 5917)]
QXcbConnection: Failed to initialize XRandr
[New Thread 0x7fffd5cbc700 (LWP 5918)]
...
[omitted for brevity]
...
[New Thread 0x7fff6b32a700 (LWP 5945)]
Thread 23 "Chrome_InProcGp" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff8d7fa700 (LWP 5942)]
0x00007ffff081abba in ?? () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
(gdb) bt
#0 0x00007ffff081abba in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#1 0x00007ffff081b4bc in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#2 0x00007ffff1a51d54 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#3 0x00007ffff1a54478 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#4 0x00007ffff1a55589 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#5 0x00007ffff1a4ffd0 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#6 0x00007ffff1a5024e in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#7 0x00007ffff1a50969 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#8 0x00007ffff1a51225 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#9 0x00007ffff1a512f3 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#10 0x00007ffff19f725d in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#11 0x00007ffff19a5dbe in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#12 0x00007ffff19a694d in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#13 0x00007ffff19a6c1b in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#14 0x00007ffff19a8559 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#15 0x00007ffff19bb18a in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#16 0x00007ffff19d0c05 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#17 0x00007ffff19d0de7 in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#18 0x00007ffff19cd76d in () at /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5WebEngineCore.so.5
#19 0x00007ffff7bc06da in start_thread (arg=0x7fff8d7fa700) at pthread_create.c:456
#20 0x00007fffef6aad7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
This only happens in vncviewer of remote desktop. On the local system it runs as expected.
Please let me know if there are any workarounds.

The application needs an OpenGL context for the rendering process. It looks like it is not available on your server.
If you are running the application via ssh, try to run it with the graphical user interface integration:
ssh -X ...
This is needed because by default Qt's use the xcb backend on Linux so it needs an active X session to show something.
If it does not work, you may need to check the OpengGL support of the distribution/configuration you are running in your server.

Related

Should LWP still be running after Thread.join() returns?

I have a hung python (CPython 3.6) process. From a gdb backtrace, a forked process waits indefinitely for a mutex held by a LWP/Thread which no longer exists. After some debugging, I can see that after join() returns on the blocking Thread, its LWP is still active, with its stack unwinding with a backtrace like this:
#0 dl_open_worker (a=a#entry=0x7fffefb0eb90) at dl-open.c:515
#1 0x00007ffff7b4b2df in __GI__dl_catch_exception (exception=0x7fffefb0eb70, operate=0x7ffff7de9dc0 <dl_open_worker>, args=0x7fffefb0eb90) at dl-error-skeleton.c:196
#2 0x00007ffff7de97ca in _dl_open (file=0x7ffff77d9bc0 "libgcc_s.so.1", mode=-2147483646, caller_dlopen=0x7ffff77d7deb <pthread_cancel_init+43>, nsid=<optimised out>, argc=9, argv=<optimised out>, env=0x7fffffffe318) at dl-open.c:605
#3 0x00007ffff7b4a3ad in do_dlopen (ptr=ptr#entry=0x7fffefb0edc0) at dl-libc.c:96
#4 0x00007ffff7b4b2df in __GI__dl_catch_exception (exception=exception#entry=0x7fffefb0ed60, operate=operate#entry=0x7ffff7b4a370 <do_dlopen>, args=args#entry=0x7fffefb0edc0) at dl-error-skeleton.c:196
#5 0x00007ffff7b4b36f in __GI__dl_catch_error (objname=objname#entry=0x7fffefb0edb0, errstring=errstring#entry=0x7fffefb0edb8, mallocedp=mallocedp#entry=0x7fffefb0edaf, operate=operate#entry=0x7ffff7b4a370 <do_dlopen>, args=args#entry=0x7fffefb0edc0) at dl-error-skeleton.c:215
#6 0x00007ffff7b4a4d9 in dlerror_run (args=0x7fffefb0edc0, operate=0x7ffff7b4a370 <do_dlopen>) at dl-libc.c:46
#7 __GI___libc_dlopen_mode (name=name#entry=0x7ffff77d9bc0 "libgcc_s.so.1", mode=mode#entry=-2147483646) at dl-libc.c:195
#8 0x00007ffff77d7deb in pthread_cancel_init () at ../sysdeps/nptl/unwind-forcedunwind.c:52
#9 0x00007ffff77d7fd4 in _Unwind_ForcedUnwind (exc=0x7fffefb0fd70, stop=stop#entry=0x7ffff77d5d80 <unwind_stop>, stop_argument=0x7fffefb0ef10) at ../sysdeps/nptl/unwind-forcedunwind.c:126
#10 0x00007ffff77d5f10 in __GI___pthread_unwind (buf=<optimised out>) at unwind.c:121
#11 0x00007ffff77cdae5 in __do_cancel () at pthreadP.h:297
#12 __pthread_exit (value=<optimised out>) at pthread_exit.c:28
#13 0x00007ffff7b14504 in __pthread_exit (retval=<optimised out>) at forward.c:173
#14 0x00000000006383c5 in PyThread_exit_thread () at ../Python/thread_pthread.h:300
#15 0x00000000005e5f0f in t_bootstrap () at ../Modules/_threadmodule.c:1030
#16 0x0000000000638084 in pythread_wrapper (arg=<optimised out>) at ../Python/thread_pthread.h:205
#17 0x00007ffff77cc6db in start_thread (arg=0x7fffefb0f700) at pthread_create.c:463
#18 0x00007ffff7b0588f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Should this LWP be there at all or should it terminate before join()? If the latter, am I looking at a CPython bug?
From inspection of the source code, it seems that this is expected. From https://github.com/python/cpython/blob/master/Modules/_threadmodule.c#L1028, when a thread has finished its work, these two calls are made:
PyThreadState_DeleteCurrent();
PyThread_exit_thread();
The first ends up releasing the lock which allows join() to return; the second results in the LWP unwinding its stack.
Debugging a trivial test python script which starts a Thread, join()s it and then sends a signal to itself (which provides a convenient breakpoint which gdb can understand) shows a similar backtrace to the one in the original post, which further supports this conclusion.

Why does my Qt application lock up when I use QProcess or popen?

My Qt application is locking up with high cpu usage after running correctly for a few hours, and I'm trying to figure out why. This is on an embedded linux system.
The first thing I did was attach gdb and look at a stack backtrace. It shows the lockup occurring in ptmalloc_lock_all(), which is called by fork(). The application uses system() to play a video, and periodically uses QProcess to check whether a USB drive is mounted.
I don't intentionally use multiple threads in my application, but gdb shows 4 threads at the point where the freeze occurs. I've included the backtrace for all 4 threads:
(gdb) thread apply all backtrace
Thread 4 (Thread 995):
#0 0x4282dc50 in select () from /opt/filesys/fs/lib/libc.so.6
#1 0x4246a768 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#2 0x4246f2a8 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#3 0x4246f6e0 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#4 0x42435898 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#5 0x42435bac in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#6 0x42317834 in QThread::exec() ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#7 0x4231aaf8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x0
#8 0x4231aaf8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 3 (Thread 973):
#0 0x425c64bc in pthread_cond_wait##GLIBC_2.4 () from /opt/filesys/fs/lib/libpthread.so.0
#1 0x413f8688 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtWebKit.so.4
Cannot access memory at address 0x0
#2 0x413f8688 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtWebKit.so.4
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 949):
#0 0x4282dc50 in select () from /opt/filesys/fs/lib/libc.so.6
#1 0x4240c16c in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x3054
#2 0x4240c16c in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x3054
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 720):
#0 0x427e1194 in ptmalloc_lock_all () from /opt/filesys/fs/lib/libc.so.6
#1 0x428041c4 in fork () from /opt/filesys/fs/lib/libc.so.6
#2 0x4240fce8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#3 0x4240fce8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I'm not very experienced with multithreaded programming, but from reading online it sounds like it can be dangerous to use fork() in a multithreaded application. I'm not sure what to do as an alternative though.
Any input would be greatly appreciated!
Marlon

Qt 4.8.4 application crashes on Windows Vista while quitting

I have a Qt application which intermittently crashes while exiting on a Windows Vista machine (it works fine on Mac & Windows XP, need to try more on other Windows versions). I am doing a QApplication cleanup on exit and getting the following stack trace on crash. Please let me know if anyone gets any clue what I might be doing wrong.
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 876.0x15f0]
0x69dfb912 in QEventDispatcherWin32Private::unregisterTimer (this=0x14cdf9b8,
t=0x1a1f6868, closingDown=true) at kernel/qeventdispatcher_win.cpp:620
(gdb) bt
#0 0x69dfb912 in QEventDispatcherWin32Private::unregisterTimer (
this=0x14cdf9b8, t=0x1a1f6868, closingDown=true)
at kernel/qeventdispatcher_win.cpp:620
#1 0x69dfd479 in QEventDispatcherWin32::closingDown (this=0x14cdf998)
at kernel/qeventdispatcher_win.cpp:1115
#2 0x69cd7ff2 in QThreadPrivate::finish (arg=0x14cddb48, lockAnyway=true)
at thread/qthread_win.cpp:376
#3 0x69cd7ec8 in QThreadPrivate::start (arg=0x14cddb48)
at thread/qthread_win.cpp:348
#4 0x766f2599 in wcstombs () from C:\Windows\system32\msvcrt.dll
#5 0x766f26b3 in msvcrt!_beginthreadex () from C:\Windows\system32\msvcrt.dll
#6 0x7624d309 in KERNEL32!AcquireSRWLockExclusive ()
from C:\Windows\system32\kernel32.dll
#7 0x774b16c3 in ntdll!RtlInitializeNtUserPfn ()
from C:\Windows\system32\ntdll.dll
#8 0x774b1696 in ntdll!RtlInitializeNtUserPfn ()
from C:\Windows\system32\ntdll.dll
#9 0x00000000 in ?? ()

XCode 4.2.1 + Enable Guard Malloc -> immediate crash?

Anybody know how to solve this? With Xcode 4.2.1, turning on Enable Guard Malloc and running on iPhone Simulator 5, the app immediately crashes, and this is the stack trace:
#0 0x00000000 in <????> ()
#1 0x91594ef3 in mig_get_reply_port ()
#2 0x9158e70c in mach_ports_lookup ()
#3 0x031f0124 in _xpc_domain_init_local ()
#4 0x031edeb1 in _libxpc_initializer ()
#5 0x8fe5d15b in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#6 0x8fe5ccc0 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#7 0x8fe5a220 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#8 0x8fe5a1b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#9 0x8fe5a1b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#10 0x8fe5a1b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#11 0x8fe5a1b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#12 0x8fe5b1c0 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#13 0x8fe4f626 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#14 0x8fe53ef2 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#15 0x8fe4d2ef in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_ ()
#16 0x8fe4d063 in __dyld__dyld_start ()
You san see this answer: Application crashes on simulator 5.0 before reaching main.m
However, the linked solution didn't work for me. I had exactly the same diagnostic and absence of error message, but I found no "weak"-related issues in my project.pbxproj
However, I found that the cause of my problem was a deadlock in an +(void)initialize method.
More precisely, in this method I was calling dispatch_sync(dispatch_get_main_queue(), ^{[some block code]}). Changing this to a dispatch_async (note the "a") solved my problem.
The way I discovered the issue was accidental. While nothing seemed to happen, the "thread" navigator of Xcode was telling me that the app itself wasn't crashed. And I accidentaly clicked on "pause" in the debugger. And suddenly it stopped exactly where the deadlock was.
Enjoy.

QCoreApplication::notifyInternal Segmentation fault

Hello I'm developing a shared library in c++ and I'm testing it using a QT interface. Everything seemed ok, but suddenly the application crashed and give me the following core dump:
Program terminated with signal 11, Segmentation fault. 0 0x00401b26
in QCoreApplication::notifyInternal(QObject*, QEvent*) () from
/usr/lib/libQtCore.so.4
(gdb) bt
0 0x00401b26 in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/libQtCore.so.4
1 0x0043093a in ?? () from /usr/lib/libQtCore.so.4
2 0x009d7855 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
3 0x009db668 in ?? () from /lib/libglib-2.0.so.0
4 0x009db848 in g_main_context_iteration () from
/lib/libglib-2.0.so.0
5 0x00430565 in
QEventDispatcherGlib::processEvents(QFlags)
() from /usr/lib/libQtCore.so.4
6 0x05cedbe5 in ?? () from /usr/lib/libQtGui.so.4
7 0x00400609 in
QEventLoop::processEvents(QFlags) ()
from /usr/lib/libQtCore.so.4
8 0x00400a8a in
QEventLoop::exec(QFlags) () from
/usr/lib/libQtCore.so.4
9 0x0040500f in QCoreApplication::exec() () from
/usr/lib/libQtCore.so.4
10 0x05c2ae07 in QApplication::exec() () from /usr/lib/libQtGui.so.4
11 0x0804cd72 in main ()
I'm running in ubuntu 10.10 installed in a SD card, and I'm using QT 4.7.0. In Windows the application works ok, and in Linux too, until the application crashed at a random time. I don't know if a QT bug with ubuntu or something like that, because I have read in internet, applications with similar core dump.
Thanks!

Resources