Date: Sat, 21 Feb 2015 16:48:12 -0800 From: Sean Bruno <sbruno@ignoranthack.me> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD current <freebsd-current@freebsd.org> Subject: Re: panic on application core dump? Message-ID: <54E9274C.9010903@ignoranthack.me> In-Reply-To: <20150221211712.GG74514@kib.kiev.ua> References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 02/21/15 13:17, Konstantin Belousov wrote:
> On Sat, Feb 21, 2015 at 12:27:22PM -0800, Sean Bruno wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>
>> Well, this is new. It looks like current panic'd when trying to
>> dump a core from a qemu crash? I can leave this at the debugger
>> for now as this is a machine doing mips package builds and is not
>> "production".
>>
>> sean
>>
>> Thu Feb 19 18:50:59 UTC 2015
>>
>> FreeBSD/amd64 (dirty.ysv.freebsd.org) (ttyu0)
>>
>> login: Feb 20 08:06:05 dirty sshd[51311]: fatal: Read from
>> socket failed: Connection reset by peer [preauth] Feb 20 16:47:29
>> dirty su: sbruno to root on /dev/pts/1 Feb 21 02:15:44 dirty
>> sshd[95051]: fatal: Read from socket failed: Connection reset by
>> peer [preauth]
>>
>>
>> Fatal trap 12: page fault while in kernel mode cpuid = 15; apic
>> id = 35 fault virtual address = 0x380 fault code =
>> supervisor read data, page not present instruction pointer =
>> 0x20:0xffffffff809b2ed1 stack pointer =
>> 0x28:0xfffffe046a3a30f0 frame pointer =
>> 0x28:0xfffffe046a3a3170 code segment = base 0x0, limit
>> 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process = 42563 (qemu-mips64) [ thread pid 42563
>> tid 100956 ] Stopped at __mtx_lock_sleep+0xb1: movl
>> 0x380(%rax),%ecx db> bt Tracing pid 42563 tid 100956 td
>> 0xfffff80109a214a0 __mtx_lock_sleep() at
>> __mtx_lock_sleep+0xb1/frame 0xfffffe046a3a3170 vref() at
>> vref+0x6d/frame 0xfffffe046a3a31a0 vn_fullpath1() at
>> vn_fullpath1+0x62/frame 0xfffffe046a3a3200 vn_fullpath_global()
>> at vn_fullpath_global+0x6e/frame 0xfffffe046a3a3240 sigexit() at
>> sigexit+0xa22/frame 0xfffffe046a3a34f0 sendsig() at
>> sendsig+0x65e/frame 0xfffffe046a3a3960 trapsignal() at
>> trapsignal+0x2f7/frame 0xfffffe046a3a39e0 trap() at
>> trap+0x3ba/frame 0xfffffe046a3a3bf0 calltrap() at
>> calltrap+0x8/frame 0xfffffe046a3a3bf0 - --- trap 0xc, rip =
>> 0x600334bc, rsp = 0x7ffbffe19990, rbp = 0x7ffffffe4a20 --- db> p
>> vref+0x6d ffffffff80a876cd
>
> Err. Is it easily reproducable in your setup ? The core file vnode
> is indeed unreferenced before notification is sent.
>
Probably not a deterministic crash, but I will get a dump and try out
this change directly today.
sean
> Try this.
>
> diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index
> 41da3dd..57f66b0 100644 --- a/sys/kern/kern_sig.c +++
> b/sys/kern/kern_sig.c @@ -3310,7 +3310,7 @@ coredump(struct thread
> *td) vattr.va_nlink != 1 || (vp->v_vflag & VV_SYSTEM) != 0) {
> VOP_UNLOCK(vp, 0); error = EFAULT; - goto close; + goto out; }
>
> VOP_UNLOCK(vp, 0); @@ -3347,17 +3347,12 @@ coredump(struct thread
> *td) VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &lf, F_FLOCK); }
> vn_rangelock_unlock(vp, rl_cookie); -close: - error1 = vn_close(vp,
> FWRITE, cred, td); - if (error == 0) - error = error1; - else -
> goto out; + /* * Notify the userland helper that a process
> triggered a core dump. * This allows the helper to run an automated
> debugging session. */ - if (coredump_devctl == 0) + if (error != 0
> || coredump_devctl == 0) goto out; len = MAXPATHLEN * 2 +
> sizeof(comm_name) - 1 + sizeof(' ') + sizeof(core_name) - 1; @@
> -3377,6 +3372,9 @@ close: strlcat(data, fullpath, len);
> devctl_notify("kernel", "signal", "coredump", data); out: + error1
> = vn_close(vp, FWRITE, cred, td); + if (error == 0) + error =
> error1; #ifdef AUDIT audit_proc_coredump(td, name, error); #endif
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQF8BAEBCgBmBQJU6SdJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kZlIH/0usK1j2BfzNT95UFE6KAoUv
0+JqmkJyGiR9hEQvvgcSiL9++NXnTLLz1z5SGbwAqL0hebXYckLXhxusObENBnnK
ZMz12bsFmAI615eXK6ZJjsnZJWzmU/tjQjcY93Rao0M+AUTaGk5PFoR486hjhSM+
7lg4KA+BlD5K991Zy9BzR0ZGSkjRnuZSQBsKbHe1RGbS1SAsf4PyfpvXDt0lhfN9
E/C2uvehYbBJi3vJuJx3pVXg5s+uyutnGLjBRY/sqOuiDOuGfHFdKbdgtApIAc0o
B0/3I2IbAx3q0zy9c/4nuKjKHbr+di2pbFymUAH8beHcBuo5wsNFvfGTOqiX5ro=
=nlAC
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54E9274C.9010903>