Re: Why is r-handler a garbled string?
You may be looking at something getting clobbered, and somehow that manifests itself on OpenSolaris but not on the other platform(s). Perhaps that has to do with the way data structures are aligned, endianness (are you on Sparc or Intel?) etc. Perhaps set some breakpoints and see if the handler field is ever intact and where it gets clobbered. In the SUNWapch22 package on OpenSolaris 2008.11, httpd 2.2.9 is stripped, so I can't do much with the debugger. But when I build my own apache 2.2.9 with debugging symbols (configure --with-included-apr --enable-maintainer-mode), I can't reproduce the problem. (And I think I have seen this same problem on amd64 Ubuntu, but I still need to confirm that...) JD
Re: Why is r-handler a garbled string?
On Dec 30, 2008, at 9:10 AM, John David Duncan wrote: You may be looking at something getting clobbered, and somehow that manifests itself on OpenSolaris but not on the other platform(s). Perhaps that has to do with the way data structures are aligned, endianness (are you on Sparc or Intel?) etc. Perhaps set some breakpoints and see if the handler field is ever intact and where it gets clobbered. In the SUNWapch22 package on OpenSolaris 2008.11, httpd 2.2.9 is stripped, so I can't do much with the debugger. But when I build my own apache 2.2.9 with debugging symbols (configure --with-included-apr --enable-maintainer-mode), I can't reproduce the problem. NIICE! Does this package ship with build/config.nice? What are the contents of that file? That should tell you how the package was built. And how did you build your own Apache? (And I think I have seen this same problem on amd64 Ubuntu, but I still need to confirm that...) Definitely interesting. Maybe even for the same reasons, although we shouldn't assume that. Thanks, S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
[Fwd: cvs commit: ports/archivers/gtar Makefile distinfo ports/archivers/gtar/files extra-patch-tests_gzip.at patch-configure patch-tests_gzip.at patch-tests_pipe.at patch-tests_shortr
gtar in freebsd ports now has this support as of today :)
since its in gtar, that means that any linux should have it once they
update to a new enough version of gtar.
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior System Admin - RideCharge, Inc. http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
---BeginMessage---
naddy 2008-12-30 17:41:11 UTC
FreeBSD ports repository
Modified files:
archivers/gtar Makefile distinfo
archivers/gtar/files patch-configure
Added files:
archivers/gtar/files patch-tests_gzip.at patch-tests_pipe.at
patch-tests_shortrec.at
patch-tests_testsuite.at
Removed files:
archivers/gtar/files extra-patch-tests_gzip.at
Log:
* Update to 1.21. Notable changes:
- Some new flags, e.g. -J for lzma compression and --lzop.
- transformation scope flags
Testsuite fixes from upstream CVS.
* Drop workarounds for no longer supported FreeBSD releases.
Revision ChangesPath
1.63 +4 -18 ports/archivers/gtar/Makefile
1.20 +3 -3 ports/archivers/gtar/distinfo
1.2 +0 -15 ports/archivers/gtar/files/extra-patch-tests_gzip.at
(dead)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/extra-patch-tests_gzip.at?rev=1.1content-type=text/x-cvsweb-markup
1.7 +9 -9 ports/archivers/gtar/files/patch-configure
1.1 +15 -0 ports/archivers/gtar/files/patch-tests_gzip.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_gzip.at?rev=1.1content-type=text/x-cvsweb-markup
1.1 +24 -0 ports/archivers/gtar/files/patch-tests_pipe.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_pipe.at?rev=1.1content-type=text/x-cvsweb-markup
1.1 +33 -0 ports/archivers/gtar/files/patch-tests_shortrec.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_shortrec.at?rev=1.1content-type=text/x-cvsweb-markup
1.1 +35 -0 ports/archivers/gtar/files/patch-tests_testsuite.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_testsuite.at?rev=1.1content-type=text/x-cvsweb-markup
http://cvsweb.FreeBSD.org/ports/archivers/gtar/Makefile.diff?r1=1.62r2=1.63f=h
| --- ports/archivers/gtar/Makefile 2008/08/20 00:56:24 1.62
| +++ ports/archivers/gtar/Makefile 2008/12/30 17:40:52 1.63
| @@ -2,12 +2,11 @@
| # Date created: Sa 6 Jun 1998 10:24:51 CEST
| # Whom: Andreas Klemm andr...@klemm.gtn.com
| #
| -# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/ports/archivers/gtar/Makefile,v
1.62 2008/08/20 00:56:24 ade Exp $
| +# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/ports/archivers/gtar/Makefile,v
1.63 2008/12/30 17:40:52 naddy Exp $
| #
|
| PORTNAME=tar
| -PORTVERSION= 1.20
| -PORTREVISION=1
| +PORTVERSION= 1.21
| CATEGORIES= archivers sysutils
| MASTER_SITES=${MASTER_SITE_GNU}
| MASTER_SITE_SUBDIR= ${PORTNAME}
| @@ -18,9 +17,11 @@ COMMENT= GNU version of the traditional
|
| # Actually we need lzma(1), but not the one in archivers/lzma.
| RUN_DEPENDS= ${LOCALBASE}/bin/lzcat:${PORTSDIR}/archivers/lzmautils
| +RUN_DEPENDS+=lzop:${PORTSDIR}/archivers/lzop
|
| INFO=tar
|
| +USE_AUTOTOOLS= autoconf:262:env# autom4te
| USE_BZIP2= yes
| USE_ICONV= yes
| GNU_CONFIGURE= yes
| @@ -44,22 +45,7 @@ CONFIGURE_ARGS+=--disable-nls
| PLIST_SUB+= NLS=@comment
| .endif
|
| -.include bsd.port.pre.mk
| -
| -# after the GNU gzip implementation was replaced with a BSD licensed version
| -.if (${OSVERSION} = 602105) \
| -(${OSVERSION} 70 || ${OSVERSION} = 700029)
| -USE_AUTOTOOLS= autoconf:262:env# autom4te
| -EXTRA_PATCHES= ${PATCHDIR}/extra-patch-tests_gzip.at
| -.endif
| -
| -# avoid triggering auto framework rebuilds
| -# FreeBSD 5.5 makeinfo can't rebuild tar.info
| -post-patch:
| - @${TOUCH} -r ${WRKSRC}/configure.orig ${WRKSRC}/configure
| - @${TOUCH} ${WRKSRC}/doc/tar.info* ${WRKSRC}/stamp-vti
| -
| regression-test: build
| @cd ${WRKSRC} ${SETENV} ${MAKE_ENV} ${MAKE} check
|
| -.include bsd.port.post.mk
| +.include bsd.port.mk
http://cvsweb.FreeBSD.org/ports/archivers/gtar/distinfo.diff?r1=1.19r2=1.20f=h
| --- ports/archivers/gtar/distinfo 2008/04/21 16:03:49 1.19
| +++ ports/archivers/gtar/distinfo 2008/12/30 17:41:02 1.20
| @@ -1,3 +1,3 @@
| -MD5 (tar-1.20.tar.bz2) = 1a7e17f27abf583b3b0bc059a827e68b
| -SHA256 (tar-1.20.tar.bz2) =
be8bf33afb5adc2377e45d94693ffd46b75f267f9b808df0c7006e51211f9deb
| -SIZE (tar-1.20.tar.bz2) = 1912591
| +MD5 (tar-1.21.tar.bz2) = 4f9028d231c3e7d7bdd658e14e74c2d1
|
Re: svn commit: r730181 - in /httpd/httpd/trunk/modules/mem: mod_slotmem.h providers/mod_plainmem.c providers/mod_sharedmem.c
On 12/30/2008 06:08 PM, j...@apache.org wrote:
Author: jim
Date: Tue Dec 30 09:08:24 2008
New Revision: 730181
URL: http://svn.apache.org/viewvc?rev=730181view=rev
Log:
And complete the API changes...
Modified:
httpd/httpd/trunk/modules/mem/mod_slotmem.h
httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c
httpd/httpd/trunk/modules/mem/providers/mod_sharedmem.c
Modified: httpd/httpd/trunk/modules/mem/mod_slotmem.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mem/mod_slotmem.h?rev=730181r1=730180r2=730181view=diff
==
Modified: httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c?rev=730181r1=730180r2=730181view=diff
==
--- httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c (original)
+++ httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c Tue Dec 30
09:08:24 2008
@@ -167,6 +159,7 @@
static void ap_plainmem_register_hook(apr_pool_t *p)
{
+static const char * const prePos[] = { mod_slotmem.c, NULL };
Why is prePos not used later on? And don't we need to do the same thing
regarding hook ordering for mod_sharedmem.c?
ap_register_provider(p, SLOTMEM_STORAGE, plain, 0, storage);
ap_hook_pre_config(pre_config, NULL, NULL, APR_HOOK_MIDDLE);
}
Re: svn commit: r730180 - in /httpd/httpd/trunk/modules/mem: config5.m4 mod_plainmem.c mod_sharedmem.c mod_slotmem.c mod_slotmem.h providers/ providers/Makefile.in providers/config6.m4 providers/mod_p
On 12/30/2008 06:07 PM, j...@apache.org wrote: Author: jim Date: Tue Dec 30 09:07:25 2008 New Revision: 730180 URL: http://svn.apache.org/viewvc?rev=730180view=rev Log: Start of further refactoring Added: httpd/httpd/trunk/modules/mem/mod_slotmem.c (with props) httpd/httpd/trunk/modules/mem/mod_slotmem.h (props changed) - copied unchanged from r730179, httpd/httpd/trunk/modules/mem/slotmem.h httpd/httpd/trunk/modules/mem/providers/ httpd/httpd/trunk/modules/mem/providers/Makefile.in (with props) httpd/httpd/trunk/modules/mem/providers/config6.m4 (with props) httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c (props changed) - copied unchanged from r730179, httpd/httpd/trunk/modules/mem/mod_plainmem.c httpd/httpd/trunk/modules/mem/providers/mod_sharedmem.c (props changed) - copied unchanged from r730179, httpd/httpd/trunk/modules/mem/mod_sharedmem.c Removed: httpd/httpd/trunk/modules/mem/mod_plainmem.c httpd/httpd/trunk/modules/mem/mod_sharedmem.c httpd/httpd/trunk/modules/mem/slotmem.h Modified: httpd/httpd/trunk/modules/mem/config5.m4 Added: httpd/httpd/trunk/modules/mem/providers/config6.m4 URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mem/providers/config6.m4?rev=730180view=auto == --- httpd/httpd/trunk/modules/mem/providers/config6.m4 (added) +++ httpd/httpd/trunk/modules/mem/providers/config6.m4 Tue Dec 30 09:07:25 2008 @@ -0,0 +1,14 @@ +dnl modules enabled in this directory by default + +dnl APACHE_MODULE(name, helptext[, objects[, structname[, default[, config) + +APACHE_MODPATH_INIT(mem/providers) + +sharedmem_objs=mod_sharedmem.lo +APACHE_MODULE(sharedmem, memslot provider that uses shared memory, $sharedmem_objs, , $slotmem_mods_enable) +APACHE_MODULE(plainmem, memslot provider that uses plain memory, , , no) + +# Ensure that other modules can pick up slotmem.h +APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current]) Why do we add this? slotmem.h should be in one directory above and should be already added by the local config.m4 file. Regards Rüdiger
Re: Why is r-handler a garbled string?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 John David Duncan wrote: if(strcmp(r-handler,my_name)) return DECLINED; why aren't you using strncmp?! Sorry, couldn't help it. I've seen (and exploited) way too many vulns like this. - -- Arturo Buanzo Busleiman Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJWofWAlpOsGhXcE0RCusdAJ4rGSTzod8vgjrwuwBOiCGcfZTg6wCfWDUY gcsvk8AaZeWEj7S/AyVrW4A= =GSRX -END PGP SIGNATURE-
Re: svn commit: r729641 - /httpd/mod_mbox/trunk/scripts/site-sitemap.py
On Sat, Dec 27, 2008 at 8:51 AM, pque...@apache.org wrote: Author: pquerna Date: Sat Dec 27 08:51:31 2008 New Revision: 729641 URL: http://svn.apache.org/viewvc?rev=729641view=rev Log: Change the sitemap index generator to split the sitemap indexes every 500 entries, as the great GOOG doesn't like big sitemap indexes. FYI, you should be able to support 1,000 entries as long as you don't hit the size limitations first. -- justin
Re: mod_fcgid license questions
pqf wrote:
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
apache2 with large number of logfiles. Apache2 calls poll()
(when OS supports it), and in that case it doesn't need to be recompiled
with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.
(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he considers
his contribution to have been just simple repairs (his term).
From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.
Foes anyone have a sense of whether these would indeed require
a CLA and SGA?
Chris.
=
--- fcgid_bridge.c2006/01/22 14:16:231.25
+++ fcgid_bridge.c2006/05/13 23:45:441.26
@@ -256,8 +256,11 @@
}
bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
-if (!bucket_ctx)
+if (!bucket_ctx) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_calloc of %d bytes failed in handle_request
function, sizeof(*bucket_ctx));
return HTTP_INTERNAL_SERVER_ERROR;
+}
bucket_ctx-ipc.connect_timeout = g_connect_timeout;
bucket_ctx-ipc.communation_timeout = g_comm_timeout;
bucket_ctx-ipc.request = r;
@@ -315,7 +318,7 @@
/* Now I get a connected ipc handle */
if (!bucket_ctx-procnode) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r-server,
mod_fcgid: can't apply process slot for %s, argv0);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -326,7 +329,7 @@
if ((rv =
proc_write_ipc(main_server, bucket_ctx-ipc,
output_brigade)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
mod_fcgid: write data to fastcgi server error);
bucket_ctx-has_error = 1;
return HTTP_INTERNAL_SERVER_ERROR;
@@ -335,8 +338,11 @@
/* Create brigade */
brigade_stdout =
apr_brigade_create(request_pool, r-connection-bucket_alloc);
-if (!brigade_stdout)
+if (!brigade_stdout) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_brigade_create failed in handle_request
function);
return HTTP_INTERNAL_SERVER_ERROR;
+}
APR_BRIGADE_INSERT_TAIL(brigade_stdout,
ap_bucket_fcgid_header_create(r-connection-
bucket_alloc,
@@ -346,7 +352,11 @@
/* Check the script header first. If got error, return immediately */
if ((cond_status = ap_scan_script_header_err_core
(r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+{
+ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+mod_fcgid: ap_scan_script_header_err_core failed in
handle_request function: %d, cond_status);
return cond_status;
+}
/* Check redirect */
location = apr_table_get(r-headers_out, Location);
@@ -377,6 +387,9 @@
if ((rv =
ap_pass_brigade(r-output_filters,
brigade_stdout)) != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: ap_pass_brigade failed in handle_request
function);
+
return HTTP_INTERNAL_SERVER_ERROR;
}
@@ -437,7 +450,7 @@
AP_MODE_READBYTES,
APR_BLOCK_READ,
HUGE_STRING_LEN)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
main_server,
mod_fcgid: can't get data from http client);
apr_brigade_destroy(output_brigade);
--- arch/unix/fcgid_proc_unix.c2006/01/22 14:16:231.27
+++ arch/unix/fcgid_proc_unix.c2006/05/13 23:45:441.28
@@ -2,6 +2,7 @@
#include sys/un.h
#include sys/types.h
#include netinet/tcp.h/* For TCP_NODELAY */
+#include sys/poll.h
#define CORE_PRIVATE
#include httpd.h
#include apr_thread_proc.h
@@ -525,10 +526,9 @@
fcgid_ipc * ipc_handle, const char *buffer,
apr_size_t * size)
{
-fd_set rset;
-struct timeval tv;
int retcode, unix_socket;
fcgid_namedpipe_handle *handle_info;
+struct pollfd pollfds[1];
handle_info = (fcgid_namedpipe_handle *) ipc_handle-ipc_handle_info;
Re: svn commit: r726113 - /httpd/httpd/trunk/server/mpm/worker/fdqueue.c
Hi --
I wrote:
What we had before was:
if (apr_atomic_casptr((volatile void**)(queue_info-recycled_pools),
new_recycle, next) == next) {
but also:
if (apr_atomic_cas32((queue_info-idlers), prev_idlers + 1,
prev_idlers) == prev_idlers) {
I see no reason why a pointer to an integer doesn't need a
volatile cast, while a pointer to a pointer does. I'm also not
aware of any problems reported caused by the lack of a cast on these
other apr_atomic_*() calls.
Consider too that all the apr_atomic_*() functions explicitly cast
their arguments as pointers to volatile data, so the compiler should
perform no optimization on data accesses within the function
(which is presumably where it counts). Putting a volatile cast on
the argument in the call could only mean something, it seems to me,
if the APR functions didn't explicitly do this already.
Further, the (volatile void**) casts for the recycled_pools pointer
were only added in the first place, according to the commit log, to
avoid compiler warnings (see r101236) -- which they no longer do for
gcc anyway, even if they ever did for some platform and compiler in
the past.
That all said, I did some additional reading on void** casts
and the meaning of the type-punning warning gcc generates, and
it would seem that the underlying reason for the warning here has to
do exclusively with casting a pointer to data (struct recycled_pool*)
to a void*. See http://c-faq.com/ptrs/genericpp.html
for what seems like a pretty decent explanation.
Based on that, it would appear to me that the issue with casting
the arguments passed to apr_atomic_casptr() is that should httpd
be compiled on some unusual platform where a void* is, say, larger
than a struct recycled_pool*, things might go awry.
Now, there are a number of APR functions which take void**
arguments, and I haven't thought about any of these except for the
two apr_atomic_*() ones.
Does anyone know if we should be concerned about any modern
platforms where void* is a different size than some other pointers?
(E.g., pointers to data and pointers to functions might be different
sizes, and void* the larger of the two?) In such a case, we might
need to refactor some code, including these apr_atomic_casptr()
calls. If not, then casting to void* to silence the warnings ought
to be tolerable, I think.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
On Dec 31, 2008, at 6:31 PM, Chris Darroch wrote: pqf wrote: version 1.10 ( Jul 3rd 2006 ) 1. Use poll() instead of select() in UNIX. It becomes problematic on apache2 with large number of logfiles. Apache2 calls poll() (when OS supports it), and in that case it doesn't need to be recompiled with larger FD_SETSIZE. select() is still limited to FD_SETSIZE. (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) 2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Ryan has been in touch with Piotr Gackiewicz independently and Piotr asks if we can confirm that a CLA and SGA are necessary, as he considers his contribution to have been just simple repairs (his term). From looking over the CVS repository at http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/ it would appear to me that these patches amount to the following. Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. Roy
Re: mod_fcgid license questions
Hi, guys
Thanks Chris first :)
Please take a look at the attachments, I got it from my mail archive. The
errorlog patch is a minor patch. the poll patch change not much lines of code,
but it did come with original idea.If Piotr Gackiewicz think his job is
simple repairs, I think these patchs can be put to minor patch group too.
Thanks
- Original Message -
From: Chris Darroch chr...@pearsoncmg.com
To: dev@httpd.apache.org
Sent: Wednesday, December 31, 2008 1:31 PM
Subject: Re: mod_fcgid license questions
pqf wrote:
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
apache2 with large number of logfiles. Apache2 calls poll()
(when OS supports it), and in that case it doesn't need to be recompiled
with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.
(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he considers
his contribution to have been just simple repairs (his term).
From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.
Foes anyone have a sense of whether these would indeed require
a CLA and SGA?
Chris.
=
--- fcgid_bridge.c2006/01/22 14:16:231.25
+++ fcgid_bridge.c2006/05/13 23:45:441.26
@@ -256,8 +256,11 @@
}
bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
-if (!bucket_ctx)
+if (!bucket_ctx) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_calloc of %d bytes failed in
handle_request function, sizeof(*bucket_ctx));
return HTTP_INTERNAL_SERVER_ERROR;
+}
bucket_ctx-ipc.connect_timeout = g_connect_timeout;
bucket_ctx-ipc.communation_timeout = g_comm_timeout;
bucket_ctx-ipc.request = r;
@@ -315,7 +318,7 @@
/* Now I get a connected ipc handle */
if (!bucket_ctx-procnode) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r-server,
mod_fcgid: can't apply process slot for %s, argv0);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -326,7 +329,7 @@
if ((rv =
proc_write_ipc(main_server, bucket_ctx-ipc,
output_brigade)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
mod_fcgid: write data to fastcgi server error);
bucket_ctx-has_error = 1;
return HTTP_INTERNAL_SERVER_ERROR;
@@ -335,8 +338,11 @@
/* Create brigade */
brigade_stdout =
apr_brigade_create(request_pool, r-connection-bucket_alloc);
-if (!brigade_stdout)
+if (!brigade_stdout) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_brigade_create failed in handle_request
function);
return HTTP_INTERNAL_SERVER_ERROR;
+}
APR_BRIGADE_INSERT_TAIL(brigade_stdout,
ap_bucket_fcgid_header_create(r-connection-
bucket_alloc,
@@ -346,7 +352,11 @@
/* Check the script header first. If got error, return immediately */
if ((cond_status = ap_scan_script_header_err_core
(r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+{
+ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+mod_fcgid: ap_scan_script_header_err_core failed in
handle_request function: %d, cond_status);
return cond_status;
+}
/* Check redirect */
location = apr_table_get(r-headers_out, Location);
@@ -377,6 +387,9 @@
if ((rv =
ap_pass_brigade(r-output_filters,
brigade_stdout)) != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: ap_pass_brigade failed in handle_request
function);
+
return HTTP_INTERNAL_SERVER_ERROR;
}
@@ -437,7 +450,7 @@
AP_MODE_READBYTES,
APR_BLOCK_READ,
HUGE_STRING_LEN)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
main_server,
mod_fcgid: can't get data from http client);
apr_brigade_destroy(output_brigade);
--- arch/unix/fcgid_proc_unix.c
