I am writing an app using Qt 5.9 with C++ main and QML UI on the top. Everything fine (including sending signals from C++ to QML) but when I add ChartView to the UI, I am seeing a crash. The stripped-down version of the ChartView looks like the following; when I omit it from the code, no crash.
ChartView {
id: _chartView
LineSeries {
name: "avgZ"
XYPoint { x: 0; y: 0}
}
}
This is the stack trace (via excellent backward-cpp):
Stack trace (most recent call last):
#27 Object "", at 0xffffffffffffffff, in
#26 Object "/home/eudoxos/pw/carxx/build/main-qt", at 0x561cceac54a9, in _start
#25 Source "/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c", line 310, in __libc_start_main [0x7fafdf218b96]
#24 Object "/home/eudoxos/pw/carxx/build/main-qt", at 0x561cceac849b, in main
#23 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe297761c, in QQmlApplicationEngine::load(QUrl const&)
#22 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe29775dd, in QQmlApplicationEnginePrivate::startLoad(QUrl const&, QByteArray const&, bool)
#21 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe2977372, in QQmlApplicationEnginePrivate::finishLoad(QQmlComponent*)
#20 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe28f974e, in QQmlComponent::create(QQmlContext*)
#19 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe28fb407, in QQmlComponentPrivate::beginCreate(QQmlContextData*)
#18 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe2984c6b, in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*)
#17 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe298197b, in QQmlObjectCreator::createInstance(int, QObject*, bool)
#16 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe2980ba5, in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*)
#15 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe2983e10, in QQmlObjectCreator::setupBindings(bool)
#14 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe29833d9, in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*)
#13 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe2981145, in QQmlObjectCreator::createInstance(int, QObject*, bool)
#12 Object "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5", at 0x7fafe2910961, in QQmlType::create(QObject**, void**, unsigned long) const
#11 Object "/usr/lib/x86_64-linux-gnu/qt5/qml/QtCharts/libqtchartsqml2.so", at 0x7faf9632485a, in qt_plugin_instance
#10 Object "/usr/lib/x86_64-linux-gnu/qt5/qml/QtCharts/libqtchartsqml2.so", at 0x7faf963452a5, in QByteArray::reserve(int)
#9 Object "/usr/lib/x86_64-linux-gnu/libQt5Charts.so.5", at 0x7faf95ffc51e, in QtCharts::QChart::mapToPosition(QPointF const&, QtCharts::QAbstractSeries*)
#8 Object "/usr/lib/x86_64-linux-gnu/libQt5Charts.so.5", at 0x7faf95ff7975, in
#7 Object "/usr/lib/x86_64-linux-gnu/libQt5Charts.so.5", at 0x7faf95ff683e, in
#6 Object "/usr/lib/x86_64-linux-gnu/libQt5Charts.so.5", at 0x7faf95ff368c, in
#5 Object "/usr/lib/x86_64-linux-gnu/libQt5Charts.so.5", at 0x7faf95ff2fe2, in
#4 Object "/usr/lib/x86_64-linux-gnu/libQt5Charts.so.5", at 0x7faf9600045f, in QtCharts::QAbstractSeries::qt_metacall(QMetaObject::Call, int, void**)
#3 Object "/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7fafa2d85a5c, in QGraphicsTextItem::document() const
#2 Object "/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7fafa2d8571e, in non-virtual thunk to QGraphicsTextItem::focusOutEvent(QFocusEvent*)
#1 Object "/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7fafa2c7e311, in QWidgetTextControl::QWidgetTextControl(QObject*)
#0 Object "/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7fafa2c7e235, in QWidgetTextControl::setCursorWidth(int)
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault (core dumped)
Can anyone find some hint in the stack trace what could be causing the crash?
I was able to run QML examples with line charts without any issue.
If you are going to use Qt Charts you must change the QGuiApplication to QApplication and add QT += widgets to .pro
Related
I'm using Julia language (Version 1.3.1), JuMP package (Version 0.20.1) and Cbc package (Version 0.6.6) to solve an optimization problem in a docker container with ubuntu:16.04. The optimizer Cbc seems to be hung, with 100% cpu usage, without exiting and without any message. The problems happens rarely on similar problem and seems to be not replicable: if I run the same code with the same data it doesn't hang anymore. Hope that backtrace got through gdb can be useful.
I can share my model, if needed. It has 11520 variables, 4652 constraints, 10080 variables used in linear objective function.
This is the log of Cbc optimizer:
Welcome to the CBC MILP Solver
Version: 2.10.3 Build Date: Oct 7 2019
command line - Cbc_C_Interface -threads 0 -seconds 360.0 -maxNodes 30000 -logLevel 1 -solve -quit (default strategy 1) seconds was
changed from 1e+100 to 360 maxNodes was changed from 2147483647 to
30000 Continuous objective value is 2.3607e+08 - 0.11 seconds
Cgl0002I 3197 variables fixed Cgl0005I 7 SOS with 8323 members
Cgl0004I processed model has 15 rows, 8323 columns (8323 integer (8323
of which binary)) and 26556 elements Cbc0045I Fixing only non-zero
variables. Cbc0045I Warning: mipstart values could not be used to
build a solution.
Here Cbc seems to be hung and becomes unresponsive, with 100% cpu usage.
Here the backtrace on the running pid process:
#0 0x00007f163c3facc9 in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#1 0x00007f163c4125b3 in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#2 0x00007f163c467586 in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#3 0x00007f163c46aebc in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#4 0x00007f163c40594a in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#5 0x00007f163c29afbe in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#6 0x00007f163c2ad844 in ?? () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#7 0x00007f163b8ea31f in CbcHeuristicDive::solution(double&, int&, int&, OsiRowCut**, CbcSubProblem&, double*) () from
target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbc.so.3
#8 0x00007f163b8ebf42 in CbcHeuristicDive::solution(double&, double*) () from
target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbc.so.3
#9 0x00007f163b938fd2 in CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) () from
target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbc.so.3
#10 0x00007f163b9472d7 in CbcModel::branchAndBound(int) () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbc.so.3
#11 0x00007f163c214c47 in CbcMain1(int, char const, CbcModel&, int ()(CbcModel, int), CbcSolverUsefulData&) () from
target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#12 0x00007f163c2252ae in CbcMain1(int, char const**, CbcModel&) () from
target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#13 0x00007f163c19bc50 in Cbc_solve () from target:/root/.julia/packages/Cbc/vWzyC/deps/usr/lib/libCbcSolver.so
#14 0x00007f16698e7e71 in ?? ()
#15 0x000000000000000c in ?? ()
#16 0x00007fff70694480 in ?? ()
#17 0x00007f16604ce110 in ?? ()
#18 0x000000000000262e in ?? ()
#19 0x0000000000000006 in ?? ()
#20 0x00007fff70694480 in ?? ()
#21 0x00007f165966ab40 in ?? ()
#22 0x00007f164a7ce1d0 in ?? ()
#23 0x00007f164a7ce220 in ?? ()
#24 0x00007f164a7ce1d0 in ?? ()
#25 0x00007f1688be7b00 in ?? () at /buildworker/worker/package_linux64/build/src/array.c:738 from
target:/opt/julia/bin/../lib/libjulia.so.1
#26 0x00007f163d909af0 in ?? ()
#27 0x00007f164439d3c0 in ?? ()
#28 0x00007f1689524200 in ?? ()
#29 0x0000000000000000 in ?? ()
Using next command in gdb console, than a StackOverflowError() error is catched on CbC.
Has the objective function too many terms?
Any help is really appreciable.
Thank you
This appears to be an issue with Cbc. It's impossible to provide more advice without a reproducible example. I suggest you try to simplify your model and create an MPS file.
You can set the time limit using the seconds parameter as follows.
For newer package versions:
model = Model(optimizer_with_attributes(Cbc.Optimizer
,"seconds" => 60
,"threads" => 4
,"loglevel" => 0
,"ratioGap" => 0.0001))
Or like this for older package versions:
model = Model(with_optimizer(Cbc.Optimizer
,seconds=60
,threads=4
,loglevel=0
,ratioGap=0.0001))
Out of nothing my wp website stopped working.
This is the message I get when I turn the debug on.
Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'wp_validate_auth_cookie' not found or invalid function name in /home/u775042855/domains/amosermae.com/public_html/wp-includes/class-wp-hook.php on line 288
Fatal error: Uncaught Error: Call to undefined function wp_create_nonce() in /home/u775042855/domains/amosermae.com/public_html/wp-includes/script-loader.php:1058 Stack trace: #0 /home/u775042855/domains/amosermae.com/public_html/wp-includes/class-wp-hook.php(288): wp_default_scripts(Object(WP_Scripts)) #1 /home/u775042855/domains/amosermae.com/public_html/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters('', Array) #2 /home/u775042855/domains/amosermae.com/public_html/wp-includes/plugin.php(544): WP_Hook->do_action(Array) #3 /home/u775042855/domains/amosermae.com/public_html/wp-includes/class.wp-scripts.php(167): do_action_ref_array('wp_default_scri...', Array) #4 /home/u775042855/domains/amosermae.com/public_html/wp-includes/class.wp-scripts.php(142): WP_Scripts->init() #5 /home/u775042855/domains/amosermae.com/public_html/wp-includes/functions.wp-scripts.php(23): WP_Scripts->__construct() #6 /home/u775042855/domains/amosermae.com/public_html/wp-includes/functions.wp-scripts.php(128): wp_scripts() #7 /home/u775 in /home/u775042855/domains/amosermae.com/public_html/wp-includes/script-loader.php on line 1058
Can anyone help?
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.
I am getting seg fault when I am opening project in QT under KDE.
Error is:
QtCreator(20093)/ findLibraryInternal: plugins should not have a 'lib' prefix: "libkfilemodule.so"
QtCreator(20093)/ KPluginLoader::load: The plugin "libkfilemodule" doesn't contain a kde_plugin_verification_data structure
kdeinit4: Communication error with launcher. Exiting!
kdeinit4: Communication error with launcher. Exiting!
Segmentation fault (core dumped)
Stack is:
(gdb) where
#0 0x00007ffff66eaec1 in QDataStream::operator>>(int&) () from /opt/QtSDK/QtCreator/bin/../lib/qtcreator/libQtCore.so.4
#1 0x0000003112d18840 in KMimeTypeFactory::KMimeTypeFactory() () from /usr/lib64/libkdecore.so.5
#2 0x0000003112d18cda in KMimeTypeFactory::self() () from /usr/lib64/libkdecore.so.5
#3 0x0000003112d1f3b2 in KMimeType::buildDefaultType() () from /usr/lib64/libkdecore.so.5
#4 0x0000003112d1fc9d in KMimeType::checkEssentialMimeTypes() () from /usr/lib64/libkdecore.so.5
#5 0x0000003112d218de in KMimeType::findByUrlHelper(KUrl const&, unsigned int, bool, QIODevice*, int*) () from /usr/lib64/libkdecore.so.5
#6 0x0000003112d2234b in KMimeType::findByUrl(KUrl const&, unsigned int, bool, bool, int*) () from /usr/lib64/libkdecore.so.5
#7 0x0000003112d223b2 in KMimeType::iconNameForUrl(KUrl const&, unsigned int) () from /usr/lib64/libkdecore.so.5
#8 0x00000031180def55 in KIO::pixmapForUrl(KUrl const&, unsigned int, KIconLoader::Group, int, int, QString*) () from /usr/lib64/libkio.so.5
#9 0x000000311c65a853 in KFileWidget::KFileWidget(KUrl const&, QWidget*) () from /usr/lib64/libkfile.so.4
#10 0x00007fffba74aa14 in ?? () from /usr/lib64/kde4/libkfilemodule.so
#11 0x00000031181df118 in KFileDialog::KFileDialog(KUrl const&, QString const&, QWidget*, QWidget*) () from /usr/lib64/libkio.so.5
#12 0x00000031181e366a in ?? () from /usr/lib64/libkio.so.5
#13 0x00007ffff756365c in QFileDialog::getOpenFileNames(QWidget*, QString const&, QString const&, QString const&, QString*, QFlags<QFileDialog::Option>) () from /opt/QtSDK/QtCreator/bin/../lib/qtcreator/libQtGui.so.4
#14 0x00007fffef0d8a44 in Core::FileManager::getOpenFileNames(QString const&, QString, QString*) () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/libCore.so
#15 0x00007fffe924c29a in ProjectExplorer::ProjectExplorerPlugin::openOpenProjectDialog() () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/libProjectExplorer.so
#16 0x00007fffde875bba in ?? () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/libWelcome.so
#17 0x00007fffe8e6224b in QDeclarativeObjectMethodScriptClass::callMethod(QObject*, int, int, int, int*, QScriptContext*) () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/../../libQtDeclarative.so.4
#18 0x00007fffe8e62b1f in QDeclarativeObjectMethodScriptClass::callPrecise(QObject*, QDeclarativePropertyCache::Data const&, QScriptContext*) () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/../../libQtDeclarative.so.4
#19 0x00007fffe8e63717 in QDeclarativeObjectMethodScriptClass::call(QScriptDeclarativeClass::Object*, QScriptContext*) () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/../../libQtDeclarative.so.4
#20 0x00007fffee2e7a35 in QScript::DeclarativeObjectDelegate::call(QTJSC::ExecState*, QTJSC::JSObject*, QTJSC::JSValue, QTJSC::ArgList const&) () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/../../libQtScript.so.4
#21 0x00007fffee1d070f in QTJSC::NativeFuncWrapper::operator()(QTJSC::ExecState*, QTJSC::JSObject*, QTJSC::JSValue, QTJSC::ArgList const&) const () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/../../libQtScript.so.4
#22 0x00007fffee1a3b07 in cti_op_call_NotJSFunction () from /opt/QtSDK/QtCreator/lib/qtcreator/plugins/Nokia/../../libQtScript.so.4
#23 0x00007fffdc02c31b in ?? ()
#24 0x0000000000000000 in ?? ()
I also tried creating softlink:
ln -s libkfilemodule.so kfilemodule.so, but still getting the same problem.
If you are stuck with Qt 4.6 and can't upgrade to a newer set of libaries...
Basically the easiest fix for this, if you have access to the source code is to stop using the QFileDialog calls. I replaced mine with QInputDialog::getText and now no more seg faults!
Also this bug report talks about it:
https://bugs.kde.org/show_bug.cgi?id=210904 (includes info about a related fix)
and this one:
https://bugs.kde.org/show_bug.cgi?id=203205
Hope that helps.
For a while now (I can't remember exactly which version) Xcode 4 has not been working properly. In that whenever my code crashes the debugger just shows me the main() function and there is a stack trace like this:
#0 0x9018b9c6 in __pthread_kill ()
#1 0x90105f78 in pthread_kill ()
#2 0x900f6bdd in abort ()
#3 0x03c93e78 in dyld_stub__Unwind_DeleteException ()
#4 0x03c9189e in default_terminate() ()
#5 0x0154df4b in _objc_terminate ()
#6 0x03c918de in safe_handler_caller(void (*)()) ()
#7 0x03c91946 in __cxa_bad_typeid ()
#8 0x03c92b3e in __cxa_current_exception_type ()
#9 0x0154de49 in objc_exception_rethrow ()
#10 0x012f2e10 in CFRunLoopRunSpecific ()
#11 0x012f2ccb in CFRunLoopRunInMode ()
#12 0x012a5879 in GSEventRunModal ()
#13 0x012a593e in GSEventRun ()
#14 0x00013a9b in UIApplicationMain ()
#15 0x00002a02 in main at /Users/dan/Dev/Container/Container/main.m:16
In the console I get some more meaningful information, in this case it tells me:
2011-11-09 10:39:53.886 Container[27273:f803] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayI objectAtIndex:]: index 1 beyond bounds for empty array'
In this example I know what the problem is because I made the error (I'm trying to access an object in an empty NSArray) on purpose to try and get to the bottom of this issue. However, I can't figure out what is going wrong. I've lived with it up until now as lot of the bugs I've had I've been familiar with and knew where to look anyway but still, it's becoming a real pain.
Can anyone please shed some light on this issue?
You probably want to stop at the point in code when the exception actually occurs, not when it has been bubbled up to your main method. To do so, set an exception breakpoint as explained here: Exception Breakpoint in Xcode