Bug 255121 - Memory modified after free
Summary: Memory modified after free
Status: Closed Not Enough Information
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-16 12:20 UTC by tschweikle
Modified: 2021-06-16 15:58 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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
            freebsd_triage
        

        
          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
            freebsd_triage
        

        
          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.