Syslogd kernel:code: - crash

Question

While running some experimental Java code which interacts with a MySQL server, I received these messages and then the server crashed:
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
What do they mean? After restart, everything is working again. /var/log/messages has no entries near the time of the event and dmesg doesn't seem to show anything about it either.
Fedora release 13 (Goddard)
2.6.34.8-68.fc13.x86_64

Answer 1

Here's a disassembly of the dumped code, if that helps. I'm assuming the byte surrounded by the angle brackets is where the code crashed, although I can't see how a mov statement from one register to another could do so.
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
[looking at this again after all these years, I realize what the problem more likely was: a stack underflow. the retq had no place to return, as the stack was empty, so the instruction pointer was left pointing at the following instruction -- jc]