How to debug segmentation fault? What are the best practices to avoid segmentation faults in the code?


  • 2
    A

    How to debug segmentation fault? What are the best practices to avoid segmentation faults in the code?


  • 0
    V
    This post is deleted!

  • 0
    C

    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


  • 1
    E

    segment fault will occurs if there is one global variable shared among multiple threads.


  • 2
    A

    @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.


  • 1
    D

    @eqifzha Wrong, data race may occur but not segfault!


  • 2
    X

    use gdb, backtrace.

    Avoid: check reference of null memory.


  • 2
    K

    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
    • avoid:
      1. assert() before dereferencing suspective pointers, mainly pointers embedded in structs that are maintained in containers in lists and arrays.
      2. always remember to initialize pointers properly.
      3. protect global/shared variables from concurrent threads with mutex,semaphore(avoid shared access if possible).
      4. do free()s carefully, maybe with proper refcount on objects(also set NULL after free()).

  • 0
    B

    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.


  • 0
    E

    @kekakake , very good summary. One question: how the third item using mutex can avoid segmentation fault?


  • 0
    C

    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.


  • 0
    G

    http://www.cnblogs.com/no7dw/archive/2013/02/20/2918372.html

    I find this essay to explain more detailed.


  • 0
    S

    gdb is your friend


Log in to reply
 

Looks like your connection to LeetCode Discuss was lost, please wait while we try to reconnect.