> > There are other stacks in 0.7.7 > Second stack: > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x0000ffff9d8d281c in __GI_abort () at abort.c:79 > #2 0x0000ffff9d90b818 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xffff9d9cb888 "%s\n") at ../sysdeps/posix/libc_fatal.c:181 > #3 0x0000ffff9d911f6c in malloc_printerr (str=str@entry=0xffff9d9c90d0 "free(): invalid pointer") at malloc.c:5389 > #4 0x0000ffff9d913780 in _int_free (av=0xffff9da0ba58 <main_arena>, p=0xffff98000070, have_lock=0) at malloc.c:4172 > #5 0x0000ffff9dc2b608 in internal_hashmap_clear (h=h@entry=0xffff9814dfa0, default_free_key=<optimized out>, default_free_value=<optimized out>) at ../src/basic/hashmap.c:902 > #6 0x0000ffff9dc2b700 in internal_hashmap_free (h=<optimized out>, default_free_key=<optimized out>, default_free_value=<optimized out>, default_free_value=<optimized out>, default_free_key=<optimized out>, > h=<optimized out>) at ../src/basic/hashmap.c:874 > #7 0x0000ffff9dc2b88c in ordered_hashmap_free_free_free () at ../src/basic/hashmap.h:118 > #8 device_free (device=0xffff9814d420) at ../src/libsystemd/sd-device/sd-device.c:68 > #9 sd_device_unref (p=<optimized out>) at ../src/libsystemd/sd-device/sd-device.c:78 > #10 0x0000ffff9dc36cc8 in sd_device_unrefp () at ../src/systemd/sd-device.h:118 > #11 device_new_from_nulstr (len=<optimized out>, nulstr=0xffff9d3253d0 "SEQNUM", ret=<synthetic pointer>) at ../src/libsystemd/sd-device/device-private.c:448 > #12 device_monitor_receive_device (m=0xffff98000b20, ret=ret@entry=0xffff9d327388) at ../src/libsystemd/sd-device/device-monitor.c:447 > #13 0x0000ffff9dc38bf4 in udev_monitor_receive_sd_device (ret=0xffff9d327388, udev_monitor=0xffff98000c70) at ../src/libudev/libudev-monitor.c:207 > #14 udev_monitor_receive_device (udev_monitor=0xffff98000c70, udev_monitor@entry=0xffff9d3273a0) at ../src/libudev/libudev-monitor.c:253 > #15 0x0000ffff9dcd9478 in uevent_listen (udev=0xffff9d327f40) at uevent.c:853 > #16 0x0000aaaae3783514 in ueventloop (ap=0xffffe160fe80) at main.c:1518 > #17 0x0000ffff9dbb67ac in start_thread (arg=0xffff9d3ad380) at pthread_create.c:486 > #18 0x0000ffff9d97047c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78 > Hi Martin, There is a _cleanup_ in device_new_from_nulstr. If uevent_thr exit in device_new_from_nulstr and some keys is not be append to sd_device, the _cleanup_ will be called, which leads to multipathd crashes with the stack. When I use your advice, On 2021/1/26 16:34, Martin Wilck wrote: > int oldstate; > > pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate); > > udev_monitor_receive_device(...) > > pthread_setcancelstate(oldstate, NULL); > pthread_testcancel(); this coredump does not seem to appear anymore (several hours with test scripts). Here are some discussion in https://github.com/systemd/systemd/issues/18376. Should be pthread cancellation set in multipath-tools? Regards, Lixiaokeng -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
