My program leverages gRPC, and after a stress testing, it crashed. Use gdb to debug the core dump file:
[Current thread is 1 (Thread 0x7f73ef5f1780 (LWP 147393))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f73edee542a in __GI_abort () at abort.c:89
#2 0x00005580f74da93a in gpr_malloc ()
#3 0x00005580f74e4b65 in ?? ()
#4 0x00005580f74e28d4 in grpc_exec_ctx_flush ()
#5 0x00005580f758aee1 in ?? ()
#6 0x00005580f75061b7 in grpc_pollset_work ()
#7 0x00005580f74f1c78 in ?? ()
#8 0x00005580f72ab85e in grpc::CompletionQueue::Pluck (this=0x5580f96b3698, tag=0x7fff9cafbe90)
......
I doubt the root cause should be memory is not enough, but not sure. Check the source code of gpr_malloc:
void* gpr_malloc(size_t size) {
void* p;
if (size == 0) return nullptr;
GPR_TIMER_BEGIN("gpr_malloc", 0);
p = g_alloc_functions.malloc_fn(size);
if (!p) {
abort();
}
GPR_TIMER_END("gpr_malloc", 0);
return p;
}
We can see if p
is NULL
, the abort()
system call will be invoked. This verifies what I guessed. Besides gpr_malloc
, other memory allocate functions (such as gpr_zalloc
, gpr_realloc
, etc) have the same behaviors.