11-BETA3 Panic: Memory modified after free

Harald Schmalzbauer h.schmalzbauer at omnilan.de
Mon Aug 1 07:16:18 UTC 2016


 Hello,

11-BETA3 crashes spontaniously with this:

Unread portion of the kernel message buffer:
panic: Memory modified after free 0xfffff8000709f400(1024) val=dedeadc0
@ 0xfffff8000709f400

cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe007a2e8540
vpanic() at vpanic+0x182/frame 0xfffffe007a2e85c0
panic() at panic+0x43/frame 0xfffffe007a2e8620
trash_ctor() at trash_ctor+0x4b/frame 0xfffffe007a2e8630
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfffffe007a2e8690
namei() at namei+0xe4/frame 0xfffffe007a2e8750
kern_statat() at kern_statat+0xa8/frame 0xfffffe007a2e8900
sys_stat() at sys_stat+0x2d/frame 0xfffffe007a2e89a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe007a2e8ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe007a2e8ab0
--- syscall (188, FreeBSD ELF64, sys_stat), rip = 0x800e4f48a, rsp =
0x7fffffffde58, rbp = 0x7fffffffdfb0 ---
KDB: enter: panic

#0  doadump (textdump=2049867776) at pcpu.h:221
221             __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) tr
trace command requires an argument
(kgdb) backtrace
#0  doadump (textdump=2049867776) at pcpu.h:221
#1  0xffffffff80393346 in db_fncall (dummy1=<value optimized out>,
dummy2=<value optimized out>, dummy3=<value optimized out>,
dummy4=<value optimized out>)
    at /usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_command.c:568
#2  0xffffffff80392de9 in db_command (cmd_table=<value optimized out>)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_command.c:440
#3  0xffffffff80392b44 in db_command_loop () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_command.c:493
#4  0xffffffff80395a7b in db_trap (type=<value optimized out>,
code=<value optimized out>) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_main.c:251
#5  0xffffffff80a96133 in kdb_trap (type=<value optimized out>,
code=<value optimized out>, tf=<value optimized out>)
    at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/subr_kdb.c:654
#6  0xffffffff80ec5a4d in trap (frame=0xfffffe007a2e8470) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/trap.c:556
#7  0xffffffff80ea6161 in calltrap () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:236
#8  0xffffffff80a957db in kdb_enter (why=0xffffffff813f055e "panic",
msg=0x80 <Address 0x80 out of bounds>) at cpufunc.h:63
#9  0xffffffff80a562df in vpanic (fmt=<value optimized out>,
ap=0xfffffe007a2e8600) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:752
#10 0xffffffff80a56343 in panic (fmt=0xffffffff82890250 "\004") at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690
#11 0xffffffff80d349eb in trash_ctor (mem=<value optimized out>,
size=<value optimized out>, arg=<value optimized out>, flags=<value
optimized out>)
    at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_dbg.c:80
#12 0xffffffff80d308f4 in uma_zalloc_arg (zone=<value optimized out>,
udata=0x0, flags=<value optimized out>)
    at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_core.c:2156
#13 0xffffffff80b09384 in namei (ndp=0xfffffe007a2e8810) at uma.h:336
#14 0xffffffff80b20168 in kern_statat (td=0xfffff800078ee000,
flag=<value optimized out>, fd=-100, path=0x1a1e <Address 0x1a1e out of
bounds>,
    pathseg=<value optimized out>, sbp=<value optimized out>,
hook=0x8014161e0) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/vfs_syscalls.c:2160
#15 0xffffffff80b2009d in sys_stat (td=0xffffffff82890250,
uap=0xfffffe007a2e8a40) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/vfs_syscalls.c:2115
#16 0xffffffff80ec6b2b in amd64_syscall (td=0xfffff800078ee000,
traced=0) at subr_syscall.c:135
#17 0xffffffff80ea644b in Xfast_syscall () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:396
#18 0x0000000800e4f48a in ?? ()
Previous frame inner to this frame (corrupt stack?)

Thanks for any help, tell me if I can help narrow it down. A wild guess is it's related to unionfs?

-Harry


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20160801/962babca/attachment.sig>


More information about the freebsd-stable mailing list