Home > Enterprise >  How to automatically, and non-interactively, get where in the source code a segmentation fault is tr
How to automatically, and non-interactively, get where in the source code a segmentation fault is tr

Time:04-15

I am working on an automated testing tool which has found bugs that are usually manifested as segmentation faults. I am trying to find out how many of these detected bugs are unique. Uniqueness is a special term used in my study: If two segmentation faults are triggered by different statements, the two are considered different. My current approach to tell if two segmentation faults are triggered by different statements or not is to use GDB. For example:

(gdb) r

Program received signal SIGSEGV, Segmentation fault.
0x00007f050c9efac2 in gsl_stats_quantile_from_sorted_data (sorted_data=sorted_data@entry=0x7fffe1477c40, stride=stride@entry=1,
    n=n@entry=5, f=675) at quantiles_source.c:37
37        result = sorted_data[lhs * stride]

As you can see, GDB stops at where the segmentation fault arises (line 37 of the C program quantiles_source.c as shown above). I am wondering how to get that piece of information by a command line or script, non-interactively?

CodePudding user response:

You can run gdb non-interactive on the binary by executing the commands specified in file with -x file, or you can specify a command with -ex command (used multiple times if needed). In either case when combined with --batch it subsequently exit. Another option configure your shell to allow a core file to dumped with ulimit -c ulimited then run gdb on the binary and resulting core file using the arguments mentioned above.

  • Related