segmentation fault with hello world. error in my g++ build? - c++

I try to run this simple hello world :
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
I have no error with g++ -g -Wall hello.cpp but when I execute ./a.out I have a segmentation fault.
Here is the gdb :
(gdb) run
*Starting program: /media/theflyingman/Share/C++/gcc_test/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".*
*Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d3bf5a in std::ostream::sentry::sentry(std::ostream&) () from /lib/x86_64-linux-gnu/libstdc++.so.6*
(gdb) up
*#1 0x00007ffff7d3c9dc 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 /lib/x86_64-linux-gnu/libstdc++.so.6*
I can compile and execute this one (with gcc) :
#include <stdio.h>
int main() {
printf("Hello, world!\n");
return 0;
}
I have build gcc from sources.
gcc --version
gcc (GCC) 13.0.1 20230124 (experimental)
Copyright © 2023 Free Software Foundation, Inc.
g++ --version
g++ (GCC) 13.0.1 20230124 (experimental)
Copyright © 2023 Free Software Foundation, Inc.
LinuxMint/kernel 6.1.7
I think I can have an error with my g++ build or an error with the library path but i'm not sure.
Any help ?
Best Regards

Related

Why does clang MemorySanitizer produce error in fstream open?

I am trying to integrate Memory Sanitizer into my project. And following code raise an use-of-uninitialized-value error:
#include <fstream>
int main () {
std::ifstream ifs;
ifs.open ("test.txt", std::ifstream::in);
char c = ifs.get(); // this line doesn't matter
if (!ifs.good()) {
return -1;
}
ifs.close();
return 0;
}
$ clang -fsanitize=memory -fPIE -pie -fno-omit-frame-pointer -g -O3 main.cpp -lstdc++
$ ./a.out
==43028==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x55986e5d76ae in std::basic_ifstream<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/fstream
#1 0x55986e5d76ae in main /home/promanjuk/learn/sanityzers/main.cpp:5:7
#2 0x7f6389ffdd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#3 0x7f6389ffde3f in __libc_start_main csu/../csu/libc-start.c:392:3
#4 0x55986e551334 in _start (/home/promanjuk/learn/sanityzers/a.out+0x21334) (BuildId: 597886c0634c006622192d0fa4c5ab7f169b7625)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/fstream in std::basic_ifstream<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode)
Exiting
$ clang --version
Ubuntu clang version 14.0.0-1ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
GodBolt behavior is the same (from clang 5.0 to 15.0, older versions produce a linker error).
Any ideas?
Thanks.
Code example I take from https://cplusplus.com/reference/fstream/ifstream/open/
So, this I've tried to run with/without
char c = ifs.get();
Tried different version of the clang.

Segmentation fault when compiling with mingw g++ 7.2, declaring an ifstream and using extern "C"

I'm was writing some interfacing code to call c++ routines from fortran which is why I dumped the methods into an extern "C" block. When compiling with g++.exe (x86_64-win32-seh-rev1, Built by MinGW-W64 project) 7.2.0 under Windows 10 I was getting segmentation faults when declaring an ifstream object. I broke it down to the following code snippet:
tester.cpp
#include <fstream>
void x(){
std::ifstream infile;
}
extern "C"
{
void whatever() {
}
}
int main(){
x();
return 0;
}
I'm building with following commmand: g++ tester.cpp -o tester.out -O3. The program runs without faults when building with -O0 but crashes for -O1,-O2 and -O3. Compiling using msvc under Windows and g++ 8.30 under Linux produces no segmentation fault. Both the extern "C" block and the call to x() are required for the program to crash.
Running gdb backtrace gives the following output:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x000000006fce18b2 in ?? ()
from C:\Program Files\Git\mingw64\bin\libstdc++-6.dll
(gdb) backtrace
#0 0x000000006fce18b2 in ?? ()
from C:\Program Files\Git\mingw64\bin\libstdc++-6.dll
#1 0x000000006fcf7b6c in ?? ()
from C:\Program Files\Git\mingw64\bin\libstdc++-6.dll
#2 0x000000006fcf9b41 in ?? ()
from C:\Program Files\Git\mingw64\bin\libstdc++-6.dll
#3 0x000000000040163a in std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream (this=0x61fc20, __in_chrg=<optimized out>,
__vtt_parm=<optimized out>)
at C:/mingw64/lib/gcc/x86_64-w64-mingw32/7.2.0/include/c++/fstream:482
#4 x () at tester.cpp:4
#5 0x0000000000402ede in main () at tester.cpp:14
Is this a bug with mingw or am I missing something. std::ifstream crashes in release build on Windows with exit code 0xC0000409: Unknown software exception might be related.

