On 09/22/2016 04:02 AM, Frank Filz wrote:
>> I have pushed rc7 with Matt's c++ compile changes and one final patch from
>> Daniel G.
>> Please have at it. I'd like to get as many FSAL's verified against rc7 by
>> 9:00 AM PDT Thursday. At that time, unless some major fire has erupted, I
>> will tag V2.4.0 and push that so Kaleb can get on with his work to include
>> V2.4.0.
> Hmm, centos-ci is showing a failure in the Cthon04 lock tests. I ran NFS v3
> lock tests and got a pass.

I ran the cthon04 tests (using FSAL_GLUSTER) on v3 and v4 mounts. They 
seem to pass. But if I run in a loop, sometimes (very much spurious - 
hit only once) ganesha process seems to crash. One of the bt seen is

(gdb) bt
#0  0x00007f570da9fa98 in __GI_raise (sig=sig@entry=6)
     at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007f570daa169a in __GI_abort () at abort.c:89
#2  0x00007f570dae2e1a in __libc_message (do_abort=do_abort@entry=2,
     fmt=fmt@entry=0x7f570dbf5a00 "*** Error in `%s': %s: 0x%s ***\n")
     at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007f570dae91e4 in malloc_printerr (action=<optimized out>,
     str=0x7f570dbf5a48 "corrupted double-linked list (not small)",
     ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5000
#4  0x00007f570daebd5a in _int_free (av=0x7f5650000020, p=<optimized out>,
     have_lock=0) at malloc.c:4008
#5  0x00007f570daeebcc in __GI___libc_free (mem=<optimized out>) at 
#6  0x000000000044ad9b in gsh_free_size (p=0x7f56500a3290, n=1360)
#7  0x00007f570f4000b9 in mem_free (p=0x7f56500a3290, n=1360)
#8  0x00007f570f4006c3 in free_rpc_msg (msg=0x7f56500a3290)
#9  0x00000000004e7ba5 in nfs_dupreq_rele (req=0x7f56500a0ad8,
     func=0x54a190 <nfs4_func_desc+48>)
#10 0x000000000044a50a in nfs_rpc_execute (reqdata=0x7f56500a0ab0)

and another one (I lost the core) , but it was 
mdcache_lru_get->mdcache_lru_clean -> fsal_close()->close() . In 
FSAL_GLUSTER()->file_close(), below assert was hit -

assert(obj_hdl->type == REGULAR_FILE);

The obj_hdl->type was a large number and did not have any of the defined 
macros value. I tried reproducing, but haven't hit it again (neither of 
the above crashes).

But I would like to check if the above check is valid in FSALs close() 
routines ? I see this check in vfs_close() as well. But I assume 
mdcache_lru_clean could be called on an obj_hdl of any type but not 
restricted to REGULAR_FILE. Could you please confirm?


> If there is something broken here, we really should try to fix ASAP.
> Thanks
> Frank
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> ------------------------------------------------------------------------------
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Nfs-ganesha-devel mailing list

Reply via email to