parent member is not set under -DONE_PROCESS
When running with -DONE_PROCESS the struct at ap_scoreboard_image-parent[0] is all zeros. So for example when trying to debug an application which uses the scoreboard struct's parent member, things go wrong. I can see the same behavior in 1.x and 2.x scoreboards via mod_status, which displays 0 for PID. Any reason for not setting this entry under -DONE_PROCESS/-X? Thanks. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: cvs commit: httpd-2.0/modules/ssl ssl_scache_shmcb.c ssl_util_table.c
I think it's better to have it rather than not - safeguarding the code
against any compiler optimizations is a preferable thing to me.
BTW, did anybody get a chance to see if the patch actually works on
different platforms - it still does not work for me on HP-UX :-(.. it dumps
core at apr_rmm_malloc().
-Madhu
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 15, 2002 1:14 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: httpd-2.0/modules/ssl ssl_scache_shmcb.c
ssl_util_table.c
On Fri, Mar 15, 2002 at 01:46:47AM -, [EMAIL PROTECTED] wrote:
/* This is necessary simply so that the size passed to memset() is not
a
* compile-time constant, preventing the compiler from optimising it.
*/
+#if 0
+/* XXX: this isn't used, is it needed? */
static void shmcb_safe_clear(void *ptr, size_t size)
{
memset(ptr, 0, size);
}
+#endif
It was needed in mod_ssl 2.8 as in the below patch, since 'idx' wasn't
guaranteed to be word-aligned, and some compilers would optimise the
memset into instructions which operated on words. If you can guarantee
that idx is word-aligned in 2.0 with the new rmm stuff, it probably
isn't needed.
Index: ssl_scache_shmcb.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_scache_shmcb.c,v
retrieving revision 1.7
diff -u -r1.7 ssl_scache_shmcb.c
--- ssl_scache_shmcb.c 15 Mar 2002 01:46:47 - 1.7
+++ ssl_scache_shmcb.c 15 Mar 2002 08:49:02 -
@@ -269,13 +269,10 @@
/* This is necessary simply so that the size passed to memset() is not a
* compile-time constant, preventing the compiler from optimising it. */
-#if 0
-/* XXX: this isn't used, is it needed? */
static void shmcb_safe_clear(void *ptr, size_t size)
{
memset(ptr, 0, size);
}
-#endif
/* Underlying functions for session-caching */
static BOOL shmcb_init_memory(server_rec *, void *, unsigned int);
@@ -1178,7 +1175,7 @@
internal error);
return FALSE;
}
-memset(idx, 0, sizeof(SHMCBIndex));
+shmcb_safe_clear(idx, sizeof(SHMCBIndex));
shmcb_set_safe_time((idx-expires), expiry_time);
shmcb_set_safe_uint((idx-offset), new_offset);
debugging httpd and php
There was some recent talk on the list about debugging apache.
I have current HEAD code for both httpd-2.0 and php42. If I try to
start apache with the php module, it silently crashes on startup. So I
pop it into gdb and here's what I get.
(gdb) r -X
Starting program: /src/cvs/httpd-2.0/httpd -X
[New Thread 1024 (LWP 9253)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 9253)]
0x4031dad5 in ts_resource_ex (id=1, th_id=0x0) at
/src/cvs/php4/TSRM/TSRM.c:310
310
TSRM_SAFE_RETURN_RSRC(thread_resources-storage, id,
thread_resources-count);
(gdb) l
305 TSRM_ERROR((TSRM_ERROR_LEVEL_INFO,
Fetching resource id %d for current thread %d, id, (long)
thread_resources-thread_id));
306 /* Read a specific resource from the
thread's resources.
307 * This is called outside of a mutex, so
have to be aware about external
308 * changes to the structure as we read it.
309 */
310
TSRM_SAFE_RETURN_RSRC(thread_resources-storage, id,
thread_resources-count);
311 }
312 thread_id = tsrm_thread_id();
313 } else {
314 thread_id = *th_id;
(gdb) bt
#0 0x4031dad5 in ts_resource_ex (id=1, th_id=0x0)
at /src/cvs/php4/TSRM/TSRM.c:310
#1 0x40321bfd in php_module_startup (sf=0x4044eba0)
at /src/cvs/php4/main/main.c:856
#2 0x403746f4 in php_apache_server_startup (pconf=0x81014c0,
plog=0x81395a0,
ptemp=0x818ad58, s=0x818dfd8)
at /src/cvs/php4/sapi/apache2filter/sapi_apache2.c:428
#3 0x0808e43f in ap_run_post_config (pconf=0x81014c0, plog=0x81395a0,
ptemp=0x818ad58, s=0x818dfd8) at config.c:127
#4 0x08092715 in main (argc=2, argv=0xb6e4) at main.c:603
(gdb) p *thread_resources
$2 = {storage = 0x50435245, count = 33, thread_id = 135231232,
next = 0x2010}
Anybody have helpful suggestions here? Should I post my compile
options? 'tis fully repeatable.
Thank you,
David
smime.p7s
Description: S/MIME Cryptographic Signature
Re: daemontools/foreground support in 1.3.*
On Tue, Feb 26, 2002 at 07:49:34PM -0800, Jos Backus wrote: On Tue, Feb 26, 2002 at 07:21:16AM -0800, Aaron Bannert wrote: On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: hi, guys. i've posted this patch for foreground/supervise support FWIW, by just eyeballing this patch I can say it looks good. It is exactly how I would have done it. Fwiw, same here. It is very unintrusive, less so even than the patch that went into 2.0. Please consider including it. Fyi, I plan on submitting a patch to the FreeBSD port maintainer to include this patch automatically in 1.3.24 when it is released. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
[PATCH] PRs 8902, 8907, 9983: get nph scripts working
Axing unnecessary/harmful filters gets nph scripts working again.
If someone ever wants nph function beyond what 1.3 provides then of
course it gets more complicated and NPH probably turns into we can't
avoid parsing it but we'll still trust you. (examples: filtering
content, byterange requests, letting script on EBCDIC box output
headers in EBCDIC). I doubt that it is worth the effort.
My first patch shown at the bottom, but that left the byterange filter
in the chain, and that is just going to make a mess of things.
Index: modules/generators/mod_cgid.c
===
RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgid.c,v
retrieving revision 1.116
diff -u -r1.116 mod_cgid.c
--- modules/generators/mod_cgid.c 14 Mar 2002 22:19:13 - 1.116
+++ modules/generators/mod_cgid.c 15 Mar 2002 21:29:17 -
@@ -1148,11 +1148,24 @@
}
if (nph) {
+struct ap_filter_t *cur;
+
/* Passing our socket down the filter chain in a pipe bucket
* gives up the responsibility of closing the socket, so
* get rid of the cleanup.
*/
apr_pool_cleanup_kill(r-pool, (void *)sd, close_unix_socket);
+
+/* get rid of all filters up through protocol... since we
+ * haven't parsed off the headers, there is no way they can
+ * work
+ */
+
+cur = r-proto_output_filters;
+while (cur cur-frec-ftype AP_FTYPE_CONNECTION) {
+cur = cur-next;
+}
+r-output_filters = r-proto_output_filters = cur;
bb = apr_brigade_create(r-pool);
b = apr_bucket_pipe_create(tempsock);
(imagine the same change to mod_cgi.c)
Comments? Thoughts on a better way to do it without boiling the
ocean?
---first patch---
Index: modules/generators/mod_cgi.c
===
RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgi.c,v
retrieving revision 1.120
diff -u -r1.120 mod_cgi.c
--- modules/generators/mod_cgi.c14 Mar 2002 22:19:13 - 1.120
+++ modules/generators/mod_cgi.c15 Mar 2002 20:58:55 -
@@ -733,6 +733,7 @@
}
if (script_in nph) {
+r-assbackwards = 1;/* tell core not to generate headers */
bb = apr_brigade_create(r-pool);
b = apr_bucket_pipe_create(script_in);
APR_BRIGADE_INSERT_TAIL(bb, b);
Index: modules/generators/mod_cgid.c
===
RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgid.c,v
retrieving revision 1.116
diff -u -r1.116 mod_cgid.c
--- modules/generators/mod_cgid.c 14 Mar 2002 22:19:13 - 1.116
+++ modules/generators/mod_cgid.c 15 Mar 2002 20:58:55 -
@@ -1154,6 +1154,7 @@
*/
apr_pool_cleanup_kill(r-pool, (void *)sd, close_unix_socket);
+r-assbackwards = 1;/* tell core not to generate headers */
bb = apr_brigade_create(r-pool);
b = apr_bucket_pipe_create(tempsock);
APR_BRIGADE_INSERT_TAIL(bb, b);
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: Apache-1.3 proxy: X-Cache question
On Thu, 14 Mar 2002, Martin Kraemer wrote: --snip-- % netcat localhost 8080 . HEAD http://apache.org/favicon.ico HTTP/1.0 . HTTP/1.1 200 OK Date: Thu, 14 Mar 2002 11:20:48 GMT Server: Apache/1.3.24-dev (Unix) ... X-Cache: MISS from localhost Connection: close --snip-- Should the X-Cache line not rather read: X-Cache: MISS from localhost:8080 because that was its port number? Yes - and anoyingly squid and various other cache flow mngt products get this wrong as well. RFC2616 doesn't describe X-Cache ;-) There are some internet draft trying to get this properly documented. Dw
Re: Apache-1.3 proxy: X-Cache question
On Thu, 14 Mar 2002, Martin Kraemer wrote: On Thu, Mar 14, 2002 at 12:25:47PM +0100, Kraemer, Martin wrote: X-Cache: MISS from localhost Should the X-Cache line not rather read: X-Cache: MISS from localhost:8080 I just looked at squid's implementation. It doesn't append the port either. But IMHO that's a bug too. In the case of Squid it could be that the request was made via HTCP or ICP rather then HTTP. So the port number might still be useful, but it might be that HTTP is not spoken on this port number. -- Sander van Zoest [EMAIL PROTECTED] San Diego, CA, US http://Sander.vanZoest.com/
Re: [PATCH] mod_mem_cache using apr_atomic_dec()
Greg Ames wrote:
Bill Stoddard wrote:
(moved from dev@httpd to dev@apr)
I hesitate to commit the because I am not sure if apr_atomic_dec will be portable and
usable on enough OS/hardware combinations.
as we discussed offline, you're right. The return value for apr_atomic_dec
isn't defined, but as your code demonstrates, it's very useful for making the
cache more scaleable.
If any apr_atomic_* implementations have hardware dependencies (ie, the
implementation
explicitly exploits hardware features via assembly language calls for instance),
supporting the atomic operations in APR could become a real nightmare. APR compiled
on
one machine may not run on another machine even if the OS level of the two machines
is
identical. Most gnarley...
yeah, that's bad for binaries. Seems like we would want to build them on the
most ancient version of the CPU architecture supported, or have #defines which
dumb down your build machine.
-if (sconf-lock) {
-apr_thread_mutex_lock(sconf-lock);
-}
-obj-refcount--;
-/* If the object is marked for cleanup and the refcount
- * has dropped to zero, cleanup the object
- */
-if ((obj-cleanup) (!obj-refcount)) {
-cleanup_cache_object(obj);
-}
-if (sconf-lock) {
-apr_thread_mutex_unlock(sconf-lock);
+if (!apr_atomic_dec(obj-refcount)) {
+if (obj-cleanup) {
+cleanup_cache_object(obj);
+}
nice...a concise lock free example of the last guy out the door turns out the
lights pattern.
However, this code won't work on Linux at the moment. apr_atomic_dec invokes
the atomic_dec function which doesn't define a return value. Linux does have an
atomic_dec_and_test which we could use. But it returns true when the counter
becomes zero; Win32 returns the new value of the counter, so it is false when
the counter becomes zero. It looks to me like Solaris behaves like Win32; dunno
about Netware.
FreeBSD doesn't seem to have userland atomic functions that return anything. It
shouldn't be too hard to write an i386 asm function, but FreeBSD runs on other
chip families where I wouldn't feel comfortable with asm. Perhaps we could
emulate a atomic_dec that tells you when the value reaches zero for non-i386
FreeBSD using a lock, like Ian's existing default functions.
Would it make sense to create another new API, apr_atomic_dec_and_test (or
whatever) which is defined to return something consistant? I think Bill's code
demonstrates how useful it is to have such a function for reference counting.
The Linux kernel uses both atomic_dec and atomic_dec_and_test.
I think we should just modifiy the _dec function to return a value.
I'll patch this tonight if you don't beat me to it.
as for bsd.. I'm working on getting a freeBSD-current system which has a
atomic_cmpset_int
which will allow us to implement the rest of them..
sorry for not fixing this earlier..
ian
We already have a return value from apr_atomic_cas; I don't know that we need a
return value for the other atomics.
Greg
a quick hack to allow apr_atomic_dec to work on Linux for refcounts:
Index: srclib/apr/include/apr_atomic.h
===
RCS file: /cvs/apache/apr/include/apr_atomic.h,v
retrieving revision 1.15
diff -u -d -b -r1.15 apr_atomic.h
--- apr_atomic.h2002/03/13 20:39:13 1.15
+++ apr_atomic.h2002/03/15 17:36:13
-117,6 +117,7
/**
* decrement the atomic variable by 1
* param mem pointer to the atomic value
+ * return false (0) if the value became 0; otherwise true
*/
void apr_atomic_dec(volatile apr_atomic_t *mem);
-158,7 +159,7
#define apr_atomic_t atomic_t
#define apr_atomic_add(mem, val) atomic_add(val,mem)
-#define apr_atomic_dec(mem) atomic_dec(mem)
+#define apr_atomic_dec(mem) !atomic_dec_and_test(mem)
#define apr_atomic_inc(mem) atomic_inc(mem)
#define apr_atomic_set(mem, val) atomic_set(mem, val)
#define apr_atomic_read(mem) atomic_read(mem)
Re: httpd-2.0's proxy CHANGES file
+1. On Thursday, March 14, 2002, at 11:46 AM, Bill Stoddard wrote: +1 - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 14, 2002 11:38 AM Subject: httpd-2.0's proxy CHANGES file Now that mod_proxy is back in httpd-2.0, should we depreciate proxy's CHANGES file? If so, I'll make a note to that effect in it.
