CODEWITHSUNDEEP
c++debuggingmemorygdbsegmentation-fault
Fantastic Mr Fox
Fantastic Mr Fox

Reputation: 33944

Identify variable causing memory error

So I have run into a weird error a few times now and im looking for some good directions as to identify the problem.

Basically what I am seeing is a seg-fault. The symptoms are as follows:

  1. It occurs only when the program is in release mode, not in debug.

  2. It appears as a segfault and GDB tells me that it is in _list_release/_free()/free() at the end of a function.

    Program received signal SIGSEGV, Segmentation fault.

    0xb0328af8 in _list_release () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

    (gdb) bt

    0 0xb0328af8 in _list_release () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

    1 0xb032a464 in __free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

    2 0xb0329f7d in free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

  3. I am not using any dynamic memory (except for what might appear in Eigen (or other libraries)

  4. I can print all local variables just before the end of the function, so its not a double free.

Last time this happened it was a memory fault which fits all of these problems. Annoyingly this time i cannot find the problem.

What i would like to do is the following:

  1. This would be extra useful: How can I force this error in Debug mode, then GDB would be way more helpful.
  2. What is the best way to track down what little bugger is causing the problem. NOTE: I cannot use valgrind, it does not work on the operating system i am using (QNX)

Any help would be great.

Upvotes: 1

Views: 948

Answers (1)

Employed Russian
Employed Russian

Reputation: 213957

It appears as a segfault and GDB tells me that it is in _list_release/_free()/free()

Generally, any crash in free() is a sign of heap corruption (a double free, a write to free'd memory, freeing unallocated (e.g. stack or global) memory, or an overflow of a heap buffer).

I am not using any dynamic memory

Yes, you are. The fact that you do so indirectly via other libraries is irrelevant.

I can print all local variables just before the end of the function, so its not a double free.

As many commenters already said, your conclusion doesn't follow: you can access free'd memory just fine, and it may even still contain sensible values.

How can I force this error in Debug mode, then GDB would be way more helpful.

  • You can build with '-O2 -g' (a "release" mode but with debug info enabled).
  • GDB will likely not be more helpful -- GDB is somewhat useless in debugging heap corruption.

What is the best way to track down what little bugger

You have a few choices:

  • Port your code to a platform where you can use Valgrind or AddressSanitizer
  • Use one of many debugging malloc implementations (dmalloc, mpatrol, etc.). QNX has one.
  • Read the code very carefully, making sure that you don't write more data to possibly-malloc'd buffers than you are supposed to.

Upvotes: 4

Related Questions