free and abort

J

jois.de.vivre

I have some code that, after some time, crashes with an abort signal
(signal 6). Upon examining the core dump it would seem that the
signal originates at free(). I have read the documentation but I
cannot find anything that talks about free() ever throwing a signal.
Is this non-standard behavior from gcc?
 
B

Ben Pfaff

I have some code that, after some time, crashes with an abort signal
(signal 6). Upon examining the core dump it would seem that the
signal originates at free(). I have read the documentation but I
cannot find anything that talks about free() ever throwing a signal.

Probably, your code yields undefined behavior by overwriting some
of the bookkeeping data that malloc and related functions
maintain. Look carefully through your code to check that it does
not write beyond the boundaries of allocated data blocks, or try
using a memory debugger such as Valgrind.
Is this non-standard behavior from gcc?

GCC doesn't implement the standard C library; that's left to
external software, such as glibc. But it's not unusual for a C
library to abort when its bookkeeping data becomes corrupted.
 
T

Tor Rustad

I have some code that, after some time, crashes with an abort signal
(signal 6). Upon examining the core dump it would seem that the
signal originates at free(). I have read the documentation but I
cannot find anything that talks about free() ever throwing a signal.

My guess would be that you somewhere call free() with invalid input, that
invoke UB, in that case the implementation is free to do whatever it wants.

I support Ben's advice, by using a tool, such as valgrind or eletric fence.
 
A

Al Balmer

I have some code that, after some time, crashes with an abort signal
(signal 6). Upon examining the core dump it would seem that the
signal originates at free(). I have read the documentation but I
cannot find anything that talks about free() ever throwing a signal.
Is this non-standard behavior from gcc?

Well, it's not Standard behavior <g>. You're probably passing free()
an address which doesn't point to an allocated block. First guess -
you're freeing the same pointer twice.
 
M

Malcolm McLean

I have some code that, after some time, crashes with an abort signal
(signal 6). Upon examining the core dump it would seem that the
signal originates at free(). I have read the documentation but I
cannot find anything that talks about free() ever throwing a signal.
Is this non-standard behavior from gcc?
What tends to happen is that you corrupt some memory allocated by malloc(),
and the sytem detects it at the point where you call free().
Once you have ordered an illegal operation, as far as the standard is
concerned the rest of the program's behaviour is completely undefined. This
includes a distantly-related free() throwing a signal.
 
J

Joachim Schmitz

I have some code that, after some time, crashes with an abort signal
(signal 6). Upon examining the core dump it would seem that the
signal originates at free(). I have read the documentation but I
cannot find anything that talks about free() ever throwing a signal.
Is this non-standard behavior from gcc?
most likely you pass something to free() that hadn't been returned from
[cm]alloc() or you called free() twice with the same parameter.

Bye, Jojo
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top