Using shared_ptr and glutInit causes segmentation fault - c++

Having asked this before I tried out a lot of things and found out that the problem has to do with glutInit. Take the following code examples:
main.cpp
#include <iostream>
#include <memory>
#include<GL/glut.h>
using namespace std;
int main(int argcp, char **argv)
{
shared_ptr<double> abc;
glutInit(&argcp,argv);
cout<<"Hello!"<<endl;
return 0;
}
compiled with:
g++ -std=c++11 -g -Wall -o appx main.cpp -lGL -lGLU -lglut
cause the executable to instantly crash (no "Hello!" output) with segfault using g++ 5.2.1, ubuntu 15.10
Just commenting out the line
shared_ptr<double> abc;
will fix the crash.
Since i want to use shared_ptr and glut in a project I would like to know how this can be fixed or what causes the crash.
Edit 1:
GDB trace:
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff33fb6fd in init () at dlerror.c:177
#2 _dlerror_run (operate=operate#entry=0x7ffff33fb0e0 <dlsym_doit>,args=args#entry=0x7fffffffde00) at dlerror.c:129
#3 0x00007ffff33fb148 in __dlsym (handle=<optimized out>, name=optimized out>) at dlsym.c:70
#4 0x00007ffff6fa2e1e in ?? () from /usr/lib/nvidia-352/libGL.so.1
#5 0x00007ffff6f4db47 in ?? () from /usr/lib/nvidia-352/libGL.so.1
#6 0x00007ffff7de957d in call_init (l=0x7ffff7fc59c8,argc=argc#entry=1, argv=argv#entry=0x7fffffffdf58, env=env#entry=0x7fffffffdf68)at dl-init.c:58
#7 0x00007ffff7de96cb in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:30
#8 _dl_init (main_map=0x7ffff7ffe188, argc=1, argv=0x7fffffffdf58, env=0x7fffffffdf68) at dl-init.c:120
#9 0x00007ffff7dd9d0a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe2c8 in ?? ()
#12 0x0000000000000000 in ?? ()

As posted in the comments the problem was similar to the problem posted here.
The solution is adding:
-lpthread
to the compiler flags!
Thanks a lot!

Related

