So, I messed up and want to know why... and turns out, I have a coredump to tell me why. But the coredump tells me,

Program terminated with signal SIGABRT, Aborted
(gdb) bt
#0  0x00007f4e36c08c0c in __pthread_kill_implementation (threadid=40, signo=6, no_tid=<optimized out>) at pthread_kill.c:66
#1  0x00007f4e36bb8986 in killpg (pgrp=40, sig=40) at ../sysdeps/posix/killpg.c:28
#2  0x00007f4e36d73e90 in ?? () from /usr/lib64/libc.so.6
#3  0x00007f4e36ba27f4 in __GI_abort () at abort.c:79
#4  0x00007f4e36bfcd5e in __libc_message (action=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:156
#5  0x00007f4e36c1295c in int_mallinfo (av=0x0, m=0x8) at malloc.c:5167
#6  0x0000000000000000 in ?? ()

My code messed up malloc structs somehow, triggering a SIGABRT from libc? Frightening, but the info is insufficient to root cause anything.

So, my question is - what is the most useful next course of action here? Is there any way to wring more info from this coredump?

CodePudding user response：

My code messed up malloc structs somehow, triggering a SIGABRT from libc?

Most probably.

What to do next when you get core backtrace pointing to libc?

what is the most useful next course of action here?

Inspect your code and find a bug in your code.

Use compiler instrumentation to detect invalid code https://en.wikipedia.org/wiki/AddressSanitizer . The -fsanitize=undefined,address,pointer-compare,pointer-subtract -Wall -Wextra -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fstack-clash-protection -fstack-protector-all -fstack-protector-strong -grecord-gcc-switches -fcf-protection -Wwrite-strings -fasynchronous-unwind-tables -fexceptions -fpie -Wl,-pie is something I use. Use https://en.wikipedia.org/wiki/Valgrind . Statically check your program with https://github.com/danmar/cppcheck https://github.com/cpplint/cpplint .

Create an [MCVE] - remove your code until you find the smallest code and smallest possible actions that reproduce the problem. With that code, repost your question here in a new question, so that others can reproduce it and confirm it's not something with your environment.

Is there any way to wring more info from this coredump?

There are many introductions to gdb online, you can show registers and inspect other threads.

CodePudding user response：

bt full

will give you more information/symbols in case your binary was compiled with (-g flag), you can try that.