core dump in malloc

user_9290802 0
Viewed 575

I am observing a core dump in libc.so with below stack trace.

#6271 0xb8df in raise () from /lib64/libc.so.6
#6272 0x5cf5 in abort () from /lib64/libc.so.6
#6273 0xec17 in __libc_message () from /lib64/libc.so.6
#6274 0x553c in malloc_printerr () from /lib64/libc.so.6
#6275 0x83cc in _int_malloc () from /lib64/libc.so.6
#6276 0x9937 in malloc () from /lib64/libc.so.6
#6277 0x9dff in jsonp_malloc () from jansson
#6278 0xce06 in json_array () from jansson
#6279 0x9555 in parse_value () from jansson
#6280 0x9484 in parse_value () from jansson
#6281 0x9484 in parse_value () from jansson
#6282 0x9739 in parse_json () from jansson
#6283 0x9d88 in json_loads () from jansson

Can someone help me on how should I proceed with troubleshooting? or any kind of suspects what is going wrong?

malloc coredump unix
1 Answers

I am observing a core dump in libc.so with below stack trace.

The malloc_printerr probably printed some error message on stderr, such as double-free detected or some such.

Regardless, this crash is the result of malloc detecting some kind of heap corruption (overflowing a heap buffer, freeing unallocated memory, freeing something twice, etc. etc.)

These kinds of bugs are nearly impossible to debug with a core dump, because they often happen much later in the execution, sometimes in completely unrelated code.

Fortunately, specialized tools often make finding these bugs very easy.

You should start by building the application with gcc -fsanitize=address ... and running through your test suite. If you are lucky, this will expose the bug.

Another tool which can help (doesn't require rebuilding, but catches fewer bugs) is Valgrind.

Employed_Russian_506170
Related