I have coredump from application that crashed
because of wrong index in std::vector::at.
I created that elf file via strip myelf -o myelf.strip.
Then I run myelf.strip and it crashed.
If I ran gdb myelf.strip coredump I got:
(gdb) bt
#0 0x00007b864b918fff in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007b864b91a42a in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007b864c2310ad in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007b864c22f066 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007b864c22e089 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007b864c22e9dd in __gxx_personality_v0 () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007b864bc94f33 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#7 0x00007b864bc9529b in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#8 0x00007b864c22f2bc in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x00007b864c257b85 in std::__throw_out_of_range_fmt(char const*, ...) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00006c48e78b6cde in ?? ()
#11 0x00006c48e78beb6a in ?? ()
...
All looks as expected, then I want to decode frames #10, #11...
And I ran gdb myelf coredump, in other words the same elf file,
but with debug info, and got:
(gdb) bt
#0 0x00007b864b918fff in ?? ()
#1 0x7a69733e2d736968 in ?? ()
#2 0xfffffffe7fffffff in ?? ()
#3 0xffffffffffffffff in ?? ()
#4 0xffffffffffffffff in ?? ()
#5 0xffffffffffffffff in ?? ()
#6 0xffffffffffffffff in ?? ()
#7 0xffffffffffffffff in ?? ()
#8 0xffffffffffffffff in ?? ()
#9 0xffffffffffffffff in ?? ()
#10 0xffffffffffffffff in ?? ()
#11 0xffffffffffffffff in ?? ()
I validate myelf.strip via strip myelf -o myelf.strip_2 && diff myelf.strip myelf.strip_2, and myelf.strip is really file that corresponding to myelf.
So why the result of gdb for stripped and not stripped file is different?
strip somehow rellocate symbols?
This is old debian based distro with such packages: binutils 2.28-5 , gdb 7.12-6
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed last year.
Improve this question
I have an embedded project that uses qml, the scenario is like this: the desktop interface has two buttons, when I click a button, I will push Setting.qml with stackview, at this time the program will crash, when I click another button, I will use stackview to push Mp3.qml, the program runs normally, and the interface jumps in. When the program crashes and the daemon is pulled up, it will not crash when I click push Setting.qml again.
The following is the coredump information I intercepted:
#0 0x0000007f76d4c2b8 in raise () from /lib/libc.so.6
#1 0x0000007f76d3a9d4 in abort () from /lib/libc.so.6
#2 0x0000007f771b71e8 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#3 0x0000007f779c8368 in ?? () from /usr/lib/libQt5Qml.so.5
#4 0x0000007f77a08fd4 in ?? () from /usr/lib/libQt5Qml.so.5
#5 0x0000007f779e4dfc in QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) () from
/usr/lib/libQt5Qml.so.5
#6 0x0000007f7799ba64 in ?? () from /usr/lib/libQt5Qml.so.5
#7 0x0000007f7799be9c in QQmlEnginePrivate::incubate(QQmlIncubator&, QQmlContextData*) () from
/usr/lib/libQt5Qml.so.5
#8 0x0000007f77999974 in QQmlComponent::create(QQmlIncubator&, QQmlContext*, QQmlContext*) () from /usr/lib/libQt5Qml.so.5
#9 0x0000007f50665810 in ?? () from /usr/lib/libQt5QuickTemplates2.so.5
#10 0x0000007f50666d14 in QQuickStackView::push(QQmlV4Function*) () from /usr/lib/libQt5QuickTemplates2.so.5
#11 0x0000007f50682518 in ?? () from /usr/lib/libQt5QuickTemplates2.so.5
#12 0x0000007f50682950 in QQuickStackView::qt_metacall(QMetaObject::Call, int, void**) ()
from /usr/lib/libQt5QuickTemplates2.so.5
#13 0x0000007f77988008 in QQmlVMEMetaObject::metaCall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQt5Qml.so.5
#14 0x0000007f779c2998 in ?? () from /usr/lib/libQt5Qml.so.5
#15 0x0000007f77920654 in QV4::QObjectMethod::callInternal(QV4::Value const*, QV---Type
to continue, or q to quit---[41555.331634] dsoc
= 100000, rsoc = 94912, voltage = 4199, current_avg = 0, temperature = 2804::Value const*, int) const () from
/usr/lib/libQt5Qml.so.5
#16 0x0000007f778e1868 in ?? () from /usr/lib/libQt5Qml.so.5
#17 0x0000007f77974404 in QV4::Runtime::method_callProperty(QV4::ExecutionEngine*, QV4::Value*,
int, QV4::Value*, int) () from /usr/lib/libQt5Qml.so.5
#18 0x0000007f7792d8ec in ?? () from /usr/lib/libQt5Qml.so.5
#19 0x0000007f779300b0 in ?? () from /usr/lib/libQt5Qml.so.5
#20 0x0000007f778f3ed4 in QV4::Function::call(QV4::Value const*, QV4::Value const*, int, QV4::ExecutionContext const*) () from
/usr/lib/libQt5Qml.so.5
#21 0x0000007f779d8510 in QQmlJavaScriptExpression::evaluate(QV4::CallData*, bool*) () from
/usr/lib/libQt5Qml.so.5
#22 0x0000007f7799f108 in QQmlBoundSignalExpression::evaluate(void**) () from
/usr/lib/libQt5Qml.so.5
#23 0x0000007f7799f8dc in ?? () from /usr/lib/libQt5Qml.so.5
#24 0x0000007f779c8084 in QQmlNotifier::emitNotify(QQmlNotifierEndpoint*, void**) () from
/usr/lib/libQt5Qml.so.5
#25 0x0000007f7798a500 in QQmlData::signalEmitted(QAbstractDeclarativeData*, QObject*, int,
void**) () from /usr/lib/libQt5Qml.so.5
#26 0x0000007f772fd66c in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5
#27 0x0000007f5062c4f8 in QQuickAbstractButtonPrivate::handleRelease(QPointF const&) () from
/usr/lib/libQt5QuickTemplates2.so.5
#28 0x0000007f5063f6a4 in QQuickControl::touchEvent(QTouchEvent*) () from /usr/lib/libQt5QuickTemplates2.so.5 ---Type
to continue, or q to quit---
#29 0x0000007f781b78d8 in QQuickItem::event(QEvent*) () from /usr/lib/libQt5Quick.so.5 #30 0x0000007f78563308 in
QApplicationPrivate::notify_helper(QObject*, QEvent*) () from
/usr/lib/libQt5Widgets.so.5
#31 0x0000007f78567c14 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#32 0x0000007f772e4c24 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from
/usr/lib/libQt5Core.so.5
#33 0x0000007f781c9160 in QQuickWindowPrivate::deliverMatchingPointsToItem(QQuickItem*,
QQuickPointerEvent*, bool) () from /usr/lib/libQt5Quick.so.5
#34 0x0000007f781c9440 in QQuickWindowPrivate::deliverUpdatedTouchPoints(QQuickPointerTouchEvent*)
() from /usr/lib/libQt5Quick.so.5
#35 0x0000007f781c9ed0 in QQuickWindowPrivate::deliverTouchEvent(QQuickPointerTouchEvent*) ()
from /usr/lib/libQt5Quick.so.5
#36 0x0000007f781ca62c in QQuickWindowPrivate::deliverPointerEvent(QQuickPointerEvent*) () from
/usr/lib/libQt5Quick.so.5
#37 0x0000007f781cadac in QQuickWindowPrivate::handleTouchEvent(QTouchEvent*) () from
/usr/lib/libQt5Quick.so.5
#38 0x0000007f781cb8f8 in QQuickWindow::event(QEvent*) () from /usr/lib/libQt5Quick.so.5 #39 0x0000007f78563308 in
QApplicationPrivate::notify_helper(QObject*, QEvent*) () from
/usr/lib/libQt5Widgets.so.5
#40 0x0000007f78567c14 in QApplication::notify(QObject*, QEvent*) () ---Type to continue, or q to quit---
from /usr/lib/libQt5Widgets.so.5
#41 0x0000007f772e4c24 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from
/usr/lib/libQt5Core.so.5
#42 0x0000007f77c5eaf0 in QGuiApplicationPrivate::processTouchEvent(QWindowSystemInterfacePrivate::TouchEvent*)
() from /usr/lib/libQt5Gui.so.5
#43 0x0000007f77c5fd20 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
() from /usr/lib/libQt5Gui.so.5
#44 0x0000007f77c4ad58 in QWindowSystemInterface::sendWindowSystemEvents(QFlagsQEventLoop::ProcessEventsFlag)
() from /usr/lib/libQt5Gui.so.5
#45 0x0000007f749870a8 in ?? () from /usr/lib/libQt5WaylandClient.so.5
#46 0x0000007f7d4b4a64 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#47 0x0000007f7d4b4ce0 in ?? () from /usr/lib/libglib-2.0.so.0
#48 0x0000007f7d4b4d84 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#49 0x0000007f77318ea8 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
() from /usr/lib/libQt5Core.so.5
#50 0x0000007f772e0d8c in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from
/usr/lib/libQt5Core.so.5
#51 0x0000007f772e55b4 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#52 0x0000000000426760 in main ()
Thank you guys for the comments, I found the problem, I noticed a sentence through the log: "QQmlEngine: Illegal attempt to connect to settingWorkCenter(0x7f7c000fe0) that is in a different thread than the QML engine QQmlApplicationEngine(0x7ff2267c38)."
I instantiate the singleton object of settingWorkCenter in another thread, and then register the singleton object to the qml global context through setContextProperty in the main thread. So this error is generated
I'm playing stackflower for the first time and don't know how to upload the code
I'm using FLTK in C++ and my program was every so often crashing when I changed the value of a widget. I ran my program with gdb to replicate the error and got two similar, but not identical errors when performing the backtrace. Weirdly the backtrace doesn't list any functions in my code, but it is in code I wouldn't expect to be in error so what might be wrong in my code to give these results?
The backtraces/errors are
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000018
0x00007fff8f018d2b in tiny_free_list_remove_ptr ()
(gdb) backtrace
#0 0x00007fff8f018d2b in tiny_free_list_remove_ptr ()
#1 0x00007fff8f01579d in szone_free_definite_size ()
#2 0x00007fff8f00f8c8 in free ()
#3 0x00007fff8ccdcfc0 in object_dispose ()
#4 0x00007fff919fff2b in -[__NSArrayI dealloc] ()
#5 0x00007fff919c228a in CFRelease ()
#6 0x00007fff8f339591 in -[NSFocusState flush] ()
#7 0x00007fff8f337f43 in -[NSView _focusFromView:withContext:] ()
#8 0x00007fff8f337719 in -[NSView lockFocusIfCanDraw] ()
#9 0x00007fff8f33744e in -[NSView lockFocus] ()
#10 0x0000000100033548 in Fl_Window::make_current ()
#11 0x0000000100042e8a in Fl_Double_Window::flush ()
#12 0x0000000100034134 in Fl_X::flush ()
#13 0x000000010003acc8 in Fl::flush ()
#14 0x0000000100036e8f in fl_mac_flush_and_wait ()
#15 0x000000010003ae39 in Fl::run ()
#16 0x0000000100100150 in main ()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff8ccda718 in objc_msgSend_vtable13 ()
(gdb) backtrace
#0 0x00007fff8ccda718 in objc_msgSend_vtable13 ()
#1 0x00007fff91a132fa in __CFRunLoopDoObservers ()
#2 0x00007fff919ee7b8 in __CFRunLoopRun ()
#3 0x00007fff919ee0e2 in CFRunLoopRunSpecific ()
#4 0x00007fff8e873eb4 in RunCurrentEventLoopInMode ()
#5 0x00007fff8e873b94 in ReceiveNextEventCommon ()
#6 0x00007fff8e873ae3 in BlockUntilNextEventMatchingListInMode ()
#7 0x00007fff8f2fc533 in _DPSNextEvent ()
#8 0x00007fff8f2fbdf2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9 0x0000000100036e1a in fl_wait ()
#10 0x0000000100036eb6 in fl_mac_flush_and_wait ()
#11 0x000000010003ae39 in Fl::run ()
#12 0x0000000100100150 in main ()
Any ideas? Thanks in advance.
Any crash inside free implementation (your first stack trace) is usually a sign of double-free, or another kind heap corruption.
System malloc on MacOS has debugging features that you can turn on, and that should allow you to catch it close to where it is happening.
About a week ago I started having troubles getting a decent backtrace from a core dump using GDB. If I load the program in GDB and have it crash, I can get a backtrace fine.
This is what I get when doing it from a core dump:
(gdb) bt
#0 0x00007fd10ad42425 in ?? ()
#1 0x00007fd10ad45b8b in ?? ()
#2 0x0000000000000004 in ?? ()
#3 0x0000000000000005 in ?? ()
#4 0x00007ffff770887e in ?? ()
#5 0x0000000000000009 in ?? ()
#6 0x00007fd10ae87ea7 in ?? ()
#7 0x0000000000000003 in ?? ()
#8 0x00007ffff77072ba in ?? ()
#9 0x0000000000000006 in ?? ()
#10 0x00007fd10ae87eab in ?? ()
#11 0x0000000000000002 in ?? ()
#12 0x00007ffff77072ce in ?? ()
#13 0x0000000000000002 in ?? ()
#14 0x00007fd10ae85b82 in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fd10ae87ea7 in ?? ()
#17 0x0000000000000003 in ?? ()
#18 0x00007ffff77072b4 in ?? ()
#19 0x000000000000000c in ?? ()
#20 0x00007fd10ae87eab in ?? ()
#21 0x0000000000000002 in ?? ()
#22 0x0000000000000020 in ?? ()
#23 0x0000000000000000 in ?? ()
(gdb)
This happens regardless of whether it's a SIGSEGV, SIGABRT (Unhandled exception or assert/verify).
I am compiling with the following compiler flags:
g++ -Wall -Wextra -g -ggdb -std=gnu++0x -rdynamic -pthread -O0
I can't really think of anything that has changed to be causing this. Any ideas?
Turns out that despite the "core dumped" message, if there was an older existing core file, it wasn't being overwritten. This is apparently a ubuntu bug according to this:
Why is my core file not overwritten?
I am using
http://www.openssl.org/docs/crypto/threads.html
to make crypto library thread safe. It is working find if I am linking with static library of libssl and libcrypto.
But if I am linking with dynamic version of the library and running multiple instance of the binary it is crashing.
How to fix this issue ?
Edit
Program is always crashing at
#0 0x00007f9f42257be5 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1 0x00007f9f4225820c in lh_retrieve () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2 0x00007f9f4225ac8e in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3 0x00007f9f4225bb41 in ERR_get_state () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#4 0x00007f9f4225c886 in ERR_clear_error () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#5 0x00007f9f44df496c in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6 0x00007f9f44df6015 in Curl_ossl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7 0x00007f9f44e0a349 in Curl_ssl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#8 0x00007f9f44de0950 in Curl_http_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#9 0x00007f9f44df12ba in Curl_protocol_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#10 0x00007f9f44df15b0 in Curl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
But while linking with static version, It is not crashing
Another bt
#0 0x00007f57a01b1be5 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1 0x00007f57a01b20bf in lh_delete () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2 0x00007f57a01b45b3 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3 0x00007f57a01b5a5a in ERR_remove_thread_state () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#4 0x00007f57a2d4ffbb in Curl_ossl_close_all () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5 0x00007f57a2d47742 in Curl_close () from /usr/lib/x86_64-linux-gnu/libcurl.so.4