Why is valgrind reporting errors for libstdc++'s std::locale?

Related question: wifstream with imbue, locale produces valgrind errors
I am using cppreference's (potentially flawed) examples, in particular the one present on their imbue page. Using the command line on the coliru online compiler:
clang++ -std=c++14 -stdlib=libstdc++ -O3 -Wall -Wextra -pedantic-errors
-pthread main.cpp && valgrind ./a.out
the following test cases produce errors like these (unless I state "no errors"):
==5421== Invalid read of size 8
==5421== at 0x590CBC0: wcscmp (wcscmp.S:208)
==5421== by 0x4EAC174: std::moneypunct<wchar_t, false>::~moneypunct() (monetary_members.cc:927)
==5421== by 0x4EAC1D8: std::moneypunct<wchar_t, false>::~moneypunct() (monetary_members.cc:932)
==5421== by 0x4EA1695: std::locale::_Impl::~_Impl() (locale_classes.h:412)
==5421== by 0x4EA17D8: std::locale::~locale() (locale_classes.h:521)
==5421== by 0x400955: main (in /tmp/1412433400.2497/a.out)
==5421== Address 0x5c2e0b8 is 0 bytes after a block of size 8 alloc'd
==5421== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5421== by 0x4EABE61: std::moneypunct<wchar_t, false>::_M_initialize_moneypunct(__locale_struct*, char const*) (monetary_members.cc:847)
==5421== by 0x4EA3CD7: std::locale::_Impl::_Impl(char const*, unsigned long) (locale_facets_nonio.h:993)
==5421== by 0x4EA406A: std::locale::locale(char const*) (localename.cc:42)
==5421== by 0x40094D: main (in /tmp/1412433400.2497/a.out)
cppreference's imbue example:
#include <iostream>
#include <sstream>
#include <locale>
int main()
{
std::istringstream iss;
iss.imbue(std::locale("en_US.UTF8"));
std::cout << "Current locale: " << iss.getloc().name() << '\n';
iss.imbue(std::locale());
std::cout << "Global locale : " << iss.getloc().name() << '\n';
}
libstdc++ - errors
libc++ - no errors
The linked questioned at the top's reduced example:
#include <iostream>
#include <locale>
int main (int argc, char **argv) {
try {
std::locale * l1 = new std::locale("de_DE.UTF-8");
delete l1;
std::locale l2("de_DE.UTF-8");
} catch(...) {
return 0;
}
return 0;
};
libstdc++ - errors
libc++ - no errors
Linked bug report in above question's reduced example:
#include <wchar.h>
void foo(int)
{
}
int main()
{
wchar_t *a=new wchar_t[2], *b=new wchar_t[2];
size_t j;
a[0]=b[0]='A';
a[1]=b[1]=0;
foo(wcscmp(a, b));
delete[] a;
delete[] b;
return 0;
}
libstdc++ - no errors
libc++ - no errors
I've added the bug report's test case for completeness even though they produce no errors. Coliru's valgrind version is 3.7.0, and OP in the linked thread mentions upgrading to 3.8.1 and still receiving errors. I'm not on a Linux machine at the moment, and so cannot test it myself. If it makes any difference, here's glibc output:
GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.7) stable release version 2.15, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.3.
Compiled on a Linux 3.2.60 system on 2014-08-28.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
Where does the bug lie? cppreference's examples, valgrind, or libstdc++?
It's a false positive in Valgrind, fixed here.

