Visual studio to gcc, code compiles well in gcc but gives std::badalloc error at runtime

Question

I have a big code that uses only standard C++ libs and compiles well in gcc. As the code was actually written in VS C++ 6.0. The code runs fine in visual studio but when I use gcc compiler it gives no errors on compilation and when I run it it gives this error "terminate called after throwing an exception at instance std::bad_alloc what() bad alloc" One more confusion is that it is a numerical simulation code, it doesn't show any exception while using gdb debugging and terminates successfully but doesn't show the right results. But using gdb it doesn't terminates anywhere. So thats where I am stuck. I am unable to diagnose where does the bad_alloc is actually happening.

1. The code consists of C and C++ routines
2. Memory is allocated through new
3. gdb doesn't show any segabort or any exception during debugging

How can I debug this problem?

Answer 1

VC++ 6.0 is not exactly standards compliant. The upgrade of the compiler (to a newer version) will catch previously unseen errors.

There are three things you can do:

• Get are core dump from the unix version (I'm assuming you're using using gcc on a variant of unix), and then use gdb in a post-mortem manner to see where exactly the exception is triggered.

• Use a more recent version of Visual C++ (For example free Express 2010 edition) to check the software

• Rewrite your allocations to be more robust. i.e.: check for null values. Also you might override the new operator to do this globally.

Answer 2

If you're on Linux, give valgrind a try for debugging.

Answer 3

An exception object, even std::bad_alloc, is still an object and needs to be constructed before it can be thrown. Hence, a breakpoint on std::bad_alloc::bad_alloc will break execution before it's thrown.

Answer 4

Exceptions are meant to identify runtime errors, so the fact that the code compiles and then throws an exception at runtime is perfectly reasonable. std::bad_alloc means that you're running out of memory.

However, tracking down why you're running out of memory is the hard thing. I recently worked on some code that hadn't been updated since Visual C++ 6 and it turns out had a serious bug due to Visual C++ 6's nonstandard treatment of code. The problem was basically:

long foo(int i)
{
    return foo(long(i));
}

long foo(long& l)
{
   return l * 100;
}

This is syntactically correct code. However, Visual C++ 6 does something wrong here: it interprets the call foo(long(i)) as calling long foo(long& l). This is incorrect. The expression long(i) creates a temporary object and temporary objects cannot bind to non-const references. So, according to C++ standard method overload resolution, this simply calls long foo(int i) again and again recursively. In my case, the infinite recursion caused a stack overflow. To fix this problem, long foo(long& l) needs to be either long foo(long l) or long(const foo& l). I suspect you will find a similar problem in your code, but due to memory allocations you're getting a memory overflow before you get a stack overflow.

I fixed my problem by running Google's cpplint.py and looked for errors regarding non-cosnt references.