[Bug 1532789] Re: Trusty multipath-tools suffering seg faults

Gábor Mészáros gabor.meszaros at canonical.com
Wed May 25 09:13:18 UTC 2016


The revert was intentional, due to a minor misunderstanding, which we

You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to multipath-tools in Ubuntu.

  Trusty multipath-tools suffering seg faults

Status in multipath-tools package in Ubuntu:
Status in multipath-tools source package in Trusty:
  Fix Committed

Bug description:

   * multipath segfaults constantly on given circumstances
   * multipath might make other tools relying on it to misbehave (openstack)

  [Test Case]

   * Core Dump given. No test case or reproducer. 
   * Will ask user in charge for the dump to verify fix.

  [Regression Potential]
   * Cherry-picked commit that EXACTLY fits seg fault and dump analysis.
   * Minor change.

  [Other Info]


  Original BUG Description:

  It was brought to my knowledge that multipath-tools is facing

  Core was generated by `/sbin/multipath -v0 /dev/sdab'. Program terminated with signal 11, Segmentation fault. #0  0x00007f2b5f6c8e88 in scsi_sysfs_pathinfo (pp=0xe5c0e0) at discovery.c:441

  All core dumps I received - several - have IP at the same place:

  #0  0x00007f2b5f6c8e88 in scsi_sysfs_pathinfo (pp=0xe5c0e0) at discovery.c:441
  #1  0x00007f2b5f6c9c26 in sysfs_pathinfo (pp=0xe5c0e0) at discovery.c:689
  #2  0x00007f2b5f6ca48b in pathinfo (pp=0xe5c0e0, hwtable=0xe222f0, mask=63) at discovery.c:823
  #3  0x00007f2b5f6c7858 in store_pathinfo (pathvec=0xe2d8d0, hwtable=0xe222f0, udevice=0xe5bc60, flag=31, pp_ptr=0x0) at discovery.c:57
  #4  0x00007f2b5f6c7953 in path_discover (pathvec=0xe2d8d0, conf=0xe22110, udevice=0xe5bc60, flag=31) at discovery.c:91
  #5  0x00007f2b5f6c7ad3 in path_discovery (pathvec=0xe2d8d0, conf=0xe22110, flag=31) at discovery.c:127
  #6  0x00000000004025e6 in configure () at main.c:322

  From libmultipath/discovery.c:

  if (!strncmp(udev_device_get_subsystem(parent), "scsi", 4)) {

  It is clear that strncmp is not taking care of cases when
  udev_device_get_subsystem returns NULL and that is - most likely -
  what is happening here. I have checked upstream development for this
  particular fix and found the following commit:

  commit e546687e046b1eb1cbe5567e9d7850cbbd682dba
  Author: Benjamin Marzinski <bmarzins at redhat.com>
  Date:   Sat Jan 12 00:04:54 2013 -0600

      multipath: check for NULL from udev_device_get_*

      The udev_device_get_* functions can return NULL, an occassionally do
      so in the multipathd code.  multipath needs to check if the result
      is NULL before dereferencing it.

      Signed-off-by: Benjamin Marzinski <bmarzins at redhat.com>

  Takes care of exactly this situation. This commit is found in the
  following versions:

  inaddy at rafael(/home/inaddy/Codes/bugs/1532789/upstream/multipath-tools)$ git tag --contains e546687e046b1eb1cbe5567e9d7850cbbd682dba

  And, from rmadison, this fix should be backported to Trusty & Vivid
  (not at 0.5.0 yet).

To manage notifications about this bug go to:

More information about the foundations-bugs mailing list