Xcode STL C++ デバッグコンパイルエラー

Question

期待どおりに動作するコードを記述したファイルがいくつかありますが、デバッグモードではエラーが出力され、リリースでは出力エラーが表示されません。

コード：

#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

Answer 1

_GLIBCXX_DEBUGの別のケースのように、このルックスがで破壊されますマックOS X の上のgcc 4.2。

あなたの最良のオプションは、GCC 4.0への切り替えに_GLIBCXX_DEBUGかをドロップするように見えます。

Answer 2

これは Apple のバグのように思えます libstdc++, 少なくともデバッグモードでコンパイルした場合は。上記で指定した 2 行の削減をコンパイルすると、次のようになります。

#include <iostream>
#include <string>

using namespace std;

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

  return 0;
}

次のコマンド ラインを使用します (C++ プロジェクトのデバッグ ビルドに対する Xcode のデフォルト設定から取得した定義を使用します)。

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

これは私にとって非常にバグのように思えます。いくつかの標準ライブラリ関数を可能な限り単純な方法で使用しているため、アサーションの失敗が発生しています。

この時点で、プロプライエタリなソフトウェア (Apple のソフトウェアの多くはこれに該当しますが、幸いなことに、 libstdc++ フリーソフトウェアです）、諦めるしかありません。 ベンダーにバグレポートを提出する, 、回避策を見つけてください。幸いなことに、これは無料ソフトウェアなので、根本原因を調査できます。残念ながら、現時点では根本原因を突き止める時間がありませんが、 ソースは利用可能です 閲覧用に。

おそらくそうすべきです これについてバグを報告してください. 。この場合の回避策は、_GLIBCXX_DEBUG=1 定義 (おそらく _GLIBCXX_DEBUG_PEDANTIC=1 も) を削除することです。Xcode でこれを行うには、ターゲットを見つけてビルドする実行可能ファイルをダブルクリックし、[ビルド] タブに移動して、設定が [デバッグ] に設定されていることを確認し、下にスクロールします。 GCC 4.2 - 前処理 セクションから 2 つの値を削除します。 プリプロセッサマクロ ライン。この方法では、コードがビルドされて実行され、この場合は機能するように見えますが、標準ライブラリのデバッグ ビルドでキャッチできた可能性のあるアサーションが少なくなります。