CODEWITHSUNDEEP
c++memory-managementcrash
klm123
klm123

Reputation: 12885

Crash before main()

My program crashes before main() function. I determine this using "cerr":

int main(int argc, char **argv)
{
  cerr << " MAAIN " << endl;

The message from gdb:

   Reading symbols for shared libraries ...........+++............................ done
CA(34652) malloc: *** error for object 0x7fff76694860: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff88e1782a in __kill ()
(gdb) bt
#0  0x00007fff88e1782a in __kill ()
#1  0x00007fff8c4d2a9c in abort ()
#2  0x00007fff8c53184c in free ()
#3  0x00000001026a1db0 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
(gdb)

I have checked the code for "delete" and "free" functions. All deletes are done with check like this:

if (x) delete x;

Please help me with answering two questions: 1. What can be the possible problem? 2. How to find it? (I have a big code with a lot of files and cmake for compilation).

P.S. I read Is there any way a C/C++ program can crash before main()? but looking at gdb massage I suppose libraries are ok.

Upvotes: 1

Views: 1575

Answers (2)

Mats Petersson
Mats Petersson

Reputation: 129454

std::basic_stringbuf<char, std::char_traits<char>... tells me that it's std::string that is going wrong. One quite possible scenario is that you have something that is trying to "free" a string, that hasn't been constructed correctly or that has been overwritten by uncareful use of arrays.

Or you are relying on some global variables in different source files, so you have something like this:

 // main.cpp:

 ... 
 extern string str;  // str lives in another .cpp file
 .... 
 myclass x(str);   // Construction using str. 

 // otherfile.cpp
 string str("foobar");

In this case, str may not be constructed by the time x is being constructed, and the string is "invalid".

There are oodles of other possibilities along similar lines.

The address here: 0x7fff76694860 is on the stack. If it's always the same value, you could try to track down where it is.

Upvotes: 1

Hossein Nasr
Hossein Nasr

Reputation: 1458

cout is not a good way to check where your program is crashing because cout does not immediately flush its buffer and it is possible that you programs crashes after cout but before flushing buffer. it's better to check it with cerr instead of cout

And before main function, constructors of global variables will call. so take look at them if you think it crashes before start.

an other possibility is allocating memory for arrays in you main function that happens before calling of main function. if they are huge. you must use new to allocate memory for them.

Upvotes: 2

Related Questions