From the back trace of gdb am getting the below stack trace.
What might be the reason .
Is it that new failed to allocate memory or something else.
#0 0x00c69eff in raise () from /lib/tls/libc.so.6
#1 0x00c6b705 in abort () from /lib/tls/libc.so.6
#2 0x005564f7 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
#3 0x00556544 in std::terminate () from /usr/lib/libstdc++.so.5
#4 0x005566b6 in __cxa_throw () from /usr/lib/libstdc++.so.5
#5 0x005568d2 in operator new () from /usr/lib/libstdc++.so.5
#6 0x005569bf in operator new[] () from /usr/lib/libstdc++.so.5
Related
I'm trying to "see" the call to std::terminate() when throwing from a destructor with the following code:
#include <stdexcept>
struct boom {
~boom() {
throw std::logic_error("something went wrong");
}
};
int main() {
boom();
}
compiled with g++ and run the code:
# ./a.out
terminate called after throwing an instance of 'std::logic_error'
what(): something went wrong
Aborted (core dumped)
so far so good, seems to work as expected (call terminate()). But when trying to break on terminate in gdb, the function does not get hit and the backtrace shows only abort:
(gdb) b std::terminate
Breakpoint 2 at 0x7f60a3772240 (2 locations)
(gdb) r
Starting program: a.out
terminate called after throwing an instance of 'std::logic_error'
what(): something went wrong
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f2c241eb921 in __GI_abort () at abort.c:79
#2 0x00007f2c24628957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007f2c2462eae6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007f2c2462db49 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f2c2462e4b8 in __gxx_personality_v0 () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2c23c05573 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#7 0x00007f2c23c05ad1 in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#8 0x00007f2c2462ed47 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x0000558cee09593a in boom::~boom() ()
#10 0x0000558cee0958dd in main ()
(gdb)
This behavior is puzzling me somehow, is there something I am missing?
EDIT:
same test using clang++ and the std::terminate breakpoint is hit:
Breakpoint 1, 0x0000000000400750 in std::terminate()#plt ()
(gdb) bt
#0 0x0000000000400750 in std::terminate()#plt ()
#1 0x00000000004009bf in __clang_call_terminate ()
#2 0x000000000187eef0 in ?? ()
#3 0x00000000004009a4 in boom::~boom() ()
#4 0x00000000004008f1 in main ()
(gdb)
You are running into the as-if rule.
C++ compilers are allowed to essentially rewrite your entire program as they see fit as long as the side effects remain the same.
What a side effect is very well defined, and "a certain function gets called" is not part of that. So the compiler is perfectly allowed to just call abort() directly if it can determine that this is the only side effect std::terminate() would have on the program.
You can get more details at https://en.cppreference.com/w/cpp/language/as_if
I was compiling some teplated CUDA code today, when suddenly, I get:
nvcc foo.cu -dc -o foo.o -m64 --std c++11 -gencode arch=compute_30,code=compute_30 -I/usr/local/cuda/include -I/path/to/includes
Segmentation fault (core dumped)
This is with CUDA 7.5 and GCC 4.9.3 on Debian Stretch. Boost and CUB are not actually used by the code triggering the segfault.
running gdb, I get:
...
Reading symbols from /usr/local/cuda/bin/cudafe++...(no debugging symbols found)...done.
[New LWP 26725]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cudafe++ --allow_managed --m64 --gnu_version=40903 --c++11 --parse_templates --'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000458b48 in ?? ()
(gdb) bt
#0 0x0000000000458b48 in ?? ()
#1 0x0000000000447989 in ?? ()
#2 0x0000000000449a77 in ?? ()
#3 0x0000000000444d6b in ?? ()
#4 0x00000000004467f1 in ?? ()
#5 0x0000000000446bd5 in ?? ()
#6 0x00000000004536e7 in ?? ()
#7 0x0000000000446c95 in ?? ()
#8 0x00000000004536e7 in ?? ()
#9 0x0000000000446c95 in ?? ()
#10 0x0000000000448403 in ?? ()
#11 0x000000000040b042 in ?? ()
#12 0x00007f3637c17610 in __libc_start_main (main=0x40af50, argc=14, argv=0x7ffd24a32058, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd24a32048) at libc-start.c:291
#13 0x0000000000401769 in ?? ()
#14 0x00007ffd24a32048 in ?? ()
#15 0x000000000000001c in ?? ()
#16 0x000000000000000e in ?? ()
#17 0x00007ffd24a33e7b in ?? ()
#18 0x00007ffd24a33e84 in ?? ()
#19 0x00007ffd24a33e94 in ?? ()
#20 0x00007ffd24a33e9a in ?? ()
#21 0x00007ffd24a33eae in ?? ()
#22 0x00007ffd24a33eb6 in ?? ()
#23 0x00007ffd24a33ec8 in ?? ()
#24 0x00007ffd24a33ed3 in ?? ()
#25 0x00007ffd24a33ee5 in ?? ()
#26 0x00007ffd24a33f16 in ?? ()
#27 0x00007ffd24a33f27 in ?? ()
#28 0x00007ffd24a33f56 in ?? ()
#29 0x00007ffd24a33f6c in ?? ()
#30 0x00007ffd24a33f9b in ?? ()
#31 0x0000000000000000 in ?? ()
So that's not very useful. What can I try doing to avoid this segfault? Or to figure out why it happens?
Edit: I just noticed this similar question - but it doesn't have an answer yet.
It seems like the reason for the crash is failure to prevent an inappropriate use of the using keyword. Here's a non-MCVE (which I might make into an MCVE later):
enum class foo : bool { foolish = false, snafu = true };
template <typename T> class bar {
public:
using foo::foolish;
using foo::snafu;
}
This is incorrect C++, and should make the compiler give out an error, but for some reason, and possibly due to combination with more code not in this snippet, that didn't happen. Instead, cudafe++ is tricked into accepting that, gets confused and crashes.
As #talonmies suggested, will try to make a proper bug report to nVIDIA. ...
Edit: It's proving difficult to reproduce now :-(
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
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?
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.