Bug 1027341

Summary: LMI_FileIdentityProvider calls lstat() on hostname
Product: [Fedora] Fedora Reporter: Klaus Kämpf <kkaempf>
Component: openlmi-providersAssignee: Jan Synacek <jsynacek>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jsafrane, jsynacek, miminar, pschiffe, rnovacek, rrakus, tsmetana, vcrhonek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-22 12:50:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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

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


How reproducible:
Always

Steps to Reproduce:
1. Install sfcb 1.4.6, sblim-cmpi-base, plus the following providers
openlmi-tools-0.9-1.noarch
openlmi-providers-0.4.1-1.x86_64
openlmi-networking-0.2.1-1.x86_64
openlmi-hardware-0.4.1-1.x86_64
openlmi-indicationmanager-libs-0.4.1-1.x86_64
openlmi-python-base-0.4.1-1.noarch
openlmi-python-providers-0.4.1-1.noarch
openlmi-logicalfile-0.4.1-1.x86_64

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 14:57:08 UTC
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 15:05:59 UTC
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 15:08:31 UTC
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 12:50:19 UTC
I pushed a fix to 0.4-fixes and master branches and it will be available in next OpenLMI release.