Hi
By looping on tests/basic/afr/self-heald.t I can sometime have a crash
on this assertion:
#4 0xb9d2d966 in client3_3_opendir (frame=0xbb289918, this=0xbb2bc018,
data=0xb89fe73c) at client-rpc-fops.c:4412
4412 GF_ASSERT_AND_GOTO_WITH_ERROR (this->name,
4413 !uuid_is_null (*((uuid_t*)req.gfid)),
4414 unwind, op_errno, EINVAL);
Here is the backtrace:
#4 0xb9d2d966 in client3_3_opendir (frame=0xbb289918, this=0xbb2bc018,
data=0xb89fe73c) at client-rpc-fops.c:4412
#5 0xb9d136fb in client_opendir (frame=0xbb289918, this=0xbb2bc018,
loc=0xb89ff7d4, fd=0xbb2429d8, xdata=0x0) at client.c:1101
#6 0xbb7a5757 in syncop_opendir (subvol=0xbb2bc018, loc=0xb89ff7d4,
fd=0xbb2429d8) at syncop.c:1198
#7 0xb9ce2413 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb28a608)
at afr-self-heald.c:532
#8 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb28a338)
at afr-self-heald.c:582
#9 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb28a2a8)
at afr-self-heald.c:582
#10 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb28a218)
at afr-self-heald.c:582
#11 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb28a068)
at afr-self-heald.c:582
#12 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb289c78)
at afr-self-heald.c:582
#13 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb289e28)
(...)
At frame 8 I can see some inconstencies between entry and entry->inode:
(gdb) frame 8
#8 0xb9ce25c8 in afr_shd_full_sweep (healer=0xbb2dda58, inode=0xbb28a338)
at afr-self-heald.c:582
582 ret = afr_shd_full_sweep (healer, entry->inode);
(gdb) print *entry
$1 = {{list = {next = 0xb89ff854, prev = 0xb9aac718}, {next = 0xb89ff854,
prev = 0xb9aac718}}, d_fileno = 12265058043496541968,
d_off = 3140166272, d_len = 1, d_type = 4, d_stat = {
ia_ino = 12265058043496541968,
ia_gfid = "|\307\345C@\002J\213\252\066=N\270(\257\020", ia_dev = 36356,
ia_type = IA_IFDIR, ia_prot = {suid = 0 '\000', sgid = 0 '\000',
sticky = 0 '\000', owner = {read = 1 '\001', write = 1 '\001',
exec = 1 '\001'}, group = {read = 1 '\001', write = 0 '\000',
exec = 1 '\001'}, other = {read = 1 '\001', write = 0 '\000',
exec = 1 '\001'}}, ia_nlink = 3, ia_uid = 0, ia_gid = 0,
ia_rdev = 8843337662631, ia_size = 512, ia_blksize = 16384, ia_blocks = 1,
ia_atime = 1417155766, ia_atime_nsec = 311472906, ia_mtime = 1417155766,
ia_mtime_nsec = 327489488, ia_ctime = 1417155766,
ia_ctime_nsec = 327489488}, dict = 0x0, inode = 0xbb28a608,
d_name = 0xb9aac868 "a"}
(gdb) print *entry->inode
$2 = {table = 0xbb2893f8, gfid = '\000' <repeats 15 times>, lock = {
pts_magic = 2004287495, pts_spin = 0 '\000', pts_flags = 0}, nlookup = 0,
fd_count = 0, ref = 4, ia_type = IA_INVAL, fd_list = {next = 0xbb28a63c,
prev = 0xbb28a63c}, dentry_list = {next = 0xbb28a644, prev = 0xbb28a644},
hash = {next = 0xbb28a64c, prev = 0xbb28a64c}, list = {next = 0xbb28a5c4,
prev = 0xbb289430}, _ctx = 0xb9b9f5e8}
Anyone has an idea of how this can happen?
Note this is with http://review.gluster.org/9071 applied.
--
Emmanuel Dreyfus
manu@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
