Date: Wed, 25 Apr 2018 13:35:20 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: freebsd-current <freebsd-current@freebsd.org> Subject: Re: crash on process exit.. current at about r332467 Message-ID: <7de7c555-26f0-6b7d-f72f-37a17adea52c@FreeBSD.org> In-Reply-To: <da5f0963-03fe-dbd2-f271-3a44bb6f3049@FreeBSD.org> References: <9479e941-39be-e6e2-869e-aac475c5e33a@freebsd.org> <8644151e-7dce-1283-e804-93a4b1b7bb0b@FreeBSD.org> <da5f0963-03fe-dbd2-f271-3a44bb6f3049@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PF4398TqiUJzExLaa4PAdBmjvZtivQfPi Content-Type: multipart/mixed; boundary="GUR4RNdWSuAvgiP6LeJNzkRnpezODOuET"; protected-headers="v1" From: Bryan Drewery <bdrewery@FreeBSD.org> To: freebsd-current <freebsd-current@freebsd.org> Message-ID: <7de7c555-26f0-6b7d-f72f-37a17adea52c@FreeBSD.org> Subject: Re: crash on process exit.. current at about r332467 References: <9479e941-39be-e6e2-869e-aac475c5e33a@freebsd.org> <8644151e-7dce-1283-e804-93a4b1b7bb0b@FreeBSD.org> <da5f0963-03fe-dbd2-f271-3a44bb6f3049@FreeBSD.org> In-Reply-To: <da5f0963-03fe-dbd2-f271-3a44bb6f3049@FreeBSD.org> --GUR4RNdWSuAvgiP6LeJNzkRnpezODOuET Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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:=C2=A0 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= =2E. >>> But if it rings any bells... >>> >> >> I just hit this on r332455 and have a dump. >> >>> panic: Bad link elm 0xfffff811cd920e60 prev->next !=3D elm >>> cpuid =3D 10 >>> time =3D 1524682939 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe2= 3f450c3b0 >>> vpanic() at vpanic+0x18d/frame 0xfffffe23f450c410 >>> panic() at panic+0x43/frame 0xfffffe23f450c470 >>> vm_object_destroy() at vm_object_destroy/frame 0xfffffe23f450c4d0 >>> vm_object_deallocate() at vm_object_deallocate+0x45c/frame 0xfffffe23= f450c530 >>> vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 0xfff= ffe23f450c560 >>> vm_map_remove() at vm_map_remove+0xc6/frame 0xfffffe23f450c590 >>> exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfffffe23f450c5f0= >>> exec_elf64_imgact() at exec_elf64_imgact+0x8fb/frame 0xfffffe23f450c6= e0 >>> kern_execve() at kern_execve+0x82c/frame 0xfffffe23f450ca40 >>> sys_execve() at sys_execve+0x4c/frame 0xfffffe23f450cac0 >>> amd64_syscall() at amd64_syscall+0x786/frame 0xfffffe23f450cbf0 >>> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe23f4= 50cbf0 >>> --- syscall (59, FreeBSD ELF64, sys_execve), rip =3D 0x800d7af7a, rsp= =3D 0x7fffffffbd28, rbp =3D 0x7fffffffbe70 --- >> >> >> >=20 > It's a different stack than Julian's but it seems like the same issue t= o me. >=20 Here's the real stack: > #12 0xffffffff80b6d1c3 in panic (fmt=3D0xffffffff81dee958 <cnputs_mtx> = "\322\237'\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:764= > #13 0xffffffff80eac060 in vm_object_terminate (object=3D0xfffff80587c4d= e00) at /usr/src/sys/vm/vm_object.c:868 > #14 0xffffffff80eaaf2c in vm_object_deallocate (object=3D0xfffff80587c4= de00) at /usr/src/sys/vm/vm_object.c:684 > #15 0xffffffff80ea0089 in vm_map_entry_deallocate (system_map=3D<error = reading variable: Cannot access memory at address 0x0>, entry=3D<optimize= d out>) at /usr/src/sys/vm/vm_map.c:2997 > #16 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:541 > #17 0xffffffff80ea5186 in _vm_map_unlock (map=3D<optimized out>, file=3D= <optimized out>, line=3D3189) at /usr/src/sys/vm/vm_map.c:554 > #18 vm_map_remove (map=3D<optimized out>, start=3D4096, end=3D140737488= 355328) at /usr/src/sys/vm/vm_map.c:3189 > #19 0xffffffff80b24c35 in exec_new_vmspace (imgp=3D0xfffffe23f450c8b0, = sv=3D<optimized out>) at /usr/src/sys/kern/kern_exec.c:1099 > #20 0xffffffff80afaf1b in exec_elf64_imgact (imgp=3D<optimized out>) at= /usr/src/sys/kern/imgact_elf.c:922 > #21 0xffffffff80b2380c in do_execve (td=3D<optimized out>, args=3D<opti= mized out>, mac_p=3D<optimized out>) at /usr/src/sys/kern/kern_exec.c:606= > #22 kern_execve (td=3D<optimized out>, args=3D<optimized out>, mac_p=3D= <optimized out>) at /usr/src/sys/kern/kern_exec.c:351 > #23 0xffffffff80b22c9c in sys_execve (td=3D0xfffff801493c6000, uap=3D0x= fffff801493c63c0) at /usr/src/sys/kern/kern_exec.c:225 > (kgdb) frame 13 > #13 0xffffffff80eac060 in vm_object_terminate (object=3D0xfffff80587c4d= e00) at /usr/src/sys/vm/vm_object.c:868 > 868 KASSERT(object->cred =3D=3D NULL || object->type =3D=3D= OBJT_DEFAULT || > (kgdb) p *object > $2 =3D {lock =3D {lock_object =3D {lo_name =3D 0xffffffff81214cff "vm o= bject", lo_flags =3D 627245056, lo_data =3D 0, lo_witness =3D 0xfffff8123= fd6a700}, rw_lock =3D 18446735283140190208}, object_list =3D { > tqe_next =3D 0xfffff80587c67000, tqe_prev =3D 0xfffff80587c4dd20}, = shadow_head =3D {lh_first =3D 0x0}, shadow_list =3D {le_next =3D 0xfffff8= 0a9606c500, le_prev =3D 0xfffff8054f0c2c30}, memq =3D { > tqh_first =3D 0xfffff811d00c9980, tqh_last =3D 0xfffff811d850b8a0},= rtree =3D {rt_root =3D 18446735322516082688}, size =3D 2048, domain =3D = {dr_policy =3D 0x0, dr_iterator =3D 0}, generation =3D 1, ref_count =3D 0= , > shadow_count =3D 0, memattr =3D 6 '\006', type =3D 0 '\000', flags =3D= 12296, pg_color =3D 1024, paging_in_progress =3D 0, resident_page_count = =3D 5, backing_object =3D 0x0, backing_object_offset =3D 0, > pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, rvq =3D {= lh_first =3D 0xfffff811cbac2240}, handle =3D 0x0, un_pager =3D {vnp =3D {= vnp_size =3D 0, writemappings =3D 0}, devp =3D {devp_pglist =3D { > tqh_first =3D 0x0, tqh_last =3D 0x0}, ops =3D 0x0, dev =3D 0x0}= , sgp =3D {sgp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}}, swp =3D= {swp_tmpfs =3D 0x0, swp_blks =3D {pt_root =3D 0}}}, cred =3D 0xfffff807e= bd91500, > charge =3D 8388608, umtx_data =3D 0x0} object->type =3D 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 =3D=3D NULL || object->type =3D=3D OBJ= T_DEFAULT || > 869 object->type =3D=3D OBJT_SWAP, > 870 ("%s: non-swap obj %p has cred", __func__, object)); --=20 Regards, Bryan Drewery --GUR4RNdWSuAvgiP6LeJNzkRnpezODOuET-- --PF4398TqiUJzExLaa4PAdBmjvZtivQfPi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAlrg5okACgkQNddxu25G l8/lnAgAvp4Hc6dL1GIb2F94XQQLZ8rDkGeuAbC6sH2QFhXKFDX/TCxYWkhTY2Lu a/W8WnntrfdrCxnc78jWDA/ssPyeExK/Vz0i0VBka8BOJBX/wx3q9cw2zK+2dnOf zA3QaZBzEKJNoXRAiXkNUQnZL4fZjtF8gf+9ENzEC41G1L6EALkyCfqxBD65Z+Hc e0T3fwMStfCKmeEB0JAc3v54/b/+2ZC8Fr+E9E4SgS6wIL9HK+xFgVKMYA8qQOU+ gXwZ3Nogt0Su7Aac27WSvsHNNQpBZ8NLH7Am9nlXX1Y6gc4iMjMX/e/+/LTpBRZO oT0Ypr4t4aa6ZG7sW1Rs6tFvzuJzMw== =U1+M -----END PGP SIGNATURE----- --PF4398TqiUJzExLaa4PAdBmjvZtivQfPi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7de7c555-26f0-6b7d-f72f-37a17adea52c>