【问题标题】:*glibc detected double free or corruption() * message!*glibc 检测到双重释放或损坏() * 消息!
【发布时间】:2010-10-31 14:56:13
【问题描述】:

当我运行程序时,下面的 deleteNode 函数得到了这些: * 检测到 glibc free():下一个大小无效(正常):0x000000000103dd90 **

即使我让'免费(这里); ' 一个评论,我得到了上面的消息。 我不认为其他“免费”电话会引发这样的问题。但我不明白为什么这是错误的。 :/

struct List *deleteNode(int Code,int i,char* Number)
    {
        struct List *here;
        here=Head;

        for (here; here!=Tail; here=here->next)
        {       
            if ( (here->number==Number) && (here->code==Code) )//found node on the List
            {
                if (here->previous==Head)        //delete from beginning
                {           
                    Head=here->next;
                    here->next->previous=Head;
                }
                else if (here->next==Tail) //delete from the end
                {
                    here->previous->next=Tail;
                    Tail=here->previous;
                }
                else  //delete from the middle of the list
                {   
                    here->previous->next=here->next;
                    here->next->previous=here->previous;
                }
                break;
            }
        }

        free (here);

    }

编辑: 如果我很好地使用并理解了 valgring,那么问题就出在我的主要功能上。 我也有一些“免费”,但我在此消息之前更改了 deleteNode,所以我认为问题出在 deleteNode 函数上。

现在,没有 free() 无效的下一个大小......但不幸的是: glibc 检测到 * : double free or corruption (out): 0x00007fff1aae9ae0 * :(

主要部分:

FILE *File;
    if ( ( File=fopen("File.txt","r")) !=NULL )
    {                               
        int li = 0;    
        char *lin = (char *) malloc(MAX_LINE * sizeof(char));


        while(fgets(lin, MAX_LINE, eventFile) != NULL)
        {
            token = linetok(lin, " ");

            if(token != NULL)
            {

                int i,code,nodeID;
            char *number;
            char *event;

                for(i = 0; token[i] != NULL; i += 1)
                {
            code=atoi(token[0]);
            strcpy(event,token[1]);
            nodeID=atoi(token[2]);
            strcpy(number,token[3]) ;

            int i;
            if (!strcmp(event,"add"))
            {       
                add_to_List(code,i,number);
            }
            else if(!strcmp(event,"delete"))
            {       
                             deleteNode(eventNo,i,number);
                    }
            free(event);
            free(phoneNumber);  
        }
                free(token);
            }
            else 
            {
                printf("Error reading line %s\n", lin);
                exit(1);   
            }
        }
    } 
    else 
    {
        printf("Error opening file with the events.\nEXIT!");
        exit(0);
    }

正在调试它...

main' pro:(.text+0xce0): first defined here /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtend.o:(.dtors+0x0): multiple definition of的多重定义DTOR_END' pro:(.dtors+0x8): 首先在这里定义 /usr/bin/ld:警告:无法创建 .eh_frame_hdr 部分,--eh-frame-hdr 被忽略。 /usr/bin/ld: pro1(.eh_frame) 中的错误;不会创建 .eh_frame_hdr 表。 collect2: ld 返回 1 个退出状态

【问题讨论】:

  • 尝试使用 valgrind 运行。 Valgrind 发现了许多关于内存的错误。
  • hm with valgring 我得到这个:警告:无法创建 .eh_frame_hdr 部分,--eh-frame-hdr 被忽略。 /usr/bin/ld: deleteNode.c(.eh_frame) 中的错误;不会创建 .eh_frame_hdr 表。 collect2: ld 返回 1 个退出状态
  • 我看到的一个问题是变量 number 和 event 在 strcpy() 中使用时未初始化。 strcpy() 不分配内存。您可能应该使用 strdup() 来分配内存。

标签: c free


【解决方案1】:

“Invalid next size”表示 glibc 检测到内存区域损坏。

您已经覆盖了存储在您分配的块之间的有价值的会计信息。

malloc 为您提供的每个区块,都会在附近存储一些会计信息。例如,当您通过将 128 个字符写入 20 个字符的缓冲区来覆盖此信息时,glibc 可能会在您下次尝试释放(或可能分配)一些内存时检测到这一点。

您需要找到这个问题的根本原因 - 这不是免费的本身,而是问题被检测到的地方。在某个地方,您的一些代码正在浪费内存,而像 valgrind 这样的内存分析工具将在这里发挥不可估量的作用。

【讨论】:

    【解决方案2】:

    如果在列表中找不到节点,您将在函数结束时释放 Tail 节点,而不更新 Tail 以再次指向任何有效的对象。

    进一步使用列表和现在已解除分配的Tail 很容易导致内存损坏,稍后可能会被 glibc 检测到并显示与您收到的消息类似的消息。

    还请注意,在(here->number==Number) 中,您正在比较两个指针,而不是这些指针指向的值。我不确定这是否是你想要的。

    【讨论】:

    • thnx ……我明白你的意思...我评论了“免费”但问题仍然存在:(你最后的评论是什么意思?我该怎么办?
    • @FILIaS:您注释掉了free(),但您仍然收到来自free() 的错误消息?最后一条注释意味着如果您将两个指针变量与== 进行比较,您将比较存储在这些指针变量中的内存地址,而不是存储在这些地址的内存中的值。所以你自己比较地址。如果你想比较字符串,你应该使用strcmp() 函数。
    • 哦,是我的错。但即使是现在,我仍然收到这条消息! :(
    猜你喜欢
    • 2012-02-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-10-01
    相关资源
    最近更新 更多