I'm debugging a daemon in gdb by attaching gdb to the daemon process, and setting gdb to follow the child when it forks. It would be very useful to somehow figure out where the function I am in currently, is located - i.e. if the function were present in the daemon binary or a shared object that were loaded. If it were a shared object, it would be useful to have its name or path.
Can this be done?
(gdb) info symbol 0x002a4995
_IO_new_file_write + 7 in section .text of /lib/i386-linux-gnu/libc.so.6
It would be very useful to somehow figure out where the function I am
in currently, is located
You can do it by comparing function address with addresses of currently loaded shared libraries.
(gdb) bt
#0 0x00130416 in __kernel_vsyscall ()
#1 0x002fc683 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
#2 0x002a4995 in _IO_new_file_write (f=0x3b4500, data=0xb7ffd000, n=4) at fileops.c:1276
#3 0x002a4874 in new_do_write (fp=0x3b4500, data=0xb7ffd000 "123\n", to_do=4) at fileops.c:530
#4 0x002a5eee in _IO_new_do_write (fp=0x3b4500, data=0xb7ffd000 "123\n", to_do=4) at fileops.c:503
#5 0x002a6235 in _IO_new_file_overflow (f=0x3b4500, ch=10) at fileops.c:889
#6 0x002a6e4b in __GI___overflow (f=0x3b4500, ch=10) at genops.c:248
#7 0x0029da6f in _IO_putc (c=10, fp=0x3b4500) at putc.c:33
#8 0x001b835b in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::overflow(int) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#9 0x001b966e in std::ostream::put(char) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#10 0x001b98e4 in std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#11 0x001b8cae in std::ostream::operator<<(std::ostream& (*)(std::ostream&)) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#12 0x08048ac5 in main () at so-test.cpp:10
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00110830 0x001275af Yes (*) /lib/ld-linux.so.2
0x00176e50 0x001e93a8 Yes (*) /usr/lib/i386-linux-gnu/libstdc++.so.6
0x0021df50 0x00234cf8 Yes (*) /lib/i386-linux-gnu/libgcc_s.so.1
0x00250be0 0x0035ebd4 Yes /lib/i386-linux-gnu/libc.so.6
0x003bb4b0 0x003d6ab8 Yes /lib/i386-linux-gnu/libm.so.6
(*): Shared library is missing debugging information.
(gdb)
For example _IO_new_file_write address is 0x002a4995, which lies between 0x00250be0 and 0x0035ebd4 where /lib/i386-linux-gnu/libc.so.6 was loaded. That is _IO_new_file_write belongs to libc.so.6 library.
Related
I am using aws sdk for linux to transfer file to s3. I have compiled the shared library of aws sdk.
Transfer of file fails with bad alloc error so thought to explore the example given by aws-sdk.
I am trying to run the example to list the bucket on s3 link.
Compiling the application using command:
g++ testingAws.cpp -I . -L . -laws-cpp-sdk-transfer -laws-cpp-sdk-core -laws-cpp-sdk-s3
Everytime the executables terminates with message:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Bad alloc happens when it invokes the function:
AwsDoc::S3::PutObject(bucket_name, object_name, clientConfig);
Any suggestion if I am missing something. As well how to debug bad alloc issue.
I tried to list the bucket on my s3 server.
Backtrace:
Backtrace: terminate called after throwing an instance of 'std::bad_alloc' what():
std::bad_alloc Thread 1 "a.out" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737314626112) at ./nptl/pthread_kill.c:44 44
./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737314626112) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140737314626112) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140737314626112, signo=signo#entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff6b2d476 in __GI_raise (sig=sig#entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff6b137f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff6dd5bbe in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff6de124c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007ffff6de12b7 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007ffff6de1518 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x00007ffff6dd57cc in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007ffff6e7ee6f in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007ffff6e7f22d in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator=(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x000055555555b58d in Aws::S3::Model::PutObjectRequest::SetBucket(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#13 0x000055555555a78b in AwsDoc::S3::PutObject(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Aws::Client::ClientConfiguration const&) ()
#14 0x0000000000000000 in ?? ()
(gdb
It's been resolved. I was using header files that were from windows. There was no compilation error so thought everything should work as expectation but later I have taken header files from the Linux machine and that has resolved it.
I'm having a hard time debugging this issue: https://github.com/cnjinhao/nana/issues/445
I have previously asked about LTO vs static object initialization and edited the library's code to implement Meyer's singletons so that the correct order of initialization happens. Hello worlds still crash, although library's functions have mostly dissappeared from stack traces:
#include <nana/paint/graphics.hpp>
int main()
{
nana::paint::font f;
}
Thread 1 received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00000000004985cf in std::type_info::operator==(std::type_info const&) const ()
#1 0x0000000000455180 in __cxxabiv1::__vmi_class_type_info::__do_dyncast(long long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const ()
#2 0x00000000004eae07 in __dynamic_cast ()
#3 0x00000000004e6625 in bool std::has_facet<std::ctype<char> >(std::locale const&) ()
#4 0x00000000004e1f74 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&) ()
#5 0x00000000004e20c0 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) ()
#6 0x00000000004dfe2b in std::ios_base::Init::Init() ()
#7 0x0000000000431f2f in __static_initialization_and_destruction_0(int, int) [clone .lto_priv.4] ()
#8 0x0000000000431f59 in _GLOBAL__sub_I__ZN4nana6detail18drawable_impl_typeC2Ev ()
#9 0x00000000004398c9 in global constructors keyed to 65535_0_objects.a_0x8e.19316 ()
#10 0x00000000004432b3 in __do_global_ctors ()
at E:/GitHub/MINGW-packages/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/gccmain.c:67
#11 0x00000000004432fb in __main ()
at E:/GitHub/MINGW-packages/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/gccmain.c:83
#12 0x000000000040131c in __tmainCRTStartup ()
at E:/GitHub/MINGW-packages/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:329
#13 0x00000000004014c9 in mainCRTStartup ()
at E:/GitHub/MINGW-packages/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:223
Compiling with -O0 -g -fno-omit-frame-pointer -fno-inline -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fasynchronous-unwind-tables -fstack-clash-protection have resulted in somewhat longer stack traces, but still nothing to search for.
Even if I stuff the library with unbuffered debug prints nothing appears on the screen - the programs seems to crash before even first global object is constructed. I have used strace (from Git Bash) and verified that the executable loads all correct shared libraries.
I'm looking for anything that could help me debug the issue. Unfortunately this is a Windows-only crash so running this with uftrace or sanitizers is not possible. Using GCC 8.3.1.
The cause of the crash was that the nana library had -static-libgcc -static-libstdc++ in its CMake files as public dependency. The executable and all other libraries had them linked dynamically. Suprisingly, there were no symbol clashes but the standard library code in the executable was corrupted.
Solved by removing these flags from nana's CMake files.
So, I'm running a CPU scheduling smulation code but I came across a few errors while compiling
Undefined first referenced
symbol in file
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /var/tmp//ccz0ct2G.o
std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&)) /var/tmp//ccz0ct2G.o
std::cout /var/tmp//ccz0ct2G.o
std::basic_ofstream<char, std::char_traits<char> >::close() /var/tmp//ccz0ct2G.o
std::ios_base::Init::~Init() /var/tmp//ccz0ct2G.o
std::ios_base::Init::Init() /var/tmp//ccz0ct2G.o
std::basic_ios<char, std::char_traits<char> >::operator!() const /var/tmp//ccz0ct2G.o
__gxx_personality_v0 /var/tmp//ccz0ct2G.o
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) /var/tmp//ccz0ct2G.o
std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(char const*, std::_Ios_Openmode) /var/tmp//ccz0ct2G.o
std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&) /var/tmp//ccz0ct2G.o
ld: fatal: Symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status
I don't understand why I'm getting these errors and what is /var/tmp//ccz0ct2G.o?
Almost all the errors have it.
I don't understand why I'm getting these errors
Your program tries to use something that's part of an external library or a different object file, but you're not passing that to the linker as well.
and what is /var/tmp//ccz0ct2G.o?
A temporary object file, that contains intermediate data that's going to be used in later stages of the compilation process.
Let me guess: You tried to compile with a command that went something like
g++ somesource.cc
You see, compilation consists of several stages:
1. compiling the individual source files (`*.c`, `*.cc` and so on) into *object files* (`*.o`).
2. linking the produced object files together into the actual program or library
When you call the compiler like you did, this is a shorthand that does both operations from a single call. But for the sake of simplicity and also because object files can grow rather large and it can pose a problem to keep them all in memory, the result of compiling the source file is placed into a temporary object file. That's what you have there.
Why does STL code seem to be statically linked into the Boost dynamic libraries on Darwin?
When I build Boost 1.42/1.46.1/1.49 on OS X with gcc 4.6.1 and toolset=darwin, I find that the resulting libraries statically include a lot of STL code, such as std::basic_string<char> and std::basic_string<wchar_t>.
Building on OS X 10.6.8, I get the following results:
% otool -L /usr/local/boost-1.46.1/lib/libboost_system.dylib
boost-1.46.1/lib/libboost_system.dylib:
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Based on the 'otool -L' output, it's clear that libstdc++ is not dynamically linked with the library. By comparison, on Ubuntu 12.04 LTS, libboost_system.so 1.46.1 shows the following linking:
% ldd /usr/local/lib/libboost_system.so
linux-vdso.so.1 => (0x00007fff495ff000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fec4edb4000)
libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007fec4ea82000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec4e788000)
libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007fec4e573000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec4e355000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec4df98000)
/lib64/ld-linux-x86-64.so.2 (0x00007fec4f1e4000)
In this case libstdc++ has clearly been dynamically linked. On the OS X side, this is how I know that STL code has been included directly in the Boost library:
% nm -gfj /usr/local/boost-1.46.1/lib/libboost_system.dylib | c++filt --format=gnu-v3 | egrep "^std::basic_string"
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_disjunct(char const*) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char, unsigned long) const
... [180 more lines] ...
Just to pick on one example:
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long) const
std::basic_string is a template class, and does not exist in libstdc++.dylib. It was instantiated when the boost library was compiled, and (rightly) included there - because Boost.System uses it.
I suspect (but don't know) that this is true for all of the calls you see.
im using strtod() to convert some inputstrings. while checking my code with valgrind, i came accross a "invalid read of size 8". the message shows up if b starts with "i" or "n", thats what i discovered so far. also, if i create a const char* directly (without calling c_str()), strtod seems to do fine. heres the code:
#include <cstdlib>
#include <string>
int main(int argc, char** argv) {
char* a = 0;
std::string b = "i";
const char* c = b.c_str();
double d = strtod(c, &a);
}
and the (verbose) valgrind output:
==12638== Memcheck, a memory error detector
==12638== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==12638== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==12638== Command: ./leak
==12638==
--12638-- Valgrind options:
--12638-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--12638-- --show-reachable=yes
--12638-- --leak-check=full
--12638-- -v
--12638-- Contents of /proc/version:
--12638-- Linux version 3.2.0-24-generic (buildd#yellow) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012
--12638-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--12638-- Page sizes: currently 4096, max supported 4096
--12638-- Valgrind library directory: /usr/lib/valgrind
--12638-- Reading syms from /media/userdata/NetBeansProjects/leak/dist/Debug/GNU-Linux-x86/leak (0x400000)
--12638-- Reading syms from /lib/x86_64-linux-gnu/ld-2.15.so (0x4000000)
--12638-- Considering /lib/x86_64-linux-gnu/ld-2.15.so ..
--12638-- .. CRC mismatch (computed c5d70380 wanted 7d4a76d0)
--12638-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.15.so ..
--12638-- .. CRC is valid
--12638-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux (0x38000000)
--12638-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--12638-- .. CRC mismatch (computed b9a585cc wanted 749d1a67)
--12638-- object doesn't have a symbol table
--12638-- object doesn't have a dynamic symbol table
--12638-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp
--12638-- Reading suppressions file: /usr/lib/valgrind/default.supp
==12638== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-12638-by-chri-on-???
==12638== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-12638-by-chri-on-???
==12638== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-12638-by-chri-on-???
==12638==
==12638== TO CONTROL THIS PROCESS USING vgdb (which you probably
==12638== don't want to do, unless you know exactly what you're doing,
==12638== or are doing some strange experiment):
==12638== /usr/lib/valgrind/../../bin/vgdb --pid=12638 ...command...
==12638==
==12638== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==12638== /path/to/gdb ./leak
==12638== and then give GDB the following command
==12638== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=12638
==12638== --pid is optional if only one valgrind process is running
==12638==
--12638-- REDIR: 0x40189e0 (strlen) redirected to 0x380625c7 (???)
--12638-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so (0x4a25000)
--12638-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--12638-- .. CRC mismatch (computed c82927cb wanted 1861273b)
--12638-- object doesn't have a symbol table
--12638-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so (0x4c27000)
--12638-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--12638-- .. CRC mismatch (computed 72e29ec9 wanted f3ad49da)
--12638-- object doesn't have a symbol table
--12638-- REDIR: 0x4018850 (index) redirected to 0x4c2bc60 (index)
--12638-- REDIR: 0x40188d0 (strcmp) redirected to 0x4c2cc20 (strcmp)
--12638-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 (0x4e32000)
--12638-- Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 ..
--12638-- .. CRC mismatch (computed ef748751 wanted e44c0328)
--12638-- object doesn't have a symbol table
--12638-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x5132000)
--12638-- Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--12638-- .. CRC mismatch (computed c8e4b229 wanted 098e39f6)
--12638-- object doesn't have a symbol table
--12638-- Reading syms from /lib/x86_64-linux-gnu/libc-2.15.so (0x5348000)
--12638-- Considering /lib/x86_64-linux-gnu/libc-2.15.so ..
--12638-- .. CRC mismatch (computed 0dfc7f92 wanted 306696b6)
--12638-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.15.so ..
--12638-- .. CRC is valid
--12638-- Reading syms from /lib/x86_64-linux-gnu/libm-2.15.so (0x5705000)
--12638-- Considering /lib/x86_64-linux-gnu/libm-2.15.so ..
--12638-- .. CRC mismatch (computed 84e90409 wanted 8a8fcc58)
--12638-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.15.so ..
--12638-- .. CRC is valid
--12638-- REDIR: 0x53d48c0 (strcasecmp) redirected to 0x4a25610 (_vgnU_ifunc_wrapper)
--12638-- REDIR: 0x53d0c60 (strnlen) redirected to 0x4a25610 (_vgnU_ifunc_wrapper)
--12638-- REDIR: 0x53d6b90 (strncasecmp) redirected to 0x4a25610 (_vgnU_ifunc_wrapper)
--12638-- REDIR: 0x53d2650 (__GI_strrchr) redirected to 0x4c2ba80 (__GI_strrchr)
--12638-- REDIR: 0x53d0b30 (strlen) redirected to 0x4a25610 (_vgnU_ifunc_wrapper)
--12638-- REDIR: 0x54a93d0 (__strlen_sse2_pminub) redirected to 0x4c2bfa0 (strlen)
--12638-- REDIR: 0x4ee7dd0 (operator new(unsigned long)) redirected to 0x4c2b160 (operator new(unsigned long))
--12638-- REDIR: 0x53d0b80 (__GI_strlen) redirected to 0x4c2bfc0 (__GI_strlen)
==12638== Invalid read of size 8
==12638== at 0x53D6C4F: __GI___strncasecmp_l (strcmp.S:213)
==12638== by 0x538900A: ____strtod_l_internal (strtod_l.c:566)
==12638== by 0x40088B: main (main.cpp:9)
==12638== Address 0x59ff058 is 24 bytes inside a block of size 26 alloc'd
==12638== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12638== by 0x4ED0A88: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED2494: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED25E2: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x40085C: main (main.cpp:7)
==12638==
==12638== Invalid read of size 8
==12638== at 0x53D6C57: __GI___strncasecmp_l (strcmp.S:215)
==12638== by 0x538900A: ____strtod_l_internal (strtod_l.c:566)
==12638== by 0x40088B: main (main.cpp:9)
==12638== Address 0x59ff060 is 6 bytes after a block of size 26 alloc'd
==12638== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12638== by 0x4ED0A88: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED2494: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED25E2: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x40085C: main (main.cpp:7)
==12638==
--12638-- REDIR: 0x4ee6150 (operator delete(void*)) redirected to 0x4c2a450 (operator delete(void*))
--12638-- REDIR: 0x53cb010 (free) redirected to 0x4c2a7c0 (free)
==12638==
==12638== HEAP SUMMARY:
==12638== in use at exit: 0 bytes in 0 blocks
==12638== total heap usage: 1 allocs, 1 frees, 26 bytes allocated
==12638==
==12638== All heap blocks were freed -- no leaks are possible
==12638==
==12638== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
==12638==
==12638== 1 errors in context 1 of 2:
==12638== Invalid read of size 8
==12638== at 0x53D6C57: __GI___strncasecmp_l (strcmp.S:215)
==12638== by 0x538900A: ____strtod_l_internal (strtod_l.c:566)
==12638== by 0x40088B: main (main.cpp:9)
==12638== Address 0x59ff060 is 6 bytes after a block of size 26 alloc'd
==12638== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12638== by 0x4ED0A88: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED2494: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED25E2: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x40085C: main (main.cpp:7)
==12638==
==12638==
==12638== 1 errors in context 2 of 2:
==12638== Invalid read of size 8
==12638== at 0x53D6C4F: __GI___strncasecmp_l (strcmp.S:213)
==12638== by 0x538900A: ____strtod_l_internal (strtod_l.c:566)
==12638== by 0x40088B: main (main.cpp:9)
==12638== Address 0x59ff058 is 24 bytes inside a block of size 26 alloc'd
==12638== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12638== by 0x4ED0A88: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED2494: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x4ED25E2: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==12638== by 0x40085C: main (main.cpp:7)
==12638==
--12638--
--12638-- used_suppression: 2 dl-hack3-cond-1
==12638==
==12638== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
is there a bug or am i missing something?
I don't think there's a bug in your code. I think this is a bug in Valgrind.
Valgrind has its own implementations of functions like strchr, strcasecmp, etc., which it redirects your application to use instead of the versions in libgcc. A comment in Valgrind's mc_replace_strmem.c file explains:
/* ---------------------------------------------------------------------
We have our own versions of these functions for two reasons:
(a) it allows us to do overlap checking
(b) some of the normal versions are hyper-optimised, which fools
Memcheck and cause spurious value warnings. Our versions are
simpler.
Note that overenthusiastic use of PLT bypassing by the glibc people also
means that we need to patch multiple versions of some of the functions to
our own implementations.
THEY RUN ON THE SIMD CPU!
------------------------------------------------------------------ */
You can see these redirections occurring in the REDIR output from your log.
From examination of mc_replace_strmem.c it looks like Valgrind does not replace __GI___strncasecmp_l, which your log indicates is being called. I'd suggest filing a bug against Valgrind and including your program as a test case.