Re: crash on process exit.. current at about r332467

2018-04-25 Thread Bryan Drewery
On 4/25/18 12:41 PM, Bryan Drewery wrote:
> On 4/25/18 12:39 PM, Bryan Drewery wrote:
>> On 4/23/18 7:50 AM, Julian Elischer wrote:
>>> back trace at:  http://www.freebsd.org/~julian/bob-crash.png
>>>
>>> If anyone wants to take a look..
>>>
>>> In the exit syscall, while deallocating a vm object.
>>>
>>> I haven't see references to a similar crash in the last 10 days or so..
>>> But if it rings any bells...
>>>
>>
>> I just hit this on r332455 and have a dump.
>>
>>> panic: Bad link elm 0xf811cd920e60 prev->next != elm
>>> cpuid = 10
>>> time = 1524682939
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>>> 0xfe23f450c3b0
>>> vpanic() at vpanic+0x18d/frame 0xfe23f450c410
>>> panic() at panic+0x43/frame 0xfe23f450c470
>>> vm_object_destroy() at vm_object_destroy/frame 0xfe23f450c4d0
>>> vm_object_deallocate() at vm_object_deallocate+0x45c/frame 
>>> 0xfe23f450c530
>>> vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 
>>> 0xfe23f450c560
>>> vm_map_remove() at vm_map_remove+0xc6/frame 0xfe23f450c590
>>> exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfe23f450c5f0
>>> exec_elf64_imgact() at exec_elf64_imgact+0x8fb/frame 0xfe23f450c6e0
>>> kern_execve() at kern_execve+0x82c/frame 0xfe23f450ca40
>>> sys_execve() at sys_execve+0x4c/frame 0xfe23f450cac0
>>> amd64_syscall() at amd64_syscall+0x786/frame 0xfe23f450cbf0
>>> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe23f450cbf0
>>> --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d7af7a, rsp = 
>>> 0x7fffbd28, rbp = 0x7fffbe70 ---
>>
>>
>>
> 
> It's a different stack than Julian's but it seems like the same issue to me.
> 

Here's the real stack:

> #12 0x80b6d1c3 in panic (fmt=0x81dee958  
> "\322\237'\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:764
> #13 0x80eac060 in vm_object_terminate (object=0xf80587c4de00) at 
> /usr/src/sys/vm/vm_object.c:868
> #14 0x80eaaf2c in vm_object_deallocate (object=0xf80587c4de00) at 
> /usr/src/sys/vm/vm_object.c:684
> #15 0x80ea0089 in vm_map_entry_deallocate (system_map= variable: Cannot access memory at address 0x0>, entry=) at 
> /usr/src/sys/vm/vm_map.c:2997
> #16 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:541
> #17 0x80ea5186 in _vm_map_unlock (map=, 
> file=, line=3189) at /usr/src/sys/vm/vm_map.c:554
> #18 vm_map_remove (map=, start=4096, end=140737488355328) at 
> /usr/src/sys/vm/vm_map.c:3189
> #19 0x80b24c35 in exec_new_vmspace (imgp=0xfe23f450c8b0, 
> sv=) at /usr/src/sys/kern/kern_exec.c:1099
> #20 0x80afaf1b in exec_elf64_imgact (imgp=) at 
> /usr/src/sys/kern/imgact_elf.c:922
> #21 0x80b2380c in do_execve (td=, args= out>, mac_p=) at /usr/src/sys/kern/kern_exec.c:606
> #22 kern_execve (td=, args=, mac_p= out>) at /usr/src/sys/kern/kern_exec.c:351
> #23 0x80b22c9c in sys_execve (td=0xf801493c6000, 
> uap=0xf801493c63c0) at /usr/src/sys/kern/kern_exec.c:225

