ZFS MFC heads down

Andriy Gapon avg at icyb.net.ua
Thu May 28 13:55:52 UTC 2009


on 28/05/2009 16:26 Henri Hennebert said the following:
> (gdb) bt
> #0  0x00000008012a6f22 in strlen () from /lib/libc.so.7
> #1  0x00000008012a0feb in open () from /lib/libc.so.7
> #2  0x000000080129ea59 in open () from /lib/libc.so.7
> #3  0x00000008012a1f2e in vfprintf () from /lib/libc.so.7
> #4  0x0000000801291158 in fprintf () from /lib/libc.so.7
> #5  0x0000000801290fb0 in __assert () from /lib/libc.so.7

I find the above part interesting.
Could this be because of the following discrepancy:

1)
cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:
extern void __assert(const char *, const char *, int);
2)
lib/libc/gen/assert.c:
void
__assert(func, file, line, failedexpr)
        const char *func, *file;
        int line;
        const char *failedexpr;

> #6  0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1
> #7  0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1
> #8  0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1
> #9  0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1
> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1
> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1
> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1

But back to the problem - without an additional printf we still can not what was
the value in m_owner. Only that it was not null.
Probably it's better to build with debugging symbols and examine with gdb.

-- 
Andriy Gapon


More information about the freebsd-stable mailing list