interpreting gdb segmentation fault

Question

I have googled, froogled, moogled and doogled :-(

raspian

If I run my program under gdb I get:

(gdb) run
Starting program: /home/pi/axcept/a 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-
gnueabihf/libthread_db.so.1".
axcept v:1.0 20170710
running
[New Thread 0x768e3450 (LWP 6671)]
[Thread 0x768e3450 (LWP 6671) exited]
*** Error in `/home/pi/axcept/a': double free or corruption (out): 
0x00025178 ***

Program received signal SIGABRT, Aborted.
0x76a1af70 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or 
directory.
(gdb) where
#0  0x76a1af70 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x76a1c324 in __GI_abort () at abort.c:89
#2  0x76a56954 in __libc_message (do_abort=<optimized out>, 
fmt=0x76b0c6e8 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x76a5cb80 in malloc_printerr (action=1, str=0x76b0c860 "double 
free or corruption (out)", ptr=<optimized out>) at malloc.c:4996
#4  0x76a5db24 in _int_free (av=<optimized out>, p=<optimized out>, 
have_lock=1992996040) at malloc.c:3840
#5  0x76a7d72c in tzset_internal (always=0, explicit=1991424272) at 
tzset.c:443
#6  0x76a7db5c in __tz_convert (timer=0x7efff1e0, use_localtime=1, 
tp=0x76b2d2cc <_tmbuf>) at tzset.c:632
#7  0x00011190 in get_today () at today.c:17
#8  0x00012f14 in main (argc=1, argv=0x7efff374) at axcept.c:333
(gdb) list
51  in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb)

in axcept.c around 333 I have:

...
initialise_db();
read_parameters(0);
get_today();
....

but both read_parameters and get_today are more or less stolen from official gnu examples.

from my makefile:

CC=gcc 
CCFLAGS=  -fgnu89-inline -g -v -da -Q -std=c99 -I/usr/local/include -
L/usr/local/lib -lwiringPi -I/usr/include/mysql/ -I/home/pi/logging/  
`mysql_config --cflags --libs` -lwiringPi -lwiringPiDev -lpthread -lm 
-lcrypt -lrt

I have tried valgrind -v --track-origins=yes myprog, but it leaves me no wiser.

Now punch drunk!

double free or corruption means that you're `free`ing something twice, or that somewhere something overwrote the bookkeeping outside the `malloc`ated object. The problem can manifest itself later. `valgrind` should be the solution... — Antti Haapala -- Слава Україні, Jul 17 '17 at 06:10
Bad choice of code sample. What's going on at today.c:17 seems to be more helpful than axcept.c:333. I always start debugging by the innermost call I have. — flaviodesousa, Jul 17 '17 at 06:12

score 3 · Answer 1 · answered Jul 17 '17 at 06:16

Double free or corruption means that you're freeing something twice, or that somewhere something overwrote the bookkeeping outside the mallocated object. The problem can manifest itself later - here it is malloc that noticed the problem, so the actual heap corruption occurs before.

If valgrind doesn't seem to help (well, it should), try if you can replicate this bug by replacing the get_today() call with a useless malloc for example; if it works, then you can try to trace it in the code by moving and removing parts of the code until you will have a MCVE (which probably will resolve by itself).

Got it! I was suffering an array out of bounds in read_parameters(). Thanks a lot everyone. — tangent, Jul 19 '17 at 04:27

interpreting gdb segmentation fault

1 Answers1