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 have had to switch from C++11 to C++14 in my project to use the Catch testing framework, written for C++14 (it doesn't compile with anything less). Everything compiles fine. However, while running the program, the following function causes a series of errors which seem linked to a mismatch between C++11 and C++14 shared standard library files:
//it is called as such:
string p = "...";
handle_file(p);
//...
int handle_file (string p) {
if (is_valid(p)) {
return 0;
}
else return -1;
}
The error trace in gdb reads:
Program received signal SIGABRT, Aborted.
0x00007ffff7299ef5 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7299ef5 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff7283862 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff72dbf38 in __libc_message () from /usr/lib/libc.so.6
#3 0x00007ffff72e3bea in malloc_printerr () from /usr/lib/libc.so.6
#4 0x00007ffff72e5113 in _int_free () from /usr/lib/libc.so.6
#5 0x00007ffff72e8ca8 in free () from /usr/lib/libc.so.6
#6 0x00007ffff76b76ea in operator delete (ptr=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/del_op.cc:49
#7 0x00007ffff76b76fa in operator delete (ptr=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/del_ops.cc:33
#8 0x000055555556c893 in __gnu_cxx::new_allocator<char>::deallocate (__t=<optimized out>, __p=<optimized out>, this=0x7fffffffd910)
at /usr/include/c++/10.2.0/ext/new_allocator.h:133
#9 std::allocator_traits<std::allocator<char> >::deallocate (__n=<optimized out>, __p=<optimized out>, __a=...)
at /usr/include/c++/10.2.0/bits/alloc_traits.h:492
#10 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy (__size=<optimized out>, this=0x7fffffffd910)
at /usr/include/c++/10.2.0/bits/basic_string.h:237
#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose (this=0x7fffffffd910)
at /usr/include/c++/10.2.0/bits/basic_string.h:232
#12 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x7fffffffd910, __in_chrg=<optimized out>)
at /usr/include/c++/10.2.0/bits/basic_string.h:658
#13 Manager::handle_file (p ="./data/20pix", this=0x5555556c6d20)
at src/manager.hpp:149
Does anyone know how to solve this?
The error is inside malloc, after it has printed some error message (usually double-free or something similar) indicating heap corruption.
While it is possible that you have some kind of library mismatch, it is much more likely that you have a plain heap corruption bug in your own code (overflowing heap buffer, double delete, delete of non-allocated, etc. etc.), and that bug is simply getting exposed now, while it remained hidden before.
Your first step should be to run the program under Valgrind or with Address Sanitizer, and fix any errors these tools report.
gRPC v1.30.0
I created a grpc service and tried to run it. The execution goes smooth till the last return statement at server side.
Status theService(ServerContext *context, const Request* req, Response* res)
{
Status status = actualLogic(req,res);
//execution goes fine till here
return status;
}
Status actualLogic(req,res)
{
Response_NestedMsg msg;
msg.set_something(...);
res->mutable_nestedmsg()->CopyFrom(msg);
return Status::OK
}
//server startup code
ServerBuilder builder;
builder.AddListeningPort((address),grpc::InsecureServerCredentials());
builder.RegisterService(&serviceClassObj);
std::unique_ptr<Server> server(builder.BuildAndStart());
server->Wait();
Running this code, I get following runtime error
==14394==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x61b00000fcc8 in thread T5 (grpcpp_sync_ser)
#0 0x7fe9d35602c0 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe12c0)
#1 0x55cb87299afd in __gnu_cxx::new_allocator<std::_List_node<grpc_impl::Server const*> >::deallocate(std::_List_node<grpc_impl::Server const*>*, unsigned long) (/home/john/Desktop/my_executable+0xd0afd)
#2 0x55cb87297ba1 in std::allocator_traits<std::allocator<std::_List_node<grpc_impl::Server const*> > >::deallocate(std::allocator<std::_List_node<grpc_impl::Server const*> >&, std::_List_node<grpc_impl::Server const*>*, unsigned long) (/home/john/Desktop/my_executable+0xceba1)
#3 0x55cb8729448d in std::__cxx11::_List_base<grpc_impl::Server const*, std::allocator<grpc_impl::Server const*> >::_M_put_node(std::_List_node<grpc_impl::Server const*>*) (/home/john/Desktop/my_executable+0xcb48d)
#4 0x55cb8728bb5a in std::__cxx11::_List_base<grpc_impl::Server const*, std::allocator<grpc_impl::Server const*> >::_M_clear() (/home/john/Desktop/my_executable+0xc2b5a)
#5 0x55cb87287307 in std::__cxx11::_List_base<grpc_impl::Server const*, std::allocator<grpc_impl::Server const*> >::~_List_base() (/home/john/Desktop/my_executable+0xbe307)
#6 0x55cb87278d29 in std::__cxx11::list<grpc_impl::Server const*, std::allocator<grpc_impl::Server const*> >::~list() (/home/john/Desktop/my_executable+0xafd29)
#7 0x55cb87278e2c in grpc_impl::CompletionQueue::~CompletionQueue() (/home/john/Desktop/my_executable+0xafe2c)
#8 0x7fe9d1826998 in grpc_impl::Server::SyncRequest::CallData::ContinueRunAfterInterception() (/usr/local/lib/libgrpc++.so.1+0x6f998)
#9 0x7fe9d18278ee in grpc_impl::Server::SyncRequestThreadManager::DoWork(void*, bool, bool) (/usr/local/lib/libgrpc++.so.1+0x708ee)
#10 0x7fe9d182c4ca in grpc::ThreadManager::MainWorkLoop() (/usr/local/lib/libgrpc++.so.1+0x754ca)
#11 0x7fe9d182c68b in grpc::ThreadManager::WorkerThread::Run() (/usr/local/lib/libgrpc++.so.1+0x7568b)
#12 0x7fe9cf5a78d2 in grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::{lambda(void*)#1}::_FUN(void*) (/usr/local/lib/libgpr.so.10+0x118d2)
#13 0x7fe9d1eef6da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
#14 0x7fe9d0ba8a3e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x121a3e)
0x61b00000fcc8 is located 72 bytes inside of 1448-byte region [0x61b00000fc80,0x61b000010228)
allocated by thread T5 (grpcpp_sync_ser) here:
#0 0x7fe9d355f448 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0448)
#1 0x7fe9d18274f2 in grpc_impl::Server::SyncRequestThreadManager::DoWork(void*, bool, bool) (/usr/local/lib/libgrpc++.so.1+0x704f2)
Thread T5 (grpcpp_sync_ser) created by T0 here:
#0 0x7fe9d34b6d2f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37d2f)
#1 0x7fe9cf5a7a92 in grpc_core::Thread::Thread(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&) (/usr/local/lib/libgpr.so.10+0x11a92)
SUMMARY: AddressSanitizer: bad-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe12c0) in operator delete(void*)
==14394==ABORTING
None of my code tries to free any pointer and error seems to be coming from some auto generated file only. Please suggest if some more code/details needed.
I briefly checked the error message and code but it looks strange to me because both allocation and destruction were done by C++ new & delete. This is also consistent with your error message.
### Destruction (with operator delete)
#0 0x7fe9d35602c0 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe12c0)
### Allocation (with operator new)
#0 0x7fe9d355f448 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0448)
This might be caused by other issues like buggy ASAN or customized memory allocator.
I have some weird multithreading bugs, so I wanted to use the gcc thread sanitizer to find them. However, when I compile with -sanitize=thread the resulting binary segfaults immediatly with the following stacktrace:
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff5911cee in ?? () from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#2 0x00007ffff593408d in ?? () from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#3 0x00007ffff58eeb98 in ?? () from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#4 0x00007ffff58ef0ce in __interceptor___cxa_atexit ()
from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#5 0x00007ffff55d1e56 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff7de74ea in call_init (l=<optimised out>, argc=argc#entry=1,
argv=argv#entry=0x7fffffffdeb8, env=env#entry=0x7fffffffdec8)
at dl-init.c:72
#7 0x00007ffff7de75fb in call_init (env=0x7fffffffdec8, argv=0x7fffffffdeb8,
argc=1, l=<optimised out>) at dl-init.c:30
#8 _dl_init (main_map=0x7ffff7ffe168, argc=1, argv=0x7fffffffdeb8,
env=0x7fffffffdec8) at dl-init.c:120
#9 0x00007ffff7dd7cfa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe22b in ?? ()
#12 0x0000000000000000 in ?? ()
I tried adding the -static-libtsan attribute, but now I get the following error:
FATAL: ThreadSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator.h:1203 "((IsAligned(p, page_size_))) != (0)" (0x0, 0x0)
#0 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (sql+0x0000004aeb53)
#1 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (sql+0x0000004aeb5b)
#2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (sql+0x0000004b3af3)
#3 __tsan::user_free(__tsan::ThreadState*, unsigned long, void*, bool) <null> (sql+0x00000049e6fc)
#4 operator delete(void*) <null> (sql+0x00000045f6ec)
#5 __static_initialization_and_destruction_0(int, int) [clone .constprop.123] <null> (sql+0x00000044a4ab)
#6 __libc_csu_init <null> (sql+0x00000254468c)
#7 __libc_start_main <null> (libc.so.6+0x0000000207be)
#8 _start <null> (sql+0x000000459e18)
How can I fix this? What am I doing wrong here?
I haven't used TSAN w/gcc so can't help there, but you might want to give it a shot with clang (https://clang.llvm.org/). Since TSAN is part of clang, bugs tend to get fixed there first.
If you need help building clang, I've also written an article that might be useful: http://btorpey.github.io/blog/2015/01/02/building-clang/
Answer found here:
https://groups.google.com/forum/#!topic/thread-sanitizer/5cxyhIrl_SE
You don't need to give -ltsan (at least when using clang). You need to
give -fsanitize=thread both when compiling and linking.
-fsanitize=thread when linking will ensure that all proper libraries
get linked in.
This worked for me for both clang and gcc
From some time I am trying to catch a problem with my product hanging. This is the call stack I got after coredumping the process with gcore:
/lib64/libc.so.6
#1 0x00007f36fb339ba6 in _L_lock_12192 () from /lib64/libc.so.6
#2 0x00007f36fb337121 in malloc () from /lib64/libc.so.6
#3 0x00007f36fbbef0cd in operator new(unsigned long) () from /lib64/libstdc++.so.6
#4 0x00007f36fbc4d7e9 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) () from /lib64/libstdc++.so.6
#5 0x00007f36fbc4e42b in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) () from /lib64/libstdc++.so.6
#6 0x00007f36fbc4e4d4 in std::string::reserve(unsigned long) () from /lib64/libstdc++.so.6
#7 0x00007f36fbc2b3c6 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow(int) () from /lib64/libstdc++.so.6
#8 0x00007f36fbc2fb36 in std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long) () from /lib64/libstdc++.so.6
#9 0x00007f36fbc26885 in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) () from /lib64/libstdc++.so.6
#10 0x00007f36fe85c83a in ?? ()
#11 0x00007f36fb2ffdff in vfprintf () from /lib64/libc.so.6
#12 0x000000000055c110 in fgetc#plt ()
#13 0xffffffffffffffa8 in ?? ()
#14 0xffffffffffffffa8 in ?? ()
#15 0x0000000000bc42a0 in ?? ()
#16 0x000000000055b8b0 in setsockopt#plt ()
#17 0x000000000055bf30 in log4cxx::NDC::push ()
This is multithreaded code executed after forking a process in log4cxx ndc push seemingly. All the other threads sleep on condition variables and this is the only one deadlocked. What could possibly make malloc deadlock?
You shouldn't fork processes that use threading.
If one of the other threads has a lock acquired (let's say, the lock in malloc) during the fork, the lock is cloned in locked state, but the thread that locked it isn't running in the forked process. This means that the lock will never be released.
I encounter a coredump when read file content to std::string. Code is list below:
bool readContentFromFile(const char* fileName, std::string& content)
{
std::ifstream t(fileName);
if(!t) {
return false;
}
t.seekg(0, std::ios::end);
content.reserve(t.tellg());
t.seekg(0, std::ios::beg);
content.assign((std::istreambuf_iterator<char>(t)),
std::istreambuf_iterator<char>());
return true;
}
But occasionally the code cause coredump as below:
...
#4 <signal handler called>
#5 0x00007f347a0f3945 in raise () from /lib64/libc.so.6
#6 0x00007f347a0f4f21 in abort () from /lib64/libc.so.6
#7 0x00007f347a953504 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#8 0x00007f347a951946 in ?? () from /usr/lib64/libstdc++.so.6
#9 0x00007f347a951973 in std::terminate() () from /usr/lib64/libstdc++.so.6
#10 0x00007f347a951a5a in __cxa_throw () from /usr/lib64/libstdc++.so.6
#11 0x00007f347a8ef2ba in std::__throw_ios_failure(char const*) () from /usr/lib64/libstdc++.so.6
#12 0x00007f347a901317 in std::basic_filebuf<char, std::char_traits<char> >::underflow() () from /usr/lib64/libstdc++.so.6
#13 0x00000000004c2751 in char* std::string::_S_construct<std::istreambuf_iterator<char, std::char_traits<char> > >(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::allocator<char> const&, std::input_iterator_tag) ()
#14 0x00000000004c281b in std::string& std::string::_M_replace_dispatch<std::istreambuf_iterator<char, std::char_traits<char> > >(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::__false_type) ()
#15 0x00000000004bf225 in readContentFromFile(char const*, std::string&) ()
From the above code snippets, exception is throwed in underflow function. But I have no idea why throw exception. The file maybe removed when reading, but which statment in code maybe cause throwing exception?
Pretty clear from the stack trace that the exception is being thrown from content.assign. Looks like string::assign is an inline function which calls std::string::_M_replace_dispatch. You could check this by looking at the header files, or using a debugger. Does that answer the question?