c-处理核心转储，但看起来不像是多线程程序中的非法引用

核心转储的回溯：

#0  0x0000000000416228 in add_to_epoll (struct_fd=0x18d32760, lno=7901) at lbi.c:7092
#1  0x0000000000418b54 in connect_fc (struct_fd=0x18d32760, type=2) at lbi.c:7901
#2  0x0000000000418660 in poll_fc (arg=0x0) at lbi.c:7686
#3  0x00000030926064a7 in start_thread () from /lib64/libpthread.so.0
#4  0x0000003091ed3c2d in clone () from /lib64/libc.so.6

代码段：

#define unExp(x) __builtin_expect((x),0)
... 
7087 int add_to_epoll( struct fdStruct * struct_fd, int lno)
7088 {
7089    struct epoll_event ev;
7090    ev.events = EPOLLIN | EPOLLET | EPOLLPRI | EPOLLERR ;
7091    ev.data.fd = fd_st->fd;
7092    if (unExp(epoll_ctl(struct_fd->Hdr->info->epollfd, EPOLL_CTL_ADD,         struct_fd->fd,&ev) == -1))
7093    {
7094        perror("client FD  ADD to epoll error:");
7095        return -1;
7096    }
7097    else
7098    {
            ...
7109    }
7110    return 1;
7111 }

拆卸有问题的行我不擅长解释汇编代码，但已经尽力了：

        if (unExp(epoll_ctl(struct_fd->Hdr->info->epollfd, EPOLL_CTL_ADD, stuct_fd->fd,&ev) == -1))
  416210:       48 8b 45 d8             mov    0xffffffffffffffd8(%rbp),%rax // Storing struct_fd->fd
  416214:       8b 10                   mov    (%rax),%edx                   //  to EDX
  416216:       48 8b 45 d8             mov    0xffffffffffffffd8(%rbp),%rax // Storing struct_fd->Hdr->info->epollfd
  41621a:       48 8b 80 e8 01 00 00    mov    0x1e8(%rax),%rax              // to EDI which failed 
  416221:       48 8b 80 58 01 00 00    mov    0x158(%rax),%rax              // while trying to offset members of the structure
  416228:       8b 78 5c                mov    0x5c(%rax),%edi               // <--- failed here since Reg AX is 0x0
  41622b:       48 8d 4d e0             lea    0xffffffffffffffe0(%rbp),%rcx
  41622f:       be 01 00 00 00          mov    $0x1,%esi
  416234:       e8 b7 e1 fe ff          callq  4043f0 <epoll_ctl@plt>
  416239:       83 f8 ff                cmp    $0xffffffffffffffff,%eax
  41623c:       0f 94 c0                sete   %al
  41623f:       0f b6 c0                movzbl %al,%eax
  416242:       48 85 c0                test   %rax,%rax
  416245:       74 5e                   je     4162a5 <add_to_epoll+0xc9>

打印寄存器和结构成员值：

(gdb) i r $rax
rax            0x0      0
(gdb) p struct_fd
$3 = (struct fdStruct *) 0x18d32760
(gdb) p struct_fd->Hdr
$4 = (StHdr *) 0x3b990f30
(gdb) p struct_fd->Hdr->info
$5 = (struct Info *) 0x3b95b410    // Strangely, this is NOT NULL. Inconsistent with assembly dump.
(gdb) p ev
$6 = {events = 2147483659, data = {ptr = 0x573dc648000003d6, fd = 982, u32 = 982, u64= 6286398667419026390}}

请让我知道我的disassembly解释是否可以。如果可以，我想了解为什么gdb在打印结构成员时不显示NULL。

或者，如果分析不完美，想知道核心转储的实际原因。如果你需要更多信息，请告诉我。

谢谢

----后面添加了以下部分----

代理是一个多线程程序。做了更多的挖掘才知道，当问题发生时，以下两个线程是并行运行的。当我避免这两个函数并行运行时，问题永远不会发生。但是，问题是我无法解释这种行为是如何导致最初的问题场景的：

Thread 1: 
------------------------------------------------------------
int new_connection() {
   ...
   struct_fd->Hdr->info=NULL; /* (line 1)  */
   ...
   <some code>
   ...
   struct_fd->Hdr->info=Golbal_InFo_Ptr; /* (line 2) */  // This is a malloced memory, once allocated never freed
   ...
   ...
}
------------------------------------------------------------
Thread 2 executing add_to_epoll():
------------------------------------------------------------
int add_to_epoll( struct fdStruct * struct_fd, int lno)
{
   ...
   if (unExp(epoll_ctl(struct_fd->Hdr->info->epollfd,...)  /* (line 3) */
   ...
}
------------------------------------------------------------

在以上片段中，如果按顺序执行，LIne 1，第3行，第2行，场景可能发生。我所期望的是，每当遇到非法引用时，它都应该立即转储，而不必试图执行使其为NON NULL的LINE 3。这是一种明确的行为，因为到目前为止，我已经有大约12个相同问题的核心转储，所有这些都显示了完全相同的东西。

很明显，正如Per Johansson已经回答的那样，struct_fd->Hdr->info就是NULL。

然而，GDB认为事实并非如此。那怎么可能呢？

发生这种情况的一种常见方式是

更改struct fdStruct、struct StHdr（或两者）的布局，以及
您忽略了重新生成所有使用这些定义的对象

反汇编表明CCD_ 5和CCD_。查看GDB为以下内容打印的内容：

(gdb) print/x (char*)&struct_fd->Hdr - (char*)struct_fd
(gdb) print/x (char*)&struct_fd->Hdr->info - (char*)struct_fd->Hdr

我打赌它会打印0x1e8和0x158以外的内容。

如果是这样的话，make clean && make可能会解决这个问题。

更新：

(gdb) print/x (char*)&struct_fd->Hdr - (char*)struct_fd
$1 = 0x1e8
(gdb) print/x (char*)&struct_fd->Hdr->info - (char*)struct_fd->Hdr
$3 = 0x158

这证明了GDB关于对象如何在内存中布局的想法与编译的代码相匹配。

我们仍然不知道GDB关于struct_fd价值的想法是否符合现实。这些命令打印什么？

(gdb) print struct_fd
(gdb) x/gx $rbp-40

它们应该产生相同的值（0x18d32760）。假设他们这样做了，我能想到的唯一其他解释是，有多个线程访问struct_fd，而另一个线程则用新值覆盖过去为NULL的值。

我刚刚注意到你对这个问题的更新；-）

我所期望的是，每当遇到非法引用时，它都应该立即转储，而不必试图执行使其为NON NULL的LINE 3。

您的期望是不正确的：在任何现代CPU上，您都有多个内核，并且您的线程同时执行。也就是说，你有这样的代码（时间沿着Y轴下降）：

char *p;  // global

Time     CPU0                  CPU1
0        p = NULL
1        if (*p)               p = malloc(1)
2                              *p = 'a';
...

在T1，CPU0俘获到OS中，但CPU1继续。最终，操作系统处理硬件陷阱，并转储当时的内存状态。在CPU1上，在T1之后可能已经执行了数百条指令。CPU0和CPU1之间的时钟甚至不同步，它们不一定同步。

这个故事的寓意是：在没有适当锁定的情况下，不要从多个线程访问全局变量。

反汇编的C行部分与原始代码中的部分不匹配。但显然

struct_fd->Hdr->info

是CCD_ 12。gdb打印这个应该没有问题，但当使用-O2或更高版本编译代码时，它有时会感到困惑。

相关内容

最新更新

热门标签：