today I was suddenly aware that something fundamentaly is broken with
my 2.0.10 (and 12) kernels. IMHO the list of binary formats will get
corrupted sometimes. I don't know how this happens.
Running a cpu intensive application (for instance an endless loop in C) in
a xterm, waiting for about 20 seconds and then running a simple
application (for instance less) in a differnt xterm will crash the
application immediatly. If I stop the cpu intensive application, I
get no kernel messages any more and all processes are running o.k.
This can be repeated many times!
For every application crash I get an kernel info.
The EIP is most often far away from the kernel space. But always I
find the adress 001289f7 in the Call Trace, which belongs to the
search_binary function in fs/exec.c. The last line is always Code: 00
80 45 00 00 80 55 00 00 80 55 00 00 5c 01 00 00 7c 01 00, no matter at
which EIP the kernel crashed the application. [How can it be?]
[System.map]
00128954 T remove_arg_zero
001289b8 T search_binary_handler
00128b08 T do_execve
Disassembling of exec.o
0xa68 <search_binary_handler>: subl $0x20,%esp
0xa6b <search_binary_handler+3>: pushl %ebp
0xa6c <search_binary_handler+4>: pushl %edi
0xa6d <search_binary_handler+5>: pushl %esi
0xa6e <search_binary_handler+6>: pushl %ebx
0xa6f <search_binary_handler+7>: movl 0x34(%esp,1),%esi
0xa73 <search_binary_handler+11>: xorl %ebx,%ebx
0xa75 <search_binary_handler+13>: movl $0x0,0x18(%esp,1)
0xa7d <search_binary_handler+21>: leal 0x1c(%esp,1),%ebp
0xa81 <search_binary_handler+25>: leal 0x0(%esi),%esi
0xa84 <search_binary_handler+28>: movl 0x0,%ecx
0xa8a <search_binary_handler+34>: testl %ecx,%ecx
0xa8c <search_binary_handler+36>: je 0xb12 <search_binary_handler+170>
0xa92 <search_binary_handler+42>: leal (%esi),%esi
0xa94 <search_binary_handler+44>: movl 0x8(%ecx),%edx
0xa97 <search_binary_handler+47>: testl %edx,%edx
0xa99 <search_binary_handler+49>: je 0xb0c <search_binary_handler+164>
0xa9b <search_binary_handler+51>: movl 0x38(%esp,1),%eax
0xa9f <search_binary_handler+55>: pushl %eax
0xaa0 <search_binary_handler+56>: pushl %esi
0xaa1 <search_binary_handler+57>: movl %ecx,0x18(%esp,1)
0xaa5 <search_binary_handler+61>: call *%edx <--- The crashing routine is called here
fs/exec.c
....
for (try=0; try<2; try++) {
for (fmt = formats ; fmt ; fmt = fmt->next) {
int (*fn)(struct linux_binprm *, struct pt_regs *) = fmt->load_binary;
if (!fn)
continue;
retval = fn(bprm, regs); <--- IMHO call *%edx
if (retval >= 0) {
Kernel Log (one out of many)
Aug 18 20:59:10 dragon kernel: general protection: 0000
Aug 18 20:59:10 dragon kernel: CPU: 0
Aug 18 20:59:10 dragon kernel: EIP: 0010:[<00a93ec3>] <--- Arghhh
Aug 18 20:59:10 dragon kernel: EFLAGS: 00010202
Aug 18 20:59:10 dragon kernel: eax: 00000000 ebx: 00a93d40 ecx: 008b6540 e
dx: 00000000
Aug 18 20:59:10 dragon kernel: esi: 00a93e6c edi: 00cfc3ac ebp: 0012de61 e
sp: 00a93c90
Aug 18 20:59:10 dragon kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0
018
Aug 18 20:59:10 dragon kernel: Process lsmod (pid: 581, process nr: 35, stackpag
e=00a93000)
Aug 18 20:59:10 dragon kernel: Stack: fffffff8 00a93e6c 00a93e6e 00a93dcc 000000
01 00000341 00000400 00bac000
Aug 18 20:59:10 dragon kernel: 00122d36 00000341 00084000 00084000 000840
00 00eef7b4 003ca894 0000002b
Aug 18 20:59:10 dragon kernel: 00a93d10 00000005 00000000 00000000 ffffff
ff 0009ead8 008b65c0 00000003
Aug 18 20:59:10 dragon kernel: Call Trace: [<00122d36>] [<00120018>] [<00140015>
] [<001289f7>] [<0012f4a8>] [<0012f4cb>] [<001289f7>]
^^^^^^^^^^
Aug 18 20:59:10 dragon kernel: [<00128c4d>] [<00128c72>] [<00109bbe>] [<0
010a432>]
Aug 18 20:59:10 dragon kernel: Code: 00 80 45 00 00 80 55 00 00 80 55 00 00 5c 0
1 00 00 7c 01 00
-----------------
00140015 is located in `tcp_recvmsg'.... a call from
search_binary_handler to tcp_recvmsg is garbage.
--------------
My Configuration..
486 DX 80, kerneld, linux-1.2.10 or 1.2.12 highly modularized. No
a.out or java executables are called before crash. ELF Executables, no
shell skripts involved.
Cheers
Olaf
-- Dr. Olaf Flebbe Phone +49 (0)7071-9457-32 science + computing gmbh FAX +49 (0)7071-9457-27 Hagellocher Weg 71 D-72070 Tuebingen Email: o.flebbe@science-computing.uni-tuebingen.de