信号11 SIGSEGV在malloc中? [英] 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很好.我有一个使用旧奔腾(i386/i486 arch)更新的debian/linux wheezy系统.

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！如果没有paux == NULL，则没有时间在4520行进行测试.

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 bytes.如果我之前进行过测试，至少我会对该错误进行一些确认.

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:

• 堆缓冲区上溢或下溢
• 释放两次东西
• 释放非堆指针
• 写入释放的块
• 等

如果没有工具支持，这些bug很难捕获，因为该崩溃通常来自成千上万的指令，并且可能以后会调用许多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 或

The good news is that tools like Valgrind or AddressSanitizer usually point you straight at the problem.

这篇关于信号11 SIGSEGV在malloc中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！