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

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.
```

Related

Qt: stackview push a qml causes crash [closed]

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

gdb errors in c++ using FLTK on MAC

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.

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.

Segfault when <ctrl> + <leftflick> an unfocused window of a CygwinX QT app

When ctrl + leftclick the unfocused window of a QT application launched via Cygwin X, I am noticing a very repeatable segfault. At this point I've trimmed off all of my application code and can still see the same behavior while running a simple QMainWindow holding a few empty TextEdits. A simple left click into the unfocused window (while holding ctrl) will cause a segfault ~50% of the time.
Has anybody noticed a similar behavior? I'm very curious since I don't seem to see this behavior documented or reported elsewhere.
Note: I've noticed that this behavior applies to all Modifier keys (alt, ctrl, shift, etc).
#0 0x00007f8429cf614b in ?? () from /usr/local/lib/qt5/5.0.2/gcc_64/plugins/platforms/libqxcb.so
#1 0x00007f8429cee501 in ?? () from /usr/local/lib/qt5/5.0.2/gcc_64/plugins/platforms/libqxcb.so
#2 0x00007f8429ce9e20 in ?? () from /usr/local/lib/qt5/5.0.2/gcc_64/plugins/platforms/libqxcb.so
#3 0x00007f8429ceb0cb in ?? () from /usr/local/lib/qt5/5.0.2/gcc_64/plugins/platforms/libqxcb.so
#4 0x00007f84306c955e in QObject::event(QEvent*) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5
#5 0x00007f84311f25b4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Widgets.so.5
#6 0x00007f84311f5991 in QApplication::notify(QObject*, QEvent*) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Widgets.so.5
#7 0x00007f84306a27c4 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5
#8 0x00007f84306a4701 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5
#9 0x00007f84306ea0d3 in ?? () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5
#10 0x00007f842e7e3f05 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f842e7e4248 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f842e7e4304 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f84306ea514 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5
#14 0x00007f84306a169b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5
#15 0x00007f84306a4c3e in QCoreApplication::exec() () from /usr/local/lib/qt5/5.0.2/gcc_64/lib/libQt5Core.so.5

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?