Program crash after wxThreadEvent::GetPayload() - c++

I have a C++ program in Code::Block with gcc and wxWidgets.
After my working thread throws a wxThreadEvent with a struct as payload my program crashes (actually not at the throw, but at the moment I want to get the payload in the main).
Does anyone have an idea what is wrong?
The working thread part:
wxThread::ExitCode NavigationThread::Entry()
{
wxThreadEvent event(wxEVT_THREAD, ID_REFRESH_DIRECTION);
position_variables positionPayload;
positionPayload.latitude = latDouble;
positionPayload.longitude = lonDouble;
positionPayload.direction = direction;
event.SetPayload(&positionPayload);
m_parent->GetEventHandler()->AddPendingEvent(event);
}
The struct:
struct position_variables{
double latitude;
double longitude;
wxString direction;
};
class NavigationThread : public wxThread
{
...
}
The main.cpp
WindowsDgpsGUIFrame::WindowsDgpsGUIFrame(wxWindow* parent,wxWindowID id)
{
Bind(wxEVT_THREAD, &WindowsDgpsGUIFrame::onRefreshDirections, this, ID_REFRESH_DIRECTION);
}
void WindowsDgpsGUIFrame::onRefreshDirections(wxThreadEvent& event)
{
position_variables answerDirections = event.GetPayload<position_variables>(); //Here it crashes
}
When the crash occurs in normal "run" mode, a windows opens saying the program stopped working. In debug mode there is a small window in Code::blocks saying something about SIGSEGV, segmentation fault (or something like that) and this is the Call Stack:
#0 00877A54 std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () (??:??)
#1 04A1E550 ?? () (??:??)
#2 007ED139 position_variables::position_variables(this=0x4a1e588) (D:/WindowsDgps/WindowsDgpsGUI/NavigationThread.h:54)
#3 00851B54 wxAny::As<position_variables>(this=0x4c6fe70) (C:/wxWidgets-3.0.2/include/wx/any.h:979)
#4 0084E70C wxEventAnyPayloadMixin::GetPayload<position_variables>(this=0x4c6fe58) (C:/wxWidgets-3.0.2/include/wx/event.h:1219)
#5 0043320E WindowsDgpsGUIFrame::onRefreshDirections(this=0x4be2a68, event=...) (D:\WindowsDgps\WindowsDgpsGUI\WindowsDgpsGUIMain.cpp:440)
#6 0063AA48 wxAppConsoleBase::HandleEvent (this=0x4b2bde0, handler=0x4be2a68, func=(void (wxEvtHandler::*)(wxEvtHandler * const, wxEvent &) (../../src/common/appbase.cpp:611)
#7 0063AAD9 wxAppConsoleBase::CallEventHandler(this=0x4b2bde0, handler=0x4be2a68, functor=..., event=...) (../../src/common/appbase.cpp:623)
#8 0062DEA1 wxEvtHandler::ProcessEventIfMatchesId(entry=..., handler=0x4be2a68, event=...) (../../src/common/event.cpp:1392)
#9 0062EB3A wxEvtHandler::SearchDynamicEventTable(this=0x4be2a68, event=...) (../../src/common/event.cpp:1751)
#10 0062E318 wxEvtHandler::TryHereOnly(this=0x4be2a68, event=...) (../../src/common/event.cpp:1585)
#11 007C50A0 wxEvtHandler::TryBeforeAndHere(this=0x4be2a68, event=...) (../../include/wx/event.h:3671)
#12 0062E157 wxEvtHandler::ProcessEventLocally(this=0x4be2a68, event=...) (../../src/common/event.cpp:1522)
#13 0062E0FF wxEvtHandler::ProcessEvent(this=0x4be2a68, event=...) (../../src/common/event.cpp:1495)
#14 0062DCEC wxEvtHandler::ProcessPendingEvents(this=0x4be2a68) (../../src/common/event.cpp:1359)
#15 0063A69C wxAppConsoleBase::ProcessPendingEvents(this=0x4b2bde0) (../../src/common/appbase.cpp:520)
#16 007F0883 wxIdleWakeUpModule::MsgHookProc(nCode=0, wParam=1, lParam=77720172) (../../src/msw/window.cpp:7454)
#17 746BE1A1 USER32!TrackMouseEvent() (C:\WINDOWS\SysWOW64\user32.dll:??)
#18 ?? ?? () (??:??)
with #2 highlighted red.
Maybe it has something to do with the Clone() part in SetPayload()? Though I don't quite get how I should use it or why my accessing of the payload would be problematic...

