Re: panic: vm_page_free_toq: freeing mapped page

Ulrich Spörlein wrote:
> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote:
>   
>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote:
>>     
>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein<uqs_at_spoerlein.net> wrote:
>>>       
>>>> Hi,
>>>>
>>>> 8.0 BETA1 _at_ r195622 will panic reliably when running the clang static
>>>> analyzer on a buildworld with something like the following panic:
>>>>
>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30
>>>> cpuid = 1
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
>>>> panic() at panic+0x182
>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6
>>>> vm_object_terminate() at vm_object_terminate+0xb7
>>>> vm_object_deallocate() at vm_object_deallocate+0x17a
>>>> _vm_map_unlock() at _vm_map_unlock+0x70
>>>> vm_map_remove() at vm_map_remove+0x6f
>>>> vmspace_free() at vmspace_free+0x56
>>>> vmspace_exec() at vmspace_exec+0x56
>>>> exec_new_vmspace() at exec_new_vmspace+0x133
>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee
>>>> kern_execve() at kern_execve+0x3b2
>>>> execve() at execve+0x3d
>>>> syscall() at syscall+0x1af
>>>> Xfast_syscall() at Xfast_syscall+0xe1
>>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 ---
>>>>         
>>> Can you try the following change:
>>>
>>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297
>>>       
>> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into
>> the scan-build run. So no luck there. Next up is a test using the
>> GENERIC kernel.
>>     
>
>
> No improvement with a GENERIC kernel. Next up will be to run this with
> clean sysctl, loader.conf, etc. Then I'll try disabling SMP.
>
> Does the backtrace above point to any specific subsystem? I'm using UFS,
> ZFS and GELI on this machine and could try a few combinations...
>   

The interesting thing about the backtrace is that it shows a 32-bit i386 
executable being started on a 64-bit amd64 machine.  I've seen this 
backtrace once before, and you'll find it in the PR database.  In that 
case, the problem "went away" after the known-to-be-broken 
ZERO_COPY_SOCKETS option was removed from the reporter's kernel 
configuration.  However, I don't see that as the culprit here.

Alan