Xcode STL C ++ Debug Compilation Error

Question

I have code for writing files that works as expected, but prints an error in debug mode, no output errors in Release.

Code:

#include <iostream> #include <string> #include <fstream> #include <sstream> using namespace std; int main (int argc, char * const argv[]) { string cppfilename; std::cout << "Please enter the filename to create: "; while ( cppfilename == "" ) { getline(cin, cppfilename); // error occurs here } cppfilename += ".txt"; ofstream fileout; fileout.open( cppfilename.c_str() ); fileout << "Writing this to a file.\n"; fileout.close(); return 0; } 

Debug output:

 Please enter the filename to create: Running… myfile FileIO(5403) malloc: *** error for object 0xb3e8: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Created: myfile.txt 

Output for release:

 FileIO implementation C++ Please enter the filename to create: Running… myfile Created: myfile.txt 

Besides not checking that the file descriptor is open (for simplicity), what is wrong with this code?

Update: I broke the code until the following and still errors:

  string cppfilename; getline(cin, cppfilename); // error here 

Answer 1

This looks like another _GLIBCXX_DEBUG case , which crashes on gcc 4.2 on Mac OS X.

Your best options are looking to remove _GLIBCXX_DEBUG or switch to gcc 4.0.

Answer 2

This looks like an error in Apple libstdc++ , at least when it is compiled in debug mode. If I compile the two lines below:

 #include <iostream> #include <string> using namespace std; int main() { string cppfilename; getline(cin, cppfilename); // error here return 0; } 

On the following command line (with definitions taken from the default settings for Xcode to build Debug in a C ++ project):

 g++ -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -g -o getline getline.cpp 

Then I get the same error you saw:

 $ ./getline foo getline(74318) malloc: *** error for object 0x1000021e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap 

This prints out a crash report that gives us the stack trace (you can also get the stack trace from the debugger by running it under Xcode; I just wanted to reproduce it as clean as possible to try to isolate the cause, without anything else strange Xcode might be):

 Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff83c37fe6 __kill + 10 1 libSystem.B.dylib 0x00007fff83cd8e32 abort + 83 2 libSystem.B.dylib 0x00007fff83bf0155 free + 128 3 libstdc++.6.dylib 0x00007fff813e01e8 std::string::reserve(unsigned long) + 90 4 libstdc++.6.dylib 0x00007fff813e0243 std::string::push_back(char) + 63 5 libstdc++.6.dylib 0x00007fff813c92b5 std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) + 277 6 getline 0x00000001000011f5 std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) + 64 (basic_string.h:2451) 7 getline 0x0000000100000cbf main + 34 (getline.cpp:10) 8 getline 0x0000000100000c04 start + 52 

It looks terribly like a mistake. We use some standard library functions in the simplest way and click on the assertion error.

At this point, if we used proprietary software (most of Apple's software, but fortunately libstdc++ is free software), we would have to refuse, write a bug report with our provider and try to find a workaround. Fortunately, this is free software, so we can investigate the root cause. Unfortunately, I do not have time to trace this to the main reason, but the source is available for reading.

Probably report a bug . A workaround in this case would be to remove the definition of _GLIBCXX_DEBUG = 1 (and possibly also _GLIBCXX_DEBUG_PEDANTIC = 1). You can do this in Xcode by finding your Target, double-clicking on the executable file that it builds, go to the build tab, making sure the configuration is set to "Debug", scroll down to the GCC 4.2 - Preprocessing section, and delete the two values from the line Macros preprocessor . This way the code will build and run, and it seems to work in this case, but you will get fewer claims that the debug build of the standard library could catch.