incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: stdcxx 4.2.0/4.1.3 binary incompatibility on Linux
Date Wed, 17 Oct 2007 17:55:11 GMT
Martin Sebor wrote:
> In a 12D build with the default gcc 4.1.0 on SuSE Linux Enterprise
> Server 10 (x86_64), the following simple program abends with the
> error below after upgrading the 4.1.3 library to 4.2.0:

I've enhanced the program to replace operators new and delete
and to print the value of the pointer. The enhanced test case
and the output obtained from a 12D build with gcc 3.4.6 on Red
Hat Enterprise Linux AS release 4 (Nahant Update 4) is below.
Interestingly, the 12d (32-bit) output with Sun C++ on Solaris
is fine.

$ cat t.cpp && LD_LIBRARY_PATH=../lib ./t
#include <cstdio>
#include <cstdlib>
#include <new>
#include <string>

int main ()
{
     std::string s = "a";
}

void* operator new (std::size_t n) throw (std::bad_alloc)
{
     void* const p = std::malloc (n);
     std::fprintf (stdout, "operator new (%zu) ==> %#p\n", n, p);
     return p;
}

void operator delete (void *p) throw ()
{
     std::fprintf (stdout, "operator delete (%#p)\n", p);
     std::free (p);
}

void* operator new[] (std::size_t n) throw (std::bad_alloc)
{
     void* const p = std::malloc (n);
     std::fprintf (stdout, "operator new[] (%zu) ==> %#p\n", n, p);
     return p;
}

void operator delete[] (void *p) throw ()
{
     std::fprintf (stdout, "operator delete[] (%#p)\n", p);
     std::free (p);
}

operator new (58) ==> 0x502010
operator delete (0x501fe8)
*** glibc detected *** free(): invalid pointer: 0x0000000000501fe8 ***
Aborted


> 
> #include <string>
> 
> int main ()
> {
>     std::string s = "a";
> }
> 
> The only library symbols referenced from the executable are
> 
>   __rw::__rw_throw(int, ...)
>   __rw::__rw_deallocate(void*, unsigned long, int)
>   std::string::_C_null_ref
>   std::string::string(char const*, std::allocator<char> const&)
> 
> Of these, the first one isn't being called and the second and
> fourth haven't changed (according to diff of string.cc). I hate
> to admit I'm stumped. I suppose I should try to do a build on
> a different distribution of Linux with an older version of gcc
> to see if I can reproduce it there.
> 
> 
> *** glibc detected *** ./t: free(): invalid pointer: 0x0000000000500fe8 ***
> ======= Backtrace: =========
> /lib64/libc.so.6[0x2b71c3a4537e]
> /lib64/libc.so.6(__libc_free+0x6c)[0x2b71c3a4699c]
> ./t(__gxx_personality_v0+0x198)[0x400968]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b71c39f7154]
> ./t(__gxx_personality_v0+0x59)[0x400829]


Mime
View raw message