httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 50335] Cores dumped under high load (segmentation fault signal 11 SIGSEGV)
Date Tue, 13 Nov 2012 13:42:36 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=50335

--- Comment #24 from Jeff Trawick <trawick@apache.org> ---
(In reply to comment #23)
> Created attachment 29596 [details]
> gdb output from core 2012-11-13
> 
> Another core today, again at exactly 03:00.

Here's the backtrace of the crashing thread:

1 * [1] MPM child worker thread (running request handler)
  PyObject_Malloc, conn_alloc, CS_CONTEXT_ct_con_alloc, PyCFunction_Call,
PyEval_EvalFrameEx, PyEval_EvalCodeEx, function_call, PyObject_Call,
instancemethod_call, PyObject_Call, PyEval_CallObjectWithKeywords,
PyInstance_New, PyObject_Call, PyEval_EvalFrameEx, PyEval_EvalCodeEx,
PyEval_EvalFrameEx, PyEval_EvalFrameEx, PyEval_EvalCodeEx, function_call,
PyObject_Call, instancemethod_call, PyObject_Call,
PyEval_CallObjectWithKeywords, PyInstance_New, PyObject_Call,
PyEval_EvalFrameEx, PyEval_EvalFrameEx, PyEval_EvalFrameEx, PyEval_EvalCodeEx,
function_call, PyObject_Call, PyEval_EvalFrameEx, PyEval_EvalCodeEx,
PyEval_EvalFrameEx, PyEval_EvalCodeEx, PyEval_EvalFrameEx, PyEval_EvalFrameEx,
PyEval_EvalFrameEx, PyEval_EvalCodeEx, PyEval_EvalFrameEx, PyEval_EvalCodeEx,
function_call, PyObject_Call, instancemethod_call, PyObject_Call,
PyObject_CallMethod, python_handler, ap_run_handler, ap_invoke_handler,
ap_process_request, ap_process_http_connection, ap_run_process_connection,
worker_thread, dummy_worker

For context, here are the previous two in the same format:
Nov 11:
1 * [1] MPM child worker thread (running request handler) 
  PyObject_Malloc, PyString_FromStringAndSize, PySequence_GetSlice,
match_group, PyCFunction_Call, PyEval_EvalFrameEx, PyEval_EvalCodeEx,
PyEval_EvalFrameEx, PyEval_EvalFrameEx, PyEval_EvalFrameEx, PyEval_EvalCodeEx,
PyEval_EvalFrameEx, PyEval_EvalCodeEx, function_call, PyObject_Call,
instancemethod_call, PyObject_Call, PyObject_CallMethod, python_handler,
ap_run_handler, ap_invoke_handler, ap_process_request,
ap_process_http_connection, ap_run_process_connection, worker_thread,
dummy_worker
Nov 9:
1 * [39] MPM child worker thread 
  PyObject_Malloc, PyString_FromString, PyDict_GetItemString, get_interpreter,
python_cleanup, run_cleanups, apr_pool_destroy, apr_pool_clear, worker_thread,
dummy_worker

The 3:00 times suggest that *something* happens consistently, while the
occurrences in PyObject_Malloc suggest that the problem is very possibly
limited to the Python domain.  (I wouldn't say it is definitely caused by
something in the Python space, but it needs to be investigated from that
direction.  E.g., is the corruption caused by a memory overlay and is the data
recognizable?)

I don't see evidence in the backtraces of any web server-wide activity such as
graceful restart.  I guess you've checked the error and access logs for
anything interesting around that time?  Potentially you could wire up
mod_whatkilledus (http://emptyhammock.com/projects/httpd/diag/quick-start.html)
to see if there is something in common about the requests which trigger the
issue.

Unfortunately:
. This should be investigated separately from the mod_proxy issue (bug 50335)
as there's no reason to think they are related, and continuing here may be
confusing to others trying to understand the proxy issue.
. mod_python is officially dead for about 2.5 years, and I don't see any
discussion on the mod_python mailing list for over a year, so I don't know
where people that might have hints for debugging corruption in
Python/mod_python memory management would hang out.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message