Thread: Identify the statement causing an abend

  1. #1
    Registered User
    Join Date
    Jul 2020
    Posts
    47

    Identify the statement causing an abend

    Hello,

    Is there a way that I can configure GCC to report the line nunber when an abend occurs?

    In a recent debugging session, I was intermittently receiving an abend. Yet when I executed using the debugger the abend wasn't occurring.

    Eventually by commenting various functions I was able to narrow down where the issue was coming from.

    But I'm wondering is there a way that I can configure GCC to report the line number that caused the abend?

    Or is this something that is IDE specific (i.e. I need to investigate if there is some option for my IDE - CodeBlocks BTW)

    Thanks

    VW

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    I believe the usual approach is indeed to use a debugger, then set breakpoints until you reach one and then the program crashes.

    If the problem doesn't manifest when you run the program in a debugger, then another approach is logging, which is a bit of "printf-style debugging" except that you write to a log file that you can later examine to trace program execution. Unfortunately, it is also sometimes possible that the addition of logging causes the problem to "disappear", even though you didn't actually fix the problem. Such is the nature of undefined behaviour, after all.

    Having a suite of unit tests and integration tests can help too: again it isn't foolproof, but there's a chance the problem might be discovered by a test failure.

    As for "configure GCC to report the line number that caused the abend": you're only compiling (or building) the program with gcc, i.e., unlike a debugger gcc isn't monitoring the execution of your program, so it has no way to report any sort of line number other than by code you wrote to report line numbers (i.e., logging).

    Also, remember that while a crash may have happened right after a certain statement, the actual mistake may have been made further up.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    When I get runtime crashes that go away when using the debugger, about an quarter of the time I failed to initiate a pointer variable to NULL.

    Tim S.
    "...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well if you're on Linux/Unix, you can do this.
    Code:
    #include <stdio.h>
    #include <stdlib.h>
    
    int main()
    {
      char *p = NULL;
      printf("trouble ahead\n");
      *p = '\0';
      return 0;
    }
    Instead of running in the debugger directly, just run it normally, then post-mortem using gdb and the core file.
    Code:
    $ # set unlimited core dump size
    $ ulimit -c unlimited
    $ ulimit -a
    core file size          (blocks, -c) unlimited
    ...
    $ # compile with debug
    $ gcc -g foo.c
    $ ./a.out 
    trouble ahead
    Segmentation fault (core dumped)
    $
    $ # load into debugger to see why
    $ gdb -q a.out core
    Reading symbols from a.out...done.
    [New LWP 4947]
    Core was generated by `./a.out'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0x0000000000400544 in main () at foo.c:8
    8	  *p = '\0';
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. printf statement causing while loop to never end
    By pbyrne98 in forum C Programming
    Replies: 3
    Last Post: 05-31-2017, 06:40 PM
  2. Replies: 11
    Last Post: 06-10-2011, 01:17 PM
  3. can you identify this car?
    By axon in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 07-19-2004, 02:59 PM
  4. continue statement causing an unexpected error
    By drb2k2 in forum C++ Programming
    Replies: 2
    Last Post: 04-15-2003, 06:46 AM

Tags for this Thread