Date: Tue, 08 Oct 2019 18:25:19 +0300 From: "Yuri Pankov" <yuripv@yuripv.net> To: "Andriy Gapon" <avg@FreeBSD.org>, freebsd-fs@FreeBSD.org Subject: Re: panic: Memory modified after free Message-ID: <16474299-09e4-4b6f-9e12-5e04b7b4c3b6@www.fastmail.com> 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 Tue, Oct 8, 2019, at 10: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. Thank you. Laptop with non-ECC memory, which started showing those bit flips after several memtest86 runs (it didn't previously). Sorry for the noise!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16474299-09e4-4b6f-9e12-5e04b7b4c3b6>