unable to create a C++ ruby extension

I have problems creating a ruby extension to export a C++ library I wrote to ruby under OSX. This simple example:
#include <boost/regex.hpp>
extern "C" void Init_bayeux()
{
boost::regex expression("^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?");
}
results in a bad_cast exception being thrown:
#0 0x00000001014663bd in __cxa_throw ()
#1 0x00000001014cf6b2 in __cxa_bad_cast ()
#2 0x00000001014986f9 in std::use_facet<std::collate<char> > ()
#3 0x0000000101135a4f in boost::re_detail::cpp_regex_traits_base<char>::imbue (this=0x7fff5fbfe4d0, l=#0x7fff5fbfe520) at cpp_regex_traits.hpp:218
#4 0x0000000101138d42 in cpp_regex_traits_base (this=0x7fff5fbfe4d0, l=#0x7fff5fbfe520) at cpp_regex_traits.hpp:173
#5 0x000000010113eda6 in boost::re_detail::create_cpp_regex_traits<char> (l=#0x7fff5fbfe520) at cpp_regex_traits.hpp:859
#6 0x0000000101149bee in cpp_regex_traits (this=0x101600200) at cpp_regex_traits.hpp:880
#7 0x0000000101142758 in regex_traits (this=0x101600200) at regex_traits.hpp:75
#8 0x000000010113d68c in regex_traits_wrapper (this=0x101600200) at regex_traits.hpp:169
#9 0x000000010113bae1 in regex_data (this=0x101600060) at basic_regex.hpp:166
#10 0x000000010113981e in basic_regex_implementation (this=0x101600060) at basic_regex.hpp:202
#11 0x0000000101136e1a in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign (this=0x7fff5fbfe710, p1=0x100540ae0 "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", p2=0x100540b19 "", f=0) at basic_regex.hpp:652
#12 0x0000000100540a66 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign (this=0x7fff5fbfe710, p1=0x100540ae0 "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", p2=0x100540b19 "", f=0) at basic_regex.hpp:379
#13 0x0000000100540a13 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign (this=0x7fff5fbfe710, p=0x100540ae0 "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", f=0) at basic_regex.hpp:364
#14 0x000000010054096e in basic_regex (this=0x7fff5fbfe710, p=0x100540ae0 "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", f=0) at basic_regex.hpp:333
#15 0x00000001005407e2 in Init_bayeux () at bayeux.cpp:10
#16 0x0000000100004593 in dln_load (file=0x1008bc000 "/Users/todi/sioux/lib/debug/rack/bayeux.bundle") at dln.c:1293
I compile the extension with:
g++ ./source/rack/bayeux.cpp -o /Users/todi/sioux/obj/debug/rack/bayeux.o -Wall -pedantic -Wno-parentheses -Wno-sign-compare -fno-common -c -pipe -I/Users/todi/sioux/source -ggdb -O0
And finally link the dynamic library with:
g++ -o /Users/todi/sioux/lib/debug/rack/bayeux.bundle -bundle -ggdb /Users/todi/sioux/obj/debug/rack/bayeux.o -L/Users/todi/sioux/lib/debug -lrack -lboost_regex-mt-d -lruby
I've searched the web and tried all kind of link and compiler switches. If I build a executable there is no such problem. Does someone else had such a problem and found a solution?
I've further investigated this and found that the function causing the exception looks like this:
std::locale loc = std::locale("C");
std::use_facet< std::collate<char> >( loc );
In the source of std::collate<> I found the throw statment:
use_facet(const locale& __loc)
{
const size_t __i = _Facet::id._M_id();
const locale::facet** __facets = __loc._M_impl->_M_facets;
if (__i >= __loc._M_impl->_M_facets_size || !__facets[__i])
__throw_bad_cast();
#ifdef __GXX_RTTI
return dynamic_cast<const _Facet&>(*__facets[__i]);
#else
return static_cast<const _Facet&>(*__facets[__i]);
#endif
}
Does this makes any sense to you?
Update: I've tried Jan's suggestion:
Todis-MacBook-Pro:rack todi$ g++ -shared -fpic -o bayeux.bundle bayeux.cpp
Todis-MacBook-Pro:rack todi$ ruby -I. -rbayeux -e 'puts :ok'
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
Abort trap
versions:
Todis-MacBook-Pro:rack todi$ ruby -v
ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin10.6.0]
Todis-MacBook-Pro:rack todi$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.2/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5.2/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.5 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.5 --with-gxx-include-dir=/opt/local/include/gcc45/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.5.2 (GCC)
Update:
It's not the bound-check in use_facet() that throws, but the next line, that actually does a dynamic cast. This example boils it down to maybe something with RTTI:
#define private public
#include <locale>
#include <iostream>
#include <typeinfo>
extern "C" void Init_bayeux()
{
std::locale loc = std::locale("C");
printf( "size: %i\n", loc._M_impl->_M_facets_size );
printf( "id: %i\n", std::collate< char >::id._M_id() );
const std::locale::facet& fac = *loc._M_impl->_M_facets[ std::collate< char >::id._M_id() ];
printf( "name: %s\n", typeid( fac ).name());
printf( "name: %s\n", typeid( std::collate<char> ).name());
const std::type_info& a = typeid( fac );
const std::type_info& b = typeid( std::collate<char> );
printf( "equal: %i\n", !a.before( b ) && !b.before( a ) );
dynamic_cast< const std::collate< char >& >( fac );
}
I've used printf() because usage of cout also fails. The output of the code above is:
size: 28
id: 5
name: St7collateIcE
name: St7collateIcE
equal: 1
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
Abort trap
Build with:
g++ -shared -fpic -o bayeux.bundle bayeux.cpp && ruby -I. -rbayeux -e 'puts :ok'
Update:
If I rename Init_bayeux to main() and link it to an executable, the output is the same, but no call to terminate.
Update:
When I write a little program to load the shared library and to execute Init_bayeux(), again, no exception is thrown:
#include <dlfcn.h>
int main()
{
void* handle = dlopen("bayeux.bundle", RTLD_LAZY|RTLD_GLOBAL );
void(*f)(void) = (void(*)(void)) dlsym( handle, "Init_bayeux" ) ;
f();
}
So it looks to me, that it might be a problem with how the ruby.exe was build. Does that make sense?
Update:
I had a look at the addresses containing the names of the two type_info objects. Same content, but different addresses. I added the -flat_namespace switch to the link command. Now the dynamic_cast works. The original Problem with the boost regex library still exists, but I think this might be solvable by linking boost statically into the shared library or by rebuilding the boost libraries with the -flat_namespace switch.
Update:
Now I'm back to the very first example with the boost regex expression, build with this command:
g++ -shared -flat_namespace -fPIC -o bayeux.bundle /Users/todi/boost_1_49_0/stage/lib/libboost_regex.a bayeux.cpp
But when loading the extension into the ruby interpreter, initializing of static symbols fails:
ruby(59384,0x7fff712b8cc0) malloc: *** error for object 0x7fff70b19500: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted.
0x00007fff8a6ab0b6 in __kill ()
(gdb) bt
#0 0x00007fff8a6ab0b6 in __kill ()
#1 0x00007fff8a74b9f6 in abort ()
#2 0x00007fff8a663195 in free ()
#3 0x0000000100541023 in boost::re_detail::cpp_regex_traits_char_layer<char>::init (this=0x10060be50) at basic_string.h:237
#4 0x0000000100543904 in boost::object_cache<boost::re_detail::cpp_regex_traits_base<char>, boost::re_detail::cpp_regex_traits_implementation<char> >::do_get (k=#0x7fff5fbfddd0) at cpp_regex_traits.hpp:366
#5 0x000000010056005b in create_cpp_regex_traits<char> (l=<value temporarily unavailable, due to optimizations>) at pending/object_cache.hpp:69
#6 0x0000000100544c33 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign (this=0x7fff5fbfe090, p1=0x100567158 "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", p2=0x100567191 "", f=0) at cpp_regex_traits.hpp:880
#7 0x0000000100566280 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign ()
#8 0x000000010056622d in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign ()
#9 0x0000000100566188 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::basic_regex ()
#10 0x0000000100566025 in Init_bayeux ()
#11 0x0000000100003a23 in dln_load (file=0x10201a000 "/Users/todi/sioux/source/rack/bayeux.bundle") at dln.c:1293
#12 0x000000010016569d in vm_pop_frame [inlined] () at /Users/todi/.rvm/src/ruby-1.9.2-p320/vm_insnhelper.c:1465
#13 0x000000010016569d in rb_vm_call_cfunc (recv=4303980440, func=0x100042520 <load_ext>, arg=4303803000, blockptr=0x1, filename=<value temporarily unavailable, due to optimizations>, filepath=<value temporarily unavailable, due to optimizations>) at vm.c:1467
#14 0x0000000100043382 in rb_require_safe (fname=4303904640, safe=0) at load.c:602
#15 0x000000010017cbf3 in vm_call_cfunc [inlined] () at /Users/todi/.rvm/src/ruby-1.9.2-p320/vm_insnhelper.c:402
#16 0x000000010017cbf3 in vm_call_method (th=0x1003016b0, cfp=0x1004ffef8, num=1, blockptr=0x1, flag=8, id=<value temporarily unavailable, due to optimizations>, me=0x10182cfa0, recv=4303980440) at vm_insnhelper.c:528
...
Again, this doesn't fail, when I load the shared library by the little c program from above.
Update:
Now I link the first example static:
g++ -shared -fPIC -flat_namespace -nodefaultlibs -o bayeux.bundle -static -lstdc++ -lpthread -lgcc_eh -lboost_regex-mt bayeux.cpp
With the same error:
ruby(15197,0x7fff708aecc0) malloc: *** error for object 0x7fff7027e500: pointer being freed was not allocated
otool -L confirmed that every library is linked static:
bayeux.bundle:
bayeux.bundle (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)
debug:
If I link against the boost debug version, then it works like expected.
For the records: I've now build boost and my application with the very same compiler (version 4.2.1 [official apple version]). No problems so far. Why it will not work as expected when the ruby extension links all libraries statically is a miracle to me. Thank to all who put time into this issue.
Kind regards
Torsten

