panic: Memory modified after free

Julian Elischer julian at freebsd.org
Tue Oct 8 18:02:51 UTC 2019


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?





More information about the freebsd-fs mailing list