Re: [Gluster-devel] [Gluster-users] Glusterfsd crashed with SIGSEGV

2019-03-12 Thread Amar Tumballi Suryanarayan
We recommend to use 'tirpc' in the later releases. use '--with-tirpc' while
running ./configure

On Wed, Mar 13, 2019 at 10:55 AM ABHISHEK PALIWAL 
wrote:

> Hi Amar,
>
> this problem seems to be configuration issue due to librpc.
>
> Could you please let me know what should be configuration I need to use?
>
> Regards,
> Abhishek
>
> On Wed, Mar 13, 2019 at 10:42 AM ABHISHEK PALIWAL 
> wrote:
>
>> logs for libgfrpc.so
>>
>> pabhishe@arn-build3$ldd
>> ./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.*
>> ./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.0:
>> not a dynamic executable
>> ./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.0.0.1:
>> not a dynamic executable
>>
>>
>> On Wed, Mar 13, 2019 at 10:02 AM ABHISHEK PALIWAL <
>> abhishpali...@gmail.com> wrote:
>>
>>> Here are the logs:
>>>
>>>
>>> pabhishe@arn-build3$ldd
>>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.*
>>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0:
>>> not a dynamic executable
>>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0.0.1:
>>> not a dynamic executable
>>> pabhishe@arn-build3$ldd
>>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0.0.1
>>> not a dynamic executable
>>>
>>>
>>> For backtraces I have attached the core_logs.txt file.
>>>
>>> Regards,
>>> Abhishek
>>>
>>> On Wed, Mar 13, 2019 at 9:51 AM Amar Tumballi Suryanarayan <
>>> atumb...@redhat.com> wrote:
>>>
 Hi Abhishek,

 Few more questions,


> On Tue, Mar 12, 2019 at 10:58 AM ABHISHEK PALIWAL <
> abhishpali...@gmail.com> wrote:
>
>> Hi Amar,
>>
>> Below are the requested logs
>>
>> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libglusterfs.so
>> not a dynamic executable
>>
>> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libgfrpc.so
>> not a dynamic executable
>>
>>
 Can you please add a * at the end, so it gets the linked library list
 from the actual files (ideally this is a symlink, but I expected it to
 resolve like in Fedora).