> (kgdb) frame 13
> #13 0x80eac060 in vm_object_terminate (object=0xf80587c4de00) at 
> /usr/src/sys/vm/vm_object.c:868
> 868 KASSERT(object->cred == NULL || object->type == OBJT_DEFAULT 
> ||
> (kgdb) p *object
> $2 = {lock = {lock_object = {lo_name = 0x81214cff "vm object", 
> lo_flags = 627245056, lo_data = 0, lo_witness = 0xf8123fd6a700}, rw_lock 
> = 18446735283140190208}, object_list = {
> tqe_next = 0xf80587c67000, tqe_prev = 0xf80587c4dd20}, 
> shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0xf80a9606c500, 
> le_prev = 0xf8054f0c2c30}, memq = {
> tqh_first = 0xf811d00c9980, tqh_last = 0xf811d850b8a0}, rtree = 
> {rt_root = 18446735322516082688}, size = 2048, domain = {dr_policy = 0x0, 
> dr_iterator = 0}, generation = 1, ref_count = 0,
>   shadow_count = 0, memattr = 6 '\006', type = 0 '\000', flags = 12296, 
> pg_color = 1024, paging_in_progress = 0, resident_page_count = 5, 
> backing_object = 0x0, backing_object_offset = 0,
>   pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {lh_first = 
> 0xf811cbac2240}, handle = 0x0, un_pager = {vnp = {vnp_size = 0, 
> writemappings = 0}, devp = {devp_pglist = {
> tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = 
> {sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 0x0, 
> swp_blks = {pt_root = 0}}}, cred = 0xf807ebd91500,
>   charge = 8388608, umtx_data = 0x0}

object->type = OBJT_DEFAULT.

Er I'm not sure what's going on here as line 868 is a totally different
assert than the queue(3) one in the msgbuf...

> 868 KASSERT(object->cred == NULL || object->type == OBJT_DEFAULT ||
> 869 object->type == OBJT_SWAP,
> 870 ("%s: non-swap obj %p has cred", __func__, object));



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: crash on process exit.. current at about r332467

2018-04-25 Thread Bryan Drewery
On 4/23/18 7:50 AM, Julian Elischer wrote:
> back trace at:  http://www.freebsd.org/~julian/bob-crash.png
> 
> If anyone wants to take a look..
> 
> In the exit syscall, while deallocating a vm object.
> 
> I haven't see references to a similar crash in the last 10 days or so..
> But if it rings any bells...
> 

I just hit this on r332455 and have a dump.

> panic: Bad link elm 0xf811cd920e60 prev->next != elm
> cpuid = 10
> time = 1524682939
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe23f450c3b0
> vpanic() at vpanic+0x18d/frame 0xfe23f450c410
> panic() at panic+0x43/frame 0xfe23f450c470
> vm_object_destroy() at vm_object_destroy/frame 0xfe23f450c4d0
> vm_object_deallocate() at vm_object_deallocate+0x45c/frame 0xfe23f450c530
> vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 
> 0xfe23f450c560
> vm_map_remove() at vm_map_remove+0xc6/frame 0xfe23f450c590
> exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfe23f450c5f0
> exec_elf64_imgact() at exec_elf64_imgact+0x8fb/frame 0xfe23f450c6e0
> kern_execve() at kern_execve+0x82c/frame 0xfe23f450ca40
> sys_execve() at sys_execve+0x4c/frame 0xfe23f450cac0
> amd64_syscall() at amd64_syscall+0x786/frame 0xfe23f450cbf0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe23f450cbf0
> --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d7af7a, rsp = 
> 0x7fffbd28, rbp = 0x7fffbe70 ---



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: crash on process exit.. current at about r332467

2018-04-25 Thread Bryan Drewery
On 4/25/18 12:39 PM, Bryan Drewery wrote:
> On 4/23/18 7:50 AM, Julian Elischer wrote:
>> back trace at:  http://www.freebsd.org/~julian/bob-crash.png
>>
>> If anyone wants to take a look..
>>
>> In the exit syscall, while deallocating a vm object.
>>
>> I haven't see references to a similar crash in the last 10 days or so..
>> But if it rings any bells...
>>
> 
> I just hit this on r332455 and have a dump.
> 
>> panic: Bad link elm 0xf811cd920e60 prev->next != elm
>> cpuid = 10
>> time = 1524682939
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfe23f450c3b0
>> vpanic() at vpanic+0x18d/frame 0xfe23f450c410
>> panic() at panic+0x43/frame 0xfe23f450c470
>> vm_object_destroy() at vm_object_destroy/frame 0xfe23f450c4d0
>> vm_object_deallocate() at vm_object_deallocate+0x45c/frame 0xfe23f450c530
>> vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 
>> 0xfe23f450c560
>> vm_map_remove() at vm_map_remove+0xc6/frame 0xfe23f450c590
>> exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfe23f450c5f0
>> exec_elf64_imgact() at exec_elf64_imgact+0x8fb/frame 0xfe23f450c6e0
>> kern_execve() at kern_execve+0x82c/frame 0xfe23f450ca40
>> sys_execve() at sys_execve+0x4c/frame 0xfe23f450cac0
>> amd64_syscall() at amd64_syscall+0x786/frame 0xfe23f450cbf0
>> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe23f450cbf0
>> --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d7af7a, rsp = 
>> 0x7fffbd28, rbp = 0x7fffbe70 ---
> 
> 
> 

It's a different stack than Julian's but it seems like the same issue to me.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature