Hide Forgot
Description of problem: # sanlock direct init -s -h Segmentation fault # gdb sanlock GNU gdb (GDB) Fedora 8.3-7.fc30 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from sanlock... Reading symbols from /usr/lib/debug/usr/sbin/sanlock-3.8.0-1.fc30.x86_64.debug... (gdb) run direct init -s -h Starting program: /usr/sbin/sanlock direct init -s -h Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-22.fc30.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Missing separate debuginfo for /lib64/libsanlock.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/d5/2ef126cd66e8b8399724c0a7347d5bb01e49fa.debug Missing separate debuginfo for /lib64/libwdmd.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/d8/6c67506c2ecb5c9268eadf94ae7ab7fdd2fc23.debug warning: Loadable section ".note.gnu.property" outside of ELF segments Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e99617 in __strlen_avx2 () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install libaio-0.3.111-4.fc30.x86_64 libblkid-2.33.2-2.fc30.x86_64 libuuid-2.33.2-2.fc30.x86_64 sssd-client-2.2.2-3.fc30.x86_64 (gdb) bt #0 0x00007ffff7e99617 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x00007ffff7da5a1e in __vfprintf_internal () from /lib64/libc.so.6 #2 0x00007ffff7db747a in __vsnprintf_internal () from /lib64/libc.so.6 #3 0x00007ffff7e47591 in __snprintf_chk () from /lib64/libc.so.6 #4 0x00007ffff7f130f9 in sanlock_res_to_str () from /lib64/libsanlock.so.1 #5 0x000055555556a22c in do_direct_init () at main.c:3461 #6 do_direct () at main.c:3496 #7 0x000055555555b5ab in main (argc=<optimized out>, argv=<optimized out>) at main.c:3715 Version-Release number of selected component (if applicable): sanlock-3.8.0-1.fc30.x86_64 How reproducible: Always Steps to Reproduce: 1. Run with bad command line (missing argument) Actual results: Segmentation fault Expected results: Fail with exit code meaning usage error, with good error message like: parameter -h requires argument More info: This behave as expected: # sanlock direct init -h option 'h' requires arg # sanlock direct init -s option 's' requires arg So the issue is the interaction when using -s and -h, both without argument. It looks like sanlock is re-inventing getopt, and should really use it instead.
Digging more: # sanlock direct init -D -s ls1 2019-12-01 19:11:01 24491 [24953]: lockspace ls1 host_id 0 path offset 0 Segmentation fault [root@dhcp-1-91 ~]# sanlock direct init -D -s ls1:ls2 2019-12-01 19:11:06 24496 [24959]: lockspace ls1 host_id 0 path offset 0 Segmentation fault [root@dhcp-1-91 ~]# sanlock direct init -D -s ls1:ls2:ls3 2019-12-01 19:11:10 24499 [24964]: lockspace ls1 host_id 0 path ls3 offset 0 2019-12-01 19:11:10 24499 [24964]: open error -2 ls3 init done -19 [root@dhcp-1-91 ~]# sanlock direct init -D -s ls1:ls2:ls3:ls4 2019-12-01 19:11:15 24504 [24970]: lockspace ls1 host_id 0 path ls3 offset 0 2019-12-01 19:11:15 24504 [24970]: open error -2 ls3 init done -19 # sanlock direct init -D -s ::: 2019-12-01 19:14:00 24669 [25105]: lockspace host_id 0 path offset 0 Segmentation fault So it is not related to parsing of -h. This seems to be bad parsing of LOCKSPACE string, defined as: LOCKSPACE = <lockspace_name>:<host_id>:<path>:<offset> <lockspace_name> name of lockspace <host_id> local host identifier in lockspace <path> path to storage reserved for leases <offset> offset on path (bytes) In parse_arg_lockspace(). The expected behavior is to fail with usage error for these cases (based on the documentation above): - less than 4 components separated by ":" - lockspace_name is empty - host_id part is not host id integer value - path is empty - offset is not positive integer
Similar behavior with sanlock direct init -r RESOURCE RESOURCE = <lockspace_name>:<resource_name>:<path>:<offset>[:<lver>] <lockspace_name> name of lockspace <resource_name> name of resource <path> path to storage reserved for leases <offset> offset on path (bytes) <lver> optional leader version or SH for shared lease # sanlock direct init -D -r : resource arg parse error -6 Segmentation fault # sanlock direct init -D -r :: resource arg parse error -6 Segmentation fault # sanlock direct init -D -r ::: resource arg parse error -1 Segmentation fault # sanlock direct init -D -r :::: resource arg parse error -1 Segmentation fault # sanlock direct init -D -r res1::: resource arg parse error -1 Segmentation fault # sanlock direct init -D -r res1:res2:: resource arg parse error -1 Segmentation fault # sanlock direct init -D -r res1:res2:res4: resource arg parse error -1 Segmentation fault # sanlock direct init -D -r res1:res2:res3:res4:res5 resource arg parse error -1 Segmentation fault # sanlock direct init -D -r option 'r' requires arg Segmentation fault parse_arg_resource() looks very similar to parse_arg_lockspace(). Both should probably share code for parsing the argument. Finally, this also segfaults: # sanlock direct init Segmentation fault
Thanks for testing all those, I've tested them successfully with this fix https://pagure.io/sanlock/c/a8e3e326faf4acd33562ae9e19835007f724d65f?branch=master Regarding parse_arg_{lockspace,resource}, we don't always require all the components. Sometimes just the name is sufficient, but it depends on the command.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fixed in master, but we did not release sanlock with this fix in Fedora. Moving to 31 to handle that.
FEDORA-2020-99d4242726 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-99d4242726
FEDORA-2020-455253f67d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-455253f67d
FEDORA-2020-87665d32ca has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-87665d32ca
FEDORA-2020-99d4242726 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-99d4242726` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-99d4242726 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-455253f67d has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-455253f67d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-455253f67d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-87665d32ca has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-87665d32ca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-87665d32ca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-455253f67d has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-99d4242726 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-87665d32ca has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.