关于信号处理程序的调试信息，谁调用 calloc？答案

【问题标题】：Debug info about signal handler, who calls calloc?关于信号处理程序的调试信息，谁调用 calloc？
【发布时间】：2019-02-02 15:33:57
【问题描述】：

Calloc 是从我的生产代码中的某个信号处理程序调用的。我知道从信号处理程序调用 calloc 是不安全的。我需要在我的生产代码中找到这样做的点，但是回溯没有帮助。请指导

print $_siginfo.si_signo

我知道上面告诉了当前信号的信号号。但这并不能帮助我找到重点。

下面是调用栈，calloc下面的stacktrace是没有用的。

#26 0x00002aaaaaccfec9 in calloc () from 
#27 0x00000000047c522f in Ox4074f61149c39b9f ()
#28 0x00000000047aa93a in Ox4074ff7b773cfdf6 ()
#29 0x000000000468c981 in Ox4074ea3d1f5df78f ()
#30 0x000000000468e667 in ?? ()
#31 0x000000000468f2dd in ?? ()
#32 0x0000000004686f2c in Ox4074ea18721a0b5d ()
#33 0x00000000047b3727 in Ox4075027a04de15e3 ()
#34 0x00000000047efdd4 in ?? ()
#35 <signal handler called>
#36 0x00002aaabc5d0332 in __lll_lock_wait () from /lib64/libpthread.so.0
#37 0x00002aaabc5cb5d8 in _L_lock_854 () from /lib64/libpthread.so.0
#38 0x00002aaabc5cb4a7 in pthread_mutex_lock () from 
    /lib64/libpthread.so.0

【问题讨论】：

我从 siginfo 结构中看到生成了 SIGSTOP 信号。据我了解 SIGSTOP 无法处理。那么谁从信号处理程序中调用 calloc 呢？？

标签： debugging gdb signals

【解决方案1】：

请指导

您观察到的堆栈跟踪最可能的解释是：您正在分析来自不同机器上的生产机器的core转储，并使用错误系统库这样做。

请参阅this answer，了解如何正确执行此操作。

【讨论】：

否，堆栈跟踪是在进程运行的同一台机器上生成的。
@Rock 我不相信这个堆栈跟踪。也许您在启动崩溃的生产服务器和收集堆栈跟踪之间更新了系统libc？
我在本地可执行文件运行期间也得到了相同的调用堆栈，有人可以指导吗？