What should I do when (CUDA 7.5's) nvcc/cudafe++ crashes with a segfault?

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 :-(

SIGSEGV simple gloox client

I've been trying to use gloox 1.0.14 for the first time and I think I'm using the most minimal example there is but poorly I get a SIGSEGV. Can anyone reproduce this problem or tell me why this happens and what I'm doing wrong? It's seems to be that the JID has an impact on this but I'd expect it to throw an error instead of segv crashing and the JID seems valid to me and even if the certificate is incorrect or whatever I'd still expect it to throw instead.
#include <cstdlib>
#include "gloox/client.h"
int main() {
gloox::JID jid("segv#jabber.de");
gloox::Client client(jid, "password");
client.connect();
return EXIT_SUCCESS;
}
Sanitizer told me:
ASAN:SIGSEGV
=================================================================
==27028==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f6357f79acd bp 0x7ffcca7c1a50 sp 0x7ffcca7c17d0 T0)
#0 0x7f6357f79acc (/lib64/libgnutls.so.30+0x99acc)
#1 0x7f6357f7b49a (/lib64/libgnutls.so.30+0x9b49a)
#2 0x7f6357f7bb18 in gnutls_x509_crt_verify (/lib64/libgnutls.so.30+0x9bb18)
#3 0x7f635a4ad54b in gloox::GnuTLSClient::verifyAgainstCAs(gnutls_x509_crt_int*, gnutls_x509_crt_int**, int) (/lib64/libgloox.so.13+0xbd54b)
#4 0x7f635a4ad6bf in gloox::GnuTLSClient::getCertInfo() (/lib64/libgloox.so.13+0xbd6bf)
#5 0x7f635a4afd6c in gloox::GnuTLSBase::handshake() (/lib64/libgloox.so.13+0xbfd6c)
#6 0x7f635a4afbc0 in gloox::GnuTLSBase::decrypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/lib64/libgloox.so.13+0xbfbc0)
#7 0x7f635a4490bb in gloox::ConnectionTCPClient::recv(int) (/lib64/libgloox.so.13+0x590bb)
#8 0x7f635a4c297d in gloox::ConnectionTCPBase::receive() (/lib64/libgloox.so.13+0xd297d)
#9 0x7f635a4541d7 in gloox::ClientBase::connect(bool) (/lib64/libgloox.so.13+0x641d7)
#10 0x4014d7 in main test.cc:8
#11 0x7f6358aa357f in __libc_start_main (/lib64/libc.so.6+0x2057f)
#12 0x401198 in _start (test+0x401198)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==27028==ABORTING
I compiled via:
c++ -fsanitize=address -fsanitize=undefined -ggdb -std=c++14 -Wall -Wextra -Wpedantic -Wconversion -Wsign-conversion -lgloox main.cc
This looks like a bug in recent version of gloox. Running the code under gdb or valgrind (without sanitizer) shows nice backtrace.
Full backtrace from valgrind points to the place of problem:
==29533== at 0x62B558D: verify_crt (verify.c:602)
==29533== by 0x62B6F57: _gnutls_verify_crt_status (verify.c:936)
==29533== by 0x62B75CC: gnutls_x509_crt_verify (verify.c:1329)
==29533== by 0x4EF254B: gloox::GnuTLSClient::verifyAgainstCAs(gnutls_x509_crt_int*, gnutls_x509_crt_int**, int) (tlsgnutlsclient.cpp:227)
==29533== by 0x4EF26BF: gloox::GnuTLSClient::getCertInfo() (tlsgnutlsclient.cpp:157)
==29533== by 0x4EF4D6C: gloox::GnuTLSBase::handshake() (tlsgnutlsbase.cpp:138)
==29533== by 0x4EF4BC0: gloox::GnuTLSBase::decrypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (tlsgnutlsbase.cpp:70)
==29533== by 0x4E8E0BB: gloox::ConnectionTCPClient::recv(int) (connectiontcpclient.cpp:169)
==29533== by 0x4F0797D: gloox::ConnectionTCPBase::receive() (connectiontcpbase.cpp:115)
==29533== by 0x4E991D7: gloox::ClientBase::connect(bool) (clientbase.cpp:212)
==29533== by 0x400DAC: main (main.cc:9)
Backtrace from gdb shows:
#0 verify_crt (cert=0xbebebebebebebebe, trusted_cas=trusted_cas#entry=0x0, tcas_size=tcas_size#entry=0, flags=flags#entry=0, output=output#entry=0x7fffffffce90, _issuer=_issuer#entry=0x7fffffffce98,
now=1455405710, max_path=0x7fffffffce94, end_cert=true, nc=0x602000007a50, func=0x0) at verify.c:602
#1 0x00007ffff46bcf58 in _gnutls_verify_crt_status (certificate_list=certificate_list#entry=0x7fffffffcf08, clist_size=clist_size#entry=1, trusted_cas=trusted_cas#entry=0x0, tcas_size=tcas_size#entry=0,
flags=flags#entry=0, purpose=purpose#entry=0x0, func=0x0) at verify.c:936
#2 0x00007ffff46bd5cd in gnutls_x509_crt_verify (cert=cert#entry=0xbebebebebebebebe, CA_list=CA_list#entry=0x0, CA_list_length=CA_list_length#entry=0, flags=flags#entry=0, verify=verify#entry=0x7fffffffcf24)
at verify.c:1329
#3 0x00007ffff6bee54c in gloox::GnuTLSClient::verifyAgainstCAs (this=this#entry=0x61400000fc40, cert=0xbebebebebebebebe, CAList=CAList#entry=0x0, CAListSize=CAListSize#entry=0) at tlsgnutlsclient.cpp:227
#4 0x00007ffff6bee6c0 in gloox::GnuTLSClient::getCertInfo (this=0x61400000fc40) at tlsgnutlsclient.cpp:157
#5 0x00007ffff6bf0d6d in gloox::GnuTLSBase::handshake (this=0x61400000fc40) at tlsgnutlsbase.cpp:138
#6 0x00007ffff6bf0bc1 in gloox::GnuTLSBase::decrypt (this=0x61400000fc40,
data="\024\003\003\000\001\001\026\003\003\000(\373\336\267\221q\256\266\344\363\022\367 C\022\233\351\251\065\036\355\070\362\217\264\370\003\206+\"\201r^\355\067I\203Y\213\350\301")
at tlsgnutlsbase.cpp:70
#7 0x00007ffff6b8a0bc in gloox::ConnectionTCPClient::recv (this=<optimized out>, timeout=<optimized out>) at connectiontcpclient.cpp:169
#8 0x00007ffff6c0397e in gloox::ConnectionTCPBase::receive (this=0x60c00000bec0) at connectiontcpbase.cpp:115
#9 0x00007ffff6b951d8 in gloox::ClientBase::connect (this=0x7fffffffd410, block=<optimized out>) at clientbase.cpp:212
#10 0x00000000004013a8 in main () at main.cc:9
cert=0xbebebebebebebebe pointer is the point of failure. It is brought to that place from frame 4 in tlsgnutlsclient.cpp:157, where is such fanny construct:
157 m_certInfo.chain = verifyAgainstCAs( cert[certListSize], 0 /*CAList*/, 0 /*CAListSize*/ );
cert[certListSize] is clearly pointing away from the existing array. I tried to trace the bug in sources, but I am not so skilled with the svn commandline tools so I am leaving this on the reported to fill upstream bug (ok, I can do that, but let me know if there is anything I can do for you).

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?

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.

