6

I'm using _GLIBCXX_DEBUG mode to help find errors in my code but I'm having a problem which I think is an error in the library, but hopefully someone can tell me I'm just doing something wrong. Here is a short example which repro's the problem:

#define _GLIBCXX_DEBUG
#include <iostream>
#include <sstream>

int main (int argc, const char * argv[]) {
    std::ostringstream ostr;
    ostr << 1.2;
    std::cout << "Result: " << ostr.str() << std::endl;
    return 0;
}

If I comment out the #define then the output is (as expected):

Result: 1.2

With the _GLIBCXX_DEBUG define in place however the output is simply:

Result:

I've tracked this down to the _M_num_put field of the stream being left as NULL, which causes an exception to be thrown (and caught) in the stream and results in no output for the number. _M_num_put is supposed to be a std::num_put from the locale (I don't claim to understand how that's supposed to work, it's just what I've learned in my searching so far).

I'm running this on a Mac with XCode and have tried it with both "LLVM GCC 4.2" and "Apple LLVM Compiler 3.0" as the compiler with the same results.

I'd appreciate any help in solving this. I want to continue to run with _GLIBCXX_DEBUG mode on my code but this is interfering with that.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
John Stephen
  • 7,625
  • 2
  • 31
  • 45
  • Cannot reproduce with GCC 4.6.1. Everything works as expected. – Kerrek SB Oct 01 '11 at 21:35
  • Try explicitly flushing the stringstream – sehe Oct 01 '11 at 22:12
  • @sehe: Flushing didn't work - the problem is that the data never gets added because of the nil _M_num_put :( – John Stephen Oct 04 '11 at 18:45
  • @Kerrek: Thanks for trying it with a more current compiler. From what I've gathered reading other comment it's not very wise to try to upgrade the compiler in XCode. I'll just have to test as best I can until I find a workaround under 4.2. – John Stephen Oct 04 '11 at 18:46
  • I tried against g++ 4.3.4 and had no problems. I tried against g++ 4.1.1 and had no problems either. – sbrett Oct 13 '11 at 01:02
  • @sbrett: I think it must be specific to LLVM since it repro's for me under both Apple LLVM (which I believe is a CLANG backend) and LLVM/GCC. Still happens even with the new release of XCode too /sigh – John Stephen Oct 17 '11 at 23:23

1 Answers1

4

Someone else has seen this over at cplusplus.com and here at stackoverflow, too.

Consensus is that it is a known bug in gcc 4.2 for Mac OS, and since that compiler is no longer being updated, it is unlikely to ever be fixed.

Seems to me that you can either (1) use LLVM, or (2) build your own GCC and use it.

Community
  • 1
  • 1
Marshall Clow
  • 15,972
  • 2
  • 29
  • 45