I have had to switch from C++11 to C++14 in my project to use the Catch testing framework, written for C++14 (it doesn't compile with anything less). Everything compiles fine. However, while running the program, the following function causes a series of errors which seem linked to a mismatch between C++11 and C++14 shared standard library files:
//it is called as such:
string p = "...";
handle_file(p);
//...
int handle_file (string p) {
if (is_valid(p)) {
return 0;
}
else return -1;
}
The error trace in gdb reads:
Program received signal SIGABRT, Aborted.
0x00007ffff7299ef5 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7299ef5 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff7283862 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff72dbf38 in __libc_message () from /usr/lib/libc.so.6
#3 0x00007ffff72e3bea in malloc_printerr () from /usr/lib/libc.so.6
#4 0x00007ffff72e5113 in _int_free () from /usr/lib/libc.so.6
#5 0x00007ffff72e8ca8 in free () from /usr/lib/libc.so.6
#6 0x00007ffff76b76ea in operator delete (ptr=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/del_op.cc:49
#7 0x00007ffff76b76fa in operator delete (ptr=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/del_ops.cc:33
#8 0x000055555556c893 in __gnu_cxx::new_allocator<char>::deallocate (__t=<optimized out>, __p=<optimized out>, this=0x7fffffffd910)
at /usr/include/c++/10.2.0/ext/new_allocator.h:133
#9 std::allocator_traits<std::allocator<char> >::deallocate (__n=<optimized out>, __p=<optimized out>, __a=...)
at /usr/include/c++/10.2.0/bits/alloc_traits.h:492
#10 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy (__size=<optimized out>, this=0x7fffffffd910)
at /usr/include/c++/10.2.0/bits/basic_string.h:237
#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose (this=0x7fffffffd910)
at /usr/include/c++/10.2.0/bits/basic_string.h:232
#12 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x7fffffffd910, __in_chrg=<optimized out>)
at /usr/include/c++/10.2.0/bits/basic_string.h:658
#13 Manager::handle_file (p ="./data/20pix", this=0x5555556c6d20)
at src/manager.hpp:149
Does anyone know how to solve this?
The error is inside malloc, after it has printed some error message (usually double-free or something similar) indicating heap corruption.
While it is possible that you have some kind of library mismatch, it is much more likely that you have a plain heap corruption bug in your own code (overflowing heap buffer, double delete, delete of non-allocated, etc. etc.), and that bug is simply getting exposed now, while it remained hidden before.
Your first step should be to run the program under Valgrind or with Address Sanitizer, and fix any errors these tools report.
Related
I want to run unit test with google test, but got Segmentation fault. I have just define a global const string, and RUN_ALL_TESTS, why?
the gdb result is :
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[==========] Running 0 tests from 0 test cases.
[==========] 0 tests from 0 test cases ran. (1 ms total)
[ PASSED ] 0 tests.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6fe415c in __GI___libc_free (mem=0x603588) at malloc.c:2947
2947 malloc.c: No such file or directory.
And flowing is the backtrace:
(gdb) bt
#0 0x00007ffff6fe415c in __GI___libc_free (mem=0x603588) at malloc.c:2947
#1 0x00007ffff75fa36f in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00007ffff7bb25ba in void std::_Destroy<std::string>(std::string*) () from /home/caros/src/secsdk/datasecurity-upgrade/external/libgtest.so
#3 0x00007ffff7bb04bd in void std::_Destroy_aux<false>::__destroy<std::string*>(std::string*, std::string*) () from /home/caros/src/secsdk/datasecurity-upgrade/external/libgtest.so
#4 0x00007ffff7bac65c in void std::_Destroy<std::string*>(std::string*, std::string*) () from /home/caros/src/secsdk/datasecurity-upgrade/external/libgtest.so
#5 0x00007ffff7ba68f3 in void std::_Destroy<std::string*, std::string>(std::string*, std::string*, std::allocator<std::string>&) () from /home/caros/src/secsdk/datasecurity-upgrade/external/libgtest.so
#6 0x00007ffff7ba08b2 in std::vector<std::string, std::allocator<std::string> >::~vector() () from /home/caros/src/secsdk/datasecurity-upgrade/external/libgtest.so
#7 0x00007ffff6f9d53a in __cxa_finalize (d=0x7ffff7b2b440) at cxa_finalize.c:56
#8 0x00007ffff78b7ea3 in __do_global_dtors_aux () from /home/caros/src/secsdk/datasecurity-upgrade/external/libgmock.so
#9 0x00007fffffffd5e0 in ?? ()
#10 0x00007ffff7dea7da in _dl_fini () at dl-fini.c:252
Backtrace stopped: frame did not save the PC
This is my whole source code:
#include <iostream>
#include "gtest/gtest.h"
#include "gmock/gmock.h"
const std::string fsdfsdf = "sdfsdfsd";
int main(int argc, char* argv[]) {
testing::InitGoogleMock(&argc, argv);
RUN_ALL_TESTS();
return 0;
}
I expect the programe finished without segmentation fault.
why?
There doesn't appear to be anything wrong with your code. The problem is likely in the environment.
You didn't say where libgtest.so and libgmock.so came from. Perhaps they are incompatible with your version of g++. Hard to tell.
Running your program under Valgrind may provide additional clues.
I have some weird multithreading bugs, so I wanted to use the gcc thread sanitizer to find them. However, when I compile with -sanitize=thread the resulting binary segfaults immediatly with the following stacktrace:
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff5911cee in ?? () from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#2 0x00007ffff593408d in ?? () from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#3 0x00007ffff58eeb98 in ?? () from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#4 0x00007ffff58ef0ce in __interceptor___cxa_atexit ()
from /usr/lib/x86_64-linux-gnu/libtsan.so.0
#5 0x00007ffff55d1e56 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff7de74ea in call_init (l=<optimised out>, argc=argc#entry=1,
argv=argv#entry=0x7fffffffdeb8, env=env#entry=0x7fffffffdec8)
at dl-init.c:72
#7 0x00007ffff7de75fb in call_init (env=0x7fffffffdec8, argv=0x7fffffffdeb8,
argc=1, l=<optimised out>) at dl-init.c:30
#8 _dl_init (main_map=0x7ffff7ffe168, argc=1, argv=0x7fffffffdeb8,
env=0x7fffffffdec8) at dl-init.c:120
#9 0x00007ffff7dd7cfa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe22b in ?? ()
#12 0x0000000000000000 in ?? ()
I tried adding the -static-libtsan attribute, but now I get the following error:
FATAL: ThreadSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator.h:1203 "((IsAligned(p, page_size_))) != (0)" (0x0, 0x0)
#0 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (sql+0x0000004aeb53)
#1 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (sql+0x0000004aeb5b)
#2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (sql+0x0000004b3af3)
#3 __tsan::user_free(__tsan::ThreadState*, unsigned long, void*, bool) <null> (sql+0x00000049e6fc)
#4 operator delete(void*) <null> (sql+0x00000045f6ec)
#5 __static_initialization_and_destruction_0(int, int) [clone .constprop.123] <null> (sql+0x00000044a4ab)
#6 __libc_csu_init <null> (sql+0x00000254468c)
#7 __libc_start_main <null> (libc.so.6+0x0000000207be)
#8 _start <null> (sql+0x000000459e18)
How can I fix this? What am I doing wrong here?
I haven't used TSAN w/gcc so can't help there, but you might want to give it a shot with clang (https://clang.llvm.org/). Since TSAN is part of clang, bugs tend to get fixed there first.
If you need help building clang, I've also written an article that might be useful: http://btorpey.github.io/blog/2015/01/02/building-clang/
Answer found here:
https://groups.google.com/forum/#!topic/thread-sanitizer/5cxyhIrl_SE
You don't need to give -ltsan (at least when using clang). You need to
give -fsanitize=thread both when compiling and linking.
-fsanitize=thread when linking will ensure that all proper libraries
get linked in.
This worked for me for both clang and gcc
From some time I am trying to catch a problem with my product hanging. This is the call stack I got after coredumping the process with gcore:
/lib64/libc.so.6
#1 0x00007f36fb339ba6 in _L_lock_12192 () from /lib64/libc.so.6
#2 0x00007f36fb337121 in malloc () from /lib64/libc.so.6
#3 0x00007f36fbbef0cd in operator new(unsigned long) () from /lib64/libstdc++.so.6
#4 0x00007f36fbc4d7e9 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) () from /lib64/libstdc++.so.6
#5 0x00007f36fbc4e42b in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) () from /lib64/libstdc++.so.6
#6 0x00007f36fbc4e4d4 in std::string::reserve(unsigned long) () from /lib64/libstdc++.so.6
#7 0x00007f36fbc2b3c6 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow(int) () from /lib64/libstdc++.so.6
#8 0x00007f36fbc2fb36 in std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long) () from /lib64/libstdc++.so.6
#9 0x00007f36fbc26885 in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) () from /lib64/libstdc++.so.6
#10 0x00007f36fe85c83a in ?? ()
#11 0x00007f36fb2ffdff in vfprintf () from /lib64/libc.so.6
#12 0x000000000055c110 in fgetc#plt ()
#13 0xffffffffffffffa8 in ?? ()
#14 0xffffffffffffffa8 in ?? ()
#15 0x0000000000bc42a0 in ?? ()
#16 0x000000000055b8b0 in setsockopt#plt ()
#17 0x000000000055bf30 in log4cxx::NDC::push ()
This is multithreaded code executed after forking a process in log4cxx ndc push seemingly. All the other threads sleep on condition variables and this is the only one deadlocked. What could possibly make malloc deadlock?
You shouldn't fork processes that use threading.
If one of the other threads has a lock acquired (let's say, the lock in malloc) during the fork, the lock is cloned in locked state, but the thread that locked it isn't running in the forked process. This means that the lock will never be released.
I encounter a coredump when read file content to std::string. Code is list below:
bool readContentFromFile(const char* fileName, std::string& content)
{
std::ifstream t(fileName);
if(!t) {
return false;
}
t.seekg(0, std::ios::end);
content.reserve(t.tellg());
t.seekg(0, std::ios::beg);
content.assign((std::istreambuf_iterator<char>(t)),
std::istreambuf_iterator<char>());
return true;
}
But occasionally the code cause coredump as below:
...
#4 <signal handler called>
#5 0x00007f347a0f3945 in raise () from /lib64/libc.so.6
#6 0x00007f347a0f4f21 in abort () from /lib64/libc.so.6
#7 0x00007f347a953504 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#8 0x00007f347a951946 in ?? () from /usr/lib64/libstdc++.so.6
#9 0x00007f347a951973 in std::terminate() () from /usr/lib64/libstdc++.so.6
#10 0x00007f347a951a5a in __cxa_throw () from /usr/lib64/libstdc++.so.6
#11 0x00007f347a8ef2ba in std::__throw_ios_failure(char const*) () from /usr/lib64/libstdc++.so.6
#12 0x00007f347a901317 in std::basic_filebuf<char, std::char_traits<char> >::underflow() () from /usr/lib64/libstdc++.so.6
#13 0x00000000004c2751 in char* std::string::_S_construct<std::istreambuf_iterator<char, std::char_traits<char> > >(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::allocator<char> const&, std::input_iterator_tag) ()
#14 0x00000000004c281b in std::string& std::string::_M_replace_dispatch<std::istreambuf_iterator<char, std::char_traits<char> > >(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::__false_type) ()
#15 0x00000000004bf225 in readContentFromFile(char const*, std::string&) ()
From the above code snippets, exception is throwed in underflow function. But I have no idea why throw exception. The file maybe removed when reading, but which statment in code maybe cause throwing exception?
Pretty clear from the stack trace that the exception is being thrown from content.assign. Looks like string::assign is an inline function which calls std::string::_M_replace_dispatch. You could check this by looking at the header files, or using a debugger. Does that answer the question?
What are some of the reasons dlopen could segfault besides the shared object not existing?
In my case, I know the shared object exists, but when my program goes to load it using dlopen, it segfaults. I checked in my lib folder and the shared object is there and the paths are all correct.
handle = dlopen(libraryName.c_str(), RTLD_LAZY | RTLD_GLOBAL);
gdb bt:
#0 0x00000000001b94f5 in ?? ()
#1 0x00007fffefd96db6 in __do_global_ctors_aux () from /usr/local/lib/MY_LIB2.so
#2 0x00007fffefcf82c3 in _init () from /usr/local/lib/MY_LIB2.so
#3 0x00007fffed69c6c8 in ?? () from /usr/local/lib/MY_LIB1.so
#4 0x00007ffff7de9dc4 in call_init () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7de9ef6 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7dedf43 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7de9c36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7ded7ca in _dl_open () from /lib64/ld-linux-x86-64.so.2
#9 0x00007ffff5c5af26 in dlopen_doit () from /lib64/libdl.so.2
#10 0x00007ffff7de9c36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff5c5b4cf in _dlerror_run () from /lib64/libdl.so.2
#12 0x00007ffff5c5afc1 in dlopen##GLIBC_2.2.5 () from /lib64/libdl.so.2
#13 0x00007ffff6ecef7e in mynamespace::Factory::attachModule (this=0x61d440, libraryName=...) at Factory.cpp:324
#14 0x00007ffff6ecefe6 in mynamespace::Factory::attachFunction (this=0x61d440, functionName=..., moduleName=...) at Factory.cpp:343
#15 0x00007ffff6ecdd16 in mynamespace::Factory::ReadFile (this=0x61d440, x=...) at Factory.cpp:111
#16 0x00007ffff6ecda62 in mynamespace::Factory::ReadDirectory (this=0x61d440, x=...) at Factory.cpp:79
#17 0x00007ffff6ecdc66 in mynamespace::Factory::ReadDirectory (this=0x61d440, x=0x417901 "/usr/local/lib/") at Factory.cpp:105
#18 0x0000000000410637 in main (argc=2, argv=0x7fffffffdd58) at main.cpp:78
In addition to loading a library into memory and fixing up references, the runtime linker runs initializers such as functions labelled __attribute__((constructor)), an init function (if specified with -Wl,-init,...), and constructors for global objects. Your backtrace indicates that one of those is failing.
Specifically, __do_global_ctors_aux runs constructors for global objects. Check those.