> root@128:/# gdb /usr/sbin/glusterd core.1099
>> GNU gdb (GDB) 7.10.1
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "powerpc64-wrs-linux".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/sbin/glusterd...(no debugging symbols
>> found)...done.
>> [New LWP 1109]
>> [New LWP 1101]
>> [New LWP 1105]
>> [New LWP 1110]
>> [New LWP 1099]
>> [New LWP 1107]
>> [New LWP 1119]
>> [New LWP 1103]
>> [New LWP 1112]
>> [New LWP 1116]
>> [New LWP 1104]
>> [New LWP 1239]
>> [New LWP 1106]
>> [New LWP ]
>> [New LWP 1108]
>> [New LWP 1117]
>> [New LWP 1102]
>> [New LWP 1118]
>> [New LWP 1100]
>> [New LWP 1114]
>> [New LWP 1113]
>> [New LWP 1115]
>>
>> warning: Could not load shared library symbols for linux-vdso64.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Core was generated by `/usr/sbin/glusterfsd -s 128.224.95.140
>> --volfile-id gv0.128.224.95.140.tmp-bric'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
>> bytes=bytes@entry=36) at malloc.c:3327
>> 3327 {
>> [Current thread is 1 (Thread 0x3fffb1689160 (LWP 1109))]
>> (gdb) bt full
>>
>
 This is backtrace of one particular thread. I need output of command

 (gdb) thread apply all bt full


 Also, considering this is a crash in the malloc library call itself,
 would like to know the details of OS, Kernel version and gcc versions.

 Regards,
 Amar

 #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
>> bytes=bytes@entry=36) at malloc.c:3327
>> nb = 
>> idx = 
>> bin = 
>> victim = 
>> size = 
>> victim_index = 
>> remainder = 
>> remainder_size = 
>> block = 
>> bit = 
>> map = 
>> fwd = 
>> bck = 
>> errstr = 0x0
>> __func__ = 

Re: [Gluster-devel] [Gluster-users] Glusterfsd crashed with SIGSEGV

2019-03-12 Thread ABHISHEK PALIWAL
Hi Amar,

this problem seems to be configuration issue due to librpc.

Could you please let me know what should be configuration I need to use?

Regards,
Abhishek

On Wed, Mar 13, 2019 at 10:42 AM ABHISHEK PALIWAL 
wrote:

> logs for libgfrpc.so
>
> pabhishe@arn-build3$ldd
> ./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.*
> ./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.0:
> not a dynamic executable
> ./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.0.0.1:
> not a dynamic executable
>
>
> On Wed, Mar 13, 2019 at 10:02 AM ABHISHEK PALIWAL 
> wrote:
>
>> Here are the logs:
>>
>>
>> pabhishe@arn-build3$ldd
>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.*
>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0:
>> not a dynamic executable
>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0.0.1:
>> not a dynamic executable
>> pabhishe@arn-build3$ldd
>> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0.0.1
>> not a dynamic executable
>>
>>
>> For backtraces I have attached the core_logs.txt file.
>>
>> Regards,
>> Abhishek
>>
>> On Wed, Mar 13, 2019 at 9:51 AM Amar Tumballi Suryanarayan <
>> atumb...@redhat.com> wrote:
>>
>>> Hi Abhishek,
>>>
>>> Few more questions,
>>>
>>>
 On Tue, Mar 12, 2019 at 10:58 AM ABHISHEK PALIWAL <
 abhishpali...@gmail.com> wrote:

> Hi Amar,
>
> Below are the requested logs
>
> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libglusterfs.so
> not a dynamic executable
>
> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libgfrpc.so
> not a dynamic executable
>
>
>>> Can you please add a * at the end, so it gets the linked library list
>>> from the actual files (ideally this is a symlink, but I expected it to
>>> resolve like in Fedora).
>>>
>>>
>>>
 root@128:/# gdb /usr/sbin/glusterd core.1099
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc64-wrs-linux".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/sbin/glusterd...(no debugging symbols
> found)...done.
> [New LWP 1109]
> [New LWP 1101]
> [New LWP 1105]
> [New LWP 1110]
> [New LWP 1099]
> [New LWP 1107]
> [New LWP 1119]
> [New LWP 1103]
> [New LWP 1112]
> [New LWP 1116]
> [New LWP 1104]
> [New LWP 1239]
> [New LWP 1106]
> [New LWP ]
> [New LWP 1108]
> [New LWP 1117]
> [New LWP 1102]
> [New LWP 1118]
> [New LWP 1100]
> [New LWP 1114]
> [New LWP 1113]
> [New LWP 1115]
>
> warning: Could not load shared library symbols for linux-vdso64.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/sbin/glusterfsd -s 128.224.95.140
> --volfile-id gv0.128.224.95.140.tmp-bric'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
> bytes=bytes@entry=36) at malloc.c:3327
> 3327 {
> [Current thread is 1 (Thread 0x3fffb1689160 (LWP 1109))]
> (gdb) bt full
>

>>> This is backtrace of one particular thread. I need output of command
>>>
>>> (gdb) thread apply all bt full
>>>
>>>
>>> Also, considering this is a crash in the malloc library call itself,
>>> would like to know the details of OS, Kernel version and gcc versions.
>>>
>>> Regards,
>>> Amar
>>>
>>> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
> bytes=bytes@entry=36) at malloc.c:3327
> nb = 
> idx = 
> bin = 
> victim = 
> size = 
> victim_index = 
> remainder = 
> remainder_size = 
> block = 
> bit = 
> map = 
> fwd = 
> bck = 
> errstr = 0x0
> __func__ = "_int_malloc"
> #1  0x3fffb76a93dc in __GI___libc_malloc (bytes=36) at
> malloc.c:2921
> ar_ptr = 0x3fffa820
> victim = 
> hook = 
> __func__ = "__libc_malloc"
> #2  0x3fffb7764fd0 in x_inline (xdrs=0x3fffb1686d20,
> len=) at xdr_sizeof.c:89
> len = 36

Re: [Gluster-devel] [Gluster-users] Glusterfsd crashed with SIGSEGV

2019-03-12 Thread ABHISHEK PALIWAL
logs for libgfrpc.so

pabhishe@arn-build3$ldd
./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.*
./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.0:
not a dynamic executable
./5.4-r0/packages-split/glusterfs/usr/lib64/libgfrpc.so.0.0.1:
not a dynamic executable


On Wed, Mar 13, 2019 at 10:02 AM ABHISHEK PALIWAL 
wrote:

> Here are the logs:
>
>
> pabhishe@arn-build3$ldd
> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.*
> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0:
> not a dynamic executable
> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0.0.1:
> not a dynamic executable
> pabhishe@arn-build3$ldd
> ./5.4-r0/sysroot-destdir/usr/lib64/libglusterfs.so.0.0.1
> not a dynamic executable
>
>
> For backtraces I have attached the core_logs.txt file.
>
> Regards,
> Abhishek
>
> On Wed, Mar 13, 2019 at 9:51 AM Amar Tumballi Suryanarayan <
> atumb...@redhat.com> wrote:
>
>> Hi Abhishek,
>>
>> Few more questions,
>>
>>
>>> On Tue, Mar 12, 2019 at 10:58 AM ABHISHEK PALIWAL <
>>> abhishpali...@gmail.com> wrote:
>>>
 Hi Amar,

 Below are the requested logs

 pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libglusterfs.so
 not a dynamic executable

 pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libgfrpc.so
 not a dynamic executable


>> Can you please add a * at the end, so it gets the linked library list
>> from the actual files (ideally this is a symlink, but I expected it to
>> resolve like in Fedora).
>>
>>
>>
>>> root@128:/# gdb /usr/sbin/glusterd core.1099
 GNU gdb (GDB) 7.10.1
 Copyright (C) 2015 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later <
 http://gnu.org/licenses/gpl.html>
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show
 copying"
 and "show warranty" for details.
 This GDB was configured as "powerpc64-wrs-linux".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 .
 Find the GDB manual and other documentation resources online at:
 .
 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from /usr/sbin/glusterd...(no debugging symbols
 found)...done.
 [New LWP 1109]
 [New LWP 1101]
 [New LWP 1105]
 [New LWP 1110]
 [New LWP 1099]
 [New LWP 1107]
 [New LWP 1119]
 [New LWP 1103]
 [New LWP 1112]
 [New LWP 1116]
 [New LWP 1104]
 [New LWP 1239]
 [New LWP 1106]
 [New LWP ]
 [New LWP 1108]
 [New LWP 1117]
 [New LWP 1102]
 [New LWP 1118]
 [New LWP 1100]
 [New LWP 1114]
 [New LWP 1113]
 [New LWP 1115]

 warning: Could not load shared library symbols for linux-vdso64.so.1.
 Do you need "set solib-search-path" or "set sysroot"?
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib64/libthread_db.so.1".
 Core was generated by `/usr/sbin/glusterfsd -s 128.224.95.140
 --volfile-id gv0.128.224.95.140.tmp-bric'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
 bytes=bytes@entry=36) at malloc.c:3327
 3327 {
 [Current thread is 1 (Thread 0x3fffb1689160 (LWP 1109))]
 (gdb) bt full

>>>
>> This is backtrace of one particular thread. I need output of command
>>
>> (gdb) thread apply all bt full
>>
>>
>> Also, considering this is a crash in the malloc library call itself,
>> would like to know the details of OS, Kernel version and gcc versions.
>>
>> Regards,
>> Amar
>>
>> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
 bytes=bytes@entry=36) at malloc.c:3327
 nb = 
 idx = 
 bin = 
 victim = 
 size = 
 victim_index = 
 remainder = 
 remainder_size = 
 block = 
 bit = 
 map = 
 fwd = 
 bck = 
 errstr = 0x0
 __func__ = "_int_malloc"
 #1  0x3fffb76a93dc in __GI___libc_malloc (bytes=36) at malloc.c:2921
 ar_ptr = 0x3fffa820
 victim = 
 hook = 
 __func__ = "__libc_malloc"
 #2  0x3fffb7764fd0 in x_inline (xdrs=0x3fffb1686d20, len=>>> out>) at xdr_sizeof.c:89
 len = 36
 xdrs = 0x3fffb1686d20
 #3  0x3fffb7842488 in .xdr_gfx_iattx () from
 /usr/lib64/libgfxdr.so.0
 No symbol table info available.
 #4  0x3fffb7842e84 in .xdr_gfx_dirplist () from
 /usr/lib64/libgfxdr.so.0
 No symbol table info available.
 #5  0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
 pp=0x3fffa81099f0, size=, proc=) a

