Hide Forgot
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"
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.
Upstream fix: https://git.fedorahosted.org/cgit/openlmi-providers.git/commit/?id=a4e4d396c85fa897010c49e400e2992d9866c62a
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.
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
I pushed a fix to 0.4-fixes and master branches and it will be available in next OpenLMI release.