问题
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:
- It occurs only when the program is in release mode, not in debug.
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) bt0 0xb0328af8 in _list_release () from /usr/qnx650/target/qnx6/x86/lib/libc.so.31 0xb032a464 in __free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.32 0xb0329f7d in free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3I am not using any dynamic memory (except for what might appear in Eigen (or other libraries)
- 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:
- This would be extra useful: How can I force this error in Debug mode, then GDB would be way more helpful.
- 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.
回答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.
来源:https://stackoverflow.com/questions/14190767/identify-variable-causing-memory-error