Bug 1027341

Summary:	LMI_FileIdentityProvider calls lstat() on hostname
Product:	[Fedora] Fedora	Reporter:	Klaus Kämpf <kkaempf>
Component:	openlmi-providers	Assignee:	Jan Synacek <jsynacek>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	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:

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 2 Jan Safranek 2013-11-13 13:39:29 UTC

Upstream fix: https://git.fedorahosted.org/cgit/openlmi-providers.git/commit/?id=a4e4d396c85fa897010c49e400e2992d9866c62a

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.