2009-12-26 9 views
4

J'ai un certain code d'écriture de fichier qui fonctionne comme prévu, mais imprime une erreur en mode débogage, pas d'erreurs de sortie dans la version.Xcode STL Erreur de compilation de débogage C++ C

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

sortie de débogage:

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 

Sortie de sortie:

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

En dehors de n ot vérifier que le descripteur de fichier est ouvert (pour plus de simplicité) qu'est-ce qui ne va pas avec ce code?

Mise à jour: je me suis cassé le code jusqu'à ce qui suit et il encore des erreurs:

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

Je suppose qu'il y a plus que ce que vous décrivez ici, le code semble bien (mais mal formaté). Vous pourriez mentionner spécifiquement quelle version du compilateur vous utilisez. Je suppose que tu n'as pas essayé de mettre un break sur malloc_error_break? –

+1

est-ce l'exemple entier? ça fonctionne bien pour moi (Mingw g ++ sur Windows) –

+0

Oui. Cela fonctionne aussi bien pour moi. Je suis juste confus quant à pourquoi je reçois l'erreur. –

Répondre

5

Cela semble être un autre cas de _GLIBCXX_DEBUG being broken with gcc 4.2 on Mac OS X.

Vos meilleures options semblent être d'abandonner _GLIBCXX_DEBUG ou de passer à gcc 4.0.

+0

Eh bien, putain. Tout ce temps pour enquêter et écrire une réponse longue et détaillée, et il arrive qu'il y ait une autre réponse ici sur SO qui dit que c'est un problème connu. Je me sens bête maintenant. –

+0

J'ai changé le compilateur dans Xcode à 4.0 et il a résolu le problème. Merci beaucoup –

6

Cela ressemble à un bug dans Apple libstdc++, au moins lorsqu'il est compilé en mode débogage. Si je compile les deux la réduction de la ligne que vous avez donné ci-dessus:

#include <iostream> 
#include <string> 

using namespace std; 

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

    return 0; 
} 

Avec la ligne de commande suivante (avec définit pris dans les paramètres par défaut de Xcode pour une version de débogage dans un C++ du projet):

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

Je obtenir la même erreur que vous avez vu:

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

cette affiche un rapport d'accident, ce qui nous donne une trace de la pile (vous pouvez également obtenir une trace de la pile du débogueur en exécutant cette sous Xcode; Je voulais juste de le reproduire dans un environnement aussi propre que possible, pour essayer d'isoler la cause, sans rien d'autre Xcode étrange pourrait faire):

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 

Cela ressemble beaucoup comme un bug pour moi. Nous utilisons des fonctions de bibliothèque standard de la manière la plus triviale possible, et en rencontrant un échec d'assertion. À ce stade, si nous utilisions un logiciel propriétaire (ce qui est le cas du logiciel d'Apple, mais heureusement libstdc++ est un logiciel libre), nous devrions abandonner, file a bug report with our vendor, et essayer de trouver une solution de contournement. Heureusement, il s'agit d'un logiciel libre, nous pouvons donc enquêter sur la cause première. Malheureusement, je n'ai pas le temps en ce moment pour suivre cela jusqu'à la cause première, mais le source is available pour la lecture. Vous devriez probablement file a bug about this. Une solution de contournement dans ce cas serait de supprimer la définition _GLIBCXX_DEBUG = 1 (et probablement le _GLIBCXX_DEBUG_PEDANTIC = 1 également). Vous pouvez le faire dans Xcode en trouvant votre cible, en double-cliquant sur l'exécutable qu'il construit, en allant dans l'onglet de construction, en vous assurant que la configuration est réglée sur Déboguer, en descendant jusqu'au GCC 4.2 - Prétraitement de la section et suppression des deux valeurs de la ligne Macros du préprocesseur. De cette façon, le code va se construire et s'exécuter, et semble fonctionner dans ce cas, mais vous obtiendrez moins d'assertions que la compilation de débogage de la bibliothèque standard pourrait avoir pu attraper.

+0

Wow merci pour une réponse aussi complète Brian. Je dois vous donner +1 –