[Gluster-devel] spurious error in self-heald.t

[Emmanuel Dreyfus]

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 at netbsd.org