"Segmentation fault"

This is a discussion on "Segmentation fault" within the C Programming forums, part of the General Programming Boards category; Hi, I was wondering if there is a way for the debugger GDB or complier GCC to show where the ...

  1. #1
    Registered User
    Join Date
    Jan 2009
    Posts
    159

    "Segmentation fault"

    Hi,
    I was wondering if there is a way for the debugger GDB or complier GCC to show where the mistake actually happen instead of showing runtime error "Segmentation fault" at somewhere far downstream from the mistake?
    For example, mistakes like array index exceeding its range, overflow, etc. Thanks!
    Last edited by lehe; 03-31-2009 at 10:54 AM.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    You can't get gdb to tell you WHY it segfaulted, but you should be able to see where it went wrong with "bt" - which will list function name, line number and filename. Of course, where it goes wrong is not necessarily where the fault was CAUSED - if you store a bad index in a struct, and use the index some time later, it's obviously not the code USING the value that is at fault, but the code that stuffed the bad value into the struct that is to be fixed.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Jan 2009
    Posts
    159
    Thanks!
    But how do you tell where it actually goes wrong by examing the place giving segfault? I would check the whole code, try to increasingly comment code from that place till no error happen. But sometimes the mistake exists without run time segdefault error.
    Also I tried GDB "set check range on" to set range checking on , it seems not give any info.
    Last edited by lehe; 03-31-2009 at 11:18 AM.

  4. #4
    Registered User
    Join Date
    Mar 2009
    Posts
    20
    On linux there is a tool called Valgrind with valkyrie as gui which has memcheck. It saved my life!!!!I was searching faults about weeks, using this program i found more mistakes than i expected. I don't know on what platform you work or if Valgring has a windows version. i hope to helped you a little bit

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Finding the actual source of a bug is 95% of fixing bugs (the other 5% is 1% writing new code to cope with the situation in some way or antoher and 4% making sure you haven't broken something else in the process).

    That's why good design helps isolate & identify bugs "early", rather than having to find them LONG after it went wrong. For example, if you have a function that stuffs a value that should be in a certain range into some struct, that later on will be used as an index into an array, you check when you stuff it into the struct that it is in the valid range.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Registered User
    Join Date
    Apr 2009
    Posts
    2

    reverse debugging

    Lehe,

    You've highlighted one of the hardest kinds of bugs to analyze .. one where the failure (the seg fault) is "far" from the error (the actual bug).

    One of the most effective techniques for tracking down this kind of error is to use reverse debugging. No, that doesn't mean putting bugs into your code.

    There are ways, using debuggers, to record and then deterministically replay the execution of your program. With that kind of technology you can run the program right to the failure .. examine the segfault and then work your way back earlier and earlier into the program execution to find your error.

    Why is this better than just stepping forward through the program with a debugger? It is better because A. it may be that the error is closer to the failure than the start and B. there are often clues in crash that you can use.

    For example if you step a few instructions back from your segfault and see that when it crashed your program was trying to dereference a pointer that somehow got corrupted and has a "garbage" value that is a perfect clue. One of my favorite techniques is to note the address of the variable .. then jump back a "good way" in the execution history to find a place where the pointer had a "valid" value. Then I take advantage of hindsight being 20/20 and set a debugger watchpoint on the specific address of the pointer (I want the address of the pointer itself, not the address that the pointer points to).

    Then I can run my program forward and the debugger will stop it each time the pointer is changed .. regardless of who or why the value is changing. Often in one or two clicks I'm looking at the spot where the error occurred.

    Then I can step forwards and back over the error to see why it occurred.

    I believe there is some early experimental support in GDB for this .. though my understanding is that it slows your program down by many orders of magnitude.

    My company, TotalView Technologies, as a mature solution for reverse debugging on linux systems called ReplayEngine. See

    Video tutorials for TotalView, MemoryScape and ReplayEngine

    for a 5 minute video showing the tool and

    ReplayEngine - Linux Reverse Debugger. Record and Replay Race Conditions and Deadlocks | TotalView Technologies

    for more info. Feel free to email me at

    chris.gottbrath (you can figure out the domain name from the web address) if there is any info I can provide.

    Best of luck with your troubleshooting.

    Cheers,
    Chris
    Last edited by ChrisGTVTech; 04-10-2009 at 09:38 AM. Reason: typo

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem with a function ("Segmentation fault")
    By kinghajj in forum C Programming
    Replies: 6
    Last Post: 02-21-2004, 01:31 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21