I am seeing that if I run a QT application on Ubuntu desktop edition I am able to run the application. If I take the same application and try and run it on Ubuntu server edition I am seeing a crash when starting the QT application. So far I have seen that I need to set QT to render offscreen with setting this environmental variable:
export QT_QPA_PLATFORM=offscreen
And then when I run the application I get this stack trace with the application crashing:
Thread 3 "hmi" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fa8700 (LWP 18084)]
0x00007fffdf88decb in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
(gdb) bt
#0 0x00007fffdf88decb in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
#1 0x00007fffdf88e283 in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
#2 0x00007ffff399a78d in QOpenGLContext::create() () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#3 0x00007ffff41d2a67 in ?? () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Quick.so.5
#4 0x00007ffff41d32d2 in ?? () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Quick.so.5
#5 0x00007ffff39633ea in QWindow::event(QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#6 0x00007ffff4206553 in QQuickWindow::event(QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Quick.so.5
#7 0x00007ffff4eb25ca in QCoreApplication::notify(QObject*, QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#8 0x00007ffff4eb2720 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#9 0x00007ffff3958c69 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#10 0x00007ffff39597fd in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#11 0x00007ffff393aad3 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#12 0x00007fffdf88e3f0 in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
#13 0x00007fffe9eb3197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007fffe9eb33f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007fffe9eb349c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff4f01f07 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#17 0x00007ffff4eb076a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#18 0x00007ffff4eb85fd in QCoreApplication::exec() () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
I take the same application and run with offscreen set and on the desktop edition I am not seeing the same crash. I do not see much info about the QT library libqoffscreen.so and cannot find symbols for the prebuilt libraries to get a better stack trace. Is there anything that I may need to install on the Ubuntu server to allow me to run this QT application?
You’re trying to use Qt Quick, and this won’t work with the offscreen platform, as there’s no OpenGL support there. I don’t understand why you’d want to run such an application headless – it won’t be useful, presumably. Since it your code, you shouldn’t be showing the GUI in the headless mode: either add a command option to start without the GUI, or disable the GUI code using compile options (e.g. a macro passed from the makefile).
Related
Recently I upgraded my OS from Ubuntu Precise Saucy (13.10) to Trusty (14.04). After this upgrade, cv::VideoCapture became not working properly. The program aborts when reading a video file. For example,
int main(int argc, char**argv)
{
cv::VideoCapture vin("sample/vout2l.avi");
...
Executing this program, it aborts with a message:
*** Error in `./cv2-videoread.out': malloc(): memory corruption: 0x0000000000e3eff0 ***
Abort (core dumped)
The backtrace looks like:
[New LWP 15586]
[New LWP 15587]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./cv2-videoread.out'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff953e61c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ff953e61c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ff953e65028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ff953e9e2a4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ff953eabe26 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ff953eac1ab in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5 0x00007ff953eadba4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#6 0x00007ff953eaf7d2 in posix_memalign () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007ff94fa640fe in av_malloc () from /usr/lib/x86_64-linux-gnu/libavutil.so.52
#8 0x00007ff94fa641b1 in av_strdup () from /usr/lib/x86_64-linux-gnu/libavutil.so.52
#9 0x00007ff94fa5e5db in av_dict_set ()
from /usr/lib/x86_64-linux-gnu/libavutil.so.52
#10 0x00007ff954738574 in CvCapture_FFMPEG::open(char const*) ()
from /usr/lib/libopencv_highgui.so.2.4
#11 0x00007ff954738719 in cvCreateFileCapture_FFMPEG ()
from /usr/lib/libopencv_highgui.so.2.4
#12 0x00007ff95473aac9 in cvCreateFileCapture_FFMPEG_proxy(char const*) ()
from /usr/lib/libopencv_highgui.so.2.4
---Type <return> to continue, or q <return> to quit---
#13 0x00007ff954722d89 in cvCreateFileCapture ()
from /usr/lib/libopencv_highgui.so.2.4
#14 0x00007ff954723045 in cv::VideoCapture::open(std::string const&) ()
from /usr/lib/libopencv_highgui.so.2.4
#15 0x00007ff95472315c in cv::VideoCapture::VideoCapture(std::string const&) ()
from /usr/lib/libopencv_highgui.so.2.4
#16 0x0000000000401281 in main (argc=1, argv=0x7fff1f938388) at cv2-videoread.cpp:30
(gdb)
NOTE: cv::VideoCapture vin(... is 30th line.
Before upgrading the OS, this code was working with the same input file.
From the backtrace, it seems that the trouble happens at CvCapture_FFMPEG and libavutil. I upgraded the packages ffmpeg libavutil-dev libavutil51 libavutil52 but they were already up-to-date.
Also, OpenCV packages are up-to-date (I checked libopencv-core-dev libopencv-core2.4 libopencv-dev libopencv-highgui-dev libopencv-highgui2.4).
I also tested OpenCV built from source, but got the same results.
Do you have ideas to figure this out?
So, I've solved this issue.
By analyzing the program with ldd, I found that it was linked to, for example, /usr/lib/libopencv_highgui.so. However, in x86_64 system, it should be /usr/lib/x86_64-linux-gnu/libopencv_highgui.so. In my system, both files were installed.
The issue was caused by /usr/lib/libopencv_*.so (I'm not sure how I installed them. Maybe from source code...?). I removed these files, and compiled the above program again. Then it worked without errors.
I have a fairly large binary which I had been building for a while on a pretty old version of GCC (4.1.2). I recently built it with 4.7 but when I run it it crashes with the following backtrace:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
Program received signal SIGABRT, Aborted.
0x000003728472c5 in raise() from /lib64/libc.so.6
(gdb) bt
#0 0xbla in raise () from /lib64/libc.so.6
#1 0xbla in abort() from /lib64/libc.so.6
#2 0xbla in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#3 0xbla in ?? () from /usr/lib64/libstdc++.so.6
#4 0xbla in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0xbla in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0xbla in std::__throw_logic_error(char const*) () from /usr/lib64/libstdc++.so.6
#7 0x00000024727472 in ?? () from /usr/lib64/libstdc++.so.6
#8 0xbla in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib64/libdstdc++.so.6
#9 0xbla in CFGS_XML_Parser::ns_name (name=0x12283c0 "name") at CFGS_XML_Parser.H:258
#10 0xbla in __static_initialization_and_destruction_0 (__initialize_p=1,__priority=65535)
#11 0xbla in _GLOBAL__sub_I__Z15init_xml_loaderv () at CFGS_XML_Loader.C:728
#12 0xbla in __libc_csu_init()
#13 0xbla in __libc_start_main () from /lib64/libc.so.6
#14 0xbla in _start ()
I have no idea what this is complaining about and why it would be a gcc 4.7 only thing. What could it be and how can I debug this?
As Mats Petersson correctly stated, you are trying to construct a std::string from a const char *, that is NULL.
The likely reason this didn't happen with older GCC and is happening with newer one is that GCC-4.7 stopped using .ctors and started usting .init_array. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
As Mats Petersson also likely correctly guessed, you have depended on initializer order between separate compilation units, and now that this order changed (the order is undefined), you are paying the price.
We had this exact problem in a codebase of 100+ MLOC, and our solution is to reconfigure GCC with configure --disable-initfini-array ... (we build our own GCC releases).
Note that some platforms (e.g. ARM) do not support .ctors, only .init_arrays.
WARNING The code I provide in my question may crash matlab AND your machine!!!
I have written a mex gateway function to a C++ class. If I compile this mex function on 32Bit windows using R2008a I have no problems. If I compile and run on Matlab R2011a running 64bit Scientific Linux (a version of Red Hat Enterprize Linux) matlab exits with a segfault when the mexfunction is called, although it appears to run about halfway through the program. The C++ class can be compiled and run (with a main function) outside of Matlab on both platforms with no errors. I am using Microsoft Visual C++ Express Edition on the windows machine, and gcc 4.4.5 on the Linux machine.
What is the cause of this and can I fix it?
A zip file containing the code and data files necessary to reproduce the problem can be downloaded from http://www.see.ed.ac.uk/~s0237326/downloads/mexcrash.zip. This zip file contains the .m and .cpp source code, and a text file for testing (Temp.fem, 10kB). The file fmeshersetup.m shows the commands I am using to compile. The file Test_mexfmesher.m runs the mexfunction with an appropriate input for testing. The mex gateway function is mexfmesher.cpp, it calls the fmesher class which is made up of the files in the fmesher directory.
There are a total of 13 C++ source files, which is a bit much to expect someone to debug, even the particular line on which the segfault occurs woud be of interest.
Unfortunately I do not have access to a graphical debugger on 64bit linux that can interface with Matlab, and was hoping someone would immediately see the problem, or it would be a known problem. As stated, when run not as a mex file, the program runs fine, so I cannot locate the error in another tool, and I'm not very familiar with gdb. I believe the problem might be related to a calls to the C++ function 'free'.
Below is a backtrace from the segfault:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff721be36 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwservices.so
(gdb) backtrace
#0 0x00007ffff721be36 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwservices.so
#1 0x00000034daa914f2 in std::basic_ostream<char, std::char_traits<char> >::flush() () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libstdc++.so.6
#2 0x00007ffff72302b0 in ioFlush () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwservices.so
#3 0x00007ffff61303f5 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#4 0x00007ffff61330ec in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#5 0x00007ffff6130c7a in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#6 0x00007ffff6131741 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#7 0x00007ffff618a7d9 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#8 0x00007ffff686d7ef in Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**) () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_dispatcher.so
#9 0x00007ffff61731f0 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#10 0x00007ffff6114975 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#11 0x00007ffff612e96e in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#12 0x00007ffff61330ec in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#13 0x00007ffff6130c7a in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#14 0x00007ffff6131741 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#15 0x00007ffff618a7d9 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#16 0x00007ffff686d7ef in Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**) () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_dispatcher.so
#17 0x00007ffff61669b2 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#18 0x00007ffff6128e13 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#19 0x00007ffff6127eb7 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#20 0x00007ffff6128397 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwm_interpreter.so
#21 0x00007ffff6d378fe in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwbridge.so
#22 0x00007ffff6d384ae in mnParser () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwbridge.so
#23 0x00007ffff6ae0d39 in mcrInstance::mnParser_on_interpreter_thread() () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#24 0x00007ffff6ac3db2 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#25 0x00007ffff6ac3ec0 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#26 0x00007fffee8badb6 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwuix.so
#27 0x00007fffee8c413d in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwuix.so
#28 0x00007fffef3110bd in sysq::during_F<boost::weak_ptr<sysq::ws_ppeHook>, boost::shared_ptr<sysq::ws_ppeHook> > std::for_each<__gnu_cxx::__normal_iterator<boost::weak_ptr<sysq::ws_ppeHook>*, std::vector<boost::weak_ptr<sysq::ws_ppeHook>, std::allocator<boost::weak_ptr<sysq::ws_ppeHook> > > >, sysq::during_F<boost::weak_ptr<sysq::ws_ppeHook>, boost::shared_ptr<sysq::ws_ppeHook> > >(__gnu_cxx::__normal_iterator<boost::weak_ptr<sysq::ws_ppeHook>*, std::vector<boost::weak_ptr<sysq::ws_ppeHook>, std::allocator<boost::weak_ptr<sysq::ws_ppeHook> > > >, __gnu_cxx::__normal_iterator<boost::weak_ptr<sysq::ws_ppeHook>*, std::vector<boost::weak_ptr<sysq::ws_ppeHook>, std::allocator<boost::weak_ptr<sysq::ws_ppeHook> > > >, sysq::during_F<boost::weak_ptr<sysq::ws_ppeHook>, boost::shared_ptr<sysq::ws_ppeHook> >) ()
from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libuij.so
#29 0x00007fffef312989 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libuij.so
#30 0x00007fffef30f4ae in svWS_ProcessPendingEvents(int, int, bool) () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libuij.so
#31 0x00007ffff6ac21c7 in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#32 0x00007ffff6ac260a in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#33 0x00007ffff6ac2d6f in ?? () from /opt/matlab-2011a/bin/glnxa64/../../bin/glnxa64/libmwmcr.so
#34 0x00000034d7a077e1 in start_thread () from /lib64/libpthread.so.0
#35 0x00000034d72e573d in clone () from /lib64/libc.so.6
(gdb) quit
You have attempted to use 'free' to free memory with a pointer which actually points to NULL. A careful programmer would check if this is the case before attempting to use free. Some libraries will have an automatic check for this.
The reason you did not notice this when compiling as a standalone may be due to the fact that matlab uses its own libstdc++ (stored in /opt/matlab-2011a/bin/glnxa64/libstdc++.so.6) instead of the main one (stored in /usr/lib/x86_64-linux-gnu/).
If you are sudoer, You should force matlab to use the main libstdc++, this can solve many problems with mex files:
cd /opt/matlab-2011a/bin/glnxa64/
sudo mkdir old
sudo mv libstdc++.so.6* old
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 libstdc++.so.6
Here is the problem which I'm trying to address:
We've got a core dump while processing data. The result of backtracing is:
#0 0x00a99402 in __kernel_vsyscall ()
#1 0x00306df0 in raise () from /lib/libc.so.6
#2 0x00308701 in abort () from /lib/libc.so.6
#3 0x001c4530 in _gnu_cxx::_verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#4 0x001c1f35 in ?? () from /usr/lib/libstdc++.so.6
#5 0x001c12ca in ?? () from /usr/lib/libstdc++.so.6
#6 0x001c1d99 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#7 0x00d1c7e6 in ?? () from /lib/libgcc_s.so.1
#8 0x00d1cb62 in _Unwind_Resume () from /lib/libgcc_s.so.1
........
I've looked through the code base of our application and it is not clear that the problem is due to uncaught exception or whatever (but i know it somehow connected with exceptions because of _Unwind_Resume call is there). So I'm trying to write simple program which also fails with core dump and its gdb backtracing contains the lines above.
os: CentOS, compiler: gnu gcc 4.1.2, language: c/c++
Any suggestions about the problem/code would be much appreciated
I'm playing with X-development. I've got a basic proto-WM going that works for a while and then produces these errors after a fairly random time.
[edit]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f71dcf9a9ac]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f71dcf9aa54]
#2 /usr/lib/libX11.so.6 [0x7f71ddefe340]
#3 /usr/lib/libX11.so.6(XAllocColor+0xc1) [0x7f71ddedada1]
#4 /home/mais/code/simplewin/bin/Debug/simplewin [0x408e0b]
#5 /home/mais/code/simplewin/bin/Debug/simplewin [0x409062]
#6 /home/mais/code/simplewin/bin/Debug/simplewin [0x407a9d]
#7 /home/mais/code/simplewin/bin/Debug/simplewin [0x406c6d]
#8 /home/mais/code/simplewin/bin/Debug/simplewin [0x402734]
#9 /home/mais/code/simplewin/bin/Debug/simplewin [0x407e37]
#10 /home/mais/code/simplewin/bin/Debug/simplewin [0x407304]
#11 /home/mais/code/simplewin/bin/Debug/simplewin [0x407335]
#12 /lib/libpthread.so.0 [0x7f71ddc9afc7]
#13 /lib/libc.so.6(clone+0x6d) [0x7f71dd26a59d]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f71dcf9a9ac]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x17) [0x7f71dcf9ab17]
#2 /usr/lib/libX11.so.6 [0x7f71ddefe420]
#3 /usr/lib/libX11.so.6 [0x7f71ddefeb5b]
#4 /usr/lib/libX11.so.6 [0x7f71ddefeeb5]
#5 /usr/lib/libX11.so.6(XNextEvent+0x68) [0x7f71ddee5898]
#6 /home/mais/code/simplewin/bin/Debug/simplewin [0x404bc2]
#7 /lib/libpthread.so.0 [0x7f71ddc9afc7]
#8 /lib/libc.so.6(clone+0x6d) [0x7f71dd26a59d]
It looks like some kind of synchronization bug in my app; that much of the time the resources used are released in the correct sequence, but at some stage this get mixed-up and then the error(s) occur.
How do I interpret the above to find the location/cause of the errors?
1) build your program with debug symbold (on gcc, pass -g option)
2) enable core files, and once your application crashes, open it in gdb with core file, and check the backtrace
3) is your application multithreaded and using xlib? If so, you need to enable multi-threading access to the xlib functions.
4) install ddd, and run your application using that (ddd is a gui frontend for the linux debuger gdb)