On Tue, Sep 25, 2018 at 3:38 PM ABHISHEK PALIWAL
wrote:
> Hi Pranith,
>
> I have some questions if you can answer them:
>
>
> What in LIBC exit() routine has resulted in SIGSEGV in this case ?
>
As per the stack trace you provided it is _IO_unbuffer_all():
(gdb) bt
#0 0x3fffad4463b0 in
Hi Pranith,
I have some questions if you can answer them:
What in LIBC exit() routine has resulted in SIGSEGV in this case ?
- Why the call trace always point to LIBC exit() in all these crash
instances on gluster ?
- Can there be any connection between LIBC exit() crash and SIGTERM
handling
On Tue, Sep 25, 2018 at 2:17 PM ABHISHEK PALIWAL
wrote:
> I don't have the step to reproduce, but its a race condition where it
> seems cleanup_and_exit() is accessing the data structure which are not yet
> initialised (as gluster is in starting phase), due to SIGTERM/SIGINT is
> sent in
I don't have the step to reproduce, but its a race condition where it seems
cleanup_and_exit() is accessing the data structure which are not yet
initialised (as gluster is in starting phase), due to SIGTERM/SIGINT is
sent in between.
Regards,
Abhishek
On Mon, Sep 24, 2018 at 9:11 PM Pranith
On Mon, Sep 24, 2018 at 5:16 PM ABHISHEK PALIWAL
wrote:
> Hi Pranith,
>
> As we know this problem is getting triggered at startup of the glusterd
> process when it received the SIGTERM.
>
> I think there is a problem in glusterfs code, if at startup someone sent
> the SIGTERM the exit handler
Hi Sanju,
Here is the output of 't a a bt'
(gdb) t a a bt
Thread 7 (LWP 444):
#0 0x3fff7a4d4ccc in __pthread_cond_timedwait (cond=0x10059a98,
mutex=0x10059a70, abstime=0x3fff77a50670) at pthread_cond_timedwait.c:198
#1 0x3fff7a5f1e74 in syncenv_task (proc=0x10053eb0) at syncop.c:607
Hi Abhishek,
Can you please share the output of "t a a bt" with us?
Thanks,
Sanju
On Fri, Sep 21, 2018 at 2:55 PM, ABHISHEK PALIWAL
wrote:
>
> We have seen a SIGSEGV crash on glusterfs process on kernel restart at
> start up.
>
> (gdb) bt
> #0 0x3fffad4463b0 in _IO_unbuffer_all () at