llvm-gcc std::allocator bug?

The code:
#include <vector>
#include <stack>
using namespace std;
class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};
int main()
{
std::stack<int, intvec> s;
}
compiles with both g++ (4.4.3) and llvm-g++ (4.2.1), but the output of the latter seg faults:
$ g++ main.cc && ./a.out
$ llvm-g++ main.cc && ./a.out
Segmentation fault
It appears to be an issue of freeing something that wasn't allocated. Is this a bug in llvm-gcc?
Update: Based on the discuss on the llvm mailing list, it looks like this is a bug, either in llvm-gcc or its implementation of the STL that has been fixed in newer versions. I haven't bother to install and build llvm-gcc from their repository to find out, however.
Okay. So I ran this on Ubuntu 10.10 x64 and I see the segmentation fault. Here's some details. In general, my summary seems to be that this is a bug in the compiler. (Note that I'm not the original question asker, I was merely able to reproduce his results).
I've also forwarded this to the llvm mailing list at http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036231.html
wlynch#green:/tmp$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
wlynch#green:/tmp$ llvm-g++ -O0 -g main.cc && ./a.out
Segmentation fault
wlynch#green:/tmp$ llvm-g++ -O3 -g main.cc && ./a.out
Segmentation fault
(gdb) bt
#0 0x00007ffff780aa75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff780e5c0 in *__GI_abort () at abort.c:92
#2 0x00007ffff78444fb in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3 0x00007ffff784e5b6 in malloc_printerr (action=3, str=0x7ffff791ead3 "free(): invalid pointer", ptr=<value optimized out>) at malloc.c:6266
#4 0x00007ffff7854e83 in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3738
#5 0x0000000000401476 in __gnu_cxx::new_allocator<int>::deallocate (this=0x7fffffffe5a8, __p=0x62c000, unnamed_arg=4) at include/c++/4.2.1/ext/new_allocator.h:97
#6 0x00000000004014b1 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0x7fffffffe5a8, __p=0x62c000, __n=4) at include/c++/4.2.1/bits/stl_vector.h:146
#7 0x00000000004014fe in std::_Vector_base<int, std::allocator<int> >::~_Vector_base (this=0x7fffffffe5a8) at include/c++/4.2.1/bits/stl_vector.h:132
#8 0x00000000004017cf in std::vector<int, std::allocator<int> >::~vector (this=0x7fffffffe5a8) at include/c++/4.2.1/bits/stl_vector.h:287
#9 0x0000000000401886 in intvec::~intvec (this=0x7fffffffe5a8) at main.cc:6
#10 0x00000000004018a4 in std::stack<int, intvec>::~stack (this=0x7fffffffe5a8) at include/c++/4.2.1/bits/stl_stack.h:99
#11 0x0000000000400c01 in main () at main.cc:10
We also get a free of an invalid pointer. Which makes sense from the traceback.
wlynch#green:/tmp$ valgrind ./a.out
==4644== Memcheck, a memory error detector
==4644== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4644== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4644== Command: ./a.out
==4644==
==4644== Invalid free() / delete / delete[]
==4644== at 0x4C270BD: free (vg_replace_malloc.c:366)
==4644== by 0x401475: __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) (new_allocator.h:97)
==4644== by 0x4014B0: std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) (stl_vector.h:146)
==4644== by 0x4014FD: std::_Vector_base<int, std::allocator<int> >::~_Vector_base() (stl_vector.h:132)
==4644== by 0x4017CE: std::vector<int, std::allocator<int> >::~vector() (stl_vector.h:287)
==4644== by 0x401885: intvec::~intvec() (main.cc:6)
==4644== by 0x4018A3: std::stack<int, intvec>::~stack() (stl_stack.h:99)
==4644== by 0x400C00: main (main.cc:10)
==4644== Address 0x5433000 is not stack'd, malloc'd or (recently) free'd
==4644==
==4644==
==4644== HEAP SUMMARY:
==4644== in use at exit: 1 bytes in 1 blocks
==4644== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==4644==
==4644== LEAK SUMMARY:
==4644== definitely lost: 1 bytes in 1 blocks
==4644== indirectly lost: 0 bytes in 0 blocks
==4644== possibly lost: 0 bytes in 0 blocks
==4644== still reachable: 0 bytes in 0 blocks
==4644== suppressed: 0 bytes in 0 blocks
==4644== Rerun with --leak-check=full to see details of leaked memory
==4644==
==4644== For counts of detected and suppressed errors, rerun with: -v
==4644== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
I reduced the test case a bit. I'm actually leaning towards this being a STL implementation error, rather than a compiler error.
#include <vector>
class blub {};
class intvec : public std::vector<int>, public blub {};
int main() {
intvec d;
intvec e(d);
}
To figure out what's actually happening, try to compile with the -g flag to enable debug information to be emitted, then run valgrind ./a.out to get a stack trace where the segfault occurs.
does not segfault for me, what platform are you using?
macmini:stackoverflow samm$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
macmini:stackoverflow samm$ cat stack.cc
#include <vector>
#include <stack>
using namespace std;
class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};
int main()
{
std::stack<int, intvec> s;
}
macmini:stackoverflow samm$ llvm-g++ -g stack.cc
macmini:stackoverflow samm$ ./a.out
macmini:stackoverflow samm$ echo $?
0
macmini:stackoverflow samm$