Stuck in DatachannelInterface - c++

I use a self compile webrtc source in cpp. Reagulary when I use DataChannel after reconnection, my program just stuck.
Here is the debug I have:
Thread 13 (Thread 0x7f3f39a33700 (LWP 819)):
#0 pthread_cond_wait##GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x000055a8542d4d05 in rtc::Event::Wait(int, int) ()
#2 0x000055a85451f630 in webrtc::DataChannelProxyWithInternal<webrtc::DataChannelInterface>::reliable() const ()
#3 0x000055a854234c4f in DataChannelInterfaceManager::reliable (this=0x7f3f00006af0) at ./PeerConnectionManager.h:100
What is that rtc::Event::Wait function and why the program just stuck with no errors?
rtc::scoped_refptr<webrtc::DataChannelInterface> dataChannel;
....
bool
reliable(void) {
if (dataChannel.get() == nullptr) {
RTC_LOG(LERROR) << __LINE__;
return false;
}
return dataChannel->reliable(); // Freeze here
}
I also add the complete log from gdb
https://pastebin.com/YGE5qUPi

Related

How to handle quick_exit in a class member thread when `this` becomes a nullptr?

I have this small snippet of code:
// (...)
class Time
{
std::atomic<bool> m_running;
std::thread m_worker;
// ...
};
Time::Time()
{
// ...
m_running = true;
m_worker = std::move(std::thread(std::bind(&Time::Worker, this)));
}
bool Time::HasTimedOut() const
{
return (!m_disabled) &&
(IsPending() && (GetRunTime() >= m_maximum_timeout) && (CloseHandlesDiff() >= m_minimum_close_time));
}
Time::~Time()
{
if (m_running)
{
m_running = false;
m_worker.join();
}
}
void Time::Worker()
{
while (m_running)
{
if (time_data->HasTimedOut())
{
time_data->RunTimedOutCallback();
}
if (m_count < 0)
{
m_count = 0;
}
if (m_running)
{
std::this_thread::sleep_for(std::chrono::milliseconds(20));
}
}
}
std::shared_ptr<Time> time_data(std::make_shared<Time>());
To my surprise, I have gotten a coredump, and the backtrace command from gdb shows this:
(gdb) bt
#0 0x09438408 in monitor::Time::HasTimedOut (this=0x0)
at monitor.cxx: // return (!m_disabled) &&
#1 0x09438a84 in monitor::Time::Worker (this=0xbd96dd8)
monitor.cxx: // if(time_data->HasTimedOut()
#2 0x0943cf81 in std::__invoke_impl<void, void (monitor::Time::*&)(), monitor::Time*&> (
__f=#0xbd96e54: (void (monitor::Time::*)(monitor::Time * const)) 0x94389f0 <monitor::Time::Worker()>, __t=#0xbd96e5c: 0xbd96dd8)
A nullptr seems to be the problem (SEGFAULT):
(this=0x0)
This means that my class got destroyed, without the destructor being called.
This might be possible when the OS/watchdog for my application does a force exit / quick terminate as far as I know/suspect.
Are there any ways to deal with this? Maybe some shared_ptr atomic wrapping where I could check if the shared_ptr is a nullptr, is there some atomic if-not-null-execute-this? Then again.. this happened literally mid-execution.
I know one can add quick-exit hooks, but the quick exit is sometimes used for good reason, it would be agains the design to slow down the quick-exit. What would be the best way to handle this becoming a nullptr?
Or should I just let the SEGFALT happen because the application is being quick-exited anyway?
Here is the full stack, but that probably won't add any more useful information:
(gdb) bt
(gdb) bt
#0 0x09438408 in monitor::Time::HasTimedOut (this=0x0)
at /opt/procesleiding/vptlib/lib/oracle_monitor.cxx:111
#1 0x09438a84 in monitor::Time::Worker (this=0xbd96dd8)
at /opt/procesleiding/vptlib/lib/oracle_monitor.cxx:142
#2 0x0943cf81 in std::__invoke_impl<void, void (monitor::Time::*&)(), monitor::Time*&> (
__f=#0xbd96e54: (void (monitor::Time::*)(monitor::Time * const)) 0x94389f0 <monitor::Time::Worker()>, __t=#0xbd96e5c: 0xbd96dd8)
at /usr/include/c++/7/bits/invoke.h:73
#3 0x0943c99f in std::__invoke<void (monitor::Time::*&)(), monitor::Time*&> (
__fn=#0xbd96e54: (void (monitor::Time::*)(monitor::Time * const)) 0x94389f0 <monitor::Time::Worker()>, __args#0=#0xbd96e5c: 0xbd96dd8)
at /usr/include/c++/7/bits/invoke.h:95
#4 0x0943c70c in std::_Bind<void (monitor::Time::*(monitor::Time*))()>::__call<void, , 0u>(std::tuple<>&&, std::_Index_tuple<0u>) (
this=0xbd96e54, __args=...)
at /usr/include/c++/7/functional:467
#5 0x0943c28c in std::_Bind<void (monitor::Time::*(monitor::Time*))()>::operator()<, void>() (this=0xbd96e54)
at /usr/include/c++/7/functional:551
#6 0x0943bcaf in std::__invoke_impl<void, std::_Bind<void (monitor::Time::*(monitor::Time*))()>>(std::__invoke_other, std::_Bind<void (monitor::Time::*(monitor::Time*))()>&&) (__f=...) at /usr/include/c++/7/bits/invoke.h:60
#7 0x0943b022 in std::__invoke<std::_Bind<void (monitor::Time::*(monitor::Time*))()>>(std::_Bind<void (monitor::Time::*(monitor::Time*))()>&&) (__fn=...) at /usr/include/c++/7/bits/invoke.h:95
#8 0x0943e2a6 in std::thread::_Invoker<std::tuple<std::_Bind<void (monitor::Time::*(monitor::Time*))()> > >::_M_invoke<0u>(std::_Index_tuple<0u>) (this=0xbd96e54) at /usr/include/c++/7/thread:234
#9 0x0943e15c in std::thread::_Invoker<std::tuple<std::_Bind<void (monitor::Time::*(monitor::Time*))()> > >::operator()() (this=0xbd96e54) at /usr/include/c++/7/thread:243
#10 0x0943e067 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<std::_Bind<void (monitor::Time::*(monitor::Time*))()> > > >::_M_run() (this=0xbd96e50) at /usr/include/c++/7/thread:186
Your code has a race condition.
Time::Time()
{
// ...
m_running = true;
m_worker = std::move(std::thread(std::bind(&Time::Worker, this)));
}
Here tread starts before
std::shared_ptr<Time> time_data(std::make_shared<Time>());
is completed.
Simply thread reaches monitor::Time::HasTimedOut before std::shared_ptr<Time> time_data(std::make_shared<Time>()); is completed.
Spawn thread not in constructor, but in separate method which you will invoke after time_data is assigned.
Anyway it would be better if your Timer do not use time_data global variable at all.

