Description of problem:
I tried to run httpd after a long time of not using it, and it terminated while
starting showing message about segmantation fault. When i run http under gdb it
shown an exception from mod_python. And, when i disabled mod_python loading,
httpd started just fine.
Version-Release number of selected component (if applicable):
(just in case)
Steps to Reproduce:
1. Run httpd (/usr/sbin/httpd)
It terminates just after it was run and shows a message abotu segmentation fault.
errorless start of httpd
I attached log from gdb
Created attachment 156369 [details]
Log from gdb
Comment on attachment 156369 [details]
Log from gdb
---Type <return> to continue, or q <return> to quit---Error while reading
shared library symbols:
are because i accidentally preseed Ctrl C
There's nothing useful in there. It's better to do:
# echo CoreDumpDirectory /tmp > /etc/httpd/conf.d/core.conf
and generate a core dump, then analyse that after-the-fact with gdb.
Make sure you have up-to-date httpd, python, httpd-debuginfo, python-debuginfo
etc packages before running gdb.
I am having this problem with httpd-2.2.4-9 and mod_python-3.3.1-4 from devel.
When run under the debugger, I find that the coredump is occurring at line 1549
of mod_python.c, in python_handler
1549 conf = (py_config *) ap_get_module_config(req->per_dir_config,
req->per_dir_config is null at this point. I put breakpoints in python_handler
and python_create_dir_config, and I found that for some requests python_handler
is being called when python_create_dir_config hasn't been called. I don't
understand the Apache ABI / module mechanism well enough to know whether
python_create_dir_config is always supposed to be called (in which case Apache
is doing something wrong?) or sometimes isn't called (in which case mod_python
is doing something wrong?).
I should mention that the request that causes the segfault is one that doesn't
actually need python for processing.
Changing component from mod_python to httpd. When I disable mod_python from
loading, I get a crash in the same call (ap_get_module_config) inside mod_suphp.
This suggests that httpd, rather than mod_python or mod_suphp, is at fault. Or
perhaps mod_python and mod_suphp need to be rebuilt against current httpd-devel?
Yes, rebuilding mod_python and mod_suphp solved the problem. Does that mean
there should be separte mod_python and mod_suphp tickets for this, rather than a
single httpd ticket? Not sure how the bookkeeping should be handled...
*** This bug has been marked as a duplicate of 254241 ***