I have a reproducible segfault in lvextend.

The crashing command is this:
  lvextend -i1 -l +5492 /dev/gall-mite/root /dev/sdb

If reportbug doesn't include it by itself, I will send a copy of the
output of lvdisplay, vgdisplay and pvdisplay.

Here's that *display output I promised.

I have the system where this occurs ready and waiting for debugging
steps.  If I don't get useful suggestions here I may get out a
debugger :-).

BTW I'm aware of #561931 but (a) that's very old and (b) supplying the
pv name doesn't help:

root@gall-mite:~# lvextend -i1 -l +5492 /dev/gall-mite/root /dev/sdb
  Extending logical volume root to 453.52 GiB
  Segmentation fault

Thanks,
Ian.

root@gall-mite:~# lvdisplay -a
  --- Logical volume ---
  LV Path                /dev/gall-mite/root
  LV Name                root
  VG Name                gall-mite
  LV UUID                ieotHT-FTgL-3WX2-4Vlq-BVRq-GLNB-yoE7Uh
  LV Write Access        read/write
  LV Creation host, time gall-mite, 2014-01-20 17:34:34 +0000
  LV Status              available
  # open                 1
  LV Size                432.06 GiB
  Current LE             110608
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     512
  Block device           254:0

No errors from badblocks, pvck, vgck, lvck, fsck.

I have to use -i1 and specify PV /dev/sdb6 as LVM wants to use
PV /dev/sda6 which doesn't have the 64 free extents I need.

However if I ask for only 1 extent the lvextend works with sda6
but still segfaults with sdb6.

Tried all alloc policies - no change.

Tried --noudevsync - no change.

Tried creating new empty /etc/lvm/{backup,archive} - no change.

The segfault occurs even with -t.

Here's the last part of -vvv output before the segfault.  The
"leaving 0" seems to be an unrelated logging error as it is also
shown when lvextend is successful


  Extending logical volume IMS+++ to 130.00 GiB
      Extending segment type, striped
        Allowing allocation on /dev/sda6 start PE 2048 length 683
        Trying allocation using contiguous policy.
        Still need 64 total extents:
          1 (1 data/0 parity) parallel areas of 64 extents each
          0 mirror logs of 0 extents each
        Considering allocation area 1 as /dev/sda6 start PE 2048 length 683
leaving 0.
        Trying allocation using cling policy.
        Still need 64 total extents:
          1 (1 data/0 parity) parallel areas of 64 extents each
          0 mirror logs of 0 extents each
        Considering allocation area 1 as /dev/sda6 start PE 2048 length 683
leaving 0.
        Trying allocation using normal policy.
        Cling_to_allocated is set
        Still need 64 total extents:
          1 (1 data/0 parity) parallel areas of 64 extents each
          0 mirror logs of 0 extents each
        Considering allocation area 1 as /dev/sda6 start PE 2048 length 683
leaving 0.
Segmentation fault


If you need more info pls let me know.  Backuping up a giant LV, removing
it, creating a larger LV, and restoring is what LVM normally helps me avoid.

From an upstream point of view, that's a pretty old release now
and there have been numerous improvements and fixes to the
relevant allocation code.

Two choices:

  Use a more up-to-date version and there's a good chance you'll find the bug
  got fixed.

  Extend the metadata manually using vgcfgbackup, editing the text file
  to add the segment you need, and vgcfgrestore.

Alasdair