C++ different threads have the same thread ID on FreeBSD 10

I am using a C++ logging library on a FreeBSD 10 machine and I am running into trouble closing threads when receiving a sigint.
A created a GitHub project for testing purposes (link). If you build it on FreeBSD 10, execute it and press [ctrl+c] it will terminate. You can find the build commands I use below.
$ git clone git#github.com:tijme/free-bsd-thread-bug.git
$ cd free-bsd-thread-bug && mkdir -p cmake-build-debug && cd cmake-build-debug
$ cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER="/usr/local/bin/gcc6" -DCMAKE_CXX_COMPILER="/usr/local/bin/g++6"
$ make -dA
$ ./FreeBSDThreadBug
Code I used (can also be found in the GitHub repository)
/* main.cpp */
#include "Example.h"
#include <iostream>
#include <csignal>
#include <thread>
#include <chrono>
Example* example = new Example();
void onSignal(int signum)
{
delete example;
exit(0);
}
int main() {
signal(SIGINT, onSignal);
std::this_thread::sleep_for(std::chrono::milliseconds(5000));
return 0;
}
/* Example.h */
#ifndef FREEBSDTHREADBUG_EXAMPLE_H
#define FREEBSDTHREADBUG_EXAMPLE_H
#include <thread>
#include <iostream>
#include <chrono>
class Example {
public:
Example();
~Example();
std::thread threadHandle;
void threadFunction();
};
#endif //FREEBSDTHREADBUG_EXAMPLE_H
/* Example.cpp */
#include "Example.h"
#include <thread>
#include <chrono>
Example::Example()
{
std::cout << "Main: starting thread" << std::endl;
threadHandle = std::thread(&Example::threadFunction, this);
std::cout << "Main: thread started" << std::endl;
}
Example::~Example()
{
std::cout << "THIS ID: " << std::this_thread::get_id() << std::endl;
std::cout << "THREAD ID: " << threadHandle.get_id() << std::endl;
std::cout << "Main: joining thread" << std::endl;
threadHandle.join();
std::cout << "Main: thread joined" << std::endl;
}
void Example::threadFunction() {
std::cout << "Thread: starting to sleep" << std::endl;
std::this_thread::sleep_for(std::chrono::milliseconds(2500));
std::cout << "Thread: sleep finished" << std::endl;
}
Correct output (on e.g. MacOS Sierra):
As you can see the ID's of the threads are different, as expected.
$ ./FreeBSDThreadBug
Main: starting thread
Main: thread started
Thread: starting to sleep
^C
THIS ID: 0x7fffa428a3c0
THREAD ID: 0x70000c044000
Main: joining thread
Thread: sleep finished
Main: thread joined
Wrong output (termination, on FreeBSD 10.3):
The thread ID's are the same here, which is pretty weird.
$ ./FreeBSDThreadBug
Main: starting thread
Main: thread started
Thread: starting to sleep
^C
THIS ID: 0x801c06800
THREAD ID: 0x801c06800
Main: joining thread
terminate called after throwing an instance of 'std::system_error'
what(): Resource deadlock avoided
Abort (core dumped)
Core dump
Core was generated by `FreeBSDThreadBug'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00000008012d335a in thr_kill () from /lib/libc.so.7
[Current thread is 1 (LWP 100146)]
(gdb) bt full
#0 0x00000008012d335a in thr_kill () from /lib/libc.so.7
No symbol table info available.
#1 0x00000008012d3346 in raise () from /lib/libc.so.7
No symbol table info available.
#2 0x00000008012d32c9 in abort () from /lib/libc.so.7
No symbol table info available.
#3 0x0000000800ad8afd in __gnu_cxx::__verbose_terminate_handler () at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/libsupc++/vterminate.cc:95
terminating = true
t = <optimized out>
#4 0x0000000800ad5b48 in __cxxabiv1::__terminate (handler=<optimized out>) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
No locals.
#5 0x0000000800ad5bb1 in std::terminate () at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
No locals.
#6 0x0000000800ad5dc8 in __cxxabiv1::__cxa_throw (obj=obj#entry=0x80200e0a0, tinfo=0x800dd0bc0 <typeinfo for std::system_error>, dest=0x800b073b0 <std::system_error::~system_error()>)
at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/libsupc++/eh_throw.cc:87
globals = <optimized out>
#7 0x0000000800b04cd1 in std::__throw_system_error (__i=11) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/src/c++11/functexcept.cc:130
No locals.
#8 0x0000000800b0792c in std::thread::join (this=0x801c5c058) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/src/c++11/thread.cc:139
__e = <optimized out>
#9 0x00000000004016fc in Example::~Example (this=0x801c5c058, __in_chrg=<optimized out>) at /root/FreeBSDThreadBug/Example.cpp:18
No locals.
#10 0x00000000004010b7 in onSignal (signum=2) at /root/FreeBSDThreadBug/main.cpp:11
No locals.
#11 0x000000080082fb4a in ?? () from /lib/libthr.so.3
No symbol table info available.
#12 0x000000080082f22c in ?? () from /lib/libthr.so.3
No symbol table info available.
#13 <signal handler called>
No symbol table info available.
#14 0x00000008012efb5a in _nanosleep () from /lib/libc.so.7
No symbol table info available.
#15 0x000000080082cc4c in ?? () from /lib/libthr.so.3
No symbol table info available.
#16 0x000000000040155d in std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > (__rtime=...) at /usr/local/lib/gcc6/include/c++/thread:322
__s = {__r = 2}
__ns = {__r = 500000000}
__ts = {tv_sec = 1, tv_nsec = 126917539}
#17 0x000000000040177a in Example::threadFunction (this=0x801c5c058) at /root/FreeBSDThreadBug/Example.cpp:24
No locals.
#18 0x0000000000402432 in std::__invoke_impl<void, void (Example::* const&)(), Example*>(std::__invoke_memfun_deref, void (Example::* const&)(), Example*&&) (
__f=#0x801c5e050: (void (Example::*)(Example * const)) 0x40172c <Example::threadFunction()>, __t=<unknown type in /root/FreeBSDThreadBug/cmake-build-debug/FreeBSDThreadBug, CU 0x552f, DIE 0xb2d7>)
at /usr/local/lib/gcc6/include/c++/functional:227
No locals.
#19 0x00000000004023bf in std::__invoke<void (Example::* const&)(), Example*>(void (Example::* const&)(), Example*&&) (__fn=#0x801c5e050: (void (Example::*)(Example * const)) 0x40172c <Example::threadFunction()>,
__args#0=<unknown type in /root/FreeBSDThreadBug/cmake-build-debug/FreeBSDThreadBug, CU 0x552f, DIE 0xb2d7>) at /usr/local/lib/gcc6/include/c++/functional:251
No locals.
#20 0x0000000000402370 in std::_Mem_fn_base<void (Example::*)(), true>::operator()<Example*>(Example*&&) const (this=0x801c5e050,
__args#0=<unknown type in /root/FreeBSDThreadBug/cmake-build-debug/FreeBSDThreadBug, CU 0x552f, DIE 0xb2d7>) at /usr/local/lib/gcc6/include/c++/functional:604
No locals.
#21 0x000000000040233b in std::_Bind_simple<std::_Mem_fn<void (Example::*)()> (Example*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0x801c5e048) at /usr/local/lib/gcc6/include/c++/functional:1391
No locals.
#22 0x0000000000402289 in std::_Bind_simple<std::_Mem_fn<void (Example::*)()> (Example*)>::operator()() (this=0x801c5e048) at /usr/local/lib/gcc6/include/c++/functional:1380
No locals.
#23 0x0000000000402268 in std::thread::_State_impl<std::_Bind_simple<std::_Mem_fn<void (Example::*)()> (Example*)> >::_M_run() (this=0x801c5e040) at /usr/local/lib/gcc6/include/c++/thread:196
No locals.
#24 0x0000000800b0769f in std::execute_native_thread_routine (__p=0x801c5e040) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/src/c++11/thread.cc:83
__t = std::unique_ptr<std::thread::_State> containing 0x801c5e040
#25 0x000000080082a855 in ?? () from /lib/libthr.so.3
No symbol table info available.
#26 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
System information
$ freebsd-version
10.3-RELEASE
$ /usr/local/bin/gcc6 --version
gcc6 (FreeBSD Ports Collection) 6.3.0
$ /usr/local/bin/g++6 --version
g++6 (FreeBSD Ports Collection) 6.3.0
$ cmake --version
cmake version 3.7.2
The original issue I created can be found on GitHub (link), however there is no fix yet.
I hope someone will be able to help me fix this issue. Thanks in advance.
That's not a bug, that's a feature.
You don't get a guarantee about where your signal is going to be delivered, and the set of things you're allowed to do in a signal handler is restricted.
See sigaction(3) for details about what you can do (and you can't do anything else). Your program is doing many things that are not allowed in a signal handler.
The correct thing to do is to signal something else in your program and return from the signal handler. An example technique for doing that is the "self pipe trick". Create a pipe and keep a handle to both ends. Read from one end in your normal I/O processing. If you get a signal, in the signal handler, write a byte to the other end of the pipe and return. When the byte is read from the pipe you know the signal has arrived and you can do extended processing safely.
Update:
As Michael Burr has pointed out, you can block particular threads from receiving particular signals using pthread_sigmask(3). However, to fix the underlying problem here you still need to not do the work in the signal handler.

std::exception occur on global thread object when calling exit in signal handler

I got the following error when pressing ctrl+c
^Cctrl-c
terminate called without an active exception
Aborted (core dumped)
And here's gdb stackstrace:
(gdb) bt
#0 0x0000003a47432625 in raise () from /lib64/libc.so.6
#1 0x0000003a47433e05 in abort () from /lib64/libc.so.6
#2 0x0000003a4a46007d in __gnu_cxx::__verbose_terminate_handler () at ../../.././libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x0000003a4a45e0e6 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../.././libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x0000003a4a45e131 in std::terminate () at ../../.././libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x000000000040172f in std::thread::~thread() ()
#6 0x00000000004036ad in void std::_Destroy<std::thread>(std::thread*) ()
#7 0x0000000000403396 in void std::_Destroy_aux<false>::__destroy<std::thread*>(std::thread*, std::thread*) ()
#8 0x000000000040311c in void std::_Destroy<std::thread*>(std::thread*, std::thread*) ()
#9 0x0000000000402dd6 in void std::_Destroy<std::thread*, std::thread>(std::thread*, std::thread*, std::allocator<std::thread>&) ()
#10 0x000000000040415b in std::vector<std::thread, std::allocator<std::thread> >::~vector() ()
#11 0x0000003a47435b22 in exit () from /lib64/libc.so.6
#12 0x000000000040142b in f(int) ()
#13 <signal handler called>
#14 0x0000003a478082fb in pthread_join () from /lib64/libpthread.so.0
#15 0x0000003a4a4bb627 in __gthread_join (__value_ptr=0x0, __threadid=<optimized out>)
at /root/tmp/gcc-4.9.3/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:668
#16 std::thread::join (this=<optimized out>) at ../../../.././libstdc++-v3/src/c++11/thread.cc:107
#17 0x0000000000401540 in t2() ()
#18 0x0000000000401585 in main ()
And here's code:
vector<thread*> v1;
vector<thread> v2;
void task1(std::string msg){
while (1) {
cout << "task1 says: " << msg << endl;
sleep(2);
}
}
void ctrl_c(int s)
{
cout << "ctrl-c\n";
exit(0);
}
void func1()
{
for (int i=0; i<3; i++) {
v1.push_back(new thread(task1, "v1"));
}
for (int i=0; i<3; i++) {
v1[i]->join();
}
}
void func2()
{
#ifndef GLOBAL
vector<thread> v2;
#endif
for (int i=0; i<3; i++) {
v2.push_back(thread(task1, "bad global v2"));
}
for (int i=0; i<3; i++) {
v2[i].join();
}
}
int main() {
signal(SIGINT,ctrl_c);
//func1();
//func2();
return 0;
}
Notice that v1 is global vector,which contains thread pointer; v2 is global vector,which contains thread object
When I only run func1, program is ok;
When I only run func2, things will be different depending on whether the GLOBAL option is given on the command line. When given, program ok, when not given, above exception will occur. Furthermore, if I comment out signal(SIGINT,ctrl_c), ctrl+c will not cause exception.(So I guess exit call causes global vector object destruction, right ?)
So my question is: what the differences among these conditions ? In the func2 condition, if I want to capture SIGINT and call exit in its signal handler, at the same time I want to use global vector<thread>, how shoud I avoid the exception when pressing ctrl+c ?
Thanks
Look at items 12-14 in your backtrace. You are inside pthread_join() (#12) when the signal is received (#13) and context switches to your signal handler (#14). You then call exit(0) from the signal handler context but the outer context is still in pthread_join().
Suppose, for example, that pthread_join() has taken a lock on the thread object and the call to thread::~thread() attempts to take a lock on the same thread object. thread::~thread() is waiting in the signal handler context to take a lock that's being held in the outer context ... and the outer context cannot possibly release the lock until execution returns from the signal handler... and you have a resource deadlock.
That isn't what's happening here (the exact problem is as your first commenter says; terminate() is called on a thread which hasn't been first detached or joined). However, it's a very common scenario and tells the story of why you simply need to be careful when you mix signal handling and threads.
Begin with the assumption that you shouldn't do anything from within a signal handler and then make deliberate choices from there. Look in the man page for signal (man 7 signal) and you'll find a list of safe functions that can be called in a signal handler. You'll notice that _exit() is listed but exit() is not. I'll leave it to you to read the man pages to determine the major differences between _exit() and exit() (an obvious difference is very relevant here).
So, instead of explaining further the various reasons why your bad code misbehaves ... I'm just going to recommend a more appropriate use of your signal handler.
Generally, I recommend you only ever use a signal handler to set the value of a global flag variable. Outside of the signal handler context, you can check the value of the flag variable periodically to determine if a signal has been received. You can then act on the signal in the outer context and not in the signal handler context.
For example (only a code snippet, insert into your code reasonably):
static volatile int sigterm_caught = 0;
void task1(std::string msg){
while (sigterm_caught == 0) {
cout << "task1 says: " << msg << endl;
sleep(2);
}
}
void ctrl_c(int s)
{
if(s == SIGTERM)
sigterm_caught = 1;
}
Also note that sleep(2) will return prematurely after a signal has been received. So once your signal handler has set sigterm_caught = 1 and returned, the while(!sigterm_caught) condition will be immediately evaluated in all your threads and your code will soon exit normally by return 0 in main().

After SDL_Quit(), return interrupt csignal control back to Qt

I'm working on a program that only needs to use SDL to get screen resolutions when needed. I'd like to start the SDL init, get what I need, then close it. But I'm having trouble because when I start the SDL is takes over the single interrupt handle, I can't even set it to SIG_IGN...
I have a main method that creates a QApplication and a mainWidget.
While running, a function in the mainWidget starts an SDL instance using the following code:
bool MainWidget::getSomeSdlInformation()
{
SDL_SetHint(SDL_HINT_RENDER_DRIVER, "software");
SDL_SetMainReady();
SDL_Init(0);
if (SDL_Init(SDL_INIT_VIDEO) != 0)
{
qDebug() << "SDL_Init failed: " << QString::fromUtf8(SDL_GetError());
SDL_Quit();
return false;
}
signal(SIGINT, SIG_DFL);
// Get the needed video information
// Quit SDL
SDL_Quit();
return true;
}
After I "Quit SDL" I'd like to return the csignal interrupt back to QT, such that when a user presses control-c the program closes gracefully.
I'm having some trouble figuring our how to return control of the handle back to QT.
Here is an a crash log from preforming the control-c operation on my existing implementation:
Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x7fffffffd2f0) at ../nptl/pthread_mutex_lock.c:66
66 ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0 __GI___pthread_mutex_lock (mutex=0x7fffffffd2f0) at ../nptl/pthread_mutex_lock.c:66
#1 0x00007ffff48070da in XrmQGetResource () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff47e4a42 in XGetDefault () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff43ab0d0 in _XcursorGetDisplayInfo () from /usr/lib/x86_64-linux-gnu/libXcursor.so.1
#4 0x00007ffff43ab1a9 in XcursorGetDefaultSize () from /usr/lib/x86_64-linux-gnu/libXcursor.so.1
#5 0x00007ffff43ad435 in XcursorLibraryLoadCursor () from /usr/lib/x86_64-linux-gnu/libXcursor.so.1
#6 0x00007ffff706ed5c in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7 0x00007ffff706f485 in QCursor::handle() const () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8 0x00007ffff707b364 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9 0x00007ffff7080398 in QWidgetPrivate::create_sys(unsigned long, bool, bool) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x00007ffff703231d in QWidget::create(unsigned long, bool, bool) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#11 0x00007ffff703a86a in QWidget::setVisible(bool) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x0000000000421270 in show (this=0x7fffffffda60) at /usr/include/qt4/QtGui/qwidget.h:497
#13 main (argc=1, argv=) at /home/jeff/Dev/openmw/apps/launcher/main.cpp:55

gdb outputs std error

gdb is giving me the following
Program received signal SIGABRT, Aborted.
0x000001efa0f31eea in kill () at <stdin>:2
2 <stdin>: No such file or directory.
in <stdin>
(gdb) where
#0 0x000001efa0f31eea in kill () at <stdin>:2
#1 0x000001efa0f986ca in abort () at /usr/src/lib/libc/stdlib/abort.c:70
#2 0x000001efa8473e71 in __gnu_cxx::__verbose_terminate_handler () at /usr/obj/gcc-4.7.2/gcc-4.7.2/libstdc++-v3/libsupc++/vterminate.cc:50
#3 0x000001efa8471ba8 in __cxxabiv1::__terminate (handler=Unhandled dwarf expression opcode 0xf3
) at /usr/obj/gcc-4.7.2/gcc-4.7.2/libstdc++-v3/libsupc++/eh_terminate.cc:40
#4 0x000001efa8471bf3 in std::terminate () at /usr/obj/gcc-4.7.2/gcc-4.7.2/libstdc++-v3/libsupc++/eh_terminate.cc:50
Die: DW_TAG_unspecified_type (abbrev = 23, offset = 133635)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Dwarf Error: Cannot find type of die [in module /usr/local/lib/libestdc++.so.15.0]
I am working on openbsd 5.3 has anyone come across this issue?
#include <iostream>
int main (void) {
try {
throw 10;
}catch (...) {
std::cout<<"thrown"<<std::endl;
}
return 0;
}
This is enough to cause the problem