FYI: Linux paysan 2.1.87 #10 Sat Feb 21 18:48:59 MET 1998 i586 (egcs-1.0.0)
What changed with shared memory on 2.1.87 from 2.1.85? X crashes when
using the MIT-SHM extensions. It seems to try to detach an unused segment.
I got the following kernel Oopses when using imlib (the Enlightenment
library):
Unable to handle kernel NULL pointer dereference at virtual address 00000021
current->tss.cr3 = 01e67000,
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c013474b>]
eax: c1e80191 ebx: c20d5d20 ecx: ffffffff edx: c20d52bc
esi: 00000005 edi: 40a7f000 ebp: 40a7a000 esp: c1e81f24
ds: 0018 es: 0018 ss: 0018
Process xbigforth (pid: 401, process nr: 56, stackpage=c1e81000)
Stack: c20d5d20 c20d5d20 40a7f000 c011a013 c20d5d20 c20d5d20 40a7a000 00005000
00000000 c011a305 c20d5d20 40a7a000 00005000 c1e81f78 c21d6dc0 40a7a000
40a7a000 40a7a000 c1e80000 00000001 c30a2c40 c20d52e0 c01347bf 40a7a000
Call Trace: [<c011a013>] [<c011a305>] [<c01347bf>] [<c010dcd6>] [<c01098da>]
Code: 66 89 41 22 a1 d0 92 1e c0 89 41 18 66 8b 41 24 89 c7 4f 66
(code disassembled is
c0134730 <shm_close+1c> je c0134738 <shm_close+24>
c0134732 <shm_close+1e> movl 0x20(%ebx),%eax
c0134735 <shm_close+21> movl %eax,0x20(%edx)
c0134738 <shm_close+24> movl 0x20(%ebx),%edx
c013473b <shm_close+27> movl 0x1c(%ebx),%eax
c013473e <shm_close+2a> movl %eax,(%edx)
c0134740 <shm_close+2c> movl %esp,%eax
c0134742 <shm_close+2e> andl $0xffffe000,%eax
c0134747 <shm_close+33> movw 0x64(%eax),%ax
c013474b <shm_close+37> movw %ax,0x22(%ecx) <================ Oops
c013474f <shm_close+3b> movl 0xc01e92d0,%eax
c0134754 <shm_close+40> movl %eax,0x18(%ecx)
c0134757 <shm_close+43> movw 0x24(%ecx),%ax
c013475b <shm_close+47> movl %eax,%edi
c013475d <shm_close+49> decl %edi
c013475e <shm_close+4a> movw %di,0x24(%ecx)
c0134762 <shm_close+4e> cmpw $0x1,%ax
c0134766 <shm_close+52> jne c0134777 <shm_close+63>
)
called from
c011a011 <unmap_fixup+45> call *%eax
from
c011a300 <do_munmap+1d4> call c0119fcc <unmap_fixup>
from
c01347ba <sys_shmdt+3e> call c011a12c <do_munmap>
from
c010dcd1 <sys_ipc+26d> call c013477c <sys_shmdt>
from
c01098d3 <system_call+33> call *0xc01bec70(,%eax,4)
Before it oopses out, there are several messages like that:
Feb 21 12:53:12 paysan linux: shm_swap_in: id=1 too big. proc mem corrupted
Feb 21 12:53:13 paysan linux: shm_swap_in: id=3 too big. proc mem corrupted
Feb 21 12:53:13 paysan kernel: shm_swap_in: id=3 too big. proc mem corrupted
Feb 21 12:53:13 paysan last message repeated 4 times
Feb 21 12:54:14 paysan linux: shm_swap_in: id=5 too big. proc mem corrupted
Feb 21 12:54:14 paysan kernel: shm_swap_in: id=5 too big. proc mem corrupted
Feb 21 12:54:14 paysan last message repeated 12 times
I added a savety guard in shm.c:
--- shm.c.old Sat Feb 21 18:48:05 1998
+++ shm.c Sat Feb 21 18:46:57 1998
@@ -617,6 +617,10 @@
/* remove from the list of attaches of the shm segment */
id = SWP_OFFSET(shmd->vm_pte) & SHM_ID_MASK;
shp = shm_segs[id];
+ if(id > max_shmid || shp == IPC_UNUSED) {
+ printk("Unused segment %d: PANIC\n", id);
+ return;
+ }
remove_attach(shp,shmd); /* remove from shp->attaches */
shp->shm_lpid = current->pid;
shp->shm_dtime = CURRENT_TIME;
and tried that. The result looks like that:
...
Feb 21 19:01:51 paysan linux: shm_swap_in: id=9 too big. proc mem corrupted
Feb 21 19:01:51 paysan kernel: shm_swap_in: id=9 too big. proc mem corrupted
Feb 21 19:01:51 paysan last message repeated 9 times
Feb 21 19:01:51 paysan linux: shm_swap_in: id=9 too big. proc mem corrupted
Feb 21 19:01:51 paysan last message repeated 10 times
Feb 21 19:01:51 paysan kernel: Unused segment 9: PANIC
Feb 21 19:01:51 paysan kernel: Unused segment 9: PANIC
Feb 21 19:01:51 paysan linux: swap_free: swap-space map bad (entry 00070900)
Feb 21 19:01:51 paysan linux: swap_free: swap-space map bad (entry 00078900)
Feb 21 19:01:51 paysan kernel: swap_free: swap-space map bad (entry 00010900)
...
Looks like there are problems with incrementing shm_maxid. I have no idea
what caused the problem, since neither patch-2.1.86 nor patch-2.1.87
changed anything with the IPC.
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu