I've attached two test scripts that configure the local machine to serve
as an iSCSI target and use then use those as targets to attach and
detach.
The best way to observe the issue is to use the first version of the
script with a single target and single iteration of the test loop, while
running multipathd under valgrind, i.e.:
service multipath-tools stop
valgrind multipathd -d &
bug1628723 1 1
When I do this, I observe the following in valgrind output:
==31667== Invalid read of size 1
==31667== at 0x4C2E4E1: __GI_strncpy (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31667== by 0x56FD3C9: sysfs_get_tgt_nodename (discovery.c:257)
==31667== by 0x56FDF98: scsi_sysfs_pathinfo (discovery.c:494)
==31667== by 0x56FEA01: sysfs_pathinfo (discovery.c:696)
==31667== by 0x56FF174: pathinfo (discovery.c:830)
==31667== by 0x56FC775: store_pathinfo (discovery.c:57)
==31667== by 0x40504E: uev_add_path (main.c:386)
==31667== by 0x4062EC: uev_trigger (main.c:777)
==31667== by 0x5713938: service_uevq (uevent.c:118)
==31667== by 0x5713B47: uevent_dispatch (uevent.c:167)
==31667== by 0x406435: uevqloop (main.c:814)
==31667== by 0x4E3F183: start_thread (pthread_create.c:312)
==31667== Address 0x7176790 is 0 bytes inside a block of size 37 free'd
==31667== at 0x4C2BDEC: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31667== by 0x54D7A1B: ??? (in /lib/x86_64-linux-gnu/libudev.so.1.3.5)
==31667== by 0x54D7ADD: ??? (in /lib/x86_64-linux-gnu/libudev.so.1.3.5)
==31667== by 0x54D84B6: udev_device_unref (in
/lib/x86_64-linux-gnu/libudev.so.1.3.5)
==31667== by 0x56FD3AA: sysfs_get_tgt_nodename (discovery.c:255)
==31667== by 0x56FDF98: scsi_sysfs_pathinfo (discovery.c:494)
==31667== by 0x56FEA01: sysfs_pathinfo (discovery.c:696)
==31667== by 0x56FF174: pathinfo (discovery.c:830)
==31667== by 0x56FC775: store_pathinfo (discovery.c:57)
==31667== by 0x40504E: uev_add_path (main.c:386)
==31667== by 0x4062EC: uev_trigger (main.c:777)
==31667== by 0x5713938: service_uevq (uevent.c:118)
Which is due to the issue resolved in commit
cb0f7127ba90ab5e8e71fc534a0a16cdbe96a88f,
and later:
==31667== Invalid read of size 8
==31667== at 0x56FC388: find_path_by_dev (structs.c:322)
==31667== by 0x404FBF: uev_add_path (main.c:376)
==31667== by 0x4062EC: uev_trigger (main.c:777)
==31667== by 0x5713938: service_uevq (uevent.c:118)
==31667== by 0x5713B47: uevent_dispatch (uevent.c:167)
==31667== by 0x406435: uevqloop (main.c:814)
==31667== by 0x4E3F183: start_thread (pthread_create.c:312)
==31667== by 0x5A2B37C: clone (clone.S:111)
==31667== Address 0x72508a0 is 0 bytes inside a block of size 40 free'd
==31667== at 0x4C2CE8E: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.
so)
==31667== by 0x56F4162: vector_del_slot (vector.c:99)
==31667== by 0x571EF72: verify_paths (structs_vec.c:477)
==31667== by 0x405397: ev_add_path (main.c:446)
==31667== by 0x4050C7: uev_add_path (main.c:398)
==31667== by 0x4062EC: uev_trigger (main.c:777)
==31667== by 0x5713938: service_uevq (uevent.c:118)
==31667== by 0x5713B47: uevent_dispatch (uevent.c:167)
==31667== by 0x406435: uevqloop (main.c:814)
==31667== by 0x4E3F183: start_thread (pthread_create.c:312)
==31667== by 0x5A2B37C: clone (clone.S:111)
==31667==
==31667== Invalid free() / delete / delete[] / realloc()
==31667== at 0x4C2CE8E: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.
so)
==31667== by 0x56F3F2B: vector_alloc_slot (vector.c:43)
==31667== by 0x56FC05F: store_path (structs.c:225)
==31667== by 0x56FC793: store_pathinfo (discovery.c:62)
==31667== by 0x40504E: uev_add_path (main.c:386)
==31667== by 0x4062EC: uev_trigger (main.c:777)
==31667== by 0x5713938: service_uevq (uevent.c:118)
==31667== by 0x5713B47: uevent_dispatch (uevent.c:167)
==31667== by 0x406435: uevqloop (main.c:814)
==31667== by 0x4E3F183: start_thread (pthread_create.c:312)
==31667== by 0x5A2B37C: clone (clone.S:111)
==31667== Address 0x72508a0 is 0 bytes inside a block of size 40 free'd
==31667== at 0x4C2CE8E: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31667== by 0x56F4162: vector_del_slot (vector.c:99)
==31667== by 0x571EF72: verify_paths (structs_vec.c:477)
==31667== by 0x405397: ev_add_path (main.c:446)
==31667== by 0x4050C7: uev_add_path (main.c:398)
==31667== by 0x4062EC: uev_trigger (main.c:777)
==31667== by 0x5713938: service_uevq (uevent.c:118)
==31667== by 0x5713B47: uevent_dispatch (uevent.c:167)
==31667== by 0x406435: uevqloop (main.c:814)
==31667== by 0x4E3F183: start_thread (pthread_create.c:312)
==31667== by 0x5A2B37C: clone (clone.S:111)
==31667==
Which are due to the issue resolved in commit
828d2fbaab304d1ec7db2f563a59eaf2c7a516ea.
As is often the case with use-after-free errors, these only sometimes
result in a a SIGSEGV. The error report from valgrind is perfectly
reproducible. I can intermittently reproduce the SIGSEGV with these
scripts when left running in a loop. Restarting multipathd during while
the test script is running sometimes aids in causing the crash.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1628723
Title:
Trusty: multipathd SIGSEGV on path addition or removal
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1628723/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
