我有一些文件写入代码,按预期工作,但打印在调试模式的错误,在发行版中没有输出错误。

<强>代码:

#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;
}

<强>调试输出:

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

<强>释放输出:

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

除了不检查文件描述符被打开(为简单起见)什么是错的代码?

更新:我打破了代码下面的这个,它仍然错误:

 string cppfilename; 
 getline(cin, cppfilename);    // error here
有帮助吗?

解决方案

这看起来是 _GLIBCXX_DEBUG的另一种情况下被破坏以GCC 4.2 Mac OS X上

您最好的选择看起来是下降_GLIBCXX_DEBUG或切换到GCC 4.0。

其他提示

这在我看来就像苹果的libstdc++的错误,在调试模式下进行编译,至少在。如果我编译两个线减少你上面给出:

#include <iostream>
#include <string>

using namespace std;

int main() {
  string cppfilename; 
  getline(cin, cppfilename);    // error here

  return 0;
}

使用下面的命令行(具有限定从Xcode的默认设置在C ++项目采取调试版本):

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

然后我让你看到了同样的错误:

$ ./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

这会弹出崩溃报告,这给了我们一个堆栈跟踪(你也可以通过Xcode的下运行此获得从调试器堆栈跟踪,我只是想重现它在清洁的环境中成为可能,尝试找出原因,没有别的什么奇怪的Xcode可能会做):

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

这看起来极像是对我的错误。我们使用最平凡的可能方式的一些标准库函数,并创下一个断言失败。

在这一点上,如果我们使用专有软件(其中大部分苹果的软件都是,但幸运的是libstdc++是免费软件),我们将不得不放弃,的提交错误报告与我们的供应商,并试图找到一个解决办法。幸运的是,这是免费的软件,以便我们调查的根本原因。不幸的是,我没有此刻的时间来跟踪下来的根本原因,但是的源是用于细读可用

您或许应该提交Bug这个。在这种情况下的解决方法是,以除去_GLIBCXX_DEBUG = 1所定义(也可能是_GLIBCXX_DEBUG_PEDANTIC = 1以及)。预处理部分 - 你可以找到它建立可执行的目标,双击,将构建选项卡,确保配置设置为调试,向下滚动到 GCC 4.2在Xcode中做到这一点和从在预处理宏线删除两个值。这样的代码将建立并运行,似乎在这种情况下工作,但你会得到更少的断言标准库的调试版本可能已经能够赶上。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top