GCC 4.5, boost and throw_error_already_set

Using Python 2.2.3, Boost 1.46 and this trivial extension module:
#include <Python.h>
#include <boost/python.hpp>
using namespace boost::python ;
using namespace boost;
class PyTest
{
public:
PyTest();
};
PyTest::PyTest()
{
PyErr_SetString(PyExc_RuntimeError, "FOO");
throw_error_already_set();
}
BOOST_PYTHON_MODULE(testmod)
{
class_<PyTest>("Test", init<>())
;
}
If I build Boost, then this module, using GCC 3.4.5 (Mingw on XP SP3), everything works well:
>>> import testmod
>>> testmod.Test()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: FOO
Not changing anything but the compiler (GCC 4.5.2) gives this:
>>> import testmod
>>> testmod.Test()
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
So I launch gdb and put a break on abort. Seems to me like the error_already_set exception isn't catched by anybody:
(gdb) bt
#0 0x77c36bb3 in msvcrt!abort () from C:\WINDOWS\system32\msvcrt.dll
#1 0x69acfdb2 in testmod!_Unwind_SetGR () from C:\Python22\DLLs\testmod.pyd
#2 0x69b2a45d in testmod!_ZNK5boost6python7objects23caller_py_function_implINS0
_6detail6callerIPFvP7_objectENS0_21default_call_policiesENS_3mpl7vector2IvS6_EEE
EE9signatureEv () from C:\Python22\DLLs\testmod.pyd
#3 0x6e9544a3 in libgcc_s_dw2-1!__trunctfxf2 ()
from C:\WINDOWS\system32\libgcc_s_dw2-1.dll
#4 0x6e954877 in libgcc_s_dw2-1!_Unwind_RaiseException ()
from C:\WINDOWS\system32\libgcc_s_dw2-1.dll
#5 0x6fcbc6e2 in libstdc++-6!__cxa_throw ()
from C:\WINDOWS\system32\libstdc++-6.dll
#6 0x63455d4c in boost::python::throw_error_already_set() ()
from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#7 0x69ac12de in testmod!_ZN6PyTestC2Ev () from C:\Python22\DLLs\testmod.pyd
#8 0x69adbbf1 in testmod!_ZN5boost6python7objects11make_holderILi0EE5applyINS1_
12value_holderI6PyTestEENS_3mpl7vector0IN4mpl_2naEEEE7executeEP7_object ()
from C:\Python22\DLLs\testmod.pyd
#9 0x69adbde9 in testmod!_ZN5boost6python7objects23caller_py_function_implINS0_
6detail6callerIPFvP7_objectENS0_21default_call_policiesENS_3mpl7vector2IvS6_EEEE
EclES6_S6_ () from C:\Python22\DLLs\testmod.pyd
#10 0x63450031 in boost::python::objects::function::call(_object*, _object*) con
st () from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#11 0x634501fb in boost::detail::function::void_function_ref_invoker0<boost::pyt
hon::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::f
unction::function_buffer&) ()
from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#12 0x63455e5a in boost::python::handle_exception_impl(boost::function0<void>)
() from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#13 0x634512be in function_call ()
from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#14 0x1e006ccc in python22!PyObject_Call ()
from C:\WINDOWS\system32\python22.dll
#15 0x0089d138 in ?? ()
#16 0x63469420 in boost::python::docstring_options::show_py_signatures_ ()
from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#17 0x0084d0f0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The funny thing is that in my actual use case, the class has several methods wrapped; for some of them the error_already_set mechanism works; for some others it doesn't... Does a C++ guru have any hint about this ?