You can't use a pointer to a local variable, which will be destroyed as soon as you exit the function containing it, thus making the pointer invalid, as the payload. Use the object itself, not a pointer to it, instead.

Related

Assigning std::function causes segfault

I have a strange segmentation fault I am unable to properly understand. I am creating a function object with std::bind, then assign this to a std::function object, this apparently results in a segfault.
std::function<ara::com::Future<SetShapeOutput>(const
messages::test::SetShapeParams&)> SetShape_callback_;
void set_SetShape_callback(const std::function<ara::com::Future<SetShapeOutput>(
const messages::test::SetShapeParams&)>& callback) {
SetShape_callback_ = callback;
}
[somewhere else]
algo_service_.GetshapeServiceSkeleton()->set_SetShape_callback(
std::bind(&ShapeServerAraBinding::on_call_serviceshapeService_methodSetShape,
this, std::placeholders::_1));
// definition
ara::com::Future<adaptiveautosarapplication::shapeServiceSkeleton::SetShapeOutput>
on_call_serviceshapeService_methodSetShape(
const messages::test::SetShapeParams& araSetShapeParams);
And the stacktrace from gdb showing the assignment causes a segfault:
#0 0x000055c45c268839 in std::swap<std::_Any_data> (__a=..., __b=...) at /usr/include/c++/6/bits/move.h:191
#1 0x000055c45c267781 in std::function<ara::com::Future<serviceInterfaces::test::shapeService::SetShapeOutput> (messages::test::SetShapeParams const&)>::swap(s
td::function<ara::com::Future<serviceInterfaces::test::shapeService::SetShapeOutput> (messages::test::SetShapeParams const&)>&) (this=0x7fffea5d6be0, __x=...)
at /usr/include/c++/6/functional:2016
#2 0x000055c45c263934 in std::function<ara::com::Future<serviceInterfaces::test::shapeService::SetShapeOutput> (messages::test::SetShapeParams const&)>::operat
or=(std::function<ara::com::Future<serviceInterfaces::test::shapeService::SetShapeOutput> (messages::test::SetShapeParams const&)> const&) (this=0x58, __x=...)
at /usr/include/c++/6/functional:1931
#3 0x000055c45c26009f in shapeServer::adaptiveautosarapplication::shapeServiceSkeleton::set_SetShape_callback(std::function<ara::com::Future<serviceInterfaces:
:test::shapeService::SetShapeOutput> (messages::test::SetShapeParams const&)> const&) (this=0x0, callback=...)
at /app/tests/eclipseProject/projects/shapeRPC/build/autogen/algos/shape/server/ara/include/shapeServer_service.h:40
#4 0x000055c45c260508 in shapeServer::ShapeServerAraBinding::Initialize (this=0x7fffea5d6dd0)
at /app/tests/eclipseProject/projects/shapeRPC/build/autogen/algos/shape/server/ara/include/shapeServerAraBinding.h:69
#5 0x000055c45c25854c in main (argc=1, argv=0x7fffea5d6fd8)
at /app/tests/eclipseProject/projects/shapeRPC/build/autogen/algos/shape/server/ara/src/shapeServerAraMain.cpp:108
The problem cause is shown in the following line:
#3 0x000055c45c26009f in shapeServer::adaptiveautosarapplication::shapeServiceSkeleton::set_SetShape_callback(std::function<ara::com::Future<serviceInterfaces:
:test::shapeService::SetShapeOutput> (messages::test::SetShapeParams const&)> const&) (this=0x0, callback=...)
Note shapeServiceSkeleton this=0x0.

