Bug 1027341 - LMI_FileIdentityProvider calls lstat() on hostname
LMI_FileIdentityProvider calls lstat() on hostname
Product: Fedora
Classification: Fedora
Component: openlmi-providers (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-06 10:30 EST by Klaus Kämpf
Modified: 2013-11-22 07:50 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-22 07:50:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Klaus Kämpf 2013-11-06 10:30:05 EST
Description of problem:
Enumerating associations of Linux_ComputerSystem fails with 'lstat(2) failed'

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install sfcb 1.4.6, sblim-cmpi-base, plus the following providers

2. Use pywbem yawn to get instance of Linux_ComputerSystem
3. Click on "objects associated with this instance"

Actual results:
lstat(2) failed

Expected results:

Additional info:
LMI_FileIdentityProvider.c, line 180, calls get_fsname_from_path on the 'Name' property of root/cimv2:Linux_ComputerSystem.CreationClassName="Linux_ComputerSystem",Name="host.domain.net"
Comment 1 Jan Safranek 2013-11-11 09:57:08 EST
I wonder why sfcb calls LMI_FileIdentityProvider.References() parameter with Linux_ComputerSystem - it does not associate CIM_ComputerSystem at all.

Some checks are needed though, chrashing is bad.
Comment 3 Klaus Kämpf 2013-11-13 10:05:59 EST
Thanks Jan !

However, I still get 'lstat(2) failed' when getting objects associated with an instance of LMI_Chassis.

Adding fprintf() reveals that lstat() is called on NULL.
Comment 4 Klaus Kämpf 2013-11-13 10:08:31 EST
gdb shows this backtrace:

#2  0x00007f93bcbb79c6 in get_fsname_from_path (b=0x7f93beec0f40 <_broker>, path=0x0, fsname=0x7f93bd5d35e8)
    at /abuild/projects/cim/openlmi/openlmi-providers/src/logicalfile/file.c:128
#3  0x00007f93bcbbff58 in references (mi=0x7f93bcdd3b80 <mi.12945>, cc=0x7f93b4000fa0, cr=0x7f93b400aaa0, cop=0x24fe7f0, assocClass=0x0, role=0x0, properties=0x0, 
    names=1) at /abuild/projects/cim/openlmi/openlmi-providers/src/logicalfile/LMI_DirectoryContainsFileProvider.c:282
#4  0x00007f93bcbc0bfc in LMI_DirectoryContainsFileReferenceNames (mi=0x7f93bcdd3b80 <mi.12945>, cc=0x7f93b4000fa0, cr=0x7f93b400aaa0, cop=0x24fe7f0, assocClass=0x0, 
    role=0x0) at /abuild/projects/cim/openlmi/openlmi-providers/src/logicalfile/LMI_DirectoryContainsFileProvider.c:501
#5  0x00007f93bec9b5b5 in referenceNames (hdr=0x24fe780, info=0x2505810, requestor=-137) at providerDrv.c:2628
#6  0x00007f93beca2786 in processProviderInvocationRequestsThread (prms=0x24fd6e0) at providerDrv.c:3493
#7  0x00007f93bea17e0f in start_thread () from /lib64/libpthread.so.0
#8  0x00007f93be74b44d in clone () from /lib64/libc.so.6
Comment 5 Jan Safranek 2013-11-22 07:50:19 EST
I pushed a fix to 0.4-fixes and master branches and it will be available in next OpenLMI release.

Note You need to log in before you can comment on or make changes to this bug.