DragonFlyBSD

: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>

:panic: hammer left edge case 0000000000004000 16384
:--
:Gergo Szakal MD <bastyaelvtars@gmail.com>

It's turning out to be more serious.  The mirror propagation is breaking
    something.  What was the machine doing at the time of the panic?

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

::panic: hammer left edge case 0000000000004000 16384

I've committed 60G which should hopefully deal with both bugs
    revealed by this panic and crash dump.

Also, please continue to test filesystem out-of-space issues.  It
    should no longer create empty files after write() failures are
    reported.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Mon, 7 Jul 2008 15:05:31 -0700 (PDT)
Matthew Dillon <dillon@apollo.backplane.com> wrote:

I was copying little files within a HAMMER partition. I do not use
mirroring.

:> It's turning out to be more serious. The mirror propagation is
:> breaking something. What was the machine doing at the time of the
:> panic?
:
:I was copying little files within a HAMMER partition. I do not use
:mirroring.
:
:--
:Gergo Szakal MD <bastyaelvtars@gmail.com>

It was the propagation of the transaction id up the B-Tree, which occurs
    whether you are mirroring or not.

It's all fixed now :-)

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Bug is fixed according to dillon@ in msg4887