what is causing this seq fault in Qt QGuiApplicationPrivate::processNativeEvent()

I have a simple Qt program that is reading from shared memory in a separate thread. I call a routine that waits until there is data in the shared memory segment, it unblocks and returns and then I emits a signal to the main GUI thread. The main GUI thread slot is received and in that routine I just print to std::cout that it was received then it returns--no further data processing. This program runs find for about 30 seconds then seq faults.
Running the program under gdb catches the seq fault and a back trace shows that the fault is deep in the event processing of Qt. None of my own code is involved in this seq fault. I am totally lost as to what the problem is.
Here is the gdb output. In the following gdb output, the readSM() routine is the one that blocks until there is data available to read from shared memory, and the readDataBuffer() is the slot from the main GUI thread that just returns without any further processing. There are tons of the std::cout lines for the signal and slot before the seg fault.
...many of the following 2 lines before the fault...
DataReader::readSM(): calling m_pSharedMemory->ReadWait()
readDataBuffer(): entered, returning
DataReader::readSM(): calling m_pSharedMemory->ReadWait()
readDataBuffer(): entered, returning
Program received signal SIGSEGV, Segmentation fault.
0xb72f5c54 in QGuiApplicationPrivate::processNativeEvent(QWindow*, QByteArray const&, void*, long*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Gui.so.5
(gdb)
(gdb) bt
#0 0xb72f5c54 in QGuiApplicationPrivate::processNativeEvent(QWindow*, QByteArray const&, void*, long*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Gui.so.5
#1 0xb72e3ff3 in QWindowSystemInterface::handleNativeEvent(QWindow*, QByteArray const&, void*, long*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Gui.so.5
#2 0xb3f40e2d in ?? () from /opt/Qt/5.2.1/gcc/plugins/platforms/libqxcb.so
#3 0xb3f33170 in ?? () from /opt/Qt/5.2.1/gcc/plugins/platforms/libqxcb.so
#4 0xb3f33dce in ?? () from /opt/Qt/5.2.1/gcc/plugins/platforms/libqxcb.so
#5 0xb3f74e8b in ?? () from /opt/Qt/5.2.1/gcc/plugins/platforms/libqxcb.so
#6 0xb701e943 in QMetaCallEvent::placeMetaCall(QObject*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#7 0xb7021d92 in QObject::event(QEvent*) () from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#8 0xb7913eb4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Widgets.so.5
#9 0xb7917d00 in QApplication::notify(QObject*, QEvent*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Widgets.so.5
#10 0xb6ff3c2e in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#11 0xb6ff68ec in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#12 0xb6ff6e2c in QCoreApplication::sendPostedEvents(QObject*, int) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#13 0xb704ad14 in ?? () from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#14 0xb68a06d3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#15 0xb68a0a70 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#16 0xb68a0b51 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#17 0xb704b128 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#18 0xb3f97836 in ?? () from /opt/Qt/5.2.1/gcc/plugins/platforms/libqxcb.so
#19 0xb6ff22e6 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#20 0xb6ff272c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#21 0xb6ff6ed2 in QCoreApplication::exec() () from /opt/Qt/5.2.1/gcc/lib/libQt5Core.so.5
#22 0xb72f5b04 in QGuiApplication::exec() () from /opt/Qt/5.2.1/gcc/lib/libQt5Gui.so.5
#23 0xb790e914 in QApplication::exec() () from /opt/Qt/5.2.1/gcc/lib/libQt5Widgets.so.5
#24 0x0805034b in main ()
(gdb)
Since I am not processing any of the data in the GUI slot, and since this program works fine for about 30 seconds with its usual signal/slots being called, I am at a loss at to what is causing this seq fault in the Qt event processing.
Any help would be very appreciated.
Thanks,
-Andres
UPDATE:
thank you Andrew Medico for your suggestion to use valgrind. I never thought of using it as a debugging tool but that makes perfect sense. After using it, it became obvious that you were correct that something else was causing the problem and I finally found the cause elsewhere in my code. I was over writing a buffer. Thanks again Andrew for your assistance.
-Andres

notify_all causes segmentation fault

I am using boost threads, upon calling notify_all() within the destructor i am seeing a segmentation fault. Here is the stack:
(gdb) where
#0 0x00007ffff752de84 in pthread_mutex_lock ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007fffe85ab22e in boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock (this=0x7fffffffdba0, m_=0x0)
at /usr/include/boost/thread/pthread/pthread_mutex_scoped_lock.hpp:26
#2 0x00007fffe85abb5d in boost::condition_variable::notify_one (this=0x0)
at /usr/include/boost/thread/pthread/condition_variable.hpp:88
#3 0x00007fffe8690864 in CampaignFrequency::stopFlushThread (this=0x6ad590)
at /home/git/gitRTB/infinityplus/src/common/shm/CampaignFrequency.cpp:197
#4 0x00007fffe868ffd7 in CampaignFrequency::~CampaignFrequency (
this=0x6ad590, __in_chrg=<optimised out>)
at /home/git/gitRTB/infinityplus/src/common/shm/CampaignFrequency.cpp:81
#5 0x00007fffe85bdc37 in rtb_child_init (s=0x7ffff7fc3238)
at /home/git/gitRTB/infinityplus/src/bidder/mod_rtb.cpp:265
#6 0x000000000044784c in ap_run_child_init ()
#7 0x000000000042817c in ?? ()
#8 0x0000000000463594 in ?? ()
#9 0x00000000004635f4 in ?? ()
#10 0x00000000004643fd in ?? ()
#11 0x000000000042f026 in ap_run_mpm ()
#12 0x0000000000428d74 in main ()
Without actually seeing the code, this is mostly conjecture.
From your debug:
#2 0x00007fffe85abb5d in boost::condition_variable::notify_one (this=0x0)
at /usr/include/boost/thread/pthread/condition_variable.hpp:88
It's saying that this (inside the condition variable) is nullptr. It appears that you are calling cv->notify_all() where cv is nullptr (aka 0). Is it possible you are deleting the condition variable prior to trying to use it?

