You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2005/07/23 13:07:36 UTC
DO NOT REPLY [Bug 34264] -
Broken mod_ssl/mod_cgid under Solaris 10 (gcc 64-bit) using MPM=worker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34264>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34264
------- Additional Comments From trawick@apache.org 2005-07-23 13:07 -------
A little more data on mod_cgid vs. Solaris 10:
Below is a trace of the mod_cgid daemon process. It is supposed to be reading
length (binary) followed by value of an environment variable. The first two
read() calls show this clearly. Look at the next two read calls though. It
reads the length properly on the first call. However, on the second call the
environment variable is prefixed with the same binary length, as if the sender
wrote the length twice. It goes downhill from there, as the mod_cgid daemon is
now out of sync with the mod_cgid handler. Next time it thinks it is reading
the length, it reads the last four bytes of the environment variable, and tries
to allocate a huge amount of memory.
If you start the web server and run cgid daemon and other child processes under
truss (-u not needed), it works fine. If you truss just the daemon, you can
still see the bogosity.
/1: read(10, "\0\0\011", 4) = 4
/1@1: <- libc:_read() = 4
/1@1: <- libc:read() = 4
/1@1: <- mod_cgid:sock_read() = 0
/1@1: -> libapr-0:apr_palloc(0x14e410, 0x12, 0x4, 0xfffffff8)
/1@1: <- libapr-0:apr_palloc() = 0x14e9b8
/1@1: -> libc_psr:memset(0x14e9b8, 0x0, 0x12, 0xfffffff8)
/1@1: <- libc_psr:memset() = 0x14e9b8
/1@1: -> mod_cgid:sock_read(0xa, 0x14e9b8, 0x11, 0xfffffff8)
/1@1: -> libc:read(0xa, 0x14e9b8, 0x11, 0x0)
/1@1: -> libc:_save_nv_regs(0xff092238, 0x0, 0x0, 0x0)
/1@1: <- libc:_save_nv_regs() = 0xff092238
/1@1: -> libc:_read(0xa, 0x14e9b8, 0x11, 0x0)
/1: read(10, " S E R V E R _ N A M E =".., 17) = 17
/1@1: <- libc:_read() = 17
/1@1: <- libc:read() = 17
/1@1: <- mod_cgid:sock_read() = 0
/1@1: -> mod_cgid:sock_read(0xa, 0xffbff870, 0x4, 0xfffffff8)
/1@1: -> libc:read(0xa, 0xffbff870, 0x4, 0x0)
/1@1: -> libc:_save_nv_regs(0xff092238, 0x0, 0x0, 0x0)
/1@1: <- libc:_save_nv_regs() = 0xff092238
/1@1: -> libc:_read(0xa, 0xffbff870, 0x4, 0x0)
/1: read(10, "\0\0\017", 4) = 4
/1@1: <- libc:_read() = 4
/1@1: <- libc:read() = 4
/1@1: <- mod_cgid:sock_read() = 0
/1@1: -> libapr-0:apr_palloc(0x14e410, 0x18, 0x4, 0xfffffff8)
/1@1: <- libapr-0:apr_palloc() = 0x14e9d0
/1@1: -> libc_psr:memset(0x14e9d0, 0x0, 0x18, 0xfffffff8)
/1@1: <- libc_psr:memset() = 0x14e9d0
/1@1: -> mod_cgid:sock_read(0xa, 0x14e9d0, 0x17, 0xfffffff8)
/1@1: -> libc:read(0xa, 0x14e9d0, 0x17, 0x0)
/1@1: -> libc:_save_nv_regs(0xff092238, 0x0, 0x0, 0x0)
/1@1: <- libc:_save_nv_regs() = 0xff092238
/1@1: -> libc:_read(0xa, 0x14e9d0, 0x17, 0x0)
/1: read(10, "\0\0\017 S E R V E R _ A".., 23) = 23
/1@1: <- libc:_read() = 23
/1@1: <- libc:read() = 23
/1@1: <- mod_cgid:sock_read() = 0
/1@1: -> mod_cgid:sock_read(0xa, 0xffbff870, 0x4, 0xfffffff8)
/1@1: -> libc:read(0xa, 0xffbff870, 0x4, 0x0)
/1@1: -> libc:_save_nv_regs(0xff092238, 0x0, 0x0, 0x0)
/1@1: <- libc:_save_nv_regs() = 0xff092238
/1@1: -> libc:_read(0xa, 0xffbff870, 0x4, 0x0)
/1: read(10, " . 2 3 2", 4) = 4
/1@1: <- libc:_read() = 4
/1@1: <- libc:read() = 4
/1@1: <- mod_cgid:sock_read() = 0
/1@1: -> libapr-0:apr_palloc(0x14e410, 0x2e323333, 0x4, 0xfffffff8)
The sender does have the capability of repeating the call to write(), but only
if it gets -1/EINTR:
static apr_status_t sock_write(int fd, const void *buf, size_t buf_size)
{
int rc;
do {
rc = write(fd, buf, buf_size);
} while (rc < 0 && errno == EINTR);
if (rc < 0) {
return errno;
}
return APR_SUCCESS;
}
But adding a write to error log for the repeat case doesn't show a repeated call
to write at the time that the server receives the binary envvar length twice.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org