2015-04-13 1 views
0

Besoin d'aide pour comprendre comment l'affectation des chaînes ci-dessous provoque un défaut de segmentation dans le processus. Notez qu'il est très aléatoire et que le même ensemble de données donne parfois des vidages de mémoire et d'autres non. Une erreur est observée lors du traitement de plusieurs fichiers. Lors du traitement d'un seul fichier, il n'y a pas d'échec. Flux de processus est - lire le fichier d'entrée (un certain format) - traiter par enregistrement - préparer le fichier de sortie (nouveau format)Défaut de segmentation C++ dans l'affectation de chaîne

J'ai vérifié que les données d'entrée traitées par le code sont correctes - pour les instances, il échoue. Par conséquent, il semble que certaines affectations/affectations dans le code puissent provoquer le vidage de l'unité centrale (erreur de segmentation)

Veuillez suggérer. Merci.

code est indiqué ci-dessous:

class RecordHolder 
{ 
public: 
    RecordHolder(); 
    ~RecordHolder(){} 
    bool init(); 
    void setRecordType(char i_recordType)   { m_recordType = i_recordType; } 
    **void setSomeID(string i_someID)   { m_someID = i_someID.c_str(); }** 
private: 
    char m_recordType; 
    string m_someID; 
}; 

bool RecordHolder::init() { m_recordType = NULL; m_someID = ""; return true; } 

int SomeClass::parseRecord(const char* i_rec) 
{ 
    char* pToken; 
    int tokenCounter; 
    char str[RECORD_SIZE]; 

    strcpy(str,i_rec); 
    pToken = strtok(str, RECORD_FIELDS_DELIMETER); 
    if (!pToken) 
    { 
     return -1; 
    } 
    m_currRecord->init(); // init the m_currRecord before parsing the record 
    tokenCounter = 0; 
    while((pToken != NULL) || (tokenCounter < NUMBER_OF_FILEDS)) 
    { 
     tokenCounter++; 
     if (pToken) 
      switch(tokenCounter) 
      { 
       case 1: 
        m_currRecord->setRecordType(*pToken); 
        break; 
       case 2: 
        **//Process crashes with SEGMENTATION FAULT here randomly** 
        m_currRecord->setsomeID(pToken); 
        break; 
       default: 
        break; 
      } // End of switch section. 
     pToken = strtok(NULL, RECORD_FIELDS_DELIMETER); 
    } // End of while loop 
} 

La pile de la décharge de base comme semblent de l'outil dbx (système solaris) est inférieure à

current thread: [email protected] 
    [1] realfree(0x1008d85d0, 0xffffffff76db6f78, 0xffffffff7ffe8daf, 0xad, 0x100067024, 0x1001cf450), at 0xffffffff76c4f5e0 
    [2] cleanfree(0x0, 0x1008d8c30, 0x60, 0x0, 0x0, 0x0), at 0xffffffff76c4fedc 
    [3] _malloc_unlocked(0x3b, 0x0, 0x0, 0x2, 0x2, 0x1), at 0xffffffff76c4efbc 
    [4] malloc(0x3b, 0xff000000, 0x0, 0x0, 0xfffffc00, 0xffffffff), at 0xffffffff76c4ee94 
    [5] operator new(0x3b, 0x0, 0x0, 0x1, 0x1, 0x400), at 0xffffffff795ef2e4 
    [6] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(0xffffffff7ffe7cb0, 0x9, 0x9, 0x123a54, 0x81010100, 0xff00), at 0xffffffff7ae761ec 
    [7] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(0xffffffff7ffe7cb0, 0xffffffff7ffe7d1e, 0xffffffff7ffe7caf, 0x3030303030300a, 0x100067024, 0x1001cf450), at 0xffffffff7ae70844 
=>[8] SomeClass::parseRecord(this = 0xffffffff7ffe9448, i_rec = 0xffffffff7ffe86b3 "D|088888888|601251194|........|K     |00000.000000\n"), line 492 in "SomeClass.cpp" 
    [9] SomeClass::processSorted(this = 0xffffffff7ffe9448), line 632 in "SomeClass.cpp" 
    [10] SomeClass::processFile(this = 0xffffffff7ffe9448), line 210 in "SomeClass.cpp" 
+0

'char str [RECORD_SIZE];' cela pourrait poser problème ici. Assurez-vous que cela se termine par ''\ 0''. Avec cela assurez-vous que la taille de 'str' est> =' strlen (i_rec) + 1' – Jagannath

+0

'c_str()' résultat peut être invalidé par d'autres appels de votre besoin de dupliquer le résultat –

Répondre

0

Une cause potentielle pourrait être strcpy (str, i_rec). C'est une bonne pratique d'utiliser strncpy plutôt que strcpy.

+0

Non, ce n'est pas le cas. Voir http://the-flat-trantor-society.blogspot.de/2012/03/no-strncpy-is-not-safer-strcpy.html et https://randomascii.wordpress.com/2013/04/03/stop-using-strncpy-already/ – cremno

+0

Essayé en utilisant strncpy - toujours échouer au même endroit. – zuma09