[Gluster-devel] glusterfs_1.4.0qa19: small issues

[Brent A Nelson]

On Fri, 13 Jun 2008, Anand Avati wrote:

>> Indeed it did.  However, when doing multiple 10 GB dd writes on my four
>> client/servers, 2 of my clients died (the other two finished their tasks
>> without issue and stayed operational).  There were a large number of "frame
>> :" lines in glusterfs.log, and the log ended with:
>>
>> frame : type(2) op(0)
>> frame : type(2) op(0)
>>
>> 2008-06-11 20:43:20 C [common-utils.c:155:gf_print_bytes] : xfer ==
>> 142359133061, rcvd == 130379872
>> [0xb7fb4420]
>> /lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7e4ea01]
>> /usr/lib/glusterfs/1.4.0qa19/xlator/mount/fuse.so[0xb758dd84]
>> /lib/tls/i686/cmov/libpthread.so.0[0xb7f764fb]
>> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7ef8e5e]
>> ---------
>>
>
> did the client memory usage grow very high before it crashed? can you tell
> us the size of the core dump file? also is it possible to get a gdb
> backtrace on the coredump? this will help us a lot.
>

I didn't think to look for a core dump.  The client must have become huge, 
as the core dump was 3GB.  Unfortunately, I didn't compile with debugging; 
just in case, here's the bt, anyway:

#0  0xb7fb4410 in __kernel_vsyscall ()
#1  0xb7e4d085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e4ea01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb758dd84 in ?? () from 
/usr/lib/glusterfs/1.4.0qa19/xlator/mount/fuse.so
#4  0x00000001 in ?? ()
#5  0x00020040 in ?? ()
#6  0x00021000 in ?? ()
#7  0x08056de0 in ?? ()
#8  0x00000000 in ?? ()

If there aren't enough clues, I can compile with debugging and try to 
crash it again.

Thanks,

Brent