From: lixiaokeng <lixiaokeng@huawei.com>
To: Martin Wilck <mwilck@suse.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: linfeilong <linfeilong@huawei.com>, dm-devel@redhat.com
Subject: Re: [dm-devel] [PATCH] multipathd: avoid crash in uevent_cleanup()
Date: Mon, 1 Mar 2021 22:53:31 +0800 [thread overview]
Message-ID: <655de0b3-9625-bf3c-85f8-d19832bd84d8@huawei.com> (raw)
In-Reply-To: <dcc6fb2a344ce75972242e2c78e2e485b58140da.camel@suse.com>
On 2021/2/3 21:57, Martin Wilck wrote:
> On Wed, 2021-02-03 at 18:48 +0800, lixiaokeng wrote:
>>
>>
>> On 2021/2/3 4:52, Martin Wilck wrote:
>>> did this fix your "crash on exit" issue?
>>
>> Unfortunately, the issue is not solved.
>>
>> There will be some different coredump stack.
>>
>> 0.8.5 (I'm not sure there are only two stacks in 0.8.5)
>> First stack:
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0 0x00007f59a0109647 in ?? ()
>> [Current thread is 1 (LWP 1997690)]
>> (gdb) bt
>> #0 0x00007f59a0109647 in ?? ()
>> #1 0x0000000000000000 in ?? ()
>> (gdb) info threads
>> Id Target Id Frame
>> * 1 LWP 1997690 0x00007f59a0109647 in ?? ()
>> 2 LWP 1996840 0x00007f59a0531de7 in ?? ()
>> 3 LWP 1997692 0x00007f59a0109647 in ?? ()
>> 4 LWP 1996857 0x00007f59a020d169 in ?? ()
>>
>> Second stack:
>> #0 0x0000ffffb6118f4c in aarch64_fallback_frame_state
>> (context=0xffffb523f200, context=0xffffb523f200, fs=0xffffb523e700)
>> at ./md-unwind-support.h:74
>> #1 uw_frame_state_for (context=context@entry=0xffffb523f200,
>> fs=fs@entry=0xffffb523e700) at ../../../libgcc/unwind-dw2.c:1257
>> #2 0x0000ffffb6119ef4 in _Unwind_ForcedUnwind_Phase2
>> (exc=exc@entry=0xffffb52403b0, context=context@entry=0xffffb523f200)
>> at ../../../libgcc/unwind.inc:155
>> #3 0x0000ffffb611a284 in _Unwind_ForcedUnwind (exc=0xffffb52403b0,
>> stop=stop@entry=0xffffb64846c0 <unwind_stop>,
>> stop_argument=0xffffb523f630) at ../../../libgcc/unwind.inc:207
>> #4 0x0000ffffb6484860 in __GI___pthread_unwind (buf=<optimized out>)
>> at unwind.c:121
>> #5 0x0000ffffb6482d08 in __do_cancel () at pthreadP.h:304
>> #6 __GI___pthread_testcancel () at pthread_testcancel.c:26
>> #7 0x0000ffffb5c528e8 in ?? ()
>>
>
Hi Martin:
Here I add condlog(2, "start funcname"), pthread_cleanup_push(func_print, NULL)
in every pthread_create func. When these two core happened, "exit tur_thread"
are less than "start tur_thread". So the trouble may be in tur_thread.
I will use
int oldstate;
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate);
...
pthread_setcancelstate(oldstate, NULL);
pthread_testcancel();
to test it.
Regards,
Lixiaokeng
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-03-01 14:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 21:08 [dm-devel] [PATCH] multipathd: avoid crash in uevent_cleanup() mwilck
2021-02-02 20:52 ` Martin Wilck
2021-02-03 10:48 ` lixiaokeng
2021-02-03 13:57 ` Martin Wilck
2021-02-04 1:40 ` lixiaokeng
2021-02-04 15:06 ` Martin Wilck
2021-02-05 11:08 ` Martin Wilck
2021-02-05 11:09 ` Martin Wilck
2021-02-07 7:05 ` lixiaokeng
2021-03-01 14:53 ` lixiaokeng [this message]
2021-03-02 8:41 ` lixiaokeng
2021-03-02 11:07 ` Martin Wilck
2021-03-02 15:49 ` lixiaokeng
2021-03-02 9:56 ` Martin Wilck
2021-03-02 12:44 ` lixiaokeng
2021-03-02 15:29 ` Martin Wilck
2021-03-02 16:55 ` Martin Wilck
2021-03-03 10:42 ` lixiaokeng
2021-03-08 9:40 ` Martin Wilck
2021-03-15 13:00 ` Martin Wilck
2021-03-16 11:12 ` lixiaokeng
2021-03-17 16:59 ` Martin Wilck
2021-03-19 1:49 ` lixiaokeng
2021-02-08 7:41 ` lixiaokeng
2021-02-08 9:50 ` Martin Wilck
2021-02-08 10:49 ` lixiaokeng
2021-02-08 11:03 ` Martin Wilck
2021-02-09 1:36 ` lixiaokeng
2021-02-09 17:30 ` Martin Wilck
2021-02-10 2:02 ` lixiaokeng
2021-02-10 2:29 ` Hexiaowen (Hex, EulerOS)
2021-02-19 10:35 ` Martin Wilck
2021-02-19 1:36 ` lixiaokeng
2021-02-02 22:23 ` Benjamin Marzinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=655de0b3-9625-bf3c-85f8-d19832bd84d8@huawei.com \
--to=lixiaokeng@huawei.com \
--cc=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@redhat.com \
--cc=linfeilong@huawei.com \
--cc=mwilck@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).