malloc中的信号11 SIGSEGV? [英] signal 11 SIGSEGV in malloc?
问题描述
我通常喜欢解释清楚的问题和答案.但在这种情况下，我真的无法提供更多线索.
I usually love good explained questions and answers. But in this case I really can't give any more clues.
问题是:为什么 malloc() 给我 SIGSEGV?下面的调试显示程序没有时间测试返回的指向 NULL 的指针并退出.程序退出 INSIDE MALLOC！
The question is: why malloc() is giving me SIGSEGV? The debug bellow show the program has no time to test the returned pointer to NULL and exit. The program quits INSIDE MALLOC!
我假设我在 glibc 中的 malloc 很好.我有一个 debian/linux wheezy 系统，在旧的 pentium(i386/i486 架构)中更新.
I'm assuming my malloc in glibc is just fine. I have a debian/linux wheezy system, updated, in an old pentium (i386/i486 arch).
为了能够跟踪，我生成了一个核心转储.让我们跟随它:
To be able to track, I generated a core dump. Lets follow it:
iguana$gdb xadreco core-20131207-150611.dump
Core was generated by `./xadreco'.
Program terminated with signal 11, Segmentation fault.
#0 0xb767fef5 in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt
#0 0xb767fef5 in ?? () from /lib/i386-linux-gnu/libc.so.6
#1 0xb76824bc in malloc () from /lib/i386-linux-gnu/libc.so.6
#2 0x080529c3 in enche_pmovi (cabeca=0xbfd40de0, pmovi=0x...) at xadreco.c:4519
#3 0x0804b93a in geramov (tabu=..., nmovi=0xbfd411f8) at xadreco.c:1473
#4 0x0804e7b7 in minimax (atual=..., deep=1, alfa=-105000, bet...) at xadreco.c:2778
#5 0x0804e9fa in minimax (atual=..., deep=0, alfa=-105000, bet...) at xadreco.c:2827
#6 0x0804de62 in compjoga (tabu=0xbfd41924) at xadreco.c:2508
#7 0x080490b5 in main (argc=1, argv=0xbfd41b24) at xadreco.c:604
(gdb) frame 2
#2 0x080529c3 in enche_pmovi (cabeca=0xbfd40de0, pmovi=0x ...) at xadreco.c:4519
4519 movimento *paux = (movimento *) malloc (sizeof (movimento));
(gdb) l
4516
4517 void enche_pmovi (movimento **cabeca, movimento **pmovi, int c0, int c1, int c2, int c3, int p, int r, int e, int f, int *nmovi)
4518 {
4519 movimento *paux = (movimento *) malloc (sizeof (movimento));
4520 if (paux == NULL)
4521 exit(1);
当然，我需要查看第 2 帧，这是与我的代码相关的堆栈的最后一个.但是4519行给出了SIGSEGV！没有时间测试，在第 4520 行，是否 paux==NULL.
Of course I need to look at frame 2, the last on stack related to my code. But the line 4519 gives SIGSEGV! It does not have time to test, on line 4520, if paux==NULL or not.
这里是movimento"(缩写):
Here it is "movimento" (abbreviated):
typedef struct smovimento
{
int lance[4]; //move in integer notation
int roque; // etc. ...
struct smovimento *prox;// pointer to next
} movimento;
这个程序可以加载很多内存.我知道记忆力已经到了极限.但是我认为当内存不可用时 malloc 会处理得更好.
This program can load a LOT of memory. And I know the memory is in its limits. But I thought malloc would handle better when memory is not available.
在执行期间执行 $free -h，我可以看到内存低至 1MB！没关系.旧电脑只有 96MB.操作系统使用 50MB.
Doing a $free -h during execution, I can see memory down to as low as 1MB! Thats ok. The old computer only has 96MB. And 50MB is used by the OS.
我不知道从哪里开始寻找.也许在 malloc 调用之前检查可用内存?但这听起来很浪费计算机能力，因为 malloc 应该会这样做.sizeof (movimento) 大约是 48 字节.如果我之前测试过，至少我会确认这个错误.
I don't know to where start looking. Maybe check available memory BEFORE a malloc call? But that sounds a wast of computer power, as malloc would supposedly do that. sizeof (movimento) is about 48 bytes. If I test before, at least I'll have some confirmation of the bug.
任何想法，请分享.谢谢.
Any ideas, please share. Thanks.
推荐答案
任何 malloc(或free)内的崩溃几乎是肯定的堆损坏的迹象，可能有多种形式:
Any crash inside malloc (or free) is an almost sure sign of heap corruption, which can come in many forms:
- 堆缓冲区溢出或下溢
- 两次释放某物
- 释放非堆指针
- 写入已释放的块
- 等等
如果没有工具支持，这些错误很难捕获，因为崩溃通常来自数千条指令，并且可能在代码中稍后多次调用 malloc 或 free这通常位于程序的完全不同的部分，并且与错误所在的位置相距甚远.
These bugs are very hard to catch without tool support, because the crash often comes many thousands of instructions, and possibly many calls to malloc or free later, in code that is often in a completely different part of the program and very far from where the bug is.
好消息是 Valgrind 或 AddressSanitizer 通常会直接指出问题所在.
The good news is that tools like Valgrind or AddressSanitizer usually point you straight at the problem.
这篇关于malloc中的信号11 SIGSEGV?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
