How to debug "Abort trap: 6" error with gdb

Question

I have a C program I compile in one of two ways: "regular" and "debug".

When I run the "regular" build, I get an Abort trap: 6 error message, which I need to fix.

When I run the "debug" version within gdb, I do not get the error message and the program runs to completion.

The compilation options and flags for the "regular" build are:

BLDFLAGS = -Wall -Wextra -pedantic -std=c99
CFLAGS = -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -O3

The compilation flags for the "debug" build are:

BLDFLAGS = -Wall -Wextra -pedantic -std=c99
CDFLAGS = -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -DDEBUG=1 -g -O0 -fno-inline

The "regular" and "debug" targets are compiled like so:

regular: setup
    $(CC) $(BLDFLAGS) $(CFLAGS) -c $(SOURCE) -o $(OBJDIR)/$(PROG).o $(INCLUDES)
    $(CC) $(BLDFLAGS) $(CFLAGS) $(OBJDIR)/$(PROG).o -o $(PROG) -lpthread

debug: setup
    $(CC) $(BLDFLAGS) $(CDFLAGS) -c $(SOURCE) -o $(OBJDIR)/$(PROG).o $(INCLUDES)
    $(CC) $(BLDFLAGS) $(CDFLAGS) $(OBJDIR)/$(PROG).o -o $(PROG) -lpthread

Basically, these targets are identically processed, with the exception of the CFLAGS and CDFLAGS variables.

I could post hundreds of lines of C code, but the debug code is virtually identical to the regular code, with the exception of more verbose comments that get sent to stderr.

Is there a component of CDFLAGS (the "debug" build flags) that is preventing gdb from being able to stop processing on SIGABRT (Abort trap: 6)?

Answer 1

Is there a component of CDFLAGS (the "debug" build flags) that is preventing gdb from being able to stop processing on SIGABRT

You appear to misunderstand what's happening.

It's not that GDB is not stopping on SIGABRT. It's that your application, when compiled without optimization, does not call abort in the first place!

It is not at all uncommon for application bugs to only show up in optimized builds.

On most platforms, you can add -g to your "regular" build, run the resulting binary under GDB, and when GDB stops on SIGABRT, examine the call stack with the GDB where command.

You can do that even without -g. You should still get a stack trace, but file/line info will be missing from it.