[Bug libstdc++/64504] New: Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[Bug libstdc++/64504] New: Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[andrey.vihrov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

            Bug ID: 64504
           Summary: Invalid free() with _GLIBCXX_DEBUG and -fwhole-program
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andrey.vihrov at gmail dot com

Created attachment 34383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34383&action=edit
Preprocessed source

Compiling the following program:

#define _GLIBCXX_DEBUG

#include <iostream>
#include <string>

int main()
{
    std::string s;
    std::cin >> s;
}

with "g++ -fwhole-program x.cpp" gives me

*** Error in `./a.out': free(): invalid pointer: 0x00000000006017c0 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x732ae)[0x7fb15966e2ae]
/usr/lib/libc.so.6(+0x7872e)[0x7fb15967372e]
/usr/lib/libc.so.6(+0x78eeb)[0x7fb159673eeb]
/usr/lib/libstdc++.so.6(_ZNSs7reserveEm+0xa4)[0x7fb159f7d3e4]
/usr/lib/libstdc++.so.6(_ZStrsIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E+0x214)[0x7fb159f302f4]
./a.out[0x400b40]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fb15961b040]
./a.out[0x4009a9]

This is on 64-bit Arch Linux with GCC 4.9.2. My understanding of
-fwhole-program is that it can be used with one source file that includes
standard library headers and links with the standard library. If this is wrong,
then I'm sorry for filing a bogus bug report.

I have searched for similar reports and found bug #53838. And indeed the sample
program from that bug also crashes with the same message. However, my system
has only one GCC and libstdc++, unlike in that case.

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.9-20141224/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20141224 (prerelease) (GCC)

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrey Vihrov from comment #0)
> -fwhole-program is that it can be used with one source file that includes
> standard library headers and links with the standard library. If this is
> wrong, then I'm sorry for filing a bogus bug report.

I don't know if it's supposed to work (I would expect not), but using
-fwhole-program with _GLIBCXX_DEBUG seems silly to me. The Debug Mode macro can
slow things down by an order of magnitude, so the advantages of -fwhole-program
will be minimal anyway.

Is there a reason you can't use -flto instead?

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[andrey.vihrov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

--- Comment #2 from Andrey Vihrov <andrey.vihrov at gmail dot com> ---
Thanks for a fast reply!

My use case for these two (amongst several others) options together is
competitive programming, in which a contestant is required a write a
one-source-file solution, test it locally and submit it to a grading server.
Debug Mode helps detect mistakes, and -fwhole-program helps find variables or
functions that I defined and intended to use, but forgot to. For example, for
this source:

int unused;

int main()
{

}

"g++ -Wall -fwhole-program x.cpp" gives

x.cpp:1:5: warning: 'unused' defined but not used [-Wunused-variable]

, and there is no warning without -fwhole-program. Of course, I can get the
same effect by making everything "static", but this depends on me remembering
to do it, so this option is better in this regard. -flto doesn't have the same
effect.

If -fwhole-program isn't supported in this case, then it's fair enough. But
then it would be great if the documentation on -fwhole-program was updated to
clarify when the option can be used and when not.

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[andrey.vihrov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

--- Comment #3 from Andrey Vihrov <andrey.vihrov at gmail dot com> ---
I compiled the example program without and with -fwhole-program to assembly
code, and here are the differences: http://pastie.org/9859649

As I understand, normally the ".weak" directive ensures that there is only one
definition of std::string::_Rep::_S_empty_rep_storage per whole program. But
with -fwhole-program the .weak directive disappears, and instead another local
definition is created.

Looking at libstdc++ source code, I see

// The following storage is init'd to 0 by the linker, resulting
// (carefully) in an empty string with one reference.
static size_type _S_empty_rep_storage[];

. . .

// Linker sets _S_empty_rep_storage to all 0s (one reference, empty string)
// at static init time (before static ctors are run).
template<typename _CharT, typename _Traits, typename _Alloc>
typename basic_string<_CharT, _Traits, _Alloc>::size_type
basic_string<_CharT, _Traits, _Alloc>::_Rep::_S_empty_rep_storage[
(sizeof(_Rep_base) + sizeof(_CharT) + sizeof(size_type) - 1) /
sizeof(size_type)];

I can get kind of the same difference in assembly by compiling this code:

template<typename T = void>
struct S
{
    static char arr[];
};

template<typename T>
char S<T>::arr[3];

int main()
{
    return S<>::arr[1];
}

Without -fwhole-program ".weak" and stuff is emitted, with the option the array
probably becomes static and so the program is compiled to "return 0".

So it looks like the problem here is that with -fwhole-program GCC does not
consider the possible existence of the same template instantiation in other
translation units.

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like _S_empty_rep_storage is tested like

  if (ptr != &_S_empty_rep_storage)

in libstdc++ and thus having multiple _S_empty_rep_storage instantiations is
going to break.

Honza - how was -fwhole-program (and LTO?!) designed to deal with C++ ODR
rules?  With -fno-linker-plugin, that is?


To others:

-fwhole-program basically assumes that all defined symbols can be brought
local to the unit (apart from main()).  Seems like this includes instantiated
templates which means that we assume there is only a single TU and thus ODR
violations never arise from that.

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrey Vihrov from comment #2)
> , and there is no warning without -fwhole-program. Of course, I can get the
> same effect by making everything "static", but this depends on me
> remembering to do it, so this option is better in this regard. -flto doesn't
> have the same effect.

This is not what -fwhole-program is for, you're just using it for a side-effect
that happens as a result of making everything static.

So my suggestion would be "don't do that".

If you have a single file how hard can it be to remember to make your globals
static? How many of them do you have?! Just enclosing them in an anonymous
namespace would work, and then all you have to remember to do is add new
globals inside that scope, not elsewhere in the file.

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[andrey.vihrov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

--- Comment #6 from Andrey Vihrov <andrey.vihrov at gmail dot com> ---
Thanks for your reply. You have a point: using -fwhole-program introduces more
effects than needed, as evidenced by this bug report, so an anonymous namespace
is safer and cleaner.

In any case, in this bug report we have a program that produces unexpected
results with GCC. If this usage is supported, then it is a bug. If this usage
is unsupported, then it would be nice to explicitly document cases when
-fwhole-program can be used in GCC. For example, GCC documentation might say
something like

   Note: -fwhole-program can be specified for programs that link only to the
standard C/C++ library (or link to nothing at all), and do not use any template
class or function from the standard C++ library.

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-09
     Ever confirmed|0                           |1

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I agree the docs should be clear on what's supported.