Syslogd 内核：代码：

Question

在运行一些与 MySQL 服务器交互的实验性 Java 代码时，我收到了这些消息，然后服务器崩溃了：

Message from syslogd@localhost at Jun 20 20:04:12 ...
 kernel:Stack:

Message from syslogd@localhost at Jun 20 20:04:12 ...
 kernel:Call Trace:

Message from syslogd@localhost at Jun 20 20:04:12 ...
 kernel:Code: e0 48 8d 55 b0 48 89 4d e8 4c 89 45 f0 48 89 45 b8 48 8d 45 d0 4c 89 4d f8 c7 45 b0 10 00 00 00 48 89 45 c0 e8 5a ff ff ff c9 c3 <89> f0 b9 40 00 00 00 55 99 45 31 c0 f7 f9 48 89 e5 48 89 fa 41 

它们是什么意思？重新启动后，一切恢复正常。 /var/log/messages 在事件发生时没有任何条目，并且 dmesg 似乎也没有显示任何有关它的信息。

Fedora 版本 13（戈达德） 2.6.34.8-68.fc13.x86_64

Answer 1

这是转储代码的反汇编，如果有帮助的话。我假设尖括号包围的字节是代码崩溃的地方，尽管我看不出从一个寄存器到另一个寄存器的 mov 语句如何做到这一点。

   0:   e0 48                   loopne 0x4a
   2:   8d 55 b0                lea    -0x50(%ebp),%edx
   5:   48                      dec    %eax
   6:   89 4d e8                mov    %ecx,-0x18(%ebp)
   9:   4c                      dec    %esp
   a:   89 45 f0                mov    %eax,-0x10(%ebp)
   d:   48                      dec    %eax
   e:   89 45 b8                mov    %eax,-0x48(%ebp)
  11:   48                      dec    %eax
  12:   8d 45 d0                lea    -0x30(%ebp),%eax
  15:   4c                      dec    %esp
  16:   89 4d f8                mov    %ecx,-0x8(%ebp)
  19:   c7 45 b0 10 00 00 00    movl   $0x10,-0x50(%ebp)
  20:   48                      dec    %eax
  21:   89 45 c0                mov    %eax,-0x40(%ebp)
  24:   e8 5a ff ff ff          call   0xffffff83
  29:   c9                      leave  
  2a:   c3                      ret    
  2b:   89 f0                   mov    %esi,%eax   <-- here is where it failed?
  2d:   b9 40 00 00 00          mov    $0x40,%ecx
  32:   55                      push   %ebp
  33:   99                      cltd   
  34:   45                      inc    %ebp
  35:   31 c0                   xor    %eax,%eax
  37:   f7 f9                   idiv   %ecx
  39:   48                      dec    %eax
  3a:   89 e5                   mov    %esp,%ebp
  3c:   48                      dec    %eax
  3d:   89 fa                   mov    %edi,%edx
  3f:   41                      inc    %ecx

---

I don't know how to use any of the *grep programs to search for binary data, so you might need to write a few lines of perl or python to locate the kernel code involved. It is quite doubtful that your Java code, or anything to do with MySQL, could have caused a kernel-level crash.

---

Corrected disassembly for 64-bit mode:

00000000 <.data>:
   0:   e0 48                   loopne 0x4a
   2:   8d 55 b0                lea    -0x50(%rbp),%edx
   5:   48 89 4d e8             mov    %rcx,-0x18(%rbp)
   9:   4c 89 45 f0             mov    %r8,-0x10(%rbp)
   d:   48 89 45 b8             mov    %rax,-0x48(%rbp)
  11:   48 8d 45 d0             lea    -0x30(%rbp),%rax
  15:   4c 89 4d f8             mov    %r9,-0x8(%rbp)
  19:   c7 45 b0 10 00 00 00    movl   $0x10,-0x50(%rbp)
  20:   48 89 45 c0             mov    %rax,-0x40(%rbp)
  24:   e8 5a ff ff ff          callq  0xffffff83
  29:   c9                      leaveq 
  2a:   c3                      retq   
  2b:   89 f0                   mov    %esi,%eax
  2d:   b9 40 00 00 00          mov    $0x40,%ecx
  32:   55                      push   %rbp
  33:   99                      cltd   
  34:   45 31 c0                xor    %r8d,%r8d
  37:   f7 f9                   idiv   %ecx
  39:   48 89 e5                mov    %rsp,%rbp
  3c:   48 89 fa                mov    %rdi,%rdx
  3f:   41                      rex.B

[这么多年后再次审视这个问题，我意识到问题更有可能是：堆栈下溢。由于堆栈为空，retq 没有地方返回，因此指令指针指向下面的指令 -- jc]