DragonFly bugs List (threaded) for 2008-07
DragonFly BSD
DragonFly bugs List (threaded) for 2008-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: HAMMER crash again


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 7 Jul 2008 12:28:34 -0700 (PDT)

:panic: hammer left edge case 0000000000004000 16384
:
:...
:#in panic (fmt=0xc0574358 "hammer left edge case %016llx %d\n")
:#at /usr/src/sys/kern/kern_shutdown.c:798 11 0xc042f905 in
:#hammer_ip_delete_range (cursor=0xcad9dc5c, ip=0xcbdd6150,
:#ran_beg=131072, ran_end=9223372036854775807,
:    truncating=2) at /usr/src/sys/vfs/hammer/hammer_object.c:1688
:#12 0xc0428c5c in hammer_sync_inode (ip=0xcbdd6150)
:#at /usr/src/sys/vfs/hammer/hammer_inode.c:2172 13 0xc0426f55 in
:#hammer_flusher_flush_inode (ip=0xcbdd6150, trans=0xcad88114)
:#at /usr/src/sys/vfs/hammer/hammer_flusher.c:361 14 0xc0427133 in
:#hammer_flusher_slave_thread (arg=0xc1666870)
:#at /usr/src/sys/vfs/hammer/hammer_flusher.c:236 15 0xc02c8ee8 in
:#lwkt_deschedule_self (td=Cannot access memory at address 0x8
:) at /usr/src/sys/kern/lwkt_thread.c:223
:Backtrace stopped: previous frame inner to this frame (corrupt stack?)
:
:-- 
:Gergo Szakal MD <bastyaelvtars@gmail.com>

    Yah, I'd like the dump on that one, just to be sure it is what I think
    it is.

    It is related to the direct-write work.   Direct writes are allowed to
    write in-memory data records which override their on-media countparts
    (when seeking into the middle of a file and doing a write).  In this
    case the above situation has occured and then userland ALSO did a
    truncation on the file, causing hammer_ip_delete_range() to be
    called.

    Because *_delete_range() needs to see both records so it can delete
    both records, it has set the HAMMER_CURSOR_DELETE_VISIBILITY flag.

    The bug is actually that the assertion itself is wrong.  It sees the
    first record, shifts 'ran_beg' to the end of the first record, then
    sees the second record's base offset is less then the new ending
    offset because the second record is the on-disk version of the first
    record.  The assertion really needs to be:

	if (off < ran_beg && leaf->base.key > ran_beg)
	    panic(...)

    instead of:

	if (off < ran_beg)
		panic(...)

    In anycase, if you could send me the URL of your dump in private email
    I'll make sure that the state matches what I think happened.

    Nice catch!  340 assertions in HAMMER and this is like only the third
    one where the bug turned out to be the assertion itself :-)

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]