Bug 958273 - Segfault loading openlmi-storage provider into Pegasus
Summary: Segfault loading openlmi-storage provider into Pegasus
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: tog-pegasus
Version: 19
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-30 19:20 UTC by Stephen Gallagher
Modified: 2013-06-18 06:10 UTC (History)
11 users (show)

Fixed In Version: tog-pegasus-2.12.1-4.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-18 06:10:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Backtrace (85.41 KB, text/plain)
2013-04-30 19:20 UTC, Stephen Gallagher
no flags Details

Description Stephen Gallagher 2013-04-30 19:20:52 UTC
Created attachment 741959 [details]
Backtrace

Description of problem:
After a certain idle time period, the storage provider is unloaded from pegasus. The next time a request comes in for the storage provider, Pegasus segfaults attempting to reload it.

Version-Release number of selected component (if applicable):
openlmi-storage-0.5.1-0.1.pre1.fc19.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Install and configure tog-pegasus and openlmi-storage
2. Perform several operations against the storage provider
3. Wait for a long while until Pegasus unloads the openlmi-storage provider (I have not measured it)
4. Perform another set of operations against the storage provider.
  
Actual results:
Pegasus crashes with the attached backtrace.

Expected results:
Pegasus should respond appropriately to the requests.

Additional info:

Log excerpt containing the last actions and then the crash (after an idle period).


DEBUG: Entering LMI_ConcreteJob.get_instance
DEBUG: Entering Job.get_method_params
DEBUG: Exiting Job.get_method_params
DEBUG: Entering Job.get_method_params
DEBUG: Exiting Job.get_method_params
DEBUG: Entering LMI_ConcreteJob.get_job_states
DEBUG: Exiting LMI_ConcreteJob.get_job_states
DEBUG: Exiting LMI_ConcreteJob.get_instance
EnumInstances() succeeded
[Thread 0x7f045d5c8700 (LWP 3539) exited]
[Thread 0x7f0446bc6700 (LWP 3600) exited]
[Thread 0x7f045cdc7700 (LWP 3663) exited]
Cleanup() called for Instance provider /usr/lib/python2.7/site-packages/openlmi/storage/cimom_entry.py
Cleanup() called, miHdl 0x7f046c003e30, miHdl->implementation 0x7f046d19a098, context 0x7f04701048f0, terminating 0
[Thread 0x7f0470083700 (LWP 3353) exited]
[Thread 0x7f04700c4700 (LWP 3352) exited]
[Thread 0x7f048a4eb700 (LWP 3305) exited]
Level 18: can_unload called
INFO: Provider shutdown.
Cleanup() 0
Cleanup() succeeded
Cleanup() called for Method provider /usr/lib/python2.7/site-packages/openlmi/storage/cimom_entry.py
Cleanup() called, miHdl 0x7f046c78af40, miHdl->implementation 0x7f046d19a098, context 0x7f04701048f0, terminating 0
Cleanup() 0
Calling Py_Finalize()
[Thread 0x7f048a4aa700 (LWP 3306) exited]
[Thread 0x7f0470042700 (LWP 3547) exited]
Cleanup() succeeded
Detaching after fork from child process 3667.
Detaching after fork from child process 3668.
Detaching after fork from child process 3669.
Detaching after fork from child process 3670.
Detaching after fork from child process 3671.
Detaching after fork from child process 3672.
Detaching after fork from child process 3673.
Detaching after fork from child process 3674.
Detaching after fork from child process 3675.
Detaching after fork from child process 3676.
Detaching after fork from child process 3677.
Detaching after fork from child process 3678.
[New Thread 0x7f0470042700 (LWP 3679)]

>>>>> in FACTORY: CMPIInstanceMI* _Generic_Create_InstanceMI... miname=/usr/lib/python2.7/site-packages/openlmi/storage/cimom_entry.py

>>>>> createInit() called, broker 0x7f046c002240, miname= /usr/lib/python2.7/site-packages/openlmi/storage/cimom_entry.py (ctx=0x7f0470041090), status 0x7f0470041040

<3288/0x70042700> Python: Loading

Program received signal SIGSEGV, Segmentation fault.

Comment 1 Jan Safranek 2013-05-07 07:42:48 UTC
It seems that it's Python fault, I filled bug there: http://bugs.python.org/issue17922

Comment 2 Fedora Admin XMLRPC Client 2013-05-10 04:59:58 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Fedora Admin XMLRPC Client 2013-05-10 05:01:09 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Jan Safranek 2013-05-29 13:52:31 UTC
I'm taking it back to tog-pegasus, I probably have a workaround.

I sent it upstream as http://bugzilla.openpegasus.org/show_bug.cgi?id=9669

Still, workaround in Pegasus does not make Python correct, Python should be able to reinitialize.

Comment 5 Fedora Update System 2013-06-04 10:52:57 UTC
tog-pegasus-2.12.1-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/tog-pegasus-2.12.1-4.fc19

Comment 6 Fedora Update System 2013-06-05 02:33:22 UTC
Package tog-pegasus-2.12.1-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tog-pegasus-2.12.1-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10043/tog-pegasus-2.12.1-4.fc19
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2013-06-18 06:10:56 UTC
tog-pegasus-2.12.1-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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