Bug #2451


panic: semexit - semid not allocated with 3.2-RELEASE

Added by lentferj over 9 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Core available if needed. This happened while I was running pkgin fug in a remote screen session, most other application processes have been terminated before.

As this seems to be related to semaphores (?) the box runs postgresql 8.4, which I killed hard before running pkgin fug. dumped core - see /var/crash/vmcore.15

Wed Nov 7 10:02:09 CET 2012

Version String: DragonFly v3.2.1.14.ga96d0-RELEASE #285: Tue Nov 6 15:20:06 CET 2012 :/usr/obj/usr/src/sys/GENERIC

panic: semexit - semid not allocated

GNU gdb (GDB) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-dragonfly".
For bug reporting instructions, please see:
Reading symbols from /boot/kernel/kernel...done.

Unread portion of the kernel message buffer:
panic: semexit - semid not allocated
cpuid = 0
Trace beginning at frame 0xd79c3bfc
panic(ffffffff,0,c08193a1,d79c3c30,d656f360) at panic+0x1a8 0xc03d4160
panic(c08193a1,c2fa8fa8,108,0,c080f744) at panic+0x1a8 0xc03d4160
semexit(d28c6ba0,0,5,d6599e70,d1b4edd4) at semexit+0xfa 0xc040d70c
exit1(0,d79c3d34,c078f3cd,d79c3cf0,d79c3d00) at exit1+0x259 0xc03c1059
rb_lwp_compare(d79c3cf0,d79c3d00,4,0,0) at rb_lwp_compare 0xc03c1560
syscall2(d79c3d40) at syscall2+0x26e 0xc078f3cd
Xint0x80_syscall() at Xint0x80_syscall+0x36 0xc075da06
Uptime: 13h1m12s
Physical memory: 993 MB
Dumping 333 MB: 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14

Actions #1

Updated by vsrinivas over 9 years ago

It looks like SEM_UNDO is broken on DragonFly 3.2+ ; I think the loop in semexit() is using a wrong index into a process's sem undo vector, an off-by-one where it is using a count as an index. In lentferj's core, httpd has one semaphore w/ a SEM_UNDO available, but it is looking in the vector at [1].

Actions #2

Updated by vsrinivas over 9 years ago is a very simple test; works on DF < 3.2, FreeBSD 9.0; DF looks at the wrong array offsets when the test is used.

Actions #3

Updated by dillon over 9 years ago

  • Status changed from New to Closed

Fixed off-by-one error noticed by vsrinivas in semexit. g.c now shows results as expected.


Also available in: Atom PDF