Xcode STL C ++ Отладочная ошибка компиляции - PullRequest
4 голосов
/ 26 декабря 2009

У меня есть код для записи в файл, который работает, как и ожидалось, но печатает ошибку в режиме отладки, в выпуске ошибок нет.

Код:

#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

Ответы [ 2 ]

6 голосов
/ 26 декабря 2009

Это выглядит для меня как ошибка в libstdc++ от Apple, по крайней мере при компиляции в режиме отладки. Если я скомпилирую приведенное выше сокращение на две строки:

#include <iostream>
#include <string>

using namespace std;

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

  return 0;
}

Со следующей командной строкой (с определениями, взятыми из настроек по умолчанию Xcode для сборки Debug в проекте 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

Это ужасно похоже на ошибку для меня. Мы используем некоторые стандартные библиотечные функции самым простым способом и пытаемся выполнить утверждение.

На этом этапе, если бы мы использовали проприетарное программное обеспечение (которое является частью программного обеспечения Apple, но, к счастью, libstdc++ бесплатное программное обеспечение), нам пришлось бы отказаться, подать отчет об ошибке нашему поставщику и попробуйте найти обходной путь. К счастью, это бесплатное программное обеспечение, поэтому мы можем выяснить причину. К сожалению, на данный момент у меня нет времени, чтобы отследить это до первопричины, но источник доступен для просмотра .

Возможно, вам следует сообщить об ошибке . Обходной путь в этом случае должен был бы удалить определение _GLIBCXX_DEBUG = 1 (и, вероятно, _GLIBCXX_DEBUG_PEDANTIC = 1 также). Вы можете сделать это в Xcode, найдя свою цель, дважды щелкнув исполняемый файл, который она собирает, перейдя на вкладку сборки, убедившись, что конфигурация настроена на отладку, прокрутив вниз до раздела GCC 4.2 - Preprocessing , и удаление двух значений из строки Macro Preprocessor Macros . Таким образом, код будет собираться и запускаться, и, похоже, в этом случае будет работать, но вы получите меньше утверждений, что отладочная сборка стандартной библиотеки могла бы перехватить.

5 голосов
/ 26 декабря 2009

Это выглядит как еще один случай, когда _GLIBCXX_DEBUG был сломан с gcc 4.2 в Mac OS X .

Ваш лучший вариант - сбросить _GLIBCXX_DEBUG или перейти на gcc 4.0.

...