Date: Tue, 8 Oct 2019 11:02:37 -0700 From: Julian Elischer <julian@freebsd.org> To: Andriy Gapon <avg@FreeBSD.org>, Yuri Pankov <yuripv@yuripv.net>, freebsd-fs@FreeBSD.org Subject: Re: panic: Memory modified after free Message-ID: <069ede9f-1098-e809-50a2-55844dd6b57c@freebsd.org> In-Reply-To: <e2ec577f-3f6c-b2c1-6139-594a605ada15@FreeBSD.org> References: <68853b35-e202-40b9-80ad-b29bc49bb5b4@www.fastmail.com> <e2ec577f-3f6c-b2c1-6139-594a605ada15@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/8/19 12:12 AM, Andriy Gapon wrote: > On 08/10/2019 03:39, Yuri Pankov wrote: >> (posting to fs@ as backtrace suggests zfs) >> >> Started seeing the following panic (sometimes reproducible, so can't point specific revision or time range) untaring an archive over ssh into my home directory on zfs: >> >> panic: Memory modified after free 0xfffff80404cff000(4096) val=dead40de @ 0xfffff80404cff694 >> >> cpuid = 4 >> time = 1570493241 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00df912650 >> vpanic() at vpanic+0x19d/frame 0xfffffe00df9126a0 >> panic() at panic+0x43/frame 0xfffffe00df912700 >> trash_ctor() at trash_ctor+0x49/frame 0xfffffe00df912710 >> uma_zalloc_arg() at uma_zalloc_arg+0xa24/frame 0xfffffe00df9127a0 >> abd_alloc() at abd_alloc+0x152/frame 0xfffffe00df9127f0 >> arc_hdr_alloc_pabd() at arc_hdr_alloc_pabd+0x166/frame 0xfffffe00df912820 >> arc_write_ready() at arc_write_ready+0x463/frame 0xfffffe00df912860 >> zio_ready() at zio_ready+0xde/frame 0xfffffe00df9128a0 >> zio_execute() at zio_execute+0x17c/frame 0xfffffe00df9128e0 >> taskqueue_run_locked() at taskqueue_run_locked+0x10c/frame 0xfffffe00df912940 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfffffe00df912970 >> fork_exit() at fork_exit+0x84/frame 0xfffffe00df9129b0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00df9129b0 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> >> Full text dump is at https://people.freebsd.org/~yuripv/core.txt.0. >> >> Real problem or failing hardware (memory?)? > Given a single bit difference between 0xdead40de and 0xdeadc0de, it can be > either. If the memory is not ECC, then I would assume a hardware problem first. > > so assuming that we know what type of object it was, if it is being reused, is that bit something that is or'd or anded?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?069ede9f-1098-e809-50a2-55844dd6b57c>