Bug 255121

Summary: Memory modified after free
Product: Base System Reporter: tschweikle
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Not Enough Information    
Severity: Affects Only Me CC: grahamperrin, markj
Priority: ---    
Version: CURRENT   
Hardware: amd64   
OS: Any   

Description tschweikle 2021-04-16 12:20:26 UTC

    
Comment 1 tschweikle 2021-04-16 12:31:02 UTC
With high loads on zfs systems crash reliably with
panic: Memory modified after free 0xfffff801cfdcb000(4096) val=dcadc0de @0xfffff801cfdcb9c4
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper()
vpanic()
panic()
trash_ctor()
item_ctor()
adb_alloc_chunks()
adb_alloc()
arc_hdr_alloc_adb()
arc_write_ready()
zio_ready()
zio_execute()
taskqueue_run_locked()
taskqueue_thread_loop()
fork_exit()
fork_trampoline()
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
Comment 2 tschweikle 2021-04-16 12:59:02 UTC
# uname -a
FreeBSD fbsd14 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n246094-e3d675958539: Fri Apr 16 08:31:30 CEST 2021     root@fbsd14:/usr/obj/usr/src/amd64.amd64/sys/FBSD14  amd64

# freebsd-version -kur
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT

# git log
commit e3d675958539eee899d42438f5b46a26f3c64902 (HEAD -> main, origin/main, origin/HEAD)
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Tue Apr 13 13:22:56 2021 +0300

    b_vflags update requries bufobj lock
    
    The trunc_dependencies() issue was reported by  Alexander Lochmann
    <alexander.lochmann@tu-dortmund.de>, who found the problem by performing
    lock analysis using LockDoc, see https://doi.org/10.1145/3302424.3303948.
Comment 3 tschweikle 2021-04-16 13:01:55 UTC
The system can be rebooted afterwards. It may fail and panic the next time at a totally different point, but with mostly the same stack backtrace.

Checking for file system inconsistencies does not show up any.
Comment 4 Andriy Gapon freebsd_committer 2021-04-16 19:22:26 UTC
(In reply to tschweikle from comment #1)
> val=dcadc0de
That's a single bit flip difference from the correct value 0xdeadc0de.
It could be a problem with the RAM.
Comment 5 Mark Johnston freebsd_committer 2021-06-16 15:58:29 UTC
(In reply to Andriy Gapon from comment #4)
Indeed, please try running memtest86 or so on the affected host and re-open the bug if you are not able to trigger any faults.