什么是“损坏的双向链表”的意思(What does 'corrupted double-li

2019-07-19 23:55发布

站内文章 / 前端开发
38 0 0

我最近得到了从我的PHP以下错误： 

WARNING: [pool www] child 42475 said into stderr: "*** glibc detected *** php-fpm: pool www: corrupted double-linked list: 0x00000000013fe680 ***"

我不是很受到这个问题的困扰，并在修复它不是很感兴趣。 但我理解这是什么错误“破坏双链表”实际上是指，因为我还没有看到过很感兴趣。 我相信知道一个双链表是什么，但我并没有产生触发这个错误的程序。

可能有人给我提供的一小段程式码，导致glibc的说“损坏的双链表”当我编译并执行它？

Answer 1:

我已经找到了答案，我自己的问题:)

因此，我不明白的是glibc的如何能段错误和损坏的双链表区分，因为根据我的理解，从glibc的他们应该像同样的事情的角度。 因为如果我实现我的计划内双链表，怎么可能glibc的可能知道，这是一个双向链表，而不是任何其他结构？ 这大概不能，所以这就是为什么我被搞糊涂了。

现在，我已经看过了的glibc的代码中的malloc / malloc.c，我看到以下内容： 

1543 /* Take a chunk off a bin list */
1544 #define unlink(P, BK, FD) {                                            \
1545   FD = P->fd;                                                          \
1546   BK = P->bk;                                                          \
1547   if (__builtin_expect (FD->bk != P || BK->fd != P, 0))                \
1548     malloc_printerr (check_action, "corrupted double-linked list", P); \
1549   else {                                                               \
1550     FD->bk = BK;                                                       \
1551     BK->fd = FD;                                                       \

所以现在这个突然有道理。 为什么glibc的可以知道，这是一个双链表的原因是因为列表的glibc本身的一部分。 我一直困惑，因为我想的glibc能以某种方式检测到一些编程正在建立一个双向链表，我想不明白是如何工作的。 但是，如果它是在谈论，这双链表的glibc本身的一部分，当然也可以知道这是一个双向链表。

我仍然不知道什么引发了这个错误。 但至少我知道损坏的双链表和段错误，以及如何glibc的可以知道这个结构应该是一个双向链表的区别:)



Answer 2:

堆溢出应该是怪（但不总是） corrupted double-linked list ， malloc(): memory corruption ， double free or corruption (!prev)般的glibc的警告。

应该通过下面的代码被复制： 

#include <vector>

using std::vector;


int main(int argc, const char *argv[])
{
    int *p = new int[3];
    vector<int> vec;
    vec.resize(100);
    p[6] = 1024;
    delete[] p;
    return 0;
}

如果使用克++（4.5.4）编译： 

$ ./heapoverflow
*** glibc detected *** ./heapoverflow: double free or corruption (!prev): 0x0000000001263030 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7af26)[0x7f853f5d3f26]
./heapoverflow[0x40138e]
./heapoverflow[0x400d9c]
./heapoverflow[0x400bd9]
./heapoverflow[0x400aa6]
./heapoverflow[0x400a26]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f853f57b4bd]
./heapoverflow[0x4008f9]
======= Memory map: ========
00400000-00403000 r-xp 00000000 08:02 2150398851                         /data1/home/mckelvin/heapoverflow
00602000-00603000 r--p 00002000 08:02 2150398851                         /data1/home/mckelvin/heapoverflow
00603000-00604000 rw-p 00003000 08:02 2150398851                         /data1/home/mckelvin/heapoverflow
01263000-01284000 rw-p 00000000 00:00 0                                  [heap]
7f853f559000-7f853f6fa000 r-xp 00000000 09:01 201329536                  /lib64/libc-2.15.so
7f853f6fa000-7f853f8fa000 ---p 001a1000 09:01 201329536                  /lib64/libc-2.15.so
7f853f8fa000-7f853f8fe000 r--p 001a1000 09:01 201329536                  /lib64/libc-2.15.so
7f853f8fe000-7f853f900000 rw-p 001a5000 09:01 201329536                  /lib64/libc-2.15.so
7f853f900000-7f853f904000 rw-p 00000000 00:00 0
7f853f904000-7f853f919000 r-xp 00000000 09:01 74726670                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1
7f853f919000-7f853fb19000 ---p 00015000 09:01 74726670                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1
7f853fb19000-7f853fb1a000 r--p 00015000 09:01 74726670                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1
7f853fb1a000-7f853fb1b000 rw-p 00016000 09:01 74726670                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1
7f853fb1b000-7f853fc11000 r-xp 00000000 09:01 201329538                  /lib64/libm-2.15.so
7f853fc11000-7f853fe10000 ---p 000f6000 09:01 201329538                  /lib64/libm-2.15.so
7f853fe10000-7f853fe11000 r--p 000f5000 09:01 201329538                  /lib64/libm-2.15.so
7f853fe11000-7f853fe12000 rw-p 000f6000 09:01 201329538                  /lib64/libm-2.15.so
7f853fe12000-7f853fefc000 r-xp 00000000 09:01 74726678                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6.0.18
7f853fefc000-7f85400fb000 ---p 000ea000 09:01 74726678                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6.0.18
7f85400fb000-7f8540103000 r--p 000e9000 09:01 74726678                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6.0.18
7f8540103000-7f8540105000 rw-p 000f1000 09:01 74726678                   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6.0.18
7f8540105000-7f854011a000 rw-p 00000000 00:00 0
7f854011a000-7f854013c000 r-xp 00000000 09:01 201328977                  /lib64/ld-2.15.so
7f854031c000-7f8540321000 rw-p 00000000 00:00 0
7f8540339000-7f854033b000 rw-p 00000000 00:00 0
7f854033b000-7f854033c000 r--p 00021000 09:01 201328977                  /lib64/ld-2.15.so
7f854033c000-7f854033d000 rw-p 00022000 09:01 201328977                  /lib64/ld-2.15.so
7f854033d000-7f854033e000 rw-p 00000000 00:00 0
7fff92922000-7fff92943000 rw-p 00000000 00:00 0                          [stack]
7fff929ff000-7fff92a00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
[1]    18379 abort      ./heapoverflow

