Re: CGI app reports broken pipe error
Hi. that should mean that the web client disconnected, and your CGI shouldn't keep pumping out data So the moment the client is gone, and the CGI app attempts to send data, it will receive "broken pipe" (as there indeed no pipe anymore)? Is this the only reason for the error? prefork MPM and strace -f Thanks, will try them. Regards, Stas.
CGI app reports broken pipe error
Hi. I have a custom CGI application writing binary data to stdout. Recently, probably after some upgrade, I begin receiving write errors with the system error "Broken pipe". The only way to proceed writing is to discard the data portion I'm trying to write and continue. Can someone advice how to debug this and find the issue? Also, are there any know recent changes (from this year beginning/last year end) which could have caused this? I'm using CentOS 4.4, Apache version 2.0.52. Thanks, Stas.
Re: towards a 2.07 release
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: Shouldn't this be fatal? (now it continues to run and you can be sure that noone will notice that suggestion) it fails only later when you run make. From `svn log Makefile.PL`: r165547 | randyk | 2005-05-01 17:54:26 -0400 (Sun, 01 May 2005) | 4 lines When testing perl prerequisites, warn, rather than die, on failure, so as CPAN clients have a chance to install missing prerequisites. Is there a way (some environment variable perhaps) to tell whether we're running under a CPAN client or not? That way we could die() in the non-cpan case. You can try to detect whether you are running under CPAN, by just checking that CPAN is loaded may be. But most likely it's running things as external procs in which case you've no access to that info. In that case you could only check something like an env var. I've grep'ed around, it doesn't seem to set any ENV vars by CPAN. May be we should suggest to have one? Unfortunately there is still no way to pass -libmodperl option anywhere in Makefile.PL stage, so after getting a few dozen core files, I have to go manually and run: I think Philip was working on this- IIRC he added an MM_OPTS to ./configure but hasn't gotten round to updating Makefile.PL. Philip++ -- ___ Stas Bekman mailto:[EMAIL PROTECTED] | http://stason.org/ MailChannels: Assured Messaging (TM) | http://mailchannels.com/ The "Practical mod_perl" book| http://modperlbook.org/
Re: svn commit: r280386 - /httpd/httpd/branches/2.0.x/STATUS
William A. Rowe, Jr. wrote: Stas... when it says add new proposals to the end of this list, please do... this list is supposed to be FIFO. I'd agree with anyone adding a security fix to the end of security fixes at the top of the list, however. identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] +*) Add ReceiveBufferSize directive to control the TCP receive buffer. + code: http://svn.apache.org/viewcvs?view=rev&rev=157583 + docs: http://svn.apache.org/viewcvs?rev=280384&view=rev + +1: stas + *) Fix CAN-2005-2700, mod_ssl SSLVerifyClient bug http://svn.apache.org/viewcvs?rev=264800&view=rev test case: perl-framework/t/security/CAN-2005-2700.t sorry, fixed... -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://mailchannels.com
Re: new directive: ReceiveBufferSize
André Malo wrote: * Stas Bekman wrote: Stas Bekman wrote: Murray Nesbitt has submitted a request for a new feature ReceiveBufferSize: http://issues.apache.org/bugzilla/show_bug.cgi?id=36038 Hmm, it was already added to trunk 6 months ago, but for some reason wasn't backported to 2.0. What would be a reason to backport it? We need this feature. Any reasons against backporting it? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://mailchannels.com
Re: new directive: ReceiveBufferSize
Stas Bekman wrote: Murray Nesbitt has submitted a request for a new feature ReceiveBufferSize: http://issues.apache.org/bugzilla/show_bug.cgi?id=36038 Hmm, it was already added to trunk 6 months ago, but for some reason wasn't backported to 2.0. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://mailchannels.com
new directive: ReceiveBufferSize
Murray Nesbitt has submitted a request for a new feature
ReceiveBufferSize: http://issues.apache.org/bugzilla/show_bug.cgi?id=36038
The SendBufferSize directive, which is used to adjust the TCP send buffer
size, has existed for many years, but it would appear there has been no
pressing need for a companion directive to control the size of the TCP
receive buffer. We have written an application that requires the ability
to adjust the size of this buffer.
I have tried using apr_socket_opt_set, unfortunately the buffer size must
be modified prior to connect() or accept() (at least on Linux...).
I've attached the code part of his patch
(The complete unwrapped patch including docs update can be found here:
http://issues.apache.org/bugzilla/attachment.cgi?id=15898)
Any objections to committing this new feature?
--- httpd-2.0.54/include/ap_listen.h.orig 2005-08-04 15:28:37.0
-0700
+++ httpd-2.0.54/include/ap_listen.h2005-08-04 18:20:56.0 -0700
@@ -102,6 +102,8 @@
const char *ap_set_listener(cmd_parms *cmd, void *dummy, const char *ips);
const char *ap_set_send_buffer_size(cmd_parms *cmd, void *dummy,
const char *arg);
+const char *ap_set_receive_buffer_size(cmd_parms *cmd, void *dummy,
+ const char *arg);
#define LISTEN_COMMANDS\
AP_INIT_TAKE1("ListenBacklog", ap_set_listenbacklog, NULL, RSRC_CONF, \
@@ -109,6 +111,8 @@
AP_INIT_TAKE1("Listen", ap_set_listener, NULL, RSRC_CONF, \
"A port number or a numeric IP address and a port number"), \
AP_INIT_TAKE1("SendBufferSize", ap_set_send_buffer_size, NULL, RSRC_CONF, \
- "Send buffer size in bytes")
+ "Send buffer size in bytes"), \
+AP_INIT_TAKE1("ReceiveBufferSize", ap_set_receive_buffer_size, NULL,
RSRC_CONF, \
+ "Receive buffer size in bytes")
#endif
--- httpd-2.0.54/server/listen.c.orig 2005-02-04 12:21:18.0 -0800
+++ httpd-2.0.54/server/listen.c2005-08-04 18:12:19.0 -0700
@@ -40,6 +40,7 @@
static ap_listen_rec *old_listeners;
static int ap_listenbacklog;
static int send_buffer_size;
+static int receive_buffer_size;
/* TODO: make_sock is just begging and screaming for APR abstraction */
static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec *server)
@@ -118,6 +119,16 @@
/* not a fatal error */
}
}
+if (receive_buffer_size) {
+stat = apr_socket_opt_set(s, APR_SO_RCVBUF, receive_buffer_size);
+if (stat != APR_SUCCESS && stat != APR_ENOTIMPL) {
+ap_log_perror(APLOG_MARK, APLOG_WARNING, stat, p,
+ "make_sock: failed to set ReceiveBufferSize for "
+ "address %pI, using default",
+ server->bind_addr);
+/* not a fatal error */
+}
+}
#if APR_TCP_NODELAY_INHERITED
ap_sock_disable_nagle(s);
@@ -462,3 +473,21 @@
send_buffer_size = s;
return NULL;
}
+
+const char *ap_set_receive_buffer_size(cmd_parms *cmd, void *dummy,
+ const char *arg)
+{
+int s = atoi(arg);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
+if (s < 512 && s != 0) {
+return "ReceiveBufferSize must be >= 512 bytes, or 0 for system
default.";
+}
+
+receive_buffer_size = s;
+return NULL;
+}
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://mailchannels.com
Re: Watchdog code for Apache
Nick Kew wrote: A little while back, I hacked up a quick&dirty experimental watchdog module. It forks a watchdog process in the pre_mpm hook, which then watches the scoreboard and kills any process in which some request has taken more than some predefined time. Also check: http://search.cpan.org/dist/Apache-Watchdog-RunAway/ which exists since 2000 and works with both Apache 1.3 and 2.x. Though with 2.0 it has the same issues, as Nick have mentioned -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
ap_save_brigade => apr_save_brigade?
Hi, what's the status of ap_save_brigade()? why it is not in the libapr? Thanks. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Post-2.2 Thoughts
Paul Querna wrote: So, here is my short-list-made-up-this-afternoon of things I would like to look at doing after 2.2 is branched/released as GA. I welcome additions too. 1) Eliminate the HTTP in HTTPD. I would like to be able to compile httpd with --disable-http. Currently the 'http core' is half mangled with the 'core core'. and then we will have 'httpd' that can't serve http, how ironic :) may be 2.2 should rename 'httpd' to something more realistic? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] add TCP_DEFER_ACCEPT to 2.0.54
Paul Querna wrote: Stas Bekman wrote: Brian Akins wrote: Torsten Foertsch wrote: Maybe it is worth to make this option settable via httpd.conf? If there is interest, I could do that. This functionality is in 2.1, so some may object to adding this feature to 2.0. I am investigating its usefulness here, however. Folks, this functionality needs to be removed in 2.1 and 2.0 or somehow made it specific to the http handler. If it stays in it'll break any protocol handler whose protocol starts with a server greeting. So if it stays say bye bye to the SMTP protocol handler, which does exactly that. Torsten has refered to the failing test in the mod_perl test suite which implements an SMTP-like protocol handler. Apparently httpd needs more protocol tests so this kind of "features" won't go in w/o being noticed. Yes, I know this is broken, thats why I made the listen-protocol branch to solve this exact issue. Cool. Thanks Paul :) -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] add TCP_DEFER_ACCEPT to 2.0.54
Brian Akins wrote: Torsten Foertsch wrote: Maybe it is worth to make this option settable via httpd.conf? If there is interest, I could do that. This functionality is in 2.1, so some may object to adding this feature to 2.0. I am investigating its usefulness here, however. Folks, this functionality needs to be removed in 2.1 and 2.0 or somehow made it specific to the http handler. If it stays in it'll break any protocol handler whose protocol starts with a server greeting. So if it stays say bye bye to the SMTP protocol handler, which does exactly that. Torsten has refered to the failing test in the mod_perl test suite which implements an SMTP-like protocol handler. Apparently httpd needs more protocol tests so this kind of "features" won't go in w/o being noticed. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Flushing lingering CGI processes
Nick wrote: Hello Firstly, thank you to everyone who has contributed to the great apache project. I understand that if a CGI process is launched then gets stuck, if the CGI process keeps quiet, the apache server will not 'know' the http connection has broken so will not 'know' to kill the CGI process. The stuck CGI process and the accompanying apache process will then needlessly use system resources indefinately. In a worst case scenario, the stuck CGI process will lock some server resource possibly causing many other CGI processes to get stuck, bringing the server down. (I attribute a recent crash to this). A great solution for administrators would be to set a timer. If the CGI program hasn't given any output for the given time, the CGI process is killed. Nick, take a look at the perl module Apache::Watchdog::RunAway http://search.cpan.org/dist/Apache-Watchdog-RunAway/ http://search.cpan.org/dist/Apache-Watchdog-RunAway/RunAway.pm which does exactly what you want and comes with a little daemon. To operate it needs to be able to fetch the scoreboard, which can be done by either Apache::Scoreboard if you run mod_perl, or by a stand-alone C module mod_scoreboard_send.c. Both live here: http://search.cpan.org/dist/Apache-Scoreboard/ -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Retrieving address via remote_ip
William McKee wrote: Hi, I am seeking some assistance in tracking down a problem with building Apache 2.0.53 + mod_perl2.0.0-RC4 under a FreeBSD 5.3 jailed environment using gcc 3.4.2 and perl 5.8.6. One of the mod_perl tests is failing because it is getting a different remote_ip address than the address being reported by result of c->remote_ip. Apache's method is getting the real ip address whereas mod_perl is getting the loopback address. It has nothing to do with mod_perl, William. It's Apache-Test that you are after, which is used to test mod_perl. Both of these are correct but I need to figure out how to get them to match. I tried looking through the httpd source files but am not a C programmer and did not have much luck finding the section where remote_ip is set. Could someone give me a hand? it's set in server/core.c: apr_sockaddr_ip_get(&c->remote_ip, c->remote_addr); it obtains this information from the live socket connected to a client, whereas Apache-Test tries to resolve the hostname of your machine since at the time when it sets this value there is no connection yet. So as I've replied at the modperl list, you want to figure out how to make Apache-Test report the same value as if it had a live connection from the same machine. If you want to discuss how this can be done, let's do that on the test-dev list where this discussion belongs. Thanks. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test subdirectory has moved (again)
Geoffrey Young wrote: hi all... we (uh, I) kinda messed up during the first migration go-round and Apache-Test has moved once again, this time to a more svn-compliant directory structure. hopefully this will be the final resting place, at least for a while :) the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test/trunk what this means for you is that you need to manually adjust your checkout. again, I wasn't able to make this happen using anything short of $ rm -rf Apache-Test/ $ svn update It doesn't work for me. % rm -rf Apache-Test/ % svn up Apache-Test At revision 153479. it doesn't fetch the new Apache-Test. It seems that only a completely new checkout of the whole modperl-2.0 brings it in. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache-Test subdirectory has moved (again)
Geoffrey Young wrote: hi all... we (uh, I) kinda messed up during the first migration go-round and Apache-Test has moved once again, this time to a more svn-compliant directory structure. hopefully this will be the final resting place, at least for a while :) the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test/trunk what this means for you is that you need to manually adjust your checkout. again, I wasn't able to make this happen using anything short of $ rm -rf Apache-Test/ $ svn update but if you have a better way I'm sure we all would appreciate it. if you have any problems with access or permissions, just let me know and we'll get it sorted out. Always proves not to rush to update things :) I still didn't do any removes :) and many appologies for making this more painful than it needed to be. Thanks for doing the moving work, Geoff and Justin! -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_status and Req
Jim Jagielski wrote: Stas Bekman wrote: Jim Jagielski wrote: Justin Erenkrantz wrote: --On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: Any reason why we don't enable reporting of Req? I have a 2.1 patch ready to go, but I don't know why we don't do this I have no earthly idea what you are talking about. =) Can you please provide some more details? -- justin Already committed (love CTR). Basically, the 'Req' value displayed by mod_status is always 0 since we never update the required worker fields that note start and stop processing time. Whoah! wait long enough and the work will be done by someone else :) I was just about to get this done :) Jim, what would it take to backport it to 2.0? I see that 149550 changes ap_time_process_request API, but it's an internal API, no? Piece o' cake. I'll add it to 2.0's STATUS. Yeah, the ap_time_process_request API changed (for the better, IMO, since the worker "info" should be opaque(sp?)), but it's just internal. At least, we don't declare it as public :) thanks Jim. and 3 +1s were added already. if it makes into 2.0.53 that would be great. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
2.1: release showstopper: * the edge connection filter cannot be removed
httpd-2.1/STATUS: RELEASE SHOWSTOPPERS: * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2 jerenkrantz asks: Why should this block a release? because it requires a rewrite of the filters stack implementation (you have suggested that) and once 2.2 is released you can't do that anymore. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_status and Req
Jim Jagielski wrote: Justin Erenkrantz wrote: --On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: Any reason why we don't enable reporting of Req? I have a 2.1 patch ready to go, but I don't know why we don't do this I have no earthly idea what you are talking about. =) Can you please provide some more details? -- justin Already committed (love CTR). Basically, the 'Req' value displayed by mod_status is always 0 since we never update the required worker fields that note start and stop processing time. Whoah! wait long enough and the work will be done by someone else :) I was just about to get this done :) Jim, what would it take to backport it to 2.0? I see that 149550 changes ap_time_process_request API, but it's an internal API, no? -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [apache-2.1.3] buffering content in input filter
Pawel Niewiadomski wrote: hello, I'm writing an input filter that needs to operate on a full content of incoming request. But it should not pass incoming data to other input filters - it gathers full body of request, changes it and then passes it further. I have one problem - if I empty a brigade that is passed to the input filter it is not called again. I read that free brigades mean that input is ended. If I leave a byte in the brigade everything works ok - input filter is called until EOS and I can dump previously gathered content. But I don't want to add these bytes. Does anyone know how can I solve this problem? Instead of returning empty brigades up the stream, you can gobble up all incoming data by issuing your own ap_get_brigade calls. I don't have example in C, but you can see how it's done in perl: t/filter/TestFilter/in_bbs_consume.pm http://svn.apache.org/viewcvs.cgi/perl/modperl/trunk/t/filter/TestFilter/in_bbs_consume.pm?rev=106958&view=markup -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
resolving the "removing the first connection filter in chain" bug
1.5+ years ago I've submitted this bug report. Back then the answer was (I
think by Justin): the fix is to rewrite the filter chains to be
double-linked and that will be possible only in 2.1. As now it's about
time to implement this, please suggest how it's the best to proceeed.
Original Message
Subject: [BUG] in 2.0's ap_read_request with regards to removing the first
connection filter in chain
Date: Fri, 23 May 2003 14:01:45 +1000
From: Stas Bekman <[EMAIL PROTECTED]>
Reply-To: dev@httpd.apache.org
Organization: Hope, Humanized
To: dev@httpd.apache.org
there is an edge case bug in filter removal code.
ap_read_request has the following code:
r->proto_output_filters = conn->output_filters;
r->output_filters = r->proto_output_filters;
r->proto_input_filters = conn->input_filters;
r->input_filters = r->proto_input_filters;
this makes it impossible to remove the very first filter in
conn->output_filters or conn->input_filters, because while it gets
conn->removed from the corresponding conn filter
conn->chain. r->output_filters and r->input_filters are still pointing
conn->to that filter, which was removed. Result: the filter gets
conn->invoked again and again...
I was toying with different possible solutions but they all have
failed to work perfectly. I believe the only long-term solution, which
doesn't slow things down, is to extend the filter struct to add a
'prev' entry, turning the filter chain into double-linked list, so
remove_any_filter can fix
r->input_filters directly.
I was thinking to plug a dummy pass-through filter as an alternative
solution, but one has to ensure that no user filter will be able to
insert a filter in front of it. So if we can ensure that
conn->output_filters always starts with a dummy filter, removing any
other filters will work correctly. This can be accomplished by
changing add_any_filter and other functions to keep the dummy edge
filter at the top of the connection filter chain.
I have a cheating solution though, the patch below, instead of
removing the edge filter, replaces its frec with an frec for a dummy
pass-through filter. I've run multiple filter tests on it and it
seems to work fine. The only potential problem with this solution if
anything is trying to access frec of the filter that was removed (just
because it may still be running). So this solution is not clean,
because it reminds me of cutting the brach ones sit on.
Index: include/http_core.h
===
RCS file: /home/cvs/httpd-2.0/include/http_core.h,v
retrieving revision 1.70.2.2
diff -u -r1.70.2.2 http_core.h
--- include/http_core.h 8 May 2003 20:49:32 - 1.70.2.2
+++ include/http_core.h 23 May 2003 03:56:18 -
@@ -609,7 +609,9 @@
extern AP_DECLARE_DATA ap_filter_rec_t *ap_content_length_filter_handle;
extern AP_DECLARE_DATA ap_filter_rec_t *ap_net_time_filter_handle;
extern AP_DECLARE_DATA ap_filter_rec_t *ap_core_input_filter_handle;
-
+extern AP_DECLARE_DATA ap_filter_rec_t *ap_core_dummy_input_filter_handle;
+extern AP_DECLARE_DATA ap_filter_rec_t *ap_core_dummy_output_filter_handle;
+
/**
* This hook provdes a way for modules to provide metrics/statistics about
* their operational status.
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.225.2.6
diff -u -r1.225.2.6 core.c
--- server/core.c 13 May 2003 16:01:04 - 1.225.2.6
+++ server/core.c 23 May 2003 03:56:18 -
@@ -125,6 +125,8 @@
AP_DECLARE_DATA ap_filter_rec_t *ap_content_length_filter_handle;
AP_DECLARE_DATA ap_filter_rec_t *ap_net_time_filter_handle;
AP_DECLARE_DATA ap_filter_rec_t *ap_core_input_filter_handle;
+AP_DECLARE_DATA ap_filter_rec_t *ap_core_dummy_input_filter_handle;
+AP_DECLARE_DATA ap_filter_rec_t *ap_core_dummy_output_filter_handle;
static void *create_core_dir_config(apr_pool_t *a, char *dir)
{
@@ -3483,6 +3485,19 @@
} while (!APR_BRIGADE_EMPTY(b) && (e != APR_BRIGADE_SENTINEL(b))); \
} while (0)
+static int core_dummy_input_filter(ap_filter_t *f, apr_bucket_brigade *b,
+ ap_input_mode_t mode, apr_read_type_e
block,
+ apr_off_t readbytes)
+{
+return ap_get_brigade(f->next, b, mode, block, readbytes);
+}
+
+static int core_dummy_output_filter(ap_filter_t *f,
+apr_bucket_brigade *b)
+{
+return ap_pass_brigade(f->next, b);
+}
+
static int core_input_filter(ap_filter_t *f, apr_bucket_brigade *b,
ap_input_mode_t mode, apr_read_type_e block,
apr_off_t readbytes)
@@ -4288,6 +4303,12 @@
*/
ap_hook_insert_filter(core_insert_filter, NULL, NULL, APR_HOOK_MIDDLE);
+
Re: kill -HUP vs. httpd -k graceful
Jeff Trawick wrote: On Thu, 02 Dec 2004 13:41:07 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote: Is there a difference between kill -HUP and httpd -k graceful? One user has reported problems with using kill -HUP graceful uses signal USR1; ungraceful restart uses HUP; Thanks Jeff. not expected that HUP would cause a crash It's quite expected if it's ungraceful. I've reported this problem long long time ago. If something is run for longer than the shutdown is willing to wait after SIGKILL was sent (e.g. pool cleanups), SIGTERM is sent and then crashes are normal. I can easily reproduce that at will. Please see: http://issues.apache.org/bugzilla/show_bug.cgi?id=23238 -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
kill -HUP vs. httpd -k graceful
Is there a difference between kill -HUP and httpd -k graceful? One user has reported problems with using kill -HUP [Fri Nov 19 00:00:05 2004] [warn] child process 12783 still did not exit, sending a SIGTERM [Fri Nov 19 00:00:05 2004] [notice] SIGHUP received. Attempting to restart panic: pthread_key_create and dumps core... whereas httpd -k graceful doesn't have this problem. Unfortunately I can't tell you which MPM he was using, since he didn't bother to tell. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Thanks Jeff and Andy, here is the updated version: Usage of signals outside the httpd core: 3rd party Apache 2 modules should avoid using code relying on signals. This is because typical signal use is not thread-safe and modules which rely on signals may not work portably. Certain signals may still work for non-threaded mpms. For example alarm() can be used under prefork MPM, but it won't work on any other MPM. Moreover Apache can't guarantee that the signals that currently happen to work will continue to do so in the future Apache releases. So use them at your own risk. It should be possible to rework the code using signals to use an alternative solution, which works under threads. For example if you were using alarm() to trap potentially long running I/O, you can modify the I/O logic for select/poll usage (or if you use APR I/O then set timeouts on the apr pipes or sockets). For example, Apache 1.3 on Unix made blocking I/O calls and relied on the parent process to send the SIGALRM signal to break it out of the I/O after a timeout expired. With Apache 2.0, APR support for timeouts on I/O operations is used so that signals or other thread-unsafe mechanisms are not necessary. CPU timeout handling is another example. It can be accomplished by modifying the computation logic to explicitly check for the timeout at intervals. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Jeff Trawick wrote: [...] 1) what would be the best place to document that in the Apache docs (mpm include/ap_mpm.h or should each mpm have it documented separately? how about at http://httpd.apache.org/docs-2.0/developer/ -> http://httpd.apache.org/docs-2.0/developer/thread_safety.html That already points out some generic thread safety information. The inappropriateness of the alarm()/SIGALRM idiom is another piece of such information. Sounds good, but let's polish here first what we want to add. 2) what's the policy on non-threaded mpms, i.e. which signals are declared usable in the user code (i.e. declare an API so one could rely on it) We can have a small section on signals in that document to point out that typical signal use is not thread-safe, and that modules which rely on signals may not work portably. A good example would be a module which uses alarm() and happens to work with the prefork MPM on Unix but does not work with any other MPM or platform. Agreed. As far as explicitly laying out what sort of signal usage will work in which MPMs: (a) I'm not sure we can do an accurate job without spending a lot of effort, and then we're tied to trying to make whatever we document work forever and ever (b) we wouldn't want to promote such practices anyway Understood. Thanks Jeff for the detailed explanation! So here is the proposed addition to the http://httpd.apache.org/docs-2.0/developer/thread_safety.html doc, based on your input, Jeff: Usage of signals outside the httpd core: 3rd party Apache 2 modules should avoid using code relying on signals. This is because typical signal use is not thread-safe and modules which rely on signals may not work portably. Certain signals may still work for non-threaded mpms. For example alarm() can be used under prefork MPM, but it won't work on any other MPM. Moreover Apache can't guarantee that the signals that currently happen to work will continue to do so in the future Apache releases. So use them at your own risk. It should be possible to rework the code using signals to use an alternative solution, which works under threads. For example if you were using alarm() to trap potentially long running I/O, you can modify the I/O logic for select/poll usage (or if you use APR I/O then set timeouts on the apr pipes or sockets). Apache 2.0 switched from the magic, thread-unsafe mechanism of having the parent send SIGALRM when the child didn't update a timeout field in the scoreboard for a "long time" to the explicit thread-safe mechanism of using select()/poll() on I/O. CPU timeout handling is another example. It can be accomplished by modifying the computation logic to explicitly check for the timeout at intervals. Alternatively one could use a manager thread that implements something like a thread-specific alarm(), where a signal handler running on the interrupted thread does siglongjmp() to break out of the interrupted processing, but implementing that sort of service is not trivial. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Jeff Trawick wrote:
On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction->new(sub { die "alarm" }))
or die "Error setting SIGALRM handler: $!\n";
alarm 2;
potentially_long_running_process()
alarm 0;
};
do_something() if $@ && $@ =~ /alarm/;
no, can't do that, unless you're the only thread in the process that
does anything like that since
1) any other code in the process can wipe out your SIGALRM handler
2) only one "alarm" per process
Thanks Jeff for the explanations.
So it's a 100% no go with threads. But I understand that it should work
just fine with prefork (and it does so far). so I have the following
questions:
1) what would be the best place to document that in the Apache docs (mpm
include/ap_mpm.h or should each mpm have it documented separately?
2) what's the policy on non-threaded mpms, i.e. which signals are declared
usable in the user code (i.e. declare an API so one could rely on it)
3) in the particular case of threads, what's the alternative approach to
the SIGALARM technique to trap long running/potentially run-away code
(e.g. IO). So we can offer something to the users migrating their code
from 1.3.x.
Is there some thread-aware service which works sort of like the thread-unaware
alarm()
call which will send SIGALRM to a specific thread?
Nope. but if the signal is sent by the same thread that catches it, it's
still not guaranteed that it'll get it?
the SIGALRM signal sent due to a call to alarm() is sent by the
kernel; no guarantee which thread will get it, unless there is only
one thread which doesn't have SIGALRM blocked
Got it. Thanks Jeff.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction->new(sub { die "alarm" }))
or die "Error setting SIGALRM handler: $!\n";
alarm 2;
potentially_long_running_process()
alarm 0;
};
do_something() if $@ && $@ =~ /alarm/;
Is there some thread-aware service which works sort of like the thread-unaware alarm()
call which will send SIGALRM to a specific thread?
Nope. but if the signal is sent by the same thread that catches it, it's
still not guaranteed that it'll get it?
SIGALRM is an asynchronous signal which can be delivered on any thread
that does not have the signal specifically blocked; if the user code
is just expecting their operation on the current thread to be
interrupted when the SIGALRM signal is generated, &deity; help them;
potentially some thread-aware code is sending SIGALRM to a specific
thread; it would be helpful to understand the testcase better
Understood. it's true even if the signal is sent by the same thread that
catches it? See the example above for the test case.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Cliff Woolley wrote: On Mon, 29 Nov 2004, Stas Bekman wrote: nuke it? So this is incorrect? - The MPM does not set a SIGALRM handler, user code may use SIGALRM. It can use it if it knows what it's doing. What do you mean? A mod_perl module that's expected to work on any MPM (which is I'm assuming what you're talking about) is not going to fall into the category of "knows what it's doing" if it tries to use signals. :-) It's the case with any other mod_*, not only mod_perl. What the alternative solution for the widely used alarm() technique? I'd expect to have a documented API, regarding signals in Apache 2.x * No signals are to be used in user code * Certain signals (please list which) can be used in all mpms * Certain signals (please list which) can be used only in certain mpms. The current situation of guess what works and what will continue to work tomorrow approach sucks. Let's polish this issue and I'll make sure it's properly documented. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Bill Stoddard wrote: Stas Bekman wrote: Jeff Trawick wrote: On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote: Is there some doc explaining the usage of signal handlers under different mpms? No, although I would suggest the following ;) /* @tip Don't use signals in your own modules. Apache makes no effort to * support modules which use signals. Module behavior which is dependent * on signals can be expected to vary between MPMs or platforms. */ I don't use, but users do. Then god help us all. I'm constantly reminded in my day to day work that there are really very few people 'out there' who really appreciate the nuances of threaded programming on Unix. Bleh. Even with POSIX signal handlers? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Cliff Woolley wrote: On Mon, 29 Nov 2004, Stas Bekman wrote: ./include/ap_mpm.h unix/posix notes: - The MPM does not set a SIGALRM handler, user code may use SIGALRM. But the preferred method of handling timeouts is to use the timeouts provided by the BUFF abstraction. That's an ancient comment that dates back to Apache 1.3 and no longer applies to anything. BUFF no longer exists. nuke it? So this is incorrect? - The MPM does not set a SIGALRM handler, user code may use SIGALRM. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Jeff Trawick wrote: On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote: Is there some doc explaining the usage of signal handlers under different mpms? No, although I would suggest the following ;) /* @tip Don't use signals in your own modules. Apache makes no effort to * support modules which use signals. Module behavior which is dependent * on signals can be expected to vary between MPMs or platforms. */ I don't use, but users do. And SIGALRM is widely used to technique to trap a runaway operation, so we aren't talking about signals in general, but to start with with a few certain ones. I get SIGALRM working fine under prefork mpm, but not under worker. I assume that it traps the signal before the user code's handler runs, child_main() calls apr_setup_signal_thread(), which ignores all signals. I suspect this is what "breaks" SIGALRM for you with worker MPM. Try commenting out the call to apr_setup_signal_thread(). If I comment it the behavior is completely broken (the thread just silently dies) If a module doesn't completely isolate its signal use from the MPM, it may be hard for the module to operate predictably, or for Apache to make changes to fix its own problems. What thread are you using to handle the SIGALRM? Why not create your own thread and have it sit in sigwait() for SIGALRM? again we are talking about the normal worker thread, where a user runs some code first setting SIGALRM. *don't rely on MPM-created threads to have a particular signal mask *don't use MPM-created threads to run handlers or otherwise react to signals Also I've found: ./include/ap_mpm.h unix/posix notes: - The MPM does not set a SIGALRM handler, user code may use SIGALRM. But the preferred method of handling timeouts is to use the timeouts provided by the BUFF abstraction. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_comment
Greg Stein wrote: This is a desired change. In no way is it close to being a showstopper. Further, I'm not even sure how to provide the feature and (at the same time) keep the fp private. Some callback nonsense or something with buffers. Blech... I'd like to just toss the feature and be done with it :-) But no... if somebody happens to get the desire to fix it by 2.2, then great. If nobody does, then great. Not so fast Greg. You can't just cut an arm because *you* decided you don't like it anymore. The feature was never called experimental and wasn't scheduled to go away. Now there are multiple users who rely on this feature, both in apache 1.3 and apache 2.x land. So if you suggest a different approach to solve the problem that's fine. But just dropping it on the floor in Apache 2.2 is not an option. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_comment
Greg Stein wrote: On Mon, Nov 29, 2004 at 01:54:18PM -0500, Geoffrey Young wrote: Justin Erenkrantz wrote: --On Monday, November 29, 2004 10:41 AM -0800 Greg Stein <[EMAIL PROTECTED]> wrote: but we were not allowed to remove features. Removing the fp from the API would have disabled this "feature" in mod_perl, among others. I can't tell you how often I've been bitten personally by mod_perl trying to reparse our configuration because of this 'feature.' It needs to go away big time. sorry, but I'm not following. can you guys be specific (code wise) about what is supposed to be forbidden? my only knowledge of mod_perl using that file pointer is when implementing containers where we (of course) need to know what is between the opening and closing markers. Yup. That's the one. And to do that, you use the file pointer which gets passed out thru the API. so what's the proposed replacement? If we get memmapped pointer or any other pointer that can be parsed instead, that will work just fine. Just hiding the fp from the API will make it impossible to implement custom containers. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
signals under worker mpm?
Is there some doc explaining the usage of signal handlers under different mpms? I get SIGALRM working fine under prefork mpm, but not under worker. I assume that it traps the signal before the user code's handler runs, simple grepping doesn't come up with anything useful, so if someone who understands those issues could follow up, that would be great. Thanks. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apxs/apr-config/apu-config on Win32
Randy Kobes wrote: I've been testing out some perl scripts to emulate apxs/apr-config/apu-config on Win32 (under Apache/2.0.x), and was wondering if there was any interest in developing them within the appropriate httpd/apr sources. At present they can be installed via a perl script http://perl.apache.org/dist/win32-bin/install_apxs This assumes an installed Apache binary with the associated apr/aprutil libs, but it would be possible to separate out the apxs from the apr/apu config utilties. In their present form they're intended for building modules outside of the httpd sources; they've been tested out on the c-modules within the perl-framework under httpd-test, as well as those under env/ of httpd-apreq-2, and they seem to work OK. +1 Randy is a long time committer to the mod_perl project, so I'm sure that if the proposed scripts are integrated with apr/httpd, Randy will be able to maintain those, once the right karma is added. There are very few brave folks who handle the win32 world, so let's make it easier for them to help the disadventaged win32 users. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_proxy debug warnings
Mladen Turk wrote: Stas Bekman wrote: So it's not possible that the number of logs relates to the number of child_init calls. Though I do have 32 vhosts, which matches much better the number of debug lines (33). So does it print one per vhost? Yes, they are duplicated for each virtual host and that is wrong behavior. They should be initialized only once. I'll fix that. That's better :) Thanks Mladen! -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Towards a generic database connection API
Nick Kew wrote: On Sun, 28 Nov 2004, Stas Bekman wrote: Please take a look at DBDI Project. http://groups.google.com/[EMAIL PROTECTED] which already targets Perl6 DBI, Python DBI, Ruby DBI, PHP DBI etc. Hmmm. Interesting in principle, but there's not sufficient information at that URL to determine whether it's useful or relevant. The description reads more like a layer on top of [something answering the description of] libdbi than anything relevant to httpd or APR. Notwithstanding Tim Bunce's personal credibility rating, libdbi would seem a better startingpoint, simply by virtue of the fact that it has a nice clear set of published APIs. DBDI builds on the existing familiar Perl DBI/DBD. My goal is simply a thin layer that ties a DBDriver API in to Apache: a connection (nonthreaded MPMs - trivial) or connection pool (threaded MPMs - the real purpose) managed by the server, and providing request- or connection-oriented access to a database handle. That then becomes an API that mod_perl et al can trivially bind in to for web apps, notwithstanding their existing/native DBI/DBD frameworks. The reverse is not the case, unless you can convince me otherwise. Several folks on IRC favour an apr_dbi layer. That's great, but it's a different project, and I'd certainly want to look at harnessing existing DBI projects rather than reinventing that wheel. You took my reply out of context, Nick. I was replying to: Paul Querna wrote: > +1 in concept from me. One thing I think needs to be kept in mind is a > separation from Apache-ism so it could be used by Python/PHP/Perl > without requiring Apache. saying that Python/PHP/Perl (at least Perl) most likely will not use the proposed API because they already have a well established and widely used API. I just quoted DBDI to mention that perl-only DBD is now going to be working across Python/PHP/Perl/etc. I have nothing against your proposal otherwise. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_proxy debug warnings
Jeff Trawick wrote: On Sun, 28 Nov 2004 13:54:02 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote: Mladen Turk wrote: Stas Bekman wrote: I know those are debug level warnings, but are those really needed? I get 34 of these identical lines every time the module is initialized: [Sat Nov 27 15:37:42 2004] [debug] proxy_util.c(1444): proxy: initialized worker 0 for (rabbit.stason.org:8529) min=0 max=2 smax=2 why so many identical traces? Can we possibly get rid of this noise? Probably adding getpid() would give more sense to that log line. That's a good idea, but the amount of output doesn't make much sense to me, since I start only 2 procs (prefork). why do I get 34 reports then? I'd expect 2 lines, no? messages in a child init hook will spew any time a new child process is created, whether at initialization (starting enough child processes to reach the StartServers limit), or later on during steady state (adding processes as load increases or replacing processes which exited due to MaxRequestsPerChild) Doesn't look like the case, I've just rebuilt worker and the config is: StartServers 1 MinSpareThreads 2 MaxSpareThreads 2 ThreadsPerChild 2 MaxClients 4 MaxRequestsPerChild 0 So it's not possible that the number of logs relates to the number of child_init calls. Though I do have 32 vhosts, which matches much better the number of debug lines (33). So does it print one per vhost? -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: latest 2.0/worker hangs all sub-request/internal redirects
Stas Bekman wrote: Has something recently changed with sub-request/internal redirects in 2.0? I'm not sure if those are tested by httpd-test, but all modperl tests that call these methods are now hanging. This happens only with worker. But works just fine with prefork. The same behavior with 2.1/worker. My apologies for the false alarm, there was a problem with httpd config pointed out by Joe Schaefer. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Towards a generic database connection API
Paul Querna wrote: Nick Kew wrote: I have recently developed a first-draft namespace module mod_sql for incorporating SQL into HTML/XML pages with mod_publisher or mod_xmlns. In doing so, I revisited the existing database connection pooling modules, and reclassified them as drivers for mod_sql. I also added support for LAMP-style single persistent connections for use in non-threaded MPMs, using #if APR_HAS_THREADS. That basically means each database module is an ap_provider for "dbd", and implements a common API. +1 in concept from me. One thing I think needs to be kept in mind is a separation from Apache-ism so it could be used by Python/PHP/Perl without requiring Apache. Please take a look at DBDI Project. http://groups.google.com/[EMAIL PROTECTED] which already targets Perl6 DBI, Python DBI, Ruby DBI, PHP DBI etc. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_proxy debug warnings
Mladen Turk wrote: Stas Bekman wrote: I know those are debug level warnings, but are those really needed? I get 34 of these identical lines every time the module is initialized: [Sat Nov 27 15:37:42 2004] [debug] proxy_util.c(1444): proxy: initialized worker 0 for (rabbit.stason.org:8529) min=0 max=2 smax=2 why so many identical traces? Can we possibly get rid of this noise? Probably adding getpid() would give more sense to that log line. That's a good idea, but the amount of output doesn't make much sense to me, since I start only 2 procs (prefork). why do I get 34 reports then? I'd expect 2 lines, no? Also it has it's purpose cause those logged numbers for max and smax can be different then the one you've put in the config, and are depending on mpm and AP_MPMQ_MAX_THREADS. (I'm talking about prefork, no threads in this particular case) We can log that only in child_init, cause on post_conf we don't have a scoreboard yet. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
mod_proxy debug warnings
I know those are debug level warnings, but are those really needed? I get 34 of these identical lines every time the module is initialized: [Sat Nov 27 15:37:42 2004] [debug] proxy_util.c(1444): proxy: initialized worker 0 for (rabbit.stason.org:8529) min=0 max=2 smax=2 why so many identical traces? Can we possibly get rid of this noise? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
latest 2.0/worker hangs all sub-request/internal redirects
Has something recently changed with sub-request/internal redirects in 2.0? I'm not sure if those are tested by httpd-test, but all modperl tests that call these methods are now hanging. This happens only with worker. But works just fine with prefork. The same behavior with 2.1/worker. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
Brad Nicholes wrote: I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see "trunk" which could be any one of a number of files. Not all of which I am interested in. Personally I would opt for file listings rather than directory listings to keep the subject line shorter and more informative. I also don't need to see "svn commit: r" at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. I agree with Brad. Also what kind of usability one finds to get a 10 lines and more long Subject? Here is an example of a recent commit. Subject: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules I think it'll be more useful to have the following Subject format: $id $first_subdir/$first_file ($trunk) in the example above (where only dirs were affected): Subject: r105803 . (httpd/test/trunk/perl-framework) If there was a file changed, e.g. Apache-Test/README Subject: r105803 Apache-Test/README (httpd/test/trunk/perl-framework) if you wish to retain 'svn' prefix, that's fine, but there is need to waste space with 'svn commit'. e.g.: Subject: svn r105803 Apache-Test/README (httpd/test/trunk/perl-framework) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [NOTICE] Subversion conversion
Geoffrey Young wrote: It's just that someone needs to simultaneously move modperl-2.0 to subversion too. And modperl-docs too, since they are checked out into modperl-2.0 check out. As long as this is all done at once there should be no problem. None of these projects had any branching so it shouldn't be a problem. But I've next to zero experience with subversion, so I'm not volunteering to do that. gozer and I can take care of this while we're here. I was waiting on you to agree with the move before we went forward, though. and it looks like your +1. ok, so we're giving sander and justin the ok to lock down cvs until the svn conversion is complete, which may be a day or two. after that, everyone will need to use svn to access mod_perl cvs (with instructions to follow). so, rock on svn. yes, yes, I'm +1. Thanks for taking care of it. Don't forget about preserving the frozen cvs though. I have lots of modified files all over. Also we will need to modify some of the sw to work with svn instead of cvs (Makefile(s) and RELEASE notes) -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [NOTICE] Subversion conversion
Justin Erenkrantz wrote: On Sun, Nov 14, 2004 at 03:29:07PM -0500, Stas Bekman wrote: It's just that someone needs to simultaneously move modperl-2.0 to subversion too. And modperl-docs too, since they are checked out into There's no reason we can't do the mp conversion today as well. Stop by at the Hackathon and we can sort this out. -- justin I'm not at ApacheCon. Gozer? Geoff? -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [NOTICE] Subversion conversion
Geoffrey Young wrote: Sander Striker wrote: Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I thought we had discussed httpd-test a while back - something like we couldn't migrate httpd-test to subversion until modperl-2.0 was also migrated to subversion, since a mp2 checkout includes part httpd-test/perl-framework/Apache-Test. personally, I'd rather use subversion for everything, and I can't recall the specifics of the issue, but I thought I'd bring it up in case it makes sense to somebody :) It's just that someone needs to simultaneously move modperl-2.0 to subversion too. And modperl-docs too, since they are checked out into modperl-2.0 check out. As long as this is all done at once there should be no problem. None of these projects had any branching so it shouldn't be a problem. But I've next to zero experience with subversion, so I'm not volunteering to do that. Also it's important to keep a frozen version of the cvs, so one could still get cvs diffs for those modified checkouts that we have, for work in progress. So first modperl-docs needs to be moved, then httpd-test, then modperl-2.0, I believe. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
Joe Orton wrote: On Sat, Nov 06, 2004 at 12:48:50AM -0800, Justin Erenkrantz wrote: --On Saturday, November 6, 2004 8:28 AM + [EMAIL PROTECTED] wrote: @@ -125,6 +125,8 @@ +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars + + pquerna: Do we want to change this for 2.2? Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin I don't really agree with this. Many third-party modules still aren't thread-safe (and probably quite a few shipped in httpd too e.g. mod_example!). Making worker the default won't solve that, it'll just create a stream of "I upgraded to 2.2 and now everything segfaults" bug reports and people will stick with 1.3/2.0. 2.2 can be a compelling upgrade without making worker the default. I second that. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Protected Mail System
Waiting for authentification.
Re: Bug: Apache hangs if script invokes fork/waitpid
Naik, Roshan wrote: Somehow I feel that this problem exists in other (it not all) mpms besides worker. Havent tested it though. Anybody know of an mpm where the forked child wont close the connection ? BTW, does it makes any difference if you use a subproc api? http://perl.apache.org/docs/2.0/api/Apache/SubProcess.html internally it does the same thing as mod_cgi... -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Philippe M. Chiasson wrote: For some reason, your output doesn't match mine. for me the difference between 22nd and 23 starts from 3428 [1] and goes into the next day, which is not included in your output: [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch I've apparently been bitten by a timezone problem, I've updated that output to reflect more stuff rather than less. Thanks, Philippe. Could you please write a quick writeup on how to get/setup that tool that you've used (including the issue of TZ), here: http://perl.apache.org/docs/2.0/devel/debug/c.html? Thanks! -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Stas Bekman wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/2004-09-22+23/
That's a handy output. I'll try applying each separately to see which
one was the trigger.
For some reason, your output doesn't match mine. for me the difference
between 22nd and 23 starts from 3428 [1] and goes into the next day,
which is not included in your output:
[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
but I think I'm getting there
It seems that this patch applied as reversed to the checkout from 23 Sept
resolves the segfault in t/filter/both_str_req_add.t. As you can see all
the changes are in creating new Vhosts entries.
However this doesn't resolve the current cvs problem, as I think there
were more entries added after Sept 23th, that cause the latest one.
diff -ru --exclude=CVS t/hooks/TestHooks/init.pm t/hooks/TestHooks/init.pm
--- t/hooks/TestHooks/init.pm 2003-08-11 16:34:22.0 -0400
+++ t/hooks/TestHooks/init.pm 2004-09-22 21:44:10.0 -0400
@@ -54,11 +54,15 @@
1;
__DATA__
-PerlInitHandler TestHooks::init::second
-
+
+
PerlModule TestHooks::init
PerlInitHandler TestHooks::init::first
-
-PerlResponseHandler TestHooks::init
-PerlResponseHandler TestHooks::init::response
-SetHandler modperl
+
+PerlInitHandler TestHooks::init::second
+PerlResponseHandler TestHooks::init
+PerlResponseHandler TestHooks::init::response
+SetHandler modperl
+
+
+
diff -ru --exclude=CVS t/response/TestUser/rewrite.pm
t/response/TestUser/rewrite.pm
--- t/response/TestUser/rewrite.pm 2004-07-09 17:52:49.0 -0400
+++ t/response/TestUser/rewrite.pm 2004-09-22 21:44:11.0 -0400
@@ -62,6 +62,7 @@
1;
__END__
+
PerlModule TestUser::rewrite
PerlTransHandlerTestUser::rewrite::trans
PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -69,5 +70,6 @@
SetHandler modperl
PerlResponseHandler TestUser::rewrite::response
+
diff -ru --exclude=CVS t/modules/proxy.t t/modules/proxy.t
--- t/modules/proxy.t 2004-08-03 12:16:22.0 -0400
+++ t/modules/proxy.t 2004-09-22 21:44:11.0 -0400
@@ -3,14 +3,19 @@
use Apache::Test;
use Apache::TestUtil;
-
use Apache::TestRequest;
-my $location = "/TestModules__proxy";
+my $module = 'TestModules::proxy';
+
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
plan tests => 1, (need_module('proxy') &&
need_access);
my $expected = "ok";
-my $received = GET_BODY_ASSERT $location;
+my $received = GET_BODY_ASSERT "http://$hostport/$path"
ok t_cmp($received, $expected, "internally proxified request");
diff -ru --exclude=CVS t/response/TestModules/proxy.pm
t/response/TestModules/proxy.pm
--- t/response/TestModules/proxy.pm 2004-07-09 04:01:21.0 -0400
+++ t/response/TestModules/proxy.pm 2004-09-22 21:44:11.0 -0400
@@ -43,6 +43,7 @@
1;
__END__
+
http://@servername@:@port@/*>
@@ -59,5 +60,6 @@
PerlResponseHandler TestModules::proxy::response
+
diff -ru --exclude=CVS t/hooks/TestHooks/trans.pm t/hooks/TestHooks/trans.pm
--- t/hooks/TestHooks/trans.pm 2003-04-18 02:18:58.0 -0400
+++ t/hooks/TestHooks/trans.pm 2004-09-22 21:44:11.0 -0400
@@ -37,5 +37,12 @@
1;
__DATA__
-PerlResponseHandler Apache::TestHandler::ok1
-SetHandler modperl
+
+
+PerlTransHandler TestHooks::trans
+
+PerlResponseHandler Apache::TestHandler::ok1
+SetHandler modperl
+
+
+
diff -ru --exclude=CVS t/hooks/trans.t t/hooks/trans.t
--- t/hooks/trans.t 2003-03-31 23:39:30.0 -0500
+++ t/hooks/trans.t 2004-09-22 21:44:10.0 -0400
@@ -8,15 +8,20 @@
use Apache2 ();
use Apache::Const ':common';
+my $module = 'TestHooks::trans';
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
plan tests => 3;
t_client_log_error_is_expected();
-ok GET_RC('/nope') == NOT_FOUND;
-
-my $module = '/TestHooks/trans.pm';
+ok t_cmp GET_RC("http://$hostport/nope";), NOT_FOUND;
-my $body = GET_BODY $module;
+my $body = GET_BODY "http://$hostport/TestHooks/trans.pm";;
-ok $body =~ /package TestHoo
Re: segfault in worker mpm
Stas Bekman wrote: Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. For some reason, your output doesn't match mine. for me the difference between 22nd and 23 starts from 3428 [1] and goes into the next day, which is not included in your output: [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch but I think I'm getting there -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Stas Bekman wrote: Cliff Woolley wrote: On Sun, 3 Oct 2004, Stas Bekman wrote: modperl-2.0 'make test' running under worker mpm (linux) always fails in t/filter/both_str_req_add.t and dumps core: #0 0xe410 in ?? () (gdb) bt #0 0xe410 in ?? () #1 0xbfffeff8 in ?? () #2 0x0001 in ?? () #3 0xbfffeff7 in ?? () #4 0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0 #5 0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53 My only guess of things to check out right off hand: Is the pipe that's being read from still a valid fd? (Maybe it somehow got closed elsewhere by some other thread accidentally? Such things have happened before...) I don't work with any pipes explicitly. This test just runs a few input and output filters, all using bucket brigades API. The problem is that I can't reproduce it as well, s/as well/at will/ other than running some 100 tests before this happens, so I'm not sure how to debug that. So I was hoping that someone has encountered this problem before and knew how to deal with that. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Cliff Woolley wrote: On Sun, 3 Oct 2004, Stas Bekman wrote: modperl-2.0 'make test' running under worker mpm (linux) always fails in t/filter/both_str_req_add.t and dumps core: #0 0xe410 in ?? () (gdb) bt #0 0xe410 in ?? () #1 0xbfffeff8 in ?? () #2 0x0001 in ?? () #3 0xbfffeff7 in ?? () #4 0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0 #5 0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53 My only guess of things to check out right off hand: Is the pipe that's being read from still a valid fd? (Maybe it somehow got closed elsewhere by some other thread accidentally? Such things have happened before...) I don't work with any pipes explicitly. This test just runs a few input and output filters, all using bucket brigades API. The problem is that I can't reproduce it as well, other than running some 100 tests before this happens, so I'm not sure how to debug that. So I was hoping that someone has encountered this problem before and knew how to deal with that. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
segfault in worker mpm
modperl-2.0 'make test' running under worker mpm (linux) always fails in t/filter/both_str_req_add.t and dumps core: #0 0xe410 in ?? () (gdb) bt #0 0xe410 in ?? () #1 0xbfffeff8 in ?? () #2 0x0001 in ?? () #3 0xbfffeff7 in ?? () #4 0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0 #5 0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53 #6 0x080de523 in child_main (child_num_arg=0) at worker.c:1199 #7 0x080de6b1 in make_child (s=0x8144238, slot=0) at worker.c:1282 #8 0x080de747 in startup_children (number_to_start=1) at worker.c:1301 #9 0x080deebf in ap_mpm_run (_pconf=0x813d0a8, plog=0x81851c8, s=0x8144238) at worker.c:1616 #10 0x080e6700 in main (argc=9, argv=0xb1c4) at main.c:619 It looks like some threads problem. I have been smoking for almost 24 hours, and it seems to happen totally randomly but always failing in t/filter/both_str_req_add.t. It deterministically fails when running a full modperl-2.0's 'make test', or least it did every time I've tried it. One of the results SMOKE gave me was a nice: t/compat/apache_file.t t/filter/both_str_req_add.t but I was never able to reproduce it with these two tests when running them outside the smoking tool. Since then the other shortest sequence was of 65 tests: t/api/show.t t/api/slurp_filename.t t/api/status.t t/api/sub_request.t t/api/uri.t t/apr-ext/base64.t t/apr-ext/bucket.t t/apr-ext/date.t t/apr-ext/finfo.t t/apr-ext/perlio.t t/apr-ext/pool.t t/apr-ext/string.t t/apr-ext/table.t t/apr-ext/threadmutex.t t/apr-ext/uri.t t/apr-ext/util.t t/apr-ext/uuid.t t/apr/base64.t t/apr/brigade.t t/apr/bucket.t t/apr/constants.t t/apr/date.t t/apr/finfo.t t/apr/flatten.t t/apr/ipsubnet.t t/apr/os.t t/apr/perlio.t t/apr/pool.t t/apr/sockaddr.t t/apr/socket.t t/apr/string.t t/apr/table.t t/apr/threadmutex.t t/apr/uri.t t/apr/util.t t/apr/uuid.t t/compat/apache.t t/compat/apache_file.t t/compat/apache_module.t t/compat/apache_table.t t/compat/apache_uri.t t/compat/apache_util.t t/compat/conn_authen.t t/compat/conn_rec.t t/compat/request.t t/compat/request_body.t t/compat/send_fd.t t/directive/cmdparms.t t/directive/env.t t/directive/perl.t t/directive/perldo.t t/directive/perlloadmodule.t t/directive/perlloadmodule2.t t/directive/perlloadmodule3.t t/directive/perlloadmodule4.t t/directive/perlloadmodule5.t t/directive/perlloadmodule6.t t/directive/perlmodule.t t/directive/perlrequire.t t/directive/pod.t t/directive/setupenv.t t/error/api.t t/error/bug.t t/error/runtime.t t/error/subreq.t t/filter/both_str_req_add.t and it's still smoking trying to reduce it... Any hints how to figure out the cause of the failure? Used Components and their Configuration: *** mod_perl version 1.9917 *** using /home/stas/apache.org/mp2-pool/lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS => /home/stas/httpd/worker/bin/apxs MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_DSO => 1 MP_USE_GTOP => *** /home/stas/httpd/worker/bin/httpd -V Server version: Apache/2.0.53-dev Server built: Sep 23 2004 23:13:14 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/worker" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/home/stas/httpd/worker" -D SUEXEC_BIN="/home/stas/httpd/worker/bin/suexec" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** (apr|apu)-config linking info -L/home/stas/httpd/worker/lib -lapr-0 -lrt -lm -lcrypt -lnsl -lpthread -ldl -L/home/stas/httpd/worker/lib -laprutil-0 -lgdbm -ldb-4.0 -lexpat *** /home/stas/perl/5.8.5-ithread/bin/perl5.8.5 -V Summary of my perl5 (revision 5 version 8 subversion 5) configuration: Platform: osname=linux, osvers=2.6.3-9mdk, archname=i686-linux-thread-multi uname='linux rabbit.stason.org 2.6.3-9mdk #1 fri apr 23 16:41:09 edt 2004 i686 unknown unknown gnulinux ' config_args='-des -Dprefix=/home/stas/perl/5.8.5-ithread -Dusethreads -Doptimize=-g -Duseshrplib -Dusedevel -Accflags=-DDEBUG_LEAKING_SCALARS' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc
Re: segfault ap_save_brigage in the latest 2.0
Joe Orton wrote: Let's continue this on [EMAIL PROTECTED] since it doesn't seem like there's an httpd bug currently. On Mon, Sep 27, 2004 at 01:49:29PM -0400, Joe Schaefer wrote: Joe Orton <[EMAIL PROTECTED]> writes: [...] when it did start up it would segfault consistently when running the tests you reference like: #0 pool_clear_debug (pool=0x441, file_line=0x2a95d3fc19 "undefined") at memory/unix/apr_pools.c:1341 1341while (pool->child) ... Does this mp2 patch help? Yes, that fixed the segfaults triggered by the test cases for me. joe++, $subrequest->DESTROY calls ap_destroy_sub_req(r) the bug was in calling it twice, once directly and once more indirectly. But the problem is that it didn't affect the current request, but some other specific request later on, so if it wasn't for Joe, I'd have lost a way more hair than I did so far. I suppose that double call was corrupting some memory, but it wasn't visible right away. Is it possible for ap_destroy_sub_req(r) to somehow protect from this kind of problem? I suppose that's not quite possible. Any ideas about how to fix the segfaults at startup time too? I'll try to reproduce it now. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[RELEASE CANDIDATE] Apache-Test 1.13
You can download the release candidate from here: http://www.apache.org/~stas/Apache-Test-1.13-dev.tar.gz If there are no problems reported Apache-Test 1.13 will be released tomorrow. Thanks. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[patch] ap_sub_req_* args naming fix
est_rec *) ap_sub_req_lookup_uri(const char *new_uri,
const request_rec *r,
ap_filter_t *next_filter)
{
-return ap_sub_req_method_uri("GET", new_file, r, next_filter);
+return ap_sub_req_method_uri("GET", new_uri, r, next_filter);
}
AP_DECLARE(request_rec *) ap_sub_req_lookup_dirent(const apr_finfo_t
*dirent,
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
ap_os_escape_path with partial=0?
Can someone please explain what this function does when partial=0? why
does it prepend "./" only if the path includes ":/" in it? what's
happening here? the API doesn't document this nuance. What kind of input
does it take care of? I can see it used by mod_autoindex, but may be it
never hits this condition?
Shouldn't it go the other way around? i.e. not append ./ if it finds ':/'
in the string?
if (!(colon && (!slash || colon < slash))) {
*d++ = '.';
*d++ = '/';
}
Thanks.
Here is the whole function for your convenience:
AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int
partial)
{
char *copy = apr_palloc(p, 3 * strlen(path) + 3);
const unsigned char *s = (const unsigned char *)path;
unsigned char *d = (unsigned char *)copy;
unsigned c;
if (!partial) {
const char *colon = ap_strchr_c(path, ':');
const char *slash = ap_strchr_c(path, '/');
if (colon && (!slash || colon < slash)) {
*d++ = '.';
*d++ = '/';
}
}
while ((c = *s)) {
if (TEST_CHAR(c, T_OS_ESCAPE_PATH)) {
d = c2x(c, d);
}
else {
*d++ = c;
}
++s;
}
*d = '\0';
return copy;
}
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Please define "canonicalize" in httpd.h
William A. Rowe, Jr. wrote:
At 02:35 PM 8/1/2004, Stas Bekman wrote:
John Rowe wrote:
Please define "canonicalize"
In the context of case-insensitive file systems, it's often the case
that a file is given the canonical name that it was created with
("MyFile") with all other capitalisations ("myfile", "myfilE") being
alternative names for the same filename.
Thanks John. I understand all that. My request was to fix the following XXX in
httpd.h:
struct request_rec {
...
/* XXX: What does this mean? Please define "canonicalize" -aaron */
/** The true filename, we canonicalize r->filename if these don't match */
char *canonical_filename;
and explain there when one should use canonical_filename, instead of filename. The
comment:
/** The true filename, we canonicalize r->filename if these don't match */
suggests that r->filename is getting canonized as well.
Yes - you don't generally play with r->canonical_filename (in fact, it should
become private) unless you are the module who is responsible for it. Only
things like the core file handler, which happens to dig through the segments,
eliminate /foo/../ sorts of elements, and checks the filesystem case as it
goes will bother to set this.
When we hit the dir_walk on win32, the system compares filename to the
canonical_filename. If they match - dir_walk won't bother to re-canonicalize
the (matching) segments of the name. This, at least, is the theory.
This should possibly be better 'hidden' - in the sense that it is probably
just confusing cruft to most module authors.
Excellent. Thanks Bill!
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: misleading doc for ap_custom_response string argument
Stas Bekman wrote: /** * Install a custom response handler for a given status * @param r The current request * @param status The status for which the custom response should be used * @param string The custom response. This can be a static string, a file * or a URL */ AP_DECLARE(void) ap_custom_response(request_rec *r, int status, const char *string); It does handle full and relative URLs and strings, but not files. Did you mean something else when saying "file"? anyone? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Please define "canonicalize" in httpd.h
John Rowe wrote:
Please define "canonicalize"
If the same thing can be referred to by a number of different names and
the convention is that one is the "one true", or canonical, name and the
others are mere aliases then canonicalisation (or canonicalization for a
non-Brit) is the process of translating a name into the canonical name
of that object. Of course this assumes that no two objects can have the
same name.
In the context of case-insensitive file systems, it's often the case
that a file is given the canonical name that it was created with
("MyFile") with all other capitalisations ("myfile", "myfilE") being
alternative names for the same filename.
Of course, the situation is complicated not only by symlinks but also
that in unix the same file can have many filenames. The normal
canonicalisation for a file, as opposed to filename, is (device, inode
number) but that's not always very useful: for security reasons you
can't actually open a file from its device and inode number.
Thanks John. I understand all that. My request was to fix the following
XXX in httpd.h:
struct request_rec {
...
/* XXX: What does this mean? Please define "canonicalize" -aaron */
/** The true filename, we canonicalize r->filename if these don't
match */
char *canonical_filename;
and explain there when one should use canonical_filename, instead of
filename. The comment:
/** The true filename, we canonicalize r->filename if these don't match */
suggests that r->filename is getting canonized as well.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
hey
i don't think so. Norton AntiVirus excluído1.txt Description: plain/text
Please define "canonicalize" in httpd.h
from httpd.h:
struct request_rec {
...
/* XXX: What does this mean? Please define "canonicalize" -aaron */
/** The true filename, we canonicalize r->filename if these don't
match */
char *canonical_filename;
I'm asking the same question. It looks like it's only different from
'filename' #ifdef CASE_BLIND_FILESYSTEM (see server/request.c). But I'm
not quite sure what it does. Any explanations?
Thanks
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ap_meets_conditions doc: bogus return value?
Jeff Trawick wrote: On Fri, 16 Jul 2004 21:48:23 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote: AP_DECLARE(int) ap_meets_conditions(request_rec *r); The @return value seems to be totally bogus, the function returns OK (0) if the conditions were met (not 1), otherwise it returns either of these two: #define HTTP_PRECONDITION_FAILED 412 #define HTTP_NOT_MODIFIED 304 though since other constants may be returned later should the doc be something like the following: * @return OK if the response fulfills the condition GET rules, some other status code otherwise +1 Thanks Jeff, done. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
ap_meets_conditions doc: bogus return value?
/** * Implements condition GET rules for HTTP/1.1 specification. This function * inspects the client headers and determines if the response fulfills * the requirements specified. * @param r The current request * @return 1 if the response fulfills the condition GET rules, 0 otherwise * @deffunc int ap_meets_conditions(request_rec *r) */ AP_DECLARE(int) ap_meets_conditions(request_rec *r); The @return value seems to be totally bogus, the function returns OK (0) if the conditions were met (not 1), otherwise it returns either of these two: #define HTTP_PRECONDITION_FAILED 412 #define HTTP_NOT_MODIFIED 304 though since other constants may be returned later should the doc be something like the following: * @return OK if the response fulfills the condition GET rules, some other status code otherwise -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
misleading doc for ap_custom_response string argument
/** * Install a custom response handler for a given status * @param r The current request * @param status The status for which the custom response should be used * @param string The custom response. This can be a static string, a file * or a URL */ AP_DECLARE(void) ap_custom_response(request_rec *r, int status, const char *string); It does handle full and relative URLs and strings, but not files. Did you mean something else when saying "file"? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
stale function ap_error_log2stderr
Does anybody use that function? I can't see any uses of it in the core code. If not, shouldn't it be removed? /** * Convert stderr to the error log * @param s The current server * @deffunc void ap_error_log2stderr(server_rec *s) */ AP_DECLARE(void) ap_error_log2stderr(server_rec *s); -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Trying to test current apreq2 CVS
Randy Kobes wrote: The following patch to the mod_perl 2 cvs sources should include modperl_common_types in the list of header files to install in apache2/include: +1 -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ap_send_fd with wrong len count or offset it doesn't trigger an error?
if I tell ap_send_fd to send more data then there is in the filehandle, I get: [Thu Jul 01 13:54:26 2004] [info] (70014)End of file found: core_output_filter: writing data to the network why doesn't this end up in the return status? why is that info and not error? same goes if the offset is bogus, there is no indication of error. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: what's the condition to stop reading input in connection handlers?
Stas Bekman wrote:
The doc for ap_get_brigade goes:
/**
* Get the current bucket brigade from the next filter on the filter
* stack. The filter returns an apr_status_t value. If the bottom-most
* filter doesn't read from the network, then ::AP_NOBODY_READ is returned.
* The bucket brigade will be empty when there is nothing left to get.
However I see a situation where, the client went away long time ago and
the connection handler continues getting APR::EOF and the returned
brigade is not empty (some empty IMMORTAL bucket) when calling
ap_get_brigade and a custom output filter is installed.
What's the right condition to abort the loop? e.g in the pseudo code:
while (1) {
my $rc = $c->input_filters->get_brigade($bb, Apache::MODE_GETLINE);
last if $bb->is_empty;
# process $bb...
last if $rc == APR::EOF;
}
should I just check for EOF and not check whether the brigade is empty?
If so, can EOF come and the brigade not being empty? It looks like I
need to check both.
So I take it that it's OK to rely on the assumption that if APR_EOF is
returned by ap_get_brigade(), then the returned brigade contains no (useful)
data and the read loop can be broken.
--
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
what's the condition to stop reading input in connection handlers?
The doc for ap_get_brigade goes:
/**
* Get the current bucket brigade from the next filter on the filter
* stack. The filter returns an apr_status_t value. If the bottom-most
* filter doesn't read from the network, then ::AP_NOBODY_READ is returned.
* The bucket brigade will be empty when there is nothing left to get.
However I see a situation where, the client went away long time ago and the
connection handler continues getting APR::EOF and the returned brigade is not
empty (some empty IMMORTAL bucket) when calling ap_get_brigade and a custom
output filter is installed.
What's the right condition to abort the loop? e.g in the pseudo code:
while (1) {
my $rc = $c->input_filters->get_brigade($bb, Apache::MODE_GETLINE);
last if $bb->is_empty;
# process $bb...
last if $rc == APR::EOF;
}
should I just check for EOF and not check whether the brigade is empty? If so,
can EOF come and the brigade not being empty? It looks like I need to check both.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Request
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: [...] I think pod is just fine for now. At least the link won't change when a new version is released. When you get a permanent location for HTML files I'll change the links to point there. Since the permanent location will be available for the next release, it really makes no difference which location you link to. Either way you'll need to reset the link once 2.04-dev comes out. I'll be just lazy and wait for you to make the perm link and then add it at once :) just let me know when it's ready... -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: is it possible to mark buckets to be copied only when to be set-aside?
Cliff Woolley wrote: On Wed, 19 May 2004, Stas Bekman wrote: And a lot of pain and wasted time could be saved if all this was documented. I know. :( I'm not aware of such documentation's existance, besides very scarce notes in the header files. The best documentation that exists, besides what's in the header files, is in the talk I gave on Bucket Brigades at ApacheCon 2002; see http://www.cs.virginia.edu/~jcw5q/talks/ for links to the slides (ppt) and notes pages (pdf). There are also links there to my slides from ApacheCon 2003, which discuss debugging buckets and brigades. The second best bucket reference is a section in Chapter 13 of Ryan's book Apache Server 2.0: The Complete Reference, pp 310-322. If anybody else knows of other resources, I'd love to know about them... but I suspect that's more or less it. Right from the horses' mouths. But unfortunately neither Ryan nor I were verbose enough in either case to really go into the kind of depth you're looking for. Not that I don't agree it would be useful to have written down somewhere. Thanks Cliff, I've been to both of your great talks :) Perhaps someone on this list will take up an initiative to write such a document, by first putting together the existing resources and then beef it up to add the missing stuff. I'm sure Cliff and other filter gurus will be more than helpful to answer any questions arising while working on such a document. I'd have taken up that project by myself, but I'm already spread too thin and must finish first the mod_perl 2.0 API docs before we can release 2.0. To add to Cliff's list of resources, mod_perl 2.0 filter documentation is pretty extensive and perhaps it's the easiest to start with filters by writing them in perl. For more information see: http://perl.apache.org/docs/2.0/user/handlers/filters.html p.s. may be rbb will be willing to contribute parts of his book's filters chapter. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: is it possible to mark buckets to be copied only when to be set-aside?
Cliff Woolley wrote: On Wed, 19 May 2004, Cliff Woolley wrote: can't just ignore APR_ENOTIMPL for bucket types, because pipe and socket buckets never had setaside implemented on them. I thought I remembered that that was because Greg and Ryan and I had some huge debate about it and it was decided for some reason that setting aside a pipe or socket didn't make sense. But now I can't find where we talked about that in the archives. BTW - I remembered the reason why it was decided that it didn't make sense to implement setaside for pipe/socket buckets. It's because for all other bucket types, setaside takes one bucket in and produces one bucket out, whereas for pipes and sockets it would take one bucket in and either produce one bucket if the lifetime request was already satisfied or it would produce a chain of n buckets out where n is proportional to the size of the data that had been waiting around to be read in the pipe/socket. It was that inconsistency that was disliked. At this point, I'm willing to agree to whatever makes things work and would probably accept this inconsistency as long as it's documented. What we have now is bug-prone beyond belief. And a lot of pain and wasted time could be saved if all this was documented. I'm not aware of such documentation's existance, besides very scarce notes in the header files. Filters are a very complex area, and w/o proper user docs it's no wonder that we see all these problems. The worst part is that some of the developers who originally wrote things are no longer here to help, so their knowledge and reasons, for doing things in certain ways, get lost. I wish someone who groks filters well could write a proper document explaining most of (all?) the ins and outs of writing a proper filter. The old article written by rbb is nice, but a way too short to cover all the nuances. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: is it possible to mark buckets to be copied only when to be set-aside?
Nick Kew wrote: On Tue, 18 May 2004, Stas Bekman wrote: extra allocation happens). But just now one user has reported that it breaks mod_xslt filter, which sets aside the buckets sent from the modperl handler, and then uses them after seeing EOS. That seems to me an unnecessarily complex and inefficient XSLT implementation. What XSLT needs to do with its data is to parse to a DOM. By using libxml2/libxslt we can use a parseChunk API, and thus feed every bucket to the parser as soon as it reaches the filter. No need at all to buffer or setaside it. We have at least one implementation that works like that (originally mine, but now more actively developed by others as "mod_transform"). Perhaps mod_perl users might benefit from switching? Frankly I even have no idea who is the author of mod_xslt, it's not part of the mod_perl project. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: is it possible to mark buckets to be copied only when to be set-aside?
William A. Rowe, Jr. wrote: It's a bug in mod_xslt, if that module trys to set aside a transient bucket. Ah, cool, for some reason I thought that transient still has to have a copy :) Thanks Bill! At 12:09 AM 5/19/2004, Stas Bekman wrote: We have the following situation in mod_perl 2 land: we use the same buffer to allocate data in buckets which are passed to the filters. That bucket is created once per request. It works perfectly fine and effective most of the time (we copy from user's program perl space into the re-usable buffer, but no extra allocation happens). But just now one user has reported that it breaks mod_xslt filter, which sets aside the buckets sent from the modperl handler, and then uses them after seeing EOS. By that time the data in all but last bucket is corrupted. Obviously the straightforward solution is to allocate a new buffer for each bucket that mod_perl sends to the filter chain. But this is a huge waste for most users, which don't use this particular kind of output filters that setaside buckets. My question is: Is it possible to mark the bucket's data as volatile or something, so if a downstream filter wants to set them aside it will have to do the copying? At the moment the bucket is created as: bucket = apr_bucket_transient_create(buf, len, ba); and buf is static for the length of the request. Thank you. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
is it possible to mark buckets to be copied only when to be set-aside?
We have the following situation in mod_perl 2 land: we use the same buffer to allocate data in buckets which are passed to the filters. That bucket is created once per request. It works perfectly fine and effective most of the time (we copy from user's program perl space into the re-usable buffer, but no extra allocation happens). But just now one user has reported that it breaks mod_xslt filter, which sets aside the buckets sent from the modperl handler, and then uses them after seeing EOS. By that time the data in all but last bucket is corrupted. Obviously the straightforward solution is to allocate a new buffer for each bucket that mod_perl sends to the filter chain. But this is a huge waste for most users, which don't use this particular kind of output filters that setaside buckets. My question is: Is it possible to mark the bucket's data as volatile or something, so if a downstream filter wants to set them aside it will have to do the copying? At the moment the bucket is created as: bucket = apr_bucket_transient_create(buf, len, ba); and buf is static for the length of the request. Thank you. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Randy Kobes wrote: [...] I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so). In this approach I don't there's a problem on Windows with linking against libraries with the same symbols; depending on the order of the libraries in the link command, VC++ will resolve the symbols not found in the object files in the 1st library file it finds that has them (which then registers the corresponding .so, if it's a shared library), so any identical symbols in a later library used in the link command are ignored. Thus, you could in principle build an application linked against two dlls that have the same symbols in them and there shouldn't be a conflict, as the application knows, from how it was linked, which dll each symbol comes from. That's excellent. So you link APR/Foo.so against APR.so which contains the minimal amount of modperl_xxx.o in it which is already provided by my patch (you only need to arrange linking against APR.lib instead of mod_perl.lib). APR/Foo.pm then must make sure that APR.pm (and so APR.so) are loaded before it loads its own APR/Foo.so. But this could be done later, for now let's say that we do it manually, by doing PerlModule APR immediately after LoadModule mod_perl.so Now the question is, whether the same could work for all other platforms. I was sure that's it's not possible to load two objects with the same symbols, but I could be wrong. Do you know whether this is true for all platforms? However, this also means that no symbols can be resolved through mod_perl.lib, as this would require loading mod_perl.so (unless one used the -delayload link option, to load the dll only if a symbol is invoked). That's perfectly fine. It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users. It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet. But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows? No, you're right - resolving all symbols only is required at link time, so this could be done by just compiling (with -c) the APR::* files to build the object files, and skip building the associated APR::* dlls, as is done now. I think things are becoming clearer to me - thanks. It looks like most of this can be done by fiddling with the compiling/linking commands, without the need (hopefully) of any source code modifications. I'll try it and see. Correct. I think your suggestion at the top is much better that dumping all .o into APR.so. If it works for every platform then we are gold. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 patch] getting APR to work w/o modperl
On Sun, 16 May 2004, Randy Kobes wrote: > On Sat, 15 May 2004, Stas Bekman wrote: > > > Randy Kobes wrote: > > > On Mon, 10 May 2004, Stas Bekman wrote: > > > > > >>How about a quick workaround as follows: For windows only, > > >>link APR.so statically with all APR/Foo.o and the required > > >>modperl_foo.o and arrange for the bootstrap not to call it > > >>for windows if APR.so is loaded? > > > > > > > > > That sounds good ... > > > > So can you try to tackle that? I guess my latest patch > > won't apply against the current cvs and I'll need to > > re-sync it and resolve collisions. > > I'll give it a go ... So as I'll be current, could you > re-sync it, if it's not too difficult? Alternatively, > if the patch is OK on others (apart from Win32, and > perhaps aix), is it ready to apply, and we'll work > from there? Well, I don't want to destabilize the tree, we should make a new release pretty soon. I think while you are playing with various solutions you could just check the cvs tree for the day I've posted my second patch and it should apply just fine. Your work is going to be in the xs/APR/APR area, not really touching anything else. If you think it's a problem I'll then try to post an up-to-date patch, but it may quickly become out-of-date in a few days. > > I guess all you need to do is to change > > xs/APR/APR/Makefile.PL to collect all .o files from under > > xs/APR and a few selected src/modules/perl/modperl_xxx.o > > and link them statically with APR.so if under win32. (and > > may be some other platforms too (aix comes to mind)). > > Just so I understand correctly, in this approach we'll have > one (big) APR.so that has collected all the functionality of > the individual APR::* modules (as well as the old APR.so > itself and selected symbols from modperl_xxx.o)? Or does APR > stay essentially the same (with the added symbols from > selected modperl_xxx.o), and then one links each APR::* with > APR.so? I was talking about the former, where APR.so will include all objects in Wrap/APR/*/.o (not .so) and some of src/modules/perl/modperl_xxx.o. I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so). It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users. > It should be relatively straightforward to do the latter (as > long as APR.so is built before APR::*). However, with the > former, there'd be problems building the individual APR::* > modules first, to be used as components in building APR.so, > for the same reason that exists now - to build APR::*, one > has to specify the library where the symbols are found, and > one can't specify a library (APR.so) that hasn't been built > yet. But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 patch] getting APR to work w/o modperl
Randy Kobes wrote:
On Sun, 9 May 2004, Stas Bekman wrote:
Yes, that sounds like a much better idea. There should be
a way to tell the application that certain symbols will be
resolved at run-time, and no matter who will provide them
(application, another library or else). On AIX the linker
is just as picky, but lets you shut up itself by telling
it that the missing symbols will be resolved at run time
and that it shouldn't worry about it. using the -brtl
option (see lib/Apache/Build.pm).
There is a link option on VC++ 6, -delayload:some.dll, which
delays the loading of a dll until a function inside it is
actually called by an application. But this is used in
situations like
if (some_condition_is_true) {
call_the_dll_function();
}
else {
do_something_else();
}
where the dll may not be available on some target machine.
What seems different on Windows compared to Unix, even with
this delayload thing (which still requires you to link
against the .lib file corresponding to the relevant .dll),
is that when you link against a .lib file which resolves
symbols, information about those symbols appears in the
result which contains references to the specific dll where
those symbols appear. What Jan suggested, in some sense, is
to try to fool Win32 by building, eg, APR.so, in a way to
make it go by the name of mod_perl.so, by using the same
.def file for both (and specifying a library name). But this
doesn't seem to quite work, at least in a simple way.
In short, no go, right?
How about a quick workaround as follows: For windows only, link APR.so
statically with all APR/Foo.o and the required modperl_foo.o and arrange for
the bootstrap not to call it for windows if APR.so is loaded?
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need Help Debugging Shared Library (libaprutil-0.so)
Steve Waltner wrote: You may find some useful notes here: http://perl.apache.org/docs/2.0/devel/debug/c.html There are for debugging mod_perl 2.0, but most of it applies to any other shared C library. Thanks for the information but it still doesn't seem to be working correctly. If this is a topic that I should take over to a gdb mailing list, let me know. I started with a clean unpack of the Apache 2.0.49 source tarball and configure it with the following command: ./configure --enable-maintainer-mode --with-ldap --enable-ldap --enable-auth-ldap --prefix=/tmp/apache-test make make install cp /tmp/httpd.conf /tmp/apache-test/conf/httpd.conf [...] (gdb) run -k start Starting program: /tmp/apache-test/bin/httpd -k start Breakpoint 1, mod_auth_ldap_parse_url (cmd=0xffbffb78, config=0xea998, url=0xeaa80 "ldap://ldap.lsil.com/ou=lsil.com,o=LSI%20Logic?uid";) at mod_auth_ldap.c:702 702 result = apr_ldap_url_parse(url, &(urld)); (gdb) info shared FromTo Syms Read Shared Object Library 0xff3847f4 0xff3929d0 Yes /tmp/apache-test/lib/libaprutil-0.so.0 0xff20d5a0 0xff2cb564 Yes /usr/lib/libldap.so.5 0xff342638 0xff35aa48 Yes /tmp/apache-test/lib/libexpat.so.0 0xff1c8064 0xff1dd4e4 Yes /tmp/apache-test/lib/libapr-0.so.0 0xff3104bc 0xff310634 Yes /usr/lib/libsendfile.so.1 0xff1a2494 0xff1a51b8 Yes /usr/lib/librt.so.1 0xff171a40 0xff180f24 Yes /usr/lib/libm.so.1 0xff1535e0 0xff1595a4 Yes /usr/lib/libsocket.so.1 0xff0940f8 0xff10098c Yes /usr/lib/libnsl.so.1 0xff028ab8 0xff057134 Yes /usr/lib/libresolv.so.2 0xff0039f4 0xff003ffc Yes /usr/lib/libpthread.so.1 0xff3b0704 0xff3b075c Yes /usr/lib/libdl.so.1 0xfef1ca08 0xfef9f038 Yes /usr/lib/libc.so.1 0xfefd04f4 0xfefd1510 Yes /usr/lib/libmd5.so.1 0xfeee1a8c 0xfeee7dd4 Yes /usr/lib/libaio.so.1 0xfeec09a0 0xfeec2950 Yes /usr/lib/libmp.so.2 0xfeeb0420 0xfeeb34e8 Yes /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 0xfee873b0 0xfee96100 Yes /usr/lib/libthread.so.1 (gdb) b apr_ldap_url.c:255 No line 255 in file "apr_ldap_url.c". (gdb) b ldap_url_parse_ext Function "ldap_url_parse_ext" not defined. Make breakpoint pending on future shared library load? (y or [n]) (gdb) quit The program is running. Exit anyway? (y or n) y dumbo:/tmp/apache-test> = I haven't turned off the autoload shared libraries, so gdb does try to load debug symbols from the libaprutil file, but it still appears as though it's not working properly since I can't set a breakpoint in apr_ldap_url.c or step into the function. Looking at the output of make, it appears as though the build process does the needed debugging flags... right make[3]: Entering directory `/tmp/httpd-2.0.49/srclib/apr-util' /bin/bash /tmp/httpd-2.0.49/srclib/apr/libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes [...] encoding/apr_base64.lo hooks/apr_hooks.lo ldap/apr_ldap_compat.lo ldap/apr_ldap_url.lo .lo gets linked alright, but it doesn't have any symbols: httpd-2.0/srclib> nm apr-util/ldap/apr_ldap*o The explanation comes from: #if APR_HAS_LDAP #if !APR_HAS_LDAP_URL_PARSE in apr_ldap_url.c and the header file apr_ldap_url.h: #if APR_HAS_LDAP #if APR_HAS_LDAP_URL_PARSE #define apr_ldap_url_desc_t LDAPURLDesc #define apr_ldap_is_ldap_url(url) ldap_is_ldap_url(url) #define apr_ldap_is_ldaps_url(url) ldap_is_ldaps_url(url) #define apr_ldap_is_ldapi_url(url) ldap_is_ldapi_url(url) #define apr_ldap_url_parse(url, ludpp) ldap_url_parse(url, ludpp) #define apr_ldap_free_urldesc(ludp) ldap_free_urldesc(ludp) #else /* ! APR_HAS_LDAP_URL_PARSE */ So you have the implementation elsewhere. ldap_url_parse_ext doesn't exist at all. You need to break at: ldap_url_parse or similar, I can't see ldap_url_parse_ext there. Though I'm not sure who links against libldap (neither libaprutil nor httpd are linked against it on my machine), I will leave it here for you to discover that. ldd and nm, should help you to discover that. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Need Help Debugging Shared Library (libaprutil-0.so)
Steve Waltner wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21719 Since my submitted bug hasn't been resolved in the 9 months since I first reported it, I figure it's about time I try and resolve this problem myself since I do have the source code. I've done a partial debug on the failure but can't get everything figured out since I can't get DDD/gdb to debug some of the code (coming from apr_ldap_url.c). I'm currently using the 2.0.49 source tree for my testing. The problem starts in mod_auth_ldap.c. When I load the source in ddd, I get an error stating: Line 1 of "mod_auth_ldap.c" is at address 0x2ebd4 but contains no code. You need two things: 1) compile with debug symbols retained which you get when building apache with --enable-maintainer-mode 2) make sure to load the library from gdb (or DDD's gdb console): gdb> sharedlib apr or whichever lib it is. You may find some useful notes here: http://perl.apache.org/docs/2.0/devel/debug/c.html There are for debugging mod_perl 2.0, but most of it applies to any other shared C library. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] decoupling APR from mod_perl
[xposting the modperl dev list] Joe Schaefer wrote: Maybe a couple of us could get together on IRC sometime this month and sort out what needs to be done to make it happen. I'd be willing to dedicate some time to the effort it if I better understood what the relevant issues are for mp2, and what course of action you guys are taking/considering. I believe the whole issue is relatively trivial: We need to take all the functions that both mod_perl and APR libs rely on (that's the missing symbols you've got reported when you tried to load APR::Table w/o mod_perl.so being loaded and others used by other APR::* modules) and put them into a separate .[ch] files, so both APR.so and mod_perl.so can include. We already do that for modperl_constants.c, you can find a copy of src/modules/perl/modperl_constants.c as xs/ModPerl/Const/modperl_constants.c. So we just need to copy these new *[ch] files into xs/APR/APR and arrange for build and inclusion of it in APR.so. And unless I've missed something it should just work. APR.pm and ModPerl/Const.pm already make sure that they won't attempt to load APR.so and Const.so if mod_perl.so is already loaded. Notice that modperl-2.0/t/apr-ext files exercise the APR-w/o-mod_perl already (at the moment it is only possible for some APR:: libs). So if there is an urgency to resolve this issue now, we can do that. Please notice that there are known problems with linking APR.so on some platforms, I believe only Solaris was reported so far. Since I don't use Solaris and nobody has volunteered help so far it's unresolved and t/apr-ext tests fail on that platform. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RELEASE CANDIDATE 2] Apache-Test-1.10
A few problems were noticed and fixed, thanks to Ken Coar. So here is a new RC. Same URL: http://perl.apache.org/~stas/Apache-Test-1.10-dev.tar.gz Changes since RC1: Quote and escape the executables in the shell calls [Ken Coar, Stas] Quote and escape filtered args received during 'perl Makefile.PL' [Geoffrey Young, Ken Coar] Please retest. Thanks! __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Bug 23238 - apr_pool_clear fails if the cleanup handler is still running
Cliff Woolley wrote: On Mon, 5 Apr 2004, Stas Bekman wrote: Apparently I'm not the only one suffering from the pool cleanup abortion at the shutdown: http://issues.apache.org/bugzilla/show_bug.cgi?id=23238 Should Apache2 ignore signals during the pool cleanup operations like 1.3 does? I thought this was fixed recently by patching mod_ssl? Good. But it doesn't fix the problem in the original report. Try to run some long apr pool cleanup and the shutdown operation will abort it. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Bug 23238 - apr_pool_clear fails if the cleanup handler is still running
Apparently I'm not the only one suffering from the pool cleanup abortion at the shutdown: http://issues.apache.org/bugzilla/show_bug.cgi?id=23238 Should Apache2 ignore signals during the pool cleanup operations like 1.3 does? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 2.0.49 rolled
Stas Bekman wrote:
Sander Temme wrote:
On Mar 18, 2004, at 12:21 AM, Sander Striker wrote:
I've put the 2.0.49 tarballs up at:
I'm not entirely happy about IPv6/IPv4 behaviour on at least FreeBSD
5.2.1 and MacOSX 10.3.{2,3}, possibly others.
I'm seeing the following when running the perl-framework. All three
boxes have IPv6 enabled. The perl-framework configures its Apache to
Listen on localhost:8529 (and a bunch of other ports). This results,
on all three machines, in the httpd only binding to ::1 for all ports.
Apparently the LWP stuff that perl-framework uses only knows about
IPv4, so all tests fail.
On the BSD box, when I switch the localhost lines so that IPv4
(127.0.0.1) comes before IPv6 (::1), and re-run the tests, I see the
server (using netstat) bind to only IPv4. Tests succeed.
I don't know how to make the same switch on the Macs: they tend to use
NetInfo for this stuff when running multi-user, but the NetInfo
database contains only IPv4 information.
I don't know enough about IPv6 to know what's going on here (maybe I
should change that), and I don't know if Apache is doing anything
wrong here... can it do anything but ask the OS for what localhost is,
and live with the answer? Is the practice to degenerate 127.0.0.1 and
::1 into the name localhost, broken?
I have not had the chance to test this on earlier releases.
Sander, please try again with the current cvs, Philippe has just committed a
change that now uses 'Listen 0.0.0.0:$port' to force listening on ipv4. If
still in trouble, pleast post a followup to the httpd-test-dev mailing list.
Thanks.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache dumping core
g g wrote: Hi, I have an application that uses apache 1.3.x. When I try to run Apache in single user mode i.e. httpd -X, on doing apachectl start, I am getting core. The bact trace of core is as below: #0 0xfe975a38 in Perl_share_hek () from /export/home/Apache/libexec/libperl.so (gdb) bt #0 0xfe975a38 in Perl_share_hek () from /export/home/Apache/libexec/libperl.so #1 0xfe97297c in Perl_hv_store () from /export/home/Apache/libexec/libperl.so #2 0xfe8e3208 in S_init_postdump_symbols () from /export/home/Apache/libexec/libperl.so #3 0xfe8de328 in S_parse_body () from /export/Apache/libexec/libperl.so #4 0xfe8dd134 in perl_parse () from /export/home/Apache/libexec/libperl.so #5 0xfe8ad7cc in perl_startup () from /export/home/Apache/libexec/libperl.so #6 0xfe8b4394 in perl_cmd_module () from /export/home/Apache/libexec/libperl.so #7 0x1fef8 in invoke_cmd () #8 0x203fc in ap_handle_command () #9 0x204d4 in ap_srm_command_loop () #10 0x2094c in ap_process_resource_config () #11 0x21660 in ap_read_config () #12 0x3159c in standalone_main () #13 0x32328 in main () What could be the issue with my apache server. Is this a configuration issue or problem with my application?? Amit, you have some problem with mod_perl 1.x. Please send a bug report to the modperl list, *after* you have read: http://perl.apache.org/bugs/. Thanks. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 2.0.49 rolled
Sander Temme wrote:
On Mar 18, 2004, at 12:21 AM, Sander Striker wrote:
I've put the 2.0.49 tarballs up at:
I'm not entirely happy about IPv6/IPv4 behaviour on at least FreeBSD
5.2.1 and MacOSX 10.3.{2,3}, possibly others.
I'm seeing the following when running the perl-framework. All three
boxes have IPv6 enabled. The perl-framework configures its Apache to
Listen on localhost:8529 (and a bunch of other ports). This results, on
all three machines, in the httpd only binding to ::1 for all ports.
Apparently the LWP stuff that perl-framework uses only knows about IPv4,
so all tests fail.
On the BSD box, when I switch the localhost lines so that IPv4
(127.0.0.1) comes before IPv6 (::1), and re-run the tests, I see the
server (using netstat) bind to only IPv4. Tests succeed.
I don't know how to make the same switch on the Macs: they tend to use
NetInfo for this stuff when running multi-user, but the NetInfo database
contains only IPv4 information.
I don't know enough about IPv6 to know what's going on here (maybe I
should change that), and I don't know if Apache is doing anything wrong
here... can it do anything but ask the OS for what localhost is, and
live with the answer? Is the practice to degenerate 127.0.0.1 and ::1
into the name localhost, broken?
I have not had the chance to test this on earlier releases.
Yes, this issue is a problematic and helping to resolve it would be great! I
don't have any ipv6 experience and my machine is ipv4, so if you do, please help.
Here is the TODO item:
- Apache-Test doesn't run on IPv6 systems, need to change the
autogeneration of httpd.conf to support IPv6. It requires a
replacement of 'Listen 80' with 'Listen servername:80'
Philippe posted patch here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105514290024419&w=2
For now, 127.0.0.1 will be hardcoded in the Listen directive, but a better
method would use this table:
Apache \ OS | IPV4 | IPV6
--enable-v4-mapped | 80 | 80
--disable-v4-mapped | can't happen | 127.0.0.1:80
To more correctly pick the right Listen flavor.
The problem is that some platforms that run ipv4, configure the dns resolver
to use ipv6 ::1 syntax, which wrecks a lot of havoc.
So if you know how to identify whether ipv6 is used or not programmatically,
across all platforms, and write the correct configuration file, I'm all ears.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: making filters more efficient
Greg Stein wrote: On Tue, Mar 02, 2004 at 10:11:06AM -0800, Stas Bekman wrote: Justin Erenkrantz wrote: ... Correct. Because the EOS is generated by the request-level protocol handler (HTTP_IN). That's exactly how it is designed. If a connection input filter saw EOS, it'd signal end-of-connection not end-of-request. But, we don't even have EOC yet - Madhu's adding it for mod_ssl's purposes for the output chain. That sounds very incosistent. Why connection output filters do get the EOS bucket at the end of every HTTP request (which makes them HTTP aware, no?), but their brother input filters don't? Why it is not a problem with connection output filters? The output filters see EOS as "end of response", and that information is useful at all levels. The input filters see EOS in different ways because of where they are in the semantic level of parsing. At the connection level, there is no such thing as a request, so EOS can only mean "end of connection". At the request level, an EOS has the meaning of "end of request". Any chance someone can document all that? The current state of the filters internals documentation at http://httpd.apache.org/docs-2.0/ is 'nada'. Please correct me if I'm wrong. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: making filters more efficient
Geoffrey Young wrote: If you have a concrete example of something that needs to query the state, then we can examine whether it should hook into the processing differently. I bet there is a different hook or approach that can avoid a query of the state. I think where stas is headed are cases like ryan's mod_apachecon http://rkbloom.net/rbb/mod_apachecon.c which seems to be to be a valid example - you want to manipulate part of the HTTP request, such as the request line or incoming headers, and post-read is too late. but simply scaning input for GET .* HTTP/1.0 isn't sufficient, since it's not foolproof, so it would be nice to have something that signaled the start of a request. Yes, that's exactly the case I'm talking about. Thanks Geoff. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: EOS is not being sent for HEAD requests
Bojan Smojver wrote:
If you have mod_logio configured, this might be its doing. It replaces
the EOS with FLUSH. This is in order to make sure all output is counted
and logged properly for each request.
Here is the code from mod_logio that does that:
---
static apr_status_t logio_out_filter(ap_filter_t *f,
apr_bucket_brigade *bb) {
apr_bucket *b = APR_BRIGADE_LAST(bb);
/* End of data, make sure we flush */
if (APR_BUCKET_IS_EOS(b)) {
APR_BRIGADE_INSERT_TAIL(bb,
apr_bucket_flush_create(f->c->bucket_alloc));
APR_BUCKET_REMOVE(b);
apr_bucket_destroy(b);
}
return ap_pass_brigade(f->next, bb);
}
---
I remember trying without APR_BUCKET_REMOVE/apr_bucket_destroy, but that
kept giving me problems. This was long time ago and I don't remember
exactly what the nature of those problems.
Anyway, may be the culprit...
Thanks Bojan, but no I don't use it.
It just shows how fragile the reliance on buckets to deliver information is.
Any filter may decide to do whatever it wants and if you get this kind of
problem how do you figure out where the problem is? Plug yourself into the
filter chain and watch which filter eats the bucket? Supposedly I can do that
on my machine. What happens to a user who can't do that? And even after
finding the faulty filter it'll take time to fix the problem. Meanwhile my
module will be unusable as long as users don't update the faulty filter. If I
didn't have to rely on other filters behaving well and my code is proper I
won't need to worry about things and spend time creating new things rather
than trying to find the faulty filter.
That's why I'd prefer for Apache to have an API for these events, in addition
to the meta buckets...
p.s. I have nothing against Bojan's mod_logio, but he just gave a good example
where a filter is not well behaved (by a non-existing well-behaved-filters
Apache spec).
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: EOS is not being sent for HEAD requests
Justin Erenkrantz wrote: --On Monday, March 1, 2004 11:20 PM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote: I've stepped through with gdb, ap_finalize_request_protocol is called and EOS is sent, but it gets lost and doesn't reach the connection output filter. That'd mean that a filter isn't passing it on as it should be. So, what filter loses it? Is it one of ours? Or, is it a custom one? As always, more details would be appreciated. -- justin I'm just installing a passive snooper filter (one snooping on incoming connection and one on the outgoing) that passes the data through as is and dumps bbs contents and bucket types to error log. So it must be some of the core filters I believe. Here are the traces: HEAD "/index.html" <<< connection input filter o bucket 1: HEAP [HEAD /index.html HTTP/1.0 ] <<< connection input filter o bucket 1: HEAP [Host: localhost.localdomain:8529 ] <<< connection input filter o bucket 1: HEAP [User-Agent: libwww-perl/5.76 ] <<< connection input filter o bucket 1: HEAP [ ] >>> connection output filter o bucket 1: HEAP [HTTP/1.1 200 OK Date: Tue, 02 Mar 2004 18:22:46 GMT Server: Apache/2.0.49-dev (Unix) mod_perl/1.99_13-dev Perl/v5.8.3 mod_ssl/2.0.49-dev OpenSSL/0.9.7b DAV/2 Last-Modified: Thu, 07 Aug 2003 19:13:15 GMT ETag: "23cb9-2d0-830a88c0" Accept-Ranges: bytes Content-Length: 720 Connection: close Content-Type: text/html ] >>> connection output filter o bucket 1: FLUSH [] >>> connection output filter o bucket 1: FLUSH [] No EOS as you can see Now issue GET "/index.html" <<< connection input filter o bucket 1: HEAP [GET /index.html HTTP/1.0 ] <<< connection input filter o bucket 1: HEAP [Host: localhost.localdomain:8529 ] <<< connection input filter o bucket 1: HEAP [User-Agent: libwww-perl/5.76 ] <<< connection input filter o bucket 1: HEAP [ ] >>> connection output filter o bucket 1: HEAP [HTTP/1.1 200 OK Date: Tue, 02 Mar 2004 18:22:45 GMT Server: Apache/2.0.49-dev (Unix) mod_perl/1.99_13-dev Perl/v5.8.3 mod_ssl/2.0.49-dev OpenSSL/0.9.7b DAV/2 Last-Modified: Thu, 07 Aug 2003 19:13:15 GMT ETag: "23cb9-2d0-830a88c0" Accept-Ranges: bytes Content-Length: 720 Connection: close Content-Type: text/html ] >>> connection output filter o bucket 1: MMAP [ welcome to localhost:8529 ] o bucket 2: EOS [] >>> connection output filter o bucket 1: FLUSH [] >>> connection output filter o bucket 1: FLUSH [] EOS is there. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: making filters more efficient
Justin Erenkrantz wrote: --On Monday, March 1, 2004 10:58 PM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote: An EOS *is* generated for this. It does in the request filter (in and out). It does in the connection output filter. It does *not* in the connection input filter. Correct. Because the EOS is generated by the request-level protocol handler (HTTP_IN). That's exactly how it is designed. If a connection input filter saw EOS, it'd signal end-of-connection not end-of-request. But, we don't even have EOC yet - Madhu's adding it for mod_ssl's purposes for the output chain. That sounds very incosistent. Why connection output filters do get the EOS bucket at the end of every HTTP request (which makes them HTTP aware, no?), but their brother input filters don't? Why it is not a problem with connection output filters? Yes, this is how it works. There is no API to tell you that. e.g. what if you want to check from the response handler whether Apache has already sent the headers or not? In 1.3 the user controlled that, but that's not the case in 2.0. The moment something sends the output the headers are flushed. that something at times could be an empty bucket when an uninitented flush triggers data out. There's been no data written by the time the response handler is called. So, the handler can always set the headers before it does the first write. Once a write is triggered, you must assume that the headers are sent. And, that's (almost) how it was in 1.3 as well. -- justin There are more complicated setups than just one simple script or a handler, where it could be hard to know whether the output headers set has been sent already or not. Granted that setup could write their own flag, which the rest of the application could use, but it sounds ideal for Apache to provide a set of state functions, which can tell you what exactly Apache is doing, whether it has completed something (sent headers) or has not completed (e.g. still parsing headers). __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to tell one request from another inside a connection filter over keep-alive connection
Justin Erenkrantz wrote: --On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote: AP_FTYPE_PROTOCOL. But what difference does it make as long as it sees the HTTP headers? Because AP_FTYPE_PROTOCOL is request-level when you are using HTTP. yes, but it won't see the headers, no? But, you should not be changing HTTP headers in a filter. You should be altering them in a post_read_request hook and add it to the table. that could be too late for some purposes, e.g. if you want to change the HTTP method I believe. I'm certain, a mod_pop3 wouldn't like HTTP filters on connection level. I fail to see what it has to do with mod_pop3. If I run a connection filter that works on HTTP headers/requests I put it inside a vhost, so it doesn't affect any other protocols. What you are suggesting is to make the connection-level filters aware of HTTP. Once again, that is *not* correct. The connection-level filters must be unaware of HTTP or things start to break. I'm not clear how to better explain this, but what you are trying to do is going against the core principles of our filter design. -- justin I'm not aware of any document explaining the core principles of Apache 2 filter design. So obviously it's open to various interpretation, including potentially erroneous ones. Or was such a spec written recently and I wasn't aware of? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: why modules/ssl keep on creating collisions on 'cvs up'
Joe Orton wrote: On Mon, Mar 01, 2004 at 11:53:00PM -0800, Stas Bekman wrote: There must be some simple explanation, but this is very annoying as 'cvs up' in httpd-2.0 keeps on colliding at these files: M modules/ssl/ssl_expr_parse.c M modules/ssl/ssl_expr_parse.h M modules/ssl/ssl_expr_scan.c This should only happen very occasionally now in HEAD when one of the ssl_expr sources is modified (as happened recently) since buildconf will touch the files to ensure that make never regenerates them: rm modules/ssl/ssl_expr* && cvs up && ./buildconf to make it go away. That's what I was doing, but I was reluctant to put that in the build script, because you never remember those delete commands. But as you say they are autogenerated then I'll just the above trick. Similarly build/PrintPath seems to be modified. That doesn't sound right. If thinds are generated they shouldn't be under cvs control. PrintPath should be fixed already too if you cvs up and buildconf. (I don't see why it needs to be under version control in httpd-2.0 since it could be copied from APR) Not keeping the ssl_expr* files under version control would mean Win32 etc then require yacc/lex to build mod_ssl, that's less clear cut. Understood! Thanks Joe! ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
