[dm-devel] [PATCH] multipathd: avoid crash in uevent_cleanup()
Martin Wilck
mwilck at suse.com
Wed Feb 3 13:57:29 UTC 2021
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 at entry=0xffffb523f200,
> fs=fs at entry=0xffffb523e700) at ../../../libgcc/unwind-dw2.c:1257
> #2 0x0000ffffb6119ef4 in _Unwind_ForcedUnwind_Phase2
> (exc=exc at entry=0xffffb52403b0, context=context at entry=0xffffb523f200)
> at ../../../libgcc/unwind.inc:155
> #3 0x0000ffffb611a284 in _Unwind_ForcedUnwind (exc=0xffffb52403b0,
> stop=stop at 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 ?? ()
>
Please check your glibc and gcc versions. Google turns up some general
issues with pthread_cancel() and certain library versions, especially
on ARM. There's a chance that this isn't a multipath-tools bug after
all.
https://www.google.com/search?q=SIGSEGV+_Unwind_ForcedUnwind_Phase2
You could also try to compile with clang and see if the error goes
away.
> If exit() before all pthread_cancel in child of 0.7.7, there is no
> any crash.
What do you mean with "exit() before all pthread_cancel"? If this
happens on pthread_cancel(), and you don't call that function, this
would actually be expected.
Regards,
Martin
> So I believe there are many races in thread cancel but I don't know
> how it comes.
>
> Regards,
> Lixiaokeng
>
More information about the dm-devel
mailing list