并且如果使用铛++编译（6.0（铛-600.0.56））： 

$  ./heapoverflow
[1]    96277 segmentation fault  ./heapoverflow

如果你认为你可能会写这样的一个bug，这里是一些提示，以追查出来。

首先，编译调试标志（代码-g ）： 

g++ -g foo.cpp

然后，使用运行它的valgrind ： 

$ valgrind ./a.out
==12693== Memcheck, a memory error detector
==12693== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==12693== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==12693== Command: ./a.out
==12693==
==12693== Invalid write of size 4
==12693==    at 0x400A25: main (foo.cpp:11)
==12693==  Address 0x5a1c058 is 12 bytes after a block of size 12 alloc'd
==12693==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12693==    by 0x4009F6: main (foo.cpp:8)
==12693==
==12693==
==12693== HEAP SUMMARY:
==12693==     in use at exit: 0 bytes in 0 blocks
==12693==   total heap usage: 2 allocs, 2 frees, 412 bytes allocated
==12693==
==12693== All heap blocks were freed -- no leaks are possible
==12693==
==12693== For counts of detected and suppressed errors, rerun with: -v
==12693== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

该缺陷位于==在0x400A25 12693 ==：主（Foo.cpp中：11）



Answer 3:

对于任何人谁在这里寻找解决办法，我曾与C ++类似的问题：malloc（）函数：smallbin双链表损坏：

这是由于函数没有返回它应该值。 

std::vector<Object> generateStuff(std::vector<Object>& target> {
  std::vector<Object> returnValue;
  editStuff(target);
  // RETURN MISSING
}

不知道这是为什么能毕竟编译。 也许有一个警告。



Answer 4:

这可能是由不同的原因造成的，有的说其他候选人，我会介绍我的情况：

我使用多线程（均在得到这个错误std::pthread和std::thread ），并发生了错误，因为我忘了锁它的多线程可以在同一时间改变一个变量。 这个错误出现在随机运行的一些但不是全部，因为......你在线程之间知道事故是随机的。

在我的情况下，该变量是一个全球性std::vector ，我尝试push_back()在它的东西在一个由线程调用的函数..然后我使用std::mutex ，并再也没有得到这个错误。

可以帮助一些



Answer 5:

我就遇到了这个错误在一些代码中有人在一个线程大约在同一时间，调用exit（） main()返回，所以所有全局/静态构造函数正在以两个独立的线程同时拉开序幕。

这个错误也表现为double free or corruption ，或内段错误/ SIG11 exit()或内部malloc_consolidate ，并有可能别人。 对于malloc_consolidate崩溃调用堆栈可能类似于： 

#0  0xabcdabcd in malloc_consolidate () from /lib/libc.so.6
#1  0xabcdabcd in _int_free () from /lib/libc.so.6
#2  0xabcdabcd in operator delete (...)
#3  0xabcdabcd in operator delete[] (...)
(...)

我无法得到它的valgrind下运行时出现此问题。



文章来源: What does 'corrupted double-linked list' mean
标签： memory-management glibc
举报

收藏的人(0)

Ta的文章 更多文章
登录 后发表评论
0条评论
还没有人评论过~