Question

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.

Answer 1

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.