Bug 647457

Summary: Segfault when used with Spacewalk
Product: [Fedora] Fedora Reporter: Erik van Pienbroek <erik-fedora>
Component: pythonAssignee: Dave Malcolm <dmalcolm>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: dmalcolm, ivazqueznet, james.antill, jonathansteffan, jorton, robinlee.sysu
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: 2010-10-28 16:55:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
stacktrace none

Description Erik van Pienbroek 2010-10-28 13:31:39 UTC
Created attachment 456234 [details]
stacktrace

I have a Fedora 14 environment which has Spacewalk installed (https://fedorahosted.org/spacewalk/). When trying to create a kickstart file at the URL http://spacewalk-test.tribase.nl/rhn/kickstart/KickstartFileDownload.do?ksid=1 the httpd child which is processing the request segfaults.

I managed to collect the stacktrace with gdb. I think that mod_python (or python itself) is to blame for the segfault

Comment 1 Erik van Pienbroek 2010-10-28 15:25:13 UTC
With valgrind I managed to retrieve some additional information about the segfault:

==8235== Process terminating with default action of signal 11 (SIGSEGV)
==8235==  Access not within mapped region at address 0x10
==8235==    at 0x10EA09F5: do_warn (_warnings.c:449)
==8235==    by 0x10EA0F5A: PyErr_WarnEx (_warnings.c:719)
==8235==    by 0x10E3591D: PyCObject_FromVoidPtr (cobject.c:25)
==8235==    by 0x10BCB52A: save_interpreter (mod_python.c:185)
==8235==    by 0x10BCB6CC: get_interpreter (mod_python.c:261)
==8235==    by 0x10BCF302: python_handler (mod_python.c:1628)
==8235==    by 0x134787: ap_run_handler (config.c:158)
==8235==    by 0x134BEB: ap_invoke_handler (config.c:376)
==8235==    by 0x14238F: ap_process_request (http_request.c:282)
==8235==    by 0x13F457: ap_process_http_connection (http_core.c:190)
==8235==    by 0x13B3D7: ap_run_process_connection (connection.c:43)
==8235==    by 0x146DC9: child_main (prefork.c:662)

Comment 2 Erik van Pienbroek 2010-10-28 15:32:52 UTC
My guess is that the PyThreadState_GET() call mentioned at Python's _warnings.c:449 is returning NULL. The complete instruction at that line is: PyFrameObject *f = PyThreadState_GET()->frame;

Re-assigning to python

Comment 3 Joe Orton 2010-10-28 15:50:40 UTC
I haven't looked into this but the quick advice is: use mod_wsgi.

The backtrace:

(gdb) bt
#0  0x00007fffebcfe9f5 in setup_context (message='The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.', 

implies it may be something to do with exception handling during mod_python's interpreter setup.  I certainly wouldn't suspect a Python bug without diagnosing further.

Comment 4 Dave Malcolm 2010-10-28 16:55:20 UTC

*** This bug has been marked as a duplicate of bug 640432 ***