Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex
I think this is fixed already with this upstream patch (appeared in lvm2 v2.02.115): https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=f94f8463b0d3dddaa0e429123aba673d106f783e Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex
--[ Peter Rajnoha prajn...@redhat.com 2015-07-04 10:58:44 +0200 ] I think this is fixed already with this upstream patch (appeared in lvm2 v2.02.115): https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=f94f8463b0d3dddaa0e429123aba673d106f783e This looks very much like the behaviour I see. I didn't test the patch yet, though. --[ Julius Seemayer deb...@yeeer.net 2015-07-04 11:16:14 +0200 ] [...] - output is attached to this message. Of course I failed to attach the log, but it seems rather pointless since the bug got confirmed and patched elsewhere. Thanks for the quick reply to both of you! Cheers, Julius -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex
On Fri, Jul 03, 2015 at 11:50:39PM +0200, Julius Seemayer wrote: Please tell me if/how I can help to further debug this issue. 1) People need to see the complete debug output from the failing command with - added. That is what enables people to reproduce issues. 2) There have been a lot of changes to the reporting code since that release, so the first thing is to try a recent release to see if the bug is already fixed upstream. Alasdair -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex
--[ Alasdair G Kergon a...@redhat.com 2015-07-04 10:35:16 +0200 ] On Fri, Jul 03, 2015 at 11:50:39PM +0200, Julius Seemayer wrote: Please tell me if/how I can help to further debug this issue. 1) People need to see the complete debug output from the failing command with - added. That is what enables people to reproduce issues. - output is attached to this message. Note that I moved the debugging over to another host to avoid disclosure of internal paths etc.. The issue is still reproducible in the very same manner. 2) There have been a lot of changes to the reporting code since that release, so the first thing is to try a recent release to see if the bug is already fixed upstream. While I generally agree to your hint, lvm2 in particular seems to be as version 2.02.111-2.2 in all of stable, testing and unstable. Since both libdevmapper* and the binary lvm2 administration tools should have the same version in testing/unstable, I decided not to upgrade and test again. Cheers, Julius -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex
Package: lvm2
Version: 2.02.111-2.2
Severity: normal
Hi,
lvs --unbuffered in Jessie seems to be broken:
sh# ulimit -c $((1024*1024))
sh# lvs vm --select 'lv_name =~ .*img' --unbuffered || echo $?
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
Convert
test.img vm -wi-a- 8.00g
deb-installer.img vm -wi-ao 8.00g
Segmentation fault (core dumped)
139
sh# gdb -q lvs core
Reading symbols from lvs...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 23047]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `lvs vm --select lv_name =~ .*img --unbuffered'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7ff74c9a9ab8 in dm_bit_and () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
(gdb) bt
#0 0x7ff74c9a9ab8 in dm_bit_and () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#1 0x7ff74c9cf18c in ?? () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#2 0x7ff74c9cf3a2 in ?? () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#3 0x7ff74c9d00a2 in dm_regex_match () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#4 0x7ff74c9c5111 in ?? () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#5 0x7ff74c9c4ed7 in ?? () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#6 0x7ff74c9ca2f4 in dm_report_object () from
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#7 0x7ff74d4e0ee9 in report_object ()
#8 0x7ff74d467e82 in ?? ()
#9 0x7ff74d469a95 in process_each_lv_in_vg ()
#10 0x7ff74d46b494 in process_each_lv ()
#11 0x7ff74d468507 in ?? ()
#12 0x7ff74d45f258 in lvm_run_command ()
#13 0x7ff74d45f8ee in lvm2_main ()
#14 0x7ff74c3d9b45 in __libc_start_main (main=0x7ff74d44a6f0 main,
argc=5, argv=0x7ffe2708, init=optimized out, fini=optimized out,
rtld_fini=optimized out,
stack_end=0x7ffe27eeedf8) at libc-start.c:287
#15 0x7ff74d44a71e in _start ()
(gdb) q
sh#
I'm pretty sure that the issue is related to the regex expansion, since a
fixed string comparision ('=') works fine:
sh# lvs vm --select 'lv_name = test.img' --unbuffered || echo $?
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
Convert
test.img vm -wi-a- 8.00g
sh#
Also, the output does always consist of two lines plus header, before the
segfault occurs. I can confirm this on another host.
It is important to have at least four LVs inside a VG, this will trigger the
segfault. Having exactly three LVs does not segfault, but causes _wrong_
output (the last entry does not get displayed).
Please tell me if/how I can help to further debug this issue.
Cheers,
Julius
-- System Information:
Debian Release: 8.1
Architecture: amd64 (x86_64)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
