Re: sendfile panic

Kris Kennaway wrote:
> 8 machines panicked overnight with:
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xf0
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc04e12f0
> stack pointer           = 0x28:0xe5e1fb30
> frame pointer           = 0x28:0xe5e1fb4c
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 93306 (conftest)
> db> wh
> Tracing pid 93306 tid 100139 td 0xc373a1c0
> _mtx_lock_flags(e0,0,c06d58d2,8e7,c2fda104,...) at _mtx_lock_flags+0x40
> kern_sendfile(c373a1c0,e5e1fd04,0,c44fc640,0,...) at kern_sendfile+0xe89
> do_sendfile(c373a1c0,e5e1fd04,0,e5e1fd30,c069ff73,...) at do_sendfile+0xc4
> sendfile(c373a1c0,e5e1fd04,20,4,c,...) at sendfile+0x20
> syscall(3b,3b,3b,bfbfe42c,bfbfe424,...) at syscall+0x2e3
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x280c9b57, esp = 0xbfbfe3ac, ebp = 0xbfbfe3d8 ---
> 
> Looks like it's a GNU configure test failing, so something fairly
> basic is broken in sendfile.  I think it's the lighttpd port that is
> triggering the bug.

Coverity already complained about the bug and I have prepared a fix
already.  Need to test and commit in the next hours.

-- 
Andre