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.
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? –
est-ce l'exemple entier? ça fonctionne bien pour moi (Mingw g ++ sur Windows) –
Oui. Cela fonctionne aussi bien pour moi. Je suis juste confus quant à pourquoi je reçois l'erreur. –