malloc - c++ segmentation fault in string assignment -

malloc - c++ segmentation fault in string assignment -

need help understand how assignment of strings below causing segmentation fault in process. note random , same data-set giving core dump , other times not. failure observed while processing multiple files. while processing single file there no failure. process flow - read input file(some format) - process per record - prepare output file (new format)

i verified input info beingness processed code fine - instances fails. hence looks allocation/assignment in code causing core dump (segmentation fault)

please suggest. thanks.

code shown below:

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 = ""; homecoming 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) { homecoming -1; } m_currrecord->init(); // init m_currrecord before parsing 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 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 }

the stack of core dump seem dbx tool (solaris system) below

current thread: t@1 [1] realfree(0x1008d85d0, 0xffffffff76db6f78, 0xffffffff7ffe8daf, 0xad, 0x100067024, 0x1001cf450), @ 0xffffffff76c4f5e0 [2] cleanfree(0x0, 0x1008d8c30, 0x60, 0x0, 0x0, 0x0), @ 0xffffffff76c4fedc [3] _malloc_unlocked(0x3b, 0x0, 0x0, 0x2, 0x2, 0x1), @ 0xffffffff76c4efbc [4] malloc(0x3b, 0xff000000, 0x0, 0x0, 0xfffffc00, 0xffffffff), @ 0xffffffff76c4ee94 [5] operator new(0x3b, 0x0, 0x0, 0x1, 0x1, 0x400), @ 0xffffffff795ef2e4 [6] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getrep(0xffffffff7ffe7cb0, 0x9, 0x9, 0x123a54, 0x81010100, 0xff00), @ 0xffffffff7ae761ec [7] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(0xffffffff7ffe7cb0, 0xffffffff7ffe7d1e, 0xffffffff7ffe7caf, 0x3030303030300a, 0x100067024, 0x1001cf450), @ 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"

one potential cause might strcpy(str,i_rec). practice utilize strncpy rather strcpy.

c++ malloc new-operator stdstring