Re: [Gluster-devel] [Gluster-users] Glusterfsd crashed with SIGSEGV

2019-03-12 Thread Amar Tumballi Suryanarayan
Hi Abhishek,

Few more questions,


> On Tue, Mar 12, 2019 at 10:58 AM ABHISHEK PALIWAL 
> wrote:
>
>> Hi Amar,
>>
>> Below are the requested logs
>>
>> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libglusterfs.so
>> not a dynamic executable
>>
>> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libgfrpc.so
>> not a dynamic executable
>>
>>
Can you please add a * at the end, so it gets the linked library list from
the actual files (ideally this is a symlink, but I expected it to resolve
like in Fedora).



> root@128:/# gdb /usr/sbin/glusterd core.1099
>> GNU gdb (GDB) 7.10.1
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "powerpc64-wrs-linux".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/sbin/glusterd...(no debugging symbols
>> found)...done.
>> [New LWP 1109]
>> [New LWP 1101]
>> [New LWP 1105]
>> [New LWP 1110]
>> [New LWP 1099]
>> [New LWP 1107]
>> [New LWP 1119]
>> [New LWP 1103]
>> [New LWP 1112]
>> [New LWP 1116]
>> [New LWP 1104]
>> [New LWP 1239]
>> [New LWP 1106]
>> [New LWP ]
>> [New LWP 1108]
>> [New LWP 1117]
>> [New LWP 1102]
>> [New LWP 1118]
>> [New LWP 1100]
>> [New LWP 1114]
>> [New LWP 1113]
>> [New LWP 1115]
>>
>> warning: Could not load shared library symbols for linux-vdso64.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Core was generated by `/usr/sbin/glusterfsd -s 128.224.95.140
>> --volfile-id gv0.128.224.95.140.tmp-bric'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
>> bytes=bytes@entry=36) at malloc.c:3327
>> 3327 {
>> [Current thread is 1 (Thread 0x3fffb1689160 (LWP 1109))]
>> (gdb) bt full
>>
>
This is backtrace of one particular thread. I need output of command

(gdb) thread apply all bt full


Also, considering this is a crash in the malloc library call itself, would
like to know the details of OS, Kernel version and gcc versions.

Regards,
Amar

#0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
>> bytes=bytes@entry=36) at malloc.c:3327
>> nb = 
>> idx = 
>> bin = 
>> victim = 
>> size = 
>> victim_index = 
>> remainder = 
>> remainder_size = 
>> block = 
>> bit = 
>> map = 
>> fwd = 
>> bck = 
>> errstr = 0x0
>> __func__ = "_int_malloc"
>> #1  0x3fffb76a93dc in __GI___libc_malloc (bytes=36) at malloc.c:2921
>> ar_ptr = 0x3fffa820
>> victim = 
>> hook = 
>> __func__ = "__libc_malloc"
>> #2  0x3fffb7764fd0 in x_inline (xdrs=0x3fffb1686d20, len=> out>) at xdr_sizeof.c:89
>> len = 36
>> xdrs = 0x3fffb1686d20
>> #3  0x3fffb7842488 in .xdr_gfx_iattx () from /usr/lib64/libgfxdr.so.0
>> No symbol table info available.
>> #4  0x3fffb7842e84 in .xdr_gfx_dirplist () from
>> /usr/lib64/libgfxdr.so.0
>> No symbol table info available.
>> #5  0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
>> pp=0x3fffa81099f0, size=, proc=) at
>> xdr_ref.c:84
>> loc = 0x3fffa8109aa0 "\265\256\373\200\f\206\361j"
>> stat = 
>> #6  0x3fffb7764e04 in __GI_xdr_pointer (xdrs=0x3fffb1686d20,
>> objpp=0x3fffa81099f0, obj_size=,
>> xdr_obj=@0x3fffb785f4b0: 0x3fffb7842dc0 <.xdr_gfx_dirplist>) at
>> xdr_ref.c:135
>> more_data = 1
>> #7  0x3fffb7842ec0 in .xdr_gfx_dirplist () from
>> /usr/lib64/libgfxdr.so.0
>> No symbol table info available.
>> #8  0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
>> pp=0x3fffa8109870, size=, proc=) at
>> xdr_ref.c:84
>> loc = 0x3fffa8109920 "\232\373\377\315\352\325\005\271"
>> stat = 
>> #9  0x3fffb7764e04 in __GI_xdr_pointer (xdrs=0x3fffb1686d20,
>> objpp=0x3fffa8109870, obj_size=,
>> xdr_obj=@0x3fffb785f4b0: 0x3fffb7842dc0 <.xdr_gfx_dirplist>) at
>> xdr_ref.c:135
>> more_data = 1
>> #10 0x3fffb7842ec0 in .xdr_gfx_dirplist () from
>> /usr/lib64/libgfxdr.so.0
>> No symbol table info available.
>> #11 0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
>> pp=0x3fffa81096f0, size=, proc=) at
>> xdr_ref.c:84
>> loc = 0x3fffa81097a0 "\241X\372!\216\256=\342"
>> stat = 
>> ---Type  to contin

Re: [Gluster-devel] [Gluster-users] Glusterfsd crashed with SIGSEGV

2019-03-12 Thread ABHISHEK PALIWAL
Hi Amar,

did you get time to check the logs?

Regards,
Abhishek

On Tue, Mar 12, 2019 at 10:58 AM ABHISHEK PALIWAL 
wrote:

> Hi Amar,
>
> Below are the requested logs
>
> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libglusterfs.so
> not a dynamic executable
>
> pabhishe@arn-build3$ldd ./sysroot-destdir/usr/lib64/libgfrpc.so
> not a dynamic executable
>
> root@128:/# gdb /usr/sbin/glusterd core.1099
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc64-wrs-linux".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/sbin/glusterd...(no debugging symbols
> found)...done.
> [New LWP 1109]
> [New LWP 1101]
> [New LWP 1105]
> [New LWP 1110]
> [New LWP 1099]
> [New LWP 1107]
> [New LWP 1119]
> [New LWP 1103]
> [New LWP 1112]
> [New LWP 1116]
> [New LWP 1104]
> [New LWP 1239]
> [New LWP 1106]
> [New LWP ]
> [New LWP 1108]
> [New LWP 1117]
> [New LWP 1102]
> [New LWP 1118]
> [New LWP 1100]
> [New LWP 1114]
> [New LWP 1113]
> [New LWP 1115]
>
> warning: Could not load shared library symbols for linux-vdso64.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/sbin/glusterfsd -s 128.224.95.140 --volfile-id
> gv0.128.224.95.140.tmp-bric'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
> bytes=bytes@entry=36) at malloc.c:3327
> 3327 {
> [Current thread is 1 (Thread 0x3fffb1689160 (LWP 1109))]
> (gdb) bt full
> #0  0x3fffb76a6d48 in _int_malloc (av=av@entry=0x3fffa820,
> bytes=bytes@entry=36) at malloc.c:3327
> nb = 
> idx = 
> bin = 
> victim = 
> size = 
> victim_index = 
> remainder = 
> remainder_size = 
> block = 
> bit = 
> map = 
> fwd = 
> bck = 
> errstr = 0x0
> __func__ = "_int_malloc"
> #1  0x3fffb76a93dc in __GI___libc_malloc (bytes=36) at malloc.c:2921
> ar_ptr = 0x3fffa820
> victim = 
> hook = 
> __func__ = "__libc_malloc"
> #2  0x3fffb7764fd0 in x_inline (xdrs=0x3fffb1686d20, len= out>) at xdr_sizeof.c:89
> len = 36
> xdrs = 0x3fffb1686d20
> #3  0x3fffb7842488 in .xdr_gfx_iattx () from /usr/lib64/libgfxdr.so.0
> No symbol table info available.
> #4  0x3fffb7842e84 in .xdr_gfx_dirplist () from
> /usr/lib64/libgfxdr.so.0
> No symbol table info available.
> #5  0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
> pp=0x3fffa81099f0, size=, proc=) at
> xdr_ref.c:84
> loc = 0x3fffa8109aa0 "\265\256\373\200\f\206\361j"
> stat = 
> #6  0x3fffb7764e04 in __GI_xdr_pointer (xdrs=0x3fffb1686d20,
> objpp=0x3fffa81099f0, obj_size=,
> xdr_obj=@0x3fffb785f4b0: 0x3fffb7842dc0 <.xdr_gfx_dirplist>) at
> xdr_ref.c:135
> more_data = 1
> #7  0x3fffb7842ec0 in .xdr_gfx_dirplist () from
> /usr/lib64/libgfxdr.so.0
> No symbol table info available.
> #8  0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
> pp=0x3fffa8109870, size=, proc=) at
> xdr_ref.c:84
> loc = 0x3fffa8109920 "\232\373\377\315\352\325\005\271"
> stat = 
> #9  0x3fffb7764e04 in __GI_xdr_pointer (xdrs=0x3fffb1686d20,
> objpp=0x3fffa8109870, obj_size=,
> xdr_obj=@0x3fffb785f4b0: 0x3fffb7842dc0 <.xdr_gfx_dirplist>) at
> xdr_ref.c:135
> more_data = 1
> #10 0x3fffb7842ec0 in .xdr_gfx_dirplist () from
> /usr/lib64/libgfxdr.so.0
> No symbol table info available.
> #11 0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
> pp=0x3fffa81096f0, size=, proc=) at
> xdr_ref.c:84
> loc = 0x3fffa81097a0 "\241X\372!\216\256=\342"
> stat = 
> ---Type  to continue, or q  to quit---
> #12 0x3fffb7764e04 in __GI_xdr_pointer (xdrs=0x3fffb1686d20,
> objpp=0x3fffa81096f0, obj_size=,
> xdr_obj=@0x3fffb785f4b0: 0x3fffb7842dc0 <.xdr_gfx_dirplist>) at
> xdr_ref.c:135
> more_data = 1
> #13 0x3fffb7842ec0 in .xdr_gfx_dirplist () from
> /usr/lib64/libgfxdr.so.0
> No symbol table info available.
> #14 0x3fffb7764c28 in __GI_xdr_reference (xdrs=0x3fffb1686d20,
> pp=0x3fffa8109570, size=, proc=) at
> xdr_ref.c:84
> loc = 0x3fffa8109620 "\265\205\003Vu'\002L"
>

Re: [Gluster-devel] gfapi: add function to set client-pid

2019-03-12 Thread Niels de Vos
On Tue, Mar 12, 2019 at 03:00:27PM +0530, Ravishankar N wrote:
> Hello,
> 
> I'm planning to expose setting client-pid for gfapi clients via a new api,
> something like `glfs_set_client_pid (fs, pid)`.
> The functionality already exists for fuse mounts via the --client-pid=$PID
> option, where the value is captured in
> glusterfs_ctx_t->cmd_args->client_pid.
> 
> Background:
> 
> If the glusterfs eventing framework is enabled, AFR sends child-up/child
> down events (via the gf_event() call) in the notify code path whenever there
> is a connect/disconnect at AFR level. While this is okay for normal client
> processes, it does not make much sense if the event is coming from say
> glfsheal, which is a gfapi based program (having the AFR xlator) that is
> invoked when you run the heal info set of commands. Many applications
> periodically run heal info to monitor the heals and display it on the
> dashboard (like tendryl), leading to a flood of child up/ down messages to
> the application monitoring these events.
> 
> We need to add a unique key=value to all such gf_event() calls in AFR, based
> on which the consumer of the events can decide to ignore them if needed.
> This key-value can be client-pid=$PID, where PID can be
> GF_CLIENT_PID_SELF_HEALD for selfheal daemon, GF_CLIENT_PID_GLFS_HEAL for
> glfsheal etc (these values are already defined in the code). This is why we
> need a way to set the client-pid for gfapi clients as well.
> 
> Another approach would be to add an xlator option (say 'client-name')
> specific to AFRĀ  and use that as the key-value pair but it seems to be an
> overkill to do that just for the sake of eventing purposes. Besides, the pid
> approach can also be extended to other gluster processes like rebalance, shd
> and other daemons where AFR is loaded but AFR child-up/down events from it
> are not of any particular interest.These daemons will now have to be spawned
> by glusterd with the --client-pid option.

Sounds good to me. This probably should be a function that is not
available to all gfapi consumers, so please use api/src/glfs-internal.h
for that. With clear documentation as written in the email, it should be
obvious that only Gluster internal processes may use it.

Adding the integration mailinglist on CC, as that is where all
discussions around gfapi should be archived.

Thanks,
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel


[Gluster-devel] gfapi: add function to set client-pid

2019-03-12 Thread Ravishankar N

Hello,

I'm planning to expose setting client-pid for gfapi clients via a new 
api, something like `glfs_set_client_pid (fs, pid)`.
The functionality already exists for fuse mounts via the 
--client-pid=$PID option, where the value is captured in 
glusterfs_ctx_t->cmd_args->client_pid.


Background:

If the glusterfs eventing framework is enabled, AFR sends child-up/child 
down events (via the gf_event() call) in the notify code path whenever 
there is a connect/disconnect at AFR level. While this is okay for 
normal client processes, it does not make much sense if the event is 
coming from say glfsheal, which is a gfapi based program (having the AFR 
xlator) that is invoked when you run the heal info set of commands. Many 
applications periodically run heal info to monitor the heals and display 
it on the dashboard (like tendryl), leading to a flood of child up/ down 
messages to the application monitoring these events.


We need to add a unique key=value to all such gf_event() calls in AFR, 
based on which the consumer of the events can decide to ignore them if 
needed. This key-value can be client-pid=$PID, where PID can be 
GF_CLIENT_PID_SELF_HEALD for selfheal daemon, GF_CLIENT_PID_GLFS_HEAL 
for glfsheal etc (these values are already defined in the code). This is 
why we need a way to set the client-pid for gfapi clients as well.


Another approach would be to add an xlator option (say 'client-name') 
specific to AFRĀ  and use that as the key-value pair but it seems to be 
an overkill to do that just for the sake of eventing purposes. Besides, 
the pid approach can also be extended to other gluster processes like 
rebalance, shd and other daemons where AFR is loaded but AFR 
child-up/down events from it are not of any particular interest.These 
daemons will now have to be spawned by glusterd with the --client-pid 
option.


Regards,
Ravi


___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] [Gluster-infra] Softserve is up and running

2019-03-12 Thread Deepshikha Khandelwal
Hello folks,

Softserve is deployed back today with AWS stack to loan centos machines for
regression testing. I've tested them a few times today to confirm it works
as expected. In the past, Softserve[1] machines would be a clean Centos 7
image. Now, we have an AMI image with all the dependencies installed and
*almost* setup to run regressions. It just needs a few steps run on them
and we have a simplified playbook that will setup *just* those steps. The
instructions are on softserve wiki[2]

Please let us know if you face troubles by filing a bug.[3]
[1]: https://softserve.gluster.org/
[2]: https://github.com/gluster/softserve
/wiki/Running-Regressions-on-loaned-Softserve-instances
[3]:
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS&component=project-infrastructure

Thanks,
Deepshikha
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel