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