Coredump of qt application after qt upgrade - c++

After a Yocto upgrade to warrior and with this an qt upgrade from 5.9.7 to 5.12.8 our qt qml application crashes on the device if the user scrolls (keyboard event) through a listview. It crashes in QV4::MarkStack::drain (QmlEngine GarbageCollector) and we have no idea where the problem could be.
Any advise how to find such an error?
Here is a backtrace:
Thread 1 (LWP 516):
#0 0x0000001c in ?? ()
No symbol table info available.
#1 0xb695a9d0 in QV4::MarkStack::drain (this=this#entry=0xbee86804) at ../../include/QtQml/5.12.8/QtQml/private/../../../../../../git/src/qml/memory/qv4heap_p.h:73
h = <optimized out>
#2 0xb69b9904 in QV4::PersistentValueStorage::mark (this=<optimized out>, markStack=markStack#entry=0xbee86804) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/jsruntime/qv4persistent.cpp:243
p = 0xb0078000
#3 0xb695b4fe in QV4::MemoryManager::collectRoots (this=this#entry=0x1099c68, markStack=markStack#entry=0xbee86804) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/memory/qv4mm.cpp:871
No locals.
#4 0xb695b678 in QV4::MemoryManager::mark (this=this#entry=0x1099c68) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/memory/qv4mm.cpp:912
markStack = {top = 0xaa8b7084, base = 0xaa8b7000, limit = 0xaaa37000, engine = 0x158efb8}
#5 0xb695cbb0 in QV4::MemoryManager::runGC (this=0x1099c68) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/memory/qv4mm.cpp:1047
gcBlocker = {varRef = #0x1099d2c, oldValue = false}
#6 0xb695e1e6 in QV4::MemoryManager::allocate (size=32, allocator=0x1099c70, this=0x1099c68) at ../../include/QtQml/5.12.8/QtQml/private/../../../../../../git/src/qml/memory/qv4mm_p.h:328
didGCRun = false
didGCRun = <optimized out>
m = <optimized out>
#7 QV4::MemoryManager::allocData (this=0x1099c68, size=32) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/memory/qv4mm.cpp:797
m = <optimized out>
#8 0xb695e284 in QV4::MemoryManager::allocObjectWithMemberData (this=this#entry=0x1099c68, vtable=vtable#entry=0xb6be4358 <QV4::Object::static_vtbl>, nMembers=<optimized out>) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/memory/qv4mm.cpp:809
size = <optimized out>
o = <optimized out>
#9 0xb6a690de in QV4::MemoryManager::allocateObject<QV4::Object> (ic=<optimized out>, this=<optimized out>) at ../../include/QtQml/5.12.8/QtQml/private/../../../../../../git/src/qml/jsruntime/qv4object_p.h:142
o = <optimized out>
o = <optimized out>
#10 QV4::MemoryManager::allocateObject<QV4::Object> (ic=0xaaab80a8, this=<optimized out>) at ../../include/QtQml/5.12.8/QtQml/private/../../../../../../git/src/qml/memory/qv4mm_p.h:201
No locals.
#11 QV4::MemoryManager::allocateObject<QV4::Object> (this=<optimized out>) at ../../include/QtQml/5.12.8/QtQml/private/../../../../../../git/src/qml/memory/qv4mm_p.h:211
scope = <optimized out>
ic = <optimized out>
scope = <optimized out>
ic = <optimized out>
#12 QV4::MemoryManager::allocate<QV4::Object> (this=<optimized out>) at ../../include/QtQml/5.12.8/QtQml/private/../../../../../../git/src/qml/memory/qv4mm_p.h:244
scope = <optimized out>
t = <optimized out>
scope = <optimized out>
t = <optimized out>
#13 QV4::ExecutionEngine::newObject (this=this#entry=0x158efb8) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/jsruntime/qv4engine.cpp:720
No locals.
#14 0xb69b8bf8 in QV4::ExecutionContext::createMutableBinding (this=<optimized out>, name=0xaaab8090, deletable=<optimized out>) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/jsruntime/qv4context.cpp:163
c = 0xaa5029c0
scope = {engine = 0x158efb8, mark = 0xaaab8098}
activation = {ptr = 0xaaab8098}
ctx = {ptr = 0xaaab80a0}
id = <optimized out>
desc = <optimized out>
attrs = {{m_all = 112 'p', {m_flags = 0 '\000', m_mask = 7 '\a'}, {m_type = 0 '\000', m_writable = 0 '\000', m_enumerable = 0 '\000', m_configurable = 0 '\000', type_set = 1 '\001', writable_set = 1 '\001', enumerable_set = 1 '\001', configurable_set = 0 '\000'}}}
#15 0xb6a74aae in QV4::Runtime::method_declareVar (engine=0x158efb8, deletable=<optimized out>, nameIndex=<optimized out>) at /usr/src/debug/qtdeclarative/5.12.8+gitAUTOINC+101799f8ac-r0/git/src/qml/jsruntime/qv4value_p.h:186
scope = {engine = 0x158efb8, mark = 0xaaab8090}
name = {ptr = 0xaaab8090}
#16 0xa9b6e47c in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Related

why i get the error with"SetJsonPath()" function ..?

i tried to compile the chromium code after i added the "Hello world" example from the chromium site:
https://www.chromium.org/developers/webui
and i get this error :
**../../../chrome/browser/ui/webui/hello_world_ui.cc:21:16: error: no member named 'SetJsonPath' in 'content::WebUIDataSource'
html_source->SetJsonPath("strings.js");
1 error generated.
ninja: build stopped: subcommand failed.**
i open the "web_ui_data_source.h" file and the function 'SetJsonPath()' wasn't there .
please help me , what do i need do?
---
the error :
```
1866:1866:1102/183517.446003:INFO:content_main_runner_impl.cc(975)] Chrome is running in full browser mode.
[1866:1866:1102/183530.518294:WARNING:account_consistency_mode_manager.cc(63)] Desktop Identity Consistency cannot be enabled as no OAuth client ID and client secret have been configured.
[1934:1934:1102/183533.119812:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[1934:1976:1102/183533.118386:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[1986:1:1102/183536.410055:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[2005:1:1102/183552.441983:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[2004:1:1102/183552.441389:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[2044:1:1102/183616.706233:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[2057:1:1102/183619.207918:INFO:sandbox_bpf.cc(302)] Indirect branch speculation can not be controled by prctl.2
[1866:1866:1102/183632.431375:FATAL:shared_resources_data_source.cc(326)] Check failed: -1 != idr (-1 vs. -1) path: js/i18n_template.js
#0 0x7f60d5f507ef base::debug::CollectStackTrace()
#1 0x7f60d5cd44dd base::debug::StackTrace::StackTrace()
#2 0x7f60d5cd4498 base::debug::StackTrace::StackTrace()
#3 0x7f60d5d179dd logging::LogMessage::~LogMessage()
#4 0x7f60d5d1816c logging::LogMessage::~LogMessage()
#5 0x7f60d5c9330e logging::CheckError::~CheckError()
#6 0x7f60ce5ec7ea content::SharedResourcesDataSource::StartDataRequest()
#7 0x7f60ce60a96a content::(anonymous namespace)::StartURLLoader()
#8 0x7f60ce60a256 content::(anonymous namespace)::WebUIURLLoaderFactory::CreateLoaderAndStart()
#9 0x7f60cc015cbe network::mojom::URLLoaderFactoryStubDispatch::Accept()
#10 0x7f60cbc72be5 network::mojom::URLLoaderFactoryStub<>::Accept()
#11 0x7f60d4e5f169 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#12 0x7f60d4e5ea41 mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept()
#13 0x7f60d4e6c9a5 mojo::MessageDispatcher::Accept()
#14 0x7f60d4e6097d mojo::InterfaceEndpointClient::HandleIncomingMessage()
#15 0x7f60d4e73d87 mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#16 0x7f60d4e73400 mojo::internal::MultiplexRouter::Accept()
#17 0x7f60d4e6c91f mojo::MessageDispatcher::Accept()
#18 0x7f60d4e4806a mojo::Connector::DispatchMessage()
#19 0x7f60d4e48be8 mojo::Connector::ReadAllAvailableMessages()
#20 0x7f60d4e49103 mojo::Connector::CallDispatchNextMessageFromPipe()
#21 0x7f60d4e50ed5 base::internal::FunctorTraits<>::Invoke<>()
#22 0x7f60d4e50e17 base::internal::InvokeHelper<>::MakeItSo<>()
#23 0x7f60d4e50d82 _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo9ConnectorEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunImplIS6_NSt4__Cr5tupleIJS8_EEEJLm0EEEEvOT_OT0_NSD_16integer_sequenceImJXspT1_EEEE
#24 0x7f60d4e50d37 base::internal::Invoker<>::RunOnce()
#25 0x7f60d5c89897 _ZNO4base12OnceCallbackIFvvEE3RunEv
#26 0x7f60d5e503ef base::TaskAnnotator::RunTask()
#27 0x7f60d5e98476 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl()
#28 0x7f60d5e97d2a base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#29 0x7f60d5e987fc base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#30 0x7f60d5d3d565 base::MessagePumpGlib::Run()
#31 0x7f60d5e98efa base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#32 0x7f60d5de046c base::RunLoop::Run()
#33 0x5625a40d2dce ChromeBrowserMainParts::MainMessageLoopRun()
#34 0x7f60cd158024 content::BrowserMainLoop::RunMainMessageLoopParts()
#35 0x7f60cd167766 content::BrowserMainRunnerImpl::Run()
#36 0x7f60cd153725 content::BrowserMain()
#37 0x7f60cf453c84 content::RunBrowserProcessMain()
#38 0x7f60cf455311 content::ContentMainRunnerImpl::RunServiceManager()
#39 0x7f60cf454bc6 content::ContentMainRunnerImpl::Run()
#40 0x7f60cf451157 content::RunContentProcess()
#41 0x7f60cf451b60 content::ContentMain()
#42 0x5625a1484f0d ChromeMain
#43 0x5625a1484da2 main
#44 0x7f609e7c0b97 __libc_start_main
#45 0x5625a1484c9a _start
Task trace:
#0 0x7f60d4e49005 mojo::Connector::PostDispatchNextMessageFromPipe()
#1 0x7f60d618ac14 mojo::SimpleWatcher::Context::Notify()
Received signal 6
#0 0x7f60d5f507ef base::debug::CollectStackTrace()
#1 0x7f60d5cd44dd base::debug::StackTrace::StackTrace()
#2 0x7f60d5cd4498 base::debug::StackTrace::StackTrace()
#3 0x7f60d5f502a8 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#4 0x7f60a08f08a0 (/lib/x86_64-linux-gnu/libpthread-2.27.so+0x1289f)
#5 0x7f609e7ddf47 gsignal
#6 0x7f609e7df8b1 abort
#7 0x7f60d5f4f816 base::debug::(anonymous namespace)::DebugBreak()
#8 0x7f60d5f4f7f8 base::debug::BreakDebugger()
#9 0x7f60d5d18026 logging::LogMessage::~LogMessage()
#10 0x7f60d5d1816c logging::LogMessage::~LogMessage()
#11 0x7f60d5c9330e logging::CheckError::~CheckError()
#12 0x7f60ce5ec7ea content::SharedResourcesDataSource::StartDataRequest()
#13 0x7f60ce60a96a content::(anonymous namespace)::StartURLLoader()
#14 0x7f60ce60a256 content::(anonymous namespace)::WebUIURLLoaderFactory::CreateLoaderAndStart()
#15 0x7f60cc015cbe network::mojom::URLLoaderFactoryStubDispatch::Accept()
#16 0x7f60cbc72be5 network::mojom::URLLoaderFactoryStub<>::Accept()
#17 0x7f60d4e5f169 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#18 0x7f60d4e5ea41 mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept()
#19 0x7f60d4e6c9a5 mojo::MessageDispatcher::Accept()
#20 0x7f60d4e6097d mojo::InterfaceEndpointClient::HandleIncomingMessage()
#21 0x7f60d4e73d87 mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#22 0x7f60d4e73400 mojo::internal::MultiplexRouter::Accept()
#23 0x7f60d4e6c91f mojo::MessageDispatcher::Accept()
#24 0x7f60d4e4806a mojo::Connector::DispatchMessage()
#25 0x7f60d4e48be8 mojo::Connector::ReadAllAvailableMessages()
#26 0x7f60d4e49103 mojo::Connector::CallDispatchNextMessageFromPipe()
#27 0x7f60d4e50ed5 base::internal::FunctorTraits<>::Invoke<>()
#28 0x7f60d4e50e17 base::internal::InvokeHelper<>::MakeItSo<>()
#29 0x7f60d4e50d82 _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo9ConnectorEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunImplIS6_NSt4__Cr5tupleIJS8_EEEJLm0EEEEvOT_OT0_NSD_16integer_sequenceImJXspT1_EEEE
#30 0x7f60d4e50d37 base::internal::Invoker<>::RunOnce()
#31 0x7f60d5c89897 _ZNO4base12OnceCallbackIFvvEE3RunEv
#32 0x7f60d5e503ef base::TaskAnnotator::RunTask()
#33 0x7f60d5e98476 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl()
#34 0x7f60d5e97d2a base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#35 0x7f60d5e987fc base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#36 0x7f60d5d3d565 base::MessagePumpGlib::Run()
#37 0x7f60d5e98efa base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#38 0x7f60d5de046c base::RunLoop::Run()
#39 0x5625a40d2dce ChromeBrowserMainParts::MainMessageLoopRun()
#40 0x7f60cd158024 content::BrowserMainLoop::RunMainMessageLoopParts()
#41 0x7f60cd167766 content::BrowserMainRunnerImpl::Run()
#42 0x7f60cd153725 content::BrowserMain()
#43 0x7f60cf453c84 content::RunBrowserProcessMain()
#44 0x7f60cf455311 content::ContentMainRunnerImpl::RunServiceManager()
#45 0x7f60cf454bc6 content::ContentMainRunnerImpl::Run()
#46 0x7f60cf451157 content::RunContentProcess()
#47 0x7f60cf451b60 content::ContentMain()
#48 0x5625a1484f0d ChromeMain
#49 0x5625a1484da2 main
#50 0x7f609e7c0b97 __libc_start_main
#51 0x5625a1484c9a _start
r8: 0000000000000000 r9: 00007fff7f728650 r10: 0000000000000008 r11: 0000000000000246
r12: 00005625a1484c70 r13: 00007fff7f72d0d0 r14: 0000000000000000 r15: 0000000000000000
di: 0000000000000002 si: 00007fff7f728650 bp: 00007fff7f7288a0 bx: 0000000000000000
dx: 0000000000000000 ax: 0000000000000000 cx: 00007f609e7ddf47 sp: 00007fff7f728650
ip: 00007f609e7ddf47 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
```

libstdc++ error trace unable to understand

I am trying to enable informatica Integration Service which is failing to initialize. The core dump file traces to some libstdc++ error which we are not able to identify.
We have tried to check the libstdc++ version if that is an old version but it points to latest version.
Please see lines #2 through 8.
0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007f355b906d41 in __GI_abort () at abort.c:79
2 0x00007f355c064305 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
3 0x00007f355c061ef6 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
4 0x00007f355c061f41 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
5 0x00007f355c062184 in __cxxabiv1::__cxa_throw (obj=obj#entry=0x7f353c042e70, tinfo=0x7f355c34e368 <typeinfo for std::ios_base::failure[abi:cxx11]>, dest=0x7f355c094a30 <std::ios_base::failure[abi:cxx11]::~failure()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:93
6 0x00007f355c08cea3 in std::__throw_ios_failure (__s=__s#entry=0x7f355c115f67 "basic_ios::clear") at ../../../../../libstdc++-v3/src/c++11/ios.cc:50
7 0x00007f355c0cb54d in std::basic_ios<char, std::char_traits<char> >::clear (this=<optimized out>, __state=<optimized out>) at /usr/src/debug/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_ios.tcc:48
8 0x00007f355c0d00aa in std::basic_ios<char, std::char_traits<char> >::setstate (__state=<optimized out>, this=<optimized out>) at /usr/src/debug/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_ios.h:158
9 std::istream::_M_extract<unsigned int> (this=0x7f3543ffe440, __v=#0x7f3543ffe85c: 0) at /usr/src/debug/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/istream.tcc:114
10 0x00007f3565c90266 in PmProcessStatsManager::fetchCPUStats() () from /obin/informatica/10.2/server/bin/libpmuti.so
11 0x00007f3565c90e59 in PmProcessStatsManager::collect() () from /obin/informatica/10.2/server/bin/libpmuti.so
12 0x00007f3565c9168a in PmMetricsCollector::collect() () from /obin/informatica/10.2/server/bin/libpmuti.so
13 0x00007f35660145a5 in SFOSMonitor::doMonitorProcesses() () from /obin/informatica/10.2/server/bin/libpmsf.so
14 0x00007f3566014e98 in SFOSMonitor::runImpl() () from /obin/informatica/10.2/server/bin/libpmsf.so
15 0x00007f356601caf8 in SFRunnable::run() () from /obin/informatica/10.2/server/bin/libpmsf.so
16 0x00007f356601cb81 in SFRunnable::run(void*) () from /obin/informatica/10.2/server/bin/libpmsf.so
17 0x00007f3562498a35 in ACE_Thread_Adapter::invoke_i() () from /obin/informatica/10.2/server/bin/libACE.so.6.3.3
18 0x00007f3562498ab1 in ACE_Thread_Adapter::invoke() () from /obin/informatica/10.2/server/bin/libACE.so.6.3.3
19 0x00007f3566c7354b in start_thread (arg=0x7f3543fff700) at pthread_create.c:465
20 0x00007f355b9c62ff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

All threads stuck at "select () from /lib64/libc.so.6" with high mem usage in my C++ program

enter code hereI have a binary that I am migrating from 32 bit to 64 bit.
I ran it and this was the result when I did top -H -p <name of binary> :
Note that all the entries are the threads of the same process.
So I decided that I must check what is happening inside each thread. Thus, I started attaaching to each process.
This was the result:
gdb attach 28608
(gdb) bt
#0 0x00000039a40ccfc2 in select () from /lib64/libc.so.6
#1 0x00002b40b4d20178 in ?? ()
#2 0x0000000000000000 in ?? ()
gdb attach 28472
(gdb) bt
#0 0x00000039a40ccfc2 in select () from /lib64/libc.so.6
#1 0x00002b40b4d20178 in ?? ()
#2 0x0000002d00000000 in ?? ()
#3 0x000000300000002e in ?? ()
#4 0x0000003200000000 in ?? ()
#5 0x00000000142cf418 in ?? ()
#6 0x00000000142cf3f8 in ?? ()
#7 0x0000003900000038 in ?? ()
#8 0x0000003e0000003b in ?? ()
#9 0x0000004000000000 in ?? ()
#10 0x00000000142cf278 in ?? ()
#11 0x00000000142cf2f8 in ?? ()
#12 0x0000004800000047 in ?? ()
#13 0x00007fffe259cd00 in ?? ()
#14 0x00007fffe259cd70 in ?? ()
#15 0x0000000000000000 in ?? ()
gdb attach 28475
(gdb) bt
#0 0x00000039a40ccfc2 in select () from /lib64/libc.so.6
#1 0x00002b40b4ee8f3c in ?? ()
#2 0x0000000000000002 in ?? ()
#3 0x0000000000069f50 in ?? ()
#4 0x00002b40b542e160 in ?? ()
#5 0x00002b40b4ee9e91 in ?? ()
#6 0x00002b40b5505681 in ?? ()
#7 0x00000000140fede0 in ?? ()
#8 0x0000000000000000 in ?? ()
gdb attach 28609
(gdb) bt
#0 0x00000039a40ccfc2 in select () from /lib64/libc.so.6
#1 0x00002b40b4d20178 in ?? ()
#2 0x0000000000000000 in ?? ()
I am not quite sure what this select() function is.
Can you tell me what might be wrong here ? Why are all the threads stuck like that ?
have you ever encountered something like this before ?
select is an api call that allows you to monitor file descriptors for activity, at which point you will be notified and can carry out the activity (eg read or write).
It looks like your program has 4 threads that are each waiting on select to return.

Understanding deadlock behavior with gdb

I am hunting down a deadlock, but I don't understand gdb behavior in this respect. I have two threads:
Thread 2 (Thread 0x2aaaadf66940 (LWP 10229)):
#0 0x0000003f95e0d654 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0000003f95e08f65 in _L_lock_1127 () from /lib64/libpthread.so.0
#2 0x0000003f95e08e63 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00002b67cbdeaded in ?? ()
#4 0x000000002d0e9608 in ?? ()
#5 0x00002b67cbd1e1f2 in ?? ()
#6 0x000000000000000b in ?? ()
#7 0x00002aaaca08e410 in ?? ()
#8 0x00002aaab405d558 in ?? ()
#9 0x00002aaaadf65f48 in ?? ()
#10 0x00002aaaadf65fa0 in ?? ()
#11 0x00002aaaadf65fc0 in ?? ()
#12 0x00002aaaadf65f40 in ?? ()
#13 0x00002aaaadf65f50 in ?? ()
#14 0x000000002d0e7460 in ?? ()
#15 0x0000000026014330 in ?? ()
#16 0x00002b67cc1d08b0 in ?? ()
#17 0x0000003f94e7587b in free () from /lib64/libc.so.6
#18 0x00002aaac8b67450 in ?? ()
#19 0x00002aaaadf66070 in ?? ()
#20 0x13477fb9fe21aee8 in ?? ()
#21 0x000003742e856f43 in ?? ()
#22 0x00002b67cbe11811 in ?? ()
#23 0x00002b67cc1cfc70 in ?? ()
#24 0x000000002d0e8328 in ?? ()
#25 0x000000002d0e9630 in ?? ()
#26 0x00002b67cbded355 in ?? ()
#27 0x0000000052cdceee in ?? ()
#28 0x000000002d0e9608 in ?? ()
#29 0x0000000000000001 in ?? ()
#30 0x000000002d0e9700 in ?? ()
#31 0x000000002d0e96a8 in ?? ()
#32 0x000000002d0e9728 in ?? ()
#33 0x000000002d0e9630 in ?? ()
#34 0x00002b67cbded538 in ?? ()
#35 0x000000002ccbc6a8 in ?? ()
#36 0x00002aaaadf66070 in ?? ()
#37 0xfffffffffffffffe in ?? ()
#38 0x0000000000000008 in ?? ()
#39 0x00002b67cbe0cf00 in ?? ()
#40 0x0000003b24002216 in ?? () from /usr/lib64/tls/libnvidia-tls.so.319.60
#41 0x00002b67cbe116ec in ?? ()
#42 0x000000002d0e9648 in ?? ()
#43 0xffffffffffffff01 in ?? ()
#44 0x00002b67cc1f38f8 in ?? ()
#45 0x00002b67cbe103fa in ?? ()
#46 0x0000000019eac470 in ?? ()
#47 0x0000000034bc8ef0 in ?? ()
#48 0x00000000ffffffff in ?? ()
#49 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x2b67c311c600 (LWP 9798)):
#0 0x0000003f95e0d654 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0000003f95e08f4a in _L_lock_1034 () from /lib64/libpthread.so.0
#2 0x0000003f95e08e0c in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00002b67cbdf02a8 in ?? ()
#4 0x000000000000b000 in ?? ()
#5 0x000000000000b000 in ?? ()
#6 0x000000002d0e7460 in ?? ()
#7 0x00002aaad484e6c0 in ?? ()
#8 0x00007fffd540a1b0 in ?? ()
#9 0x0000003f94e73f0e in malloc () from /lib64/libc.so.6
#10 0x0000003b24002216 in ?? () from /usr/lib64/tls/libnvidia-tls.so.319.60
#11 0x0000000000000000 in ?? ()
These two threads are apparently deadlocking: Thread 1 wants to acquire the lock from thread 2 (note the owner)
(gdb) p *(pthread_mutex_t*)0x2d0e9648
$1 = {__data = {__lock = 2, __count = 0, __owner = 10229, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
and thread 2 wants to acquire the lock from thread 1
(gdb) p *(pthread_mutex_t*)0x2d0e8330
$2 = {__data = {__lock = 2, __count = 1, __owner = 9798, __nusers = 1, __kind = 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
Now, What I don't understand is why the backtrace is so broken. I tried checking which libraries are mapped to those address (in particular the 2b67cbd) but none do. I tried a disas. no luck:
(gdb) disas 0x00002b67cbdeaded
No function contains specified address.
There seems to be nothing on those addresses. I thought it was a stack corruption, but then what is happening that actually calls the pthread lock? Who sends the thread to that code? and how reliable is the call to free() (note that the other thread is doing a call to malloc, so they might be related in their activity)?
(gdb) disas 0x00002b67cbdeaded
No function contains specified address.
There seems to be nothing on those addresses.
Your conclusion is likely not correct. Try (gdb) x/20i 0x00002b67cbdeaded-5, and you'll see that in fact there is code there, including a CALL pthread_mutex_lock.
What's likely happening is that something in your program is using a JIT compiler, and the code that calls pthread_mutex_lock does not have any symbols (that GDB knows about) associated with it.
That code also doesn't have any unwind descriptors, which makes the rest of the stack completely unreliable. free and malloc may or may not be actually on stack.
It may be illustrative to look at /proc//maps and see what is mapped in the 0x00002b67cbdea000 region. Most likely you'll find anonymous mapping with rwxp permissions.

GDB giving useless backtrace's when using core dump

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?