How to debug segmentation fault? What are the best practices to avoid segmentation faults in the code?
to avoid seg fault you must access the array within its bounds or check whether u are accessing that memory which is not allocated or which is an illegal memory
sometimes p->data where p is null cause seg fault invalid control loop cause seg fault best practices are to manke an array and use it within the limits
segment fault will occurs if there is one global variable shared among multiple threads.
@andro14 There are many ways to debug the segmentation fault. This is easy to debug when the segmentation fault is reproducible. Look at the core dump file and analyze the stack frame with gdb/ddd etc. If you want to debug something in Kernel like OOPs again debugfs/dmesg/octaldump may help. I personally like attaching the JTAG to the embedded hw and put the breakpoint and look at all the stack traces, register dumps like ( PC, STACK PTR, CPU status registers ) etc.
If the crash is random you may want to look into the JTAG ETM and collect the last executed instruction sets etc. It may be related to the HW as well. In that case try changing the kernel to single core, reduced clock regime etc.
@eqifzha Wrong, data race may occur but not segfault!
Segmenfault is relatively easy to debug, but hard to avoid.
Segmenfault mostly implies null pointer or wild pointer.
- debug: core dump file & gdb; debugfs, dmesg
- assert() before dereferencing suspective pointers, mainly pointers embedded in structs that are maintained in containers in lists and arrays.
- always remember to initialize pointers properly.
- protect global/shared variables from concurrent threads with mutex,semaphore(avoid shared access if possible).
- do free()s carefully, maybe with proper refcount on objects(also set NULL after free()).
Get symbol file for the binary/kernel that got crashed and load the symbol file into gdb with the core file. If the object files are optimized, then need to analyze the disassembled code for the function of interest (refer to the stack trace). Dump the registers from the current context/stack frame and then analyze to understand what code portion is causing the segmentation fault.
In case of memory corruptions and is reproducible, if the data block that's causing the segmentation fault is identified, then move that adjust that memory block into a single page frame and mark it as read-only (you may use mprotect()). Whenever this memory block is stepped over by some thread corrupting it, that call trace can be caught and figure out the corruption sequence.
@kekakake , very good summary. One question: how the third item using mutex can avoid segmentation fault?
Start with the stacktrace. Figure out who is causing the segfault (either use the debugger or print all the variables that are involved). Now you need to find out where in your code things start going out of track. You can use a binary search technique setting a few checkpoints (could be either debugging breakpoints or print statements) until you isolate the place where the bug initiates from.
I find this essay to explain more detailed.
The easiest way to debug SEG fault is by using the core generated with GDB. One can invoke GDB like
gdb <path-to-core> <path-to-binary>
After invoking going through backtrace helps for most of the problems. In my view it is the easiest one to fix among all signals raised by kernel.
Regarding Best practices to avoid segmentation faults, testing the code with tools like Valgrind/Efence helps in catching memory over runs. Besides using tools, writing and organising code carefully helps to great extent.
Hope this helps.
This youtube tutorial is an excellent introduction to using gdb for debugging segfaults.
As far as prevention is concerned:
- Be careful with pointers. Make sure that you are not trying to access value stored in a pointer that has eventually become NULL.
- Take care of array bounds.
- printf directives should be correctly mapped to the data you are trying to print. e.g %s for *(arr) can give segfault.
Looks like your connection to LeetCode Discuss was lost, please wait while we try to reconnect.