Bug 474226 - Seg Fault when using mod_proxy
Seg Fault when using mod_proxy
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Joe Orton
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-02 16:09 EST by Brenton Leanhardt
Modified: 2009-02-18 07:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-13 08:14:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brenton Leanhardt 2008-12-02 16:09:45 EST
Description of problem:
I upgraded a system to RHEL 5.3 Beta and noticed one of our web applications was inaccessible. The configuration is fairly straightforward:

ProxyPass /host http://localhost:8108
ProxyPassReverse /host http://localhost:8108

Version-Release number of selected component (if applicable):

httpd-2.2.3-19.el5

2.6.18-120.el5xen #1 SMP Fri Oct 17 18:17:26 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:


Steps to Reproduce:
1.  Startup our internal application
2.  Startup httpd
3.  Browse to a url under the /host context
  
Actual results:
User sees a white page.  

Error message in the log:
[Tue Dec 02 08:38:32 2008] [notice] child pid 5451 exit signal Segmentation fault (11)


Additional info:
I upgraded to httpd-2.2.3-22.el5.x86_64.rpm and our proxy worked as expected.
I grabbed that version from the build system.  For some strange reason I
couldn't even find the -19.el5 build so maybe this is a known issue.
Comment 1 Joe Orton 2008-12-03 03:56:15 EST
Yup, known issue with the -19.el5 packages. Thanks for the feedback.
Comment 2 Joe Orton 2009-01-13 08:14:29 EST
Closing this out as it was a bug affecting only an interim build, not in production.
Comment 3 Bertrand Jacquin 2009-02-18 07:44:28 EST
The problem still exist with httpd-2.2.3-22.el5. I did some traces, and all look like this :

722   setsockopt(107, SOL_TCP, TCP_NODELAY, [1], 4) = 0
722   fcntl64(107, F_GETFL)             = 0x2 (flags O_RDWR)
722   fcntl64(107, F_SETFL, O_RDWR|O_NONBLOCK) = 0
722   connect(107, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.1.123")}, 16) = -1 EINPROGRESS (Operation now in progress)
722   poll([{fd=107, events=POLLOUT, revents=POLLOUT}], 1, 300000) = 1
722   getsockopt(107, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
722   getsockname(107, {sa_family=AF_INET, sin_port=htons(35511), sin_addr=inet_addr("192.168.1.10")}, [16]) = 0
722   writev(107, [{"POST /XXX HTTP/1.1\r\nHost: webmail."..., 534}, {"\r\n", 2}], 2) = 536
722   read(107, 0x9dfc380, 8000)        = -1 EAGAIN (Resource temporarily unavailable)
722   poll([{fd=107, events=POLLIN, revents=POLLIN}], 1, 300000) = 1
722   read(107, "HTTP/1.0 504 Gateway Time-out\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n<html><body><h1>504 Gatewa"..., 8000) = 194
722   read(107, "", 8000)               = 0
722   close(107)                        = 0
722   gettimeofday({1234956612, 739129}, NULL) = 0
722   --- SIGSEGV (Segmentation fault) @ 0 (0) ---
722   chdir("/etc/httpd")               = 0
722   rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
722   kill(722, SIGSEGV)                = 0
722   sigreturn()                       = ? (mask now [])
722   --- SIGSEGV (Segmentation fault) @ 0 (0) ---

So, it seems to be an issue with 504.

httpd is here chained on a haproxy wihich do load-balacing to final sites. httpd is used with mod_security and as https frontend.

Haproxy return the 504.

I don't get to problem with httpd-2.2.3-6.el5

Thanks.
Comment 4 Joe Orton 2009-02-18 07:55:02 EST
Bertrand - thanks for the report.  Can you open a new bug for that issue, and:

1) attach the complete configuration you're using, and
2) obtain a backtrace from the crash?

# echo CoreDumpDirectory /tmp > /etc/httpd/conf.d/coredump.conf
# debuginfo-install --enablerepo=rhel-debuginfo httpd
# service httpd restart
... reproduce the issue...
# gdb /usr/sbin/httpd /tmp/core.<pid>
...
(gdb) bt full

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