Hi I get a lot of crashes on NetBSD with latest git code. looking at core dumps, it is obvious I get memory corruption, as I find various structure overwritten by texts (file path or content). Linking with electric fence produces a much earlier crash, always at the same place. Here is how it looks: Program terminated with signal 11, Segmentation fault. #0 0xbb8aab70 in strlen () from /usr/lib/libc.so.12 (gdb) bt #0 0xbb8aab70 in strlen () from /usr/lib/libc.so.12 #1 0xbaa5ec1e in gf_strdup (src=0x0) at ../../../../libglusterfs/src/mem-pool.h:119 #2 0xbaa76dbf in client3_1_getxattr (frame=0xbb77f5c0, this=0xba3cd000, data=0xbfbfe18c) at client3_1-fops.c:4641 #3 0xbaa59ab8 in client_getxattr (frame=0xbb77f5c0, this=0xba3cd000, loc=0xb9402dd0, name=0x0, xdata=0x0) at client.c:1452 #4 0xb9ac3c7d in afr_sh_metadata_sync_prepare (frame=0xba8026bc, this=0xba3ce000) at afr-self-heal-metadata.c:419 #5 0xb9ac428b in afr_sh_metadata_fix (frame=0xba8026bc, this=0xba3ce000, op_ret=0, op_errno=0) at afr-self-heal-metadata.c:522 #6 0xb9abeb2b in afr_sh_common_lookup_cbk (frame=0xba8026bc, cookie=0x1, this=0xba3ce000, op_ret=0, op_errno=0, inode=0xb8b001a0, buf=0xbfbfe424, xattr=0xba401394, postparent=0xbfbfe3bc) at afr-self-heal-common.c:1311 #7 0xbaa6dc10 in client3_1_lookup_cbk (req=0xb92010d8, iov=0xb92010f8, count=1, myframe=0xbb77f550) at client3_1-fops.c:2636 Frame 4 is this: STACK_WIND (frame, afr_sh_metadata_getxattr_cbk, priv->children[source], priv->children[source]->fops->getxattr, &local->loc, NULL, NULL); Then in frame 3, I get args.name = NULL client_getxattr (call_frame_t *frame, xlator_t *this, loc_t *loc, const char *name, dict_t *xdata) (...) args.name = name; (...) ret = proc->fn (frame, this, &args); In frame 2, args->name = NULL client3_1_getxattr (call_frame_t *frame, xlator_t *this, void *data) (...) args = data; (...) local->name = gf_strdup (args->name); And there we will crash in gf_strdup(). The root cause is afr_sh_metadata_sync_prepare() calling client_getxattr with NULL arguments. The fix is beyond my knowledge of glusterfs internals, but I am sure that some folks here will be able to comment. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@xxxxxxxxxx