C++ terminate called without an active exception (gdb)

Using iOS 5.X
Cpp 11
Xcode
I am trying to identify what is causing this error.
It may be caused from destructor being called prior to a thread completing.
// default_delete
template <class _Tp>
struct _LIBCPP_VISIBLE default_delete
{
_LIBCPP_INLINE_VISIBILITY default_delete() _NOEXCEPT {}
template <class _Up>
_LIBCPP_INLINE_VISIBILITY default_delete(const default_delete<_Up>&,
typename enable_if<is_convertible<_Up*, _Tp*>::value>::type* = 0) _NOEXCEPT {}
_LIBCPP_INLINE_VISIBILITY void operator() (_Tp* __ptr) const _NOEXCEPT
{
static_assert(sizeof(_Tp) > 0, "default_delete can not delete incomplete type");
delete __ptr;
}
};
The stack trace is as follows:
stack trace
2013-01-28 13:50:33.704 CPP11AudioRecoClient[4633:5107] A task has completed. Map now contains 0 entries.
terminate called without an active exception(gdb) bt
#0 0x316e932c in __pthread_kill
#1 0x33de620e in pthread_kill
#2 0x33ddf29e in abort
#3 0x36c6cf6a in abort_message
#4 0x36c6a35a in default_terminate
#5 0x35237324 in _objc_terminate
#6 0x31997c96 in std::terminate
#7 0x319d3d18 in std::__1::thread::~thread ()
#8 0x00076cce in std::__1::default_delete<std::__1::thread>::operator() () at /Volumes/Xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:2512
#9 0x319d3d18 in std::__1::thread::~thread ()
#10 0x319d3d18 in std::__1::thread::~thread ()
#11 0x319c94cc in std::__1::__shared_weak_count::__release_shared ()
#12 0x00077606 in std::__1::shared_ptr<std::__1::thread>::~shared_ptr (this=0x2d64c4) at memory:4441
#13 0x0007676c in std::__1::shared_ptr<std::__1::thread>::~shared_ptr (this=0x2d64c4) at memory:4439
#14 0x00076038 in Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread::~Cpp11Thread (this=0x2d64c0) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/Cpp11ThreadFactory.cpp:125
#15 0x00075ffc in Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread::~Cpp11Thread (this=0x2d64c0) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/Cpp11ThreadFactory.cpp:123
#16 0x00075fdc in Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread::~Cpp11Thread (this=0x2d64c0) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/Cpp11ThreadFactory.cpp:123
#17 0x00077f68 in std::__1::default_delete<Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread>::operator() () at /Volumes/Xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:2512
#18 0x00077f68 in std::__1::__shared_ptr_pointer<Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread*, std::__1::default_delete<Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread>, std::__1::allocator<Microsoft::BingMobile::MusicReco::ClientSDK::Cpp11Thread> >::__on_zero_shared (this=0x2d5280) at memory:3668
#19 0x319c94cc in std::__1::__shared_weak_count::__release_shared ()
#20 0x0006a86e in std::__1::shared_ptr<Microsoft::BingMobile::MusicReco::ClientSDK::IThread>::~shared_ptr (this=0x2d6478) at memory:4441
#21 0x00069d94 in std::__1::shared_ptr<Microsoft::BingMobile::MusicReco::ClientSDK::IThread>::~shared_ptr (this=0x2d6478) at memory:4439
#22 0x00068d56 in Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask::~AsyncTask (this=0x2d6460) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/AsyncTask.cpp:34
#23 0x00068ce8 in Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask::~AsyncTask (this=0x2d6460) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/AsyncTask.cpp:33
#24 0x00068cc8 in Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask::~AsyncTask (this=0x2d6460) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/AsyncTask.cpp:33
#25 0x0006ad08 in std::__1::default_delete<Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask>::operator() () at /Volumes/Xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:2512
#26 0x0006ad08 in std::__1::__shared_ptr_pointer<Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask*, std::__1::default_delete<Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask>, std::__1::allocator<Microsoft::BingMobile::MusicReco::ClientSDK::AsyncTask> >::__on_zero_shared (this=0x2d6090) at memory:3668
#27 0x319c94cc in std::__1::__shared_weak_count::__release_shared ()
#28 0x00069fca in std::__1::shared_ptr<Microsoft::BingMobile::MusicReco::ClientSDK::ITaskObserver>::~shared_ptr (this=0x44fb4fc) at memory:4441
#29 0x00069e6c in std::__1::shared_ptr<Microsoft::BingMobile::MusicReco::ClientSDK::ITaskObserver>::~shared_ptr (this=0x44fb4fc) at memory:4439
#30 0x00099c22 in Microsoft::BingMobile::MusicReco::ClientSDK::RunnableTaskBase::notifyObserver (this=0x2d6350, observerWeak=<value temporarily unavailable, due to optimizations>, sharedReferenceToSelf=#0x44fb638) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/RunnableTaskBase.cpp:100
#31 0x00099930 in Microsoft::BingMobile::MusicReco::ClientSDK::RunnableTaskBase::notifyObservers (this=0x2d6350, sharedReferenceToSelf=<value temporarily unavailable, due to optimizations>) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/RunnableTaskBase.cpp:79
#32 0x000996e0 in Microsoft::BingMobile::MusicReco::ClientSDK::RunnableTaskBase::setStatus (this=0x2d6350, targetStatus=Microsoft::BingMobile::MusicReco::ClientSDK::Completed, sharedReferenceToSelf=#0x44fbd20) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/RunnableTaskBase.cpp:107
#33 0x00087168 in Microsoft::BingMobile::MusicReco::ClientSDK::PingWebServiceTask::runTaskChecked (this=0x2d6350, sharedReferenceToSelf=<value temporarily unavailable, due to optimizations>) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/PingWebServiceTask.cpp:120
#34 0x00099356 in Microsoft::BingMobile::MusicReco::ClientSDK::RunnableTaskBase::runTask (this=0x2d6350) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/RunnableTaskBase.cpp:60
#35 0x000991d2 in Microsoft::BingMobile::MusicReco::ClientSDK::RunnableTaskBase::run (this=0x2d6350, sharedReferenceToSelf=<value temporarily unavailable, due to optimizations>) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/RunnableTaskBase.cpp:48
#36 0x00099250 in non-virtual thunk to Microsoft::BingMobile::MusicReco::ClientSDK::RunnableTaskBase::run(std::__1::shared_ptr<Microsoft::BingMobile::MusicReco::ClientSDK::IRunnable>) () at memory:4023
#37 0x000759ca in Microsoft::BingMobile::MusicReco::ClientSDK::RunHookedRunnable::run (this=0x2d64a0, sharedReferenceToSelf=#0x44fcea8) at /Users/v-mattkn/Desktop/CPP11AudioRecoClient/Cpp11ThreadFactory.cpp:75
#38 0x0007736e in _ZNKSt3__110unique_ptrINS_5tupleIJMN9Microsoft10BingMobile9MusicReco9ClientSDK9IRunnableEFvNS_10shared_ptrIS6_EEES8_S8_EEENS_14default_deleteISB_EEEdeEv [inlined] () at /Volumes/Xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:309
#39 0x0007736e in _ZNSt3__114__thread_proxyINS_5tupleIJMN9Microsoft10BingMobile9MusicReco9ClientSDK9IRunnableEFvNS_10shared_ptrIS6_EEES8_S8_EEEEEPvSC_ (__vp=0x2d6230) at __functional_base:340
40 0x33da7734 in _pthread_start ()
That thread::~thread() in the backtrace suggests that the thread is still running when it's object gets destroyed. That's an error; you have to call join() or detach() on the thread object before destroying it.

