gcc47 empty string issue

[rob.patro@…]

I'm trying to use the Boost iostream library in OSX with gcc 4.7 (since I'll be using C++11 features). The following code compiles and links, but fails at runtime:

#include <iostream>
#include <fstream>
#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/gzip.hpp>

int main(int argc, char** argv) {

  std::string fname(argv[1]);

  std::ifstream file(fname.c_str(), std::ios_base::in | std::ios_base::binary);
  try {
    boost::iostreams::filtering_istream in;
    in.push(boost::iostreams::gzip_decompressor());
    in.push(boost::iostreams::file_source(fname));
    for( std::string str; std::getline(in, str); ) {
      std::cout << "Processed line " << str << '\n';
    }
   }
   catch(const boost::iostreams::gzip_error& e) {
   std::cout << e.what() << '\n';
  }
}

With the following error:

test(70632) malloc: *** error for object 0x100168860: pointer being freed    was not allocated
*** set a breakpoint in malloc_error_break to debug

Running this under GDB, the stackframe is the following

Program received signal SIGABRT, Aborted.
0x00007fff8b0d0d46 in __kill ()
(gdb) bt
#0  0x00007fff8b0d0d46 in __kill ()
#1  0x00007fff88f52e1c in abort ()
#2  0x00007fff88f26989 in free ()
#3  0x00007fff84365e7c in std::string::reserve ()
#4  0x00007fff8436606e in std::string::push_back ()
#5  0x00007fff8436602d in std::string::operator+= ()
#6  0x000000010006f307 in boost::iostreams::detail::gzip_header::process (this=0x113e8, c=6 '\006') at gzip.cpp:100
#7  0x000000010000f435 in boost::iostreams::basic_gzip_decompressor<std::allocator<char> >::read<boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > > ()
#8  0x000000010000f13e in boost::iostreams::detail::read_filter_impl<boost::iostreams::multichar_tag>::read<boost::iostreams::basic_gzip_decompressor<std::allocator<char> >, boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > > ()
#9  0x000000010000edd7 in boost::iostreams::read<boost::iostreams::basic_gzip_decompressor<std::allocator<char> >, boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > > ()
#10 0x000000010000e557 in boost::iostreams::detail::flt_wrapper_impl<boost::iostreams::input>::read<boost::iostreams::basic_gzip_decompressor<std::allocator<char> >, boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > > ()
#11 0x000000010000e1d8 in boost::iostreams::detail::concept_adapter<boost::iostreams::basic_gzip_decompressor<std::allocator<char> > >::read<boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > > ()
#12 0x000000010000d020 in boost::iostreams::detail::indirect_streambuf<boost::iostreams::basic_gzip_decompressor<std::allocator<char> >, std::char_traits<char>, std::allocator<char>, boost::iostreams::input>::underflow ()
#13 0x00000001000be63a in std::getline<char, std::char_traits<char>, std::allocator<char> > ()

I filed this under gcc instead of boost because it looks like the problem goes down to some very fundamental std::string code, and I assume boost isn't to blame here. It also leads me to believe this error might be encountered far outside this test case.

[cjones051073 (Chris Jones)]

Cc Me!

[cjones051073 (Chris Jones)]

Just so we are clear, could you post the command you used to build the test ?

Also, could you attach to this ticket an example input data file to the test ?

[rob.patro@…]

Sure, I compiled using the following line:

g++-mp-4.7 -std=c++11 -I /opt/local/include -L /opt/local/lib -lboost_iostreams-mt -lz test.cpp -o test

I'm also attaching the source code and simple gzipped file on which the program fails.

P.S. In addition to working on linux with gcc47, this code also compiles and runs using the system g++ on OSX 10.8.1. There's something amiss with the way gcc47 is compiling / linking (or interfacing with the dynamic lib).

[ecronin (Eric Cronin)]

MacPorts Boost is currently only able to be built using the system compiler and system c++ stdlib. When you use g++ you use the gcc stdlib, which is incompatible with errors like the one you saw.

There's no good fix for this at this time. You could try overriding the compiler for boost to use gcc47 with the understanding that this will then likely break any other macports which use boost. But given bjam's craziness I'm unsure if that even works or if it will always pick up the system compiler a bit...

You could try installing boost yourself manually into it's own namespace, and get bjam to use gcc-mp-4.7 as the compiler. I use the versioned libs for boost when I need to deal with multiple compilers, it makes it a lot harder to accidentally link the wrong one in.

[cjones051073 (Chris Jones)]

I thought all the recent changes in the gcc ports where aimed to make them more compatible libstdc++ wise with the system version. See ticket #35770. Shouldn't this help here ?

[ecronin (Eric Cronin)]

Around comment 17 in that ticket is when jeremy switched all the gcc ports to use the system stdlib and things completely broke for the gccs. He then created ports for libstdcxx and libstdcxx-devel which is the gcc stdlib as a stop-gap fix and made all the gcc ports depend on a single gcc stdlib so that at least things compiled with gcc4x and gcc4y can be linked together safely. All the macports clangs and llvms now use the system stdlib so they can be linked together with things compiled with the system toolchain. The two different families can't easily/safely be mixed though.

The "Furthermore... " part of comment 23 and comment 25 is what would need to be done to get the gcc ports to safely link with libraries built using the system stdlib, but it hasn't been done and someone other than jeremy would have to undertake it it sounds like.

[ecronin (Eric Cronin)]

Also, this ticket specifically is about trying to use Boost, which is incredibly tightly coupled with a particular compiler and standard lib's set of features. So even among gccs using the same stdlib I would be somewhat surprised that a boost built using gcc4x's headers and build-in defines (which boost uses to enable/disable things) would work perfectly under gcc4y where the header portions of boost will pre-process differently. A boost lib built using clang and used with gcc would be much worse I expect, even if there aren't ABI issues due to the stdlib being different.

[adfernandes (Andrew Fernandes)]

Also, this ticket specifically is about trying to use Boost, which is incredibly tightly coupled with a particular compiler and standard lib's set of features.

Absolutely.

The boost team, while fantastic coders that have forgotten more about c++ than I'll ever learn, are horrible system integrators. Boost makes very, very, very strong assumptions about platform and compiler. Mixing standard libraries and headers and compiler versions is guaranteed to break it (boost).

I've been putting off updating to the latest boost (1.51) because a lot of ports make assumptions about which version of boost is installed. I've been thinking that a "boost-select" type system might be needed, or a subport system... but anyway, I digress.

Hmm... according to the gcc team, mixing-and-matching ABI versions is a ​nonbug: don't expect it to work. So maybe it is not a good goal, to not require recompilation on gcc version changes?

Anyway, my vote is that this is a gcc bug, not a boost bug, even though I really wish that boost was less picky... :-)

[alecjacobson@…]

Cc Me!

[kencu (Ken)]

this is an ODR violation from mixing libstdc++ versions.

It's from 9 years sgo with versions of things that are no longer used.

Please open a new ticket with new logs if you have new info now.