Segmentation fault en fonction de la longueur de chaîne?

Question

Je suis en train d'écrire un programme qui va lire des lignes à partir d'un infile à l'aide getline en chaînes, convertir les chaînes c-chaînes contenant les premiers caractères m nonwhitespace de la chaîne, puis la concaténer les c-strings en un seul tableau de caractères.

Un exemple de fichier pourrait ressembler à ceci:

5    //number of rows and columns in a grid
2    //number of grids
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

Je finirais avec un tableau de caractères de caractères 2x5x5. Maintenant, le problème est mon code fonctionne très bien sur les cas de test plus petits comme celui ci-dessus, mais des erreurs de segmentation quand je l'essayer sur de plus grands réseaux (à savoir 100x100x100).

#include <iostream>
#include <string>
using namespace std;
int main(){
  int mapsize,levels;
  cin>>mapsize;
  cin>>levels;
  char map[mapsize*mapsize*levels];
  string input;
  for (int i=0;i<levels;i++){
    for (int j=0;j<mapsize;j++){
      getline(cin,input);
      char *row;
      row=new char[input.size()+1];
      strcpy(row, input.c_str());
      for (int k=0;k<mapsize;k++){
        map[i*mapsize*mapsize+j*mapsize+k]=row[k];
      }
      delete [] row;
    }
  }
return 0;
}

Je dirais que ce programme avec un infile: ./program

J'ai couru à l'aide de gdb et fait backtrace. Il pointe toujours à la ligne « entrée de chaîne; »

Toutes les idées comment je peux résoudre ce segfault? Merci

Answer 1

map est un VLA, alloué sur la pile, donc je suppose que votre problème est que vous obtenez un débordement de pile. gdb fait une construction de input parce que c'est la première chose qui se construit sur ce débordement de pile.

Answer 2

Je ne sais pas pourquoi le backtrace pointe vers string input; mais quand vous copiez row dans map. si Mapsize est plus grande que la taille de la ligne, vous pourriez bien finir par seg-formation de failles. Ce sera plus fréquent pour un plus grand Mapsize.

vous aussi peut-être piétiner sur les adresses de retour sur la pile qui pourrait être à l'origine du noyau dump « mal ».