Is it possible to programmatically cause dlopen() in OS X to return NULL?

Let's call it x.dylib. I only want x.dylib to be loaded sometimes.
In the initialization of the dylib is there any way to have some logic which would cause the dlopen() call that tried to load x.dylib to fail to load x.dylib and return NULL?
Renaming x.dylib is not an option.
I looked through http://opensource.apple.com/source/dyld/dyld-210.2.3/src/dyldAPIs.cpp but I am unfamiliar with the code.
I thought maybe this would do it:
__attribute__((constructor))
void initializer(void) {
fprintf(stderr, "initializer\n");
throw;
}
but when I call dlopen() on the dylib with that initializer, i just get "initializer
terminate called without an active exceptionAbort trap: 6"
So I'm stumped; any help would be great.
Edit:
The stack trace, when viewed with gdb is as follows:
Program received signal SIGABRT, Aborted.
0x00007fff9128a82a in __kill ()
(gdb) bt
#0 0x00007fff9128a82a in __kill ()
#1 0x00007fff93539a9c in abort ()
#2 0x00007fff987f07bc in abort_message ()
#3 0x00007fff987edfcf in default_terminate ()
#4 0x00007fff987ee001 in safe_handler_caller ()
#5 0x00007fff987ee05c in std::terminate ()
#6 0x00007fff987ef152 in __cxa_throw ()
#7 0x0000000100003eb5 in initializer ()
#8 0x00007fff5fc0fda6 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#9 0x00007fff5fc0faf2 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#10 0x00007fff5fc0d2e4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#11 0x00007fff5fc0d27d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#12 0x00007fff5fc0e0b7 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#13 0x00007fff5fc034dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
#14 0x00007fff5fc0760b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#15 0x00007fff5fc01059 in __dyld__dyld_start ()
which come from:
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/dyld.cpp
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/ImageLoader.cpp
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/ImageLoaderMachO.cpp
I'm surprised that I don't see dlopen() in the stack trace though.