From justin28@example.net Fri Mar 01 13:40:24 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 67585 invoked by uid 500); 1 Mar 2002 13:40:23 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 67572 invoked from network); 1 Mar 2002 13:40:22 -0000 Message-ID: <006201c1c126$f070d910$2c381b09@sashimi> From: "Bill Stoddard" <justin28@example.net> To: "APR Development List" <justin28@example.net> References: <{{EMAIL+PHONE}}> <justin28@example.net> Subject: Re: bucket api patch Date: Fri, 1 Mar 2002 08:42:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Cliff Woolley wrote: > > >Well, it's not finished yet, but it's something you can look at if you > >like. http://icarus.apache.org/~jwoolley/ . > > > >Things missing: > > > >(a) calls to apr_bucket_alloc_create() and _destroy() at strategic > >locations within the MPMs. I'm hoping that's something one of you guys > >can help me with, since I haven't exactly spent a lot of time in the MPMs > >lately. > > > > I can take on this part for prefork and worker. One question, > though: how will apr_bucket_free() work once the real version > is implemented? Will it actually free up the space within > the allocator for reuse, or will it be a no-op? > > The strategy for placing the apr_bucket_alloc_create() and > _destroy() calls depends a lot on how apr_bucket_free() works. > I can cover the Windows MPM. Bill From justin28@example.net Fri Mar 01 16:11:50 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 54180 invoked by uid 500); 1 Mar 2002 16:11:50 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 54169 invoked from network); 1 Mar 2002 16:11:50 -0000 Date: Fri, 1 Mar 2002 11:11:31 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: Brian Pane <justin28@example.net> cc: justin28@example.net Subject: Re: bucket api patch In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thu, 28 Feb 2002, Brian Pane wrote: > >(a) calls to apr_bucket_alloc_create() and _destroy() at strategic > >locations within the MPMs. I'm hoping that's something one of you guys > >can help me with, since I haven't exactly spent a lot of time in the MPMs > >lately. > > I can take on this part for prefork and worker. One question, > though: how will apr_bucket_free() work once the real version > is implemented? Will it actually free up the space within > the allocator for reuse, or will it be a no-op? It is definitely a real _free() and not a noop. Otherwise we wouldn't get much for freelists. :) > The strategy for placing the apr_bucket_alloc_create() and > _destroy() calls depends a lot on how apr_bucket_free() works. The ideas I had in mind go like this: prefork: create one bucket allocator for each child when the child is born, and use that same bucket allocator in every connection handled by that child worker: similar to prefork, except there can either be one allocator per worker thread or one per transaction pool (now that we're reusing those pools, might as well associate a bucket allocator with each one and reuse those too... don't know if that's a benefit or not) others: I guess it's one per worker thread? I know next to nothing about these MPMs Note that the future MPM that does async I/O and passes requests from one thread to another mid-flight will *have to* have a group of bucket allocators that it keeps around, assigning an available one to each *connection* as it comes in -- ie, this one cannot be thread-private like some of the others might be able to. --Cliff -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA From justin28@example.net Fri Mar 01 16:16:55 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 59111 invoked by uid 500); 1 Mar 2002 16:16:54 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 59099 invoked from network); 1 Mar 2002 16:16:54 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: justin28@example.net, justin28@example.net Subject: [PATCH] fix alignment on shared memory References: <justin28@example.net> <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 11:14:05 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 83 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jeff Trawick <justin28@example.net> writes: > Aaron Bannert <justin28@example.net> writes: > > > Could this be what's causing the SIGBUS? My current theory is that > > there's a size mismatch betwen ws->conn_bytes (an apr_off_t) and > > the (unsigned long) that only shows up on word-alignment-picky > > chips like sparcs. > > I'm bombing today on Solaris/sparc trying to do > > ap_scoreboard_image->global->restart_time = apr_time_now() > > That field lives at 0x14 from the start of the page. I would suppose > that there are alignment requirements that we aren't maintaining. > ap_scoreboard_image->global is at 0x4 from the start of the page. > Does anybody know about any documentation on alignment requirements? > Should the shared memory code return storage on 8-byte alignment? This patch gets me running again: Index: srclib/apr/shmem/unix/shm.c =================================================================== RCS file: /home/cvs/apr/shmem/unix/shm.c,v retrieving revision 1.14 diff -u -r1.14 shm.c --- srclib/apr/shmem/unix/shm.c 5 Feb 2002 04:32:52 -0000 1.14 +++ srclib/apr/shmem/unix/shm.c 1 Mar 2002 16:03:33 -0000 @@ -59,6 +59,12 @@ #include "apr_user.h" #include "apr_strings.h" +/* APR_ALIGN() is only to be used to align on a power of 2 boundary */ +#define APR_ALIGN(size, boundary) \ + (((size) + ((boundary) - 1)) & ~((boundary) - 1)) + +#define APR_ALIGN_DEFAULT(size) APR_ALIGN(size, 8) + static apr_status_t shm_cleanup_owner(void *m_) { apr_shm_t *m = (apr_shm_t *)m_; @@ -189,7 +195,7 @@ /* store the real size in the metadata */ *(apr_size_t*)(new_m->base) = new_m->realsize; /* metadata isn't usable */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, apr_pool_cleanup_null); @@ -206,7 +212,7 @@ /* store the real size in the metadata */ *(apr_size_t*)(new_m->base) = new_m->realsize; /* metadata isn't usable */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, apr_pool_cleanup_null); @@ -345,7 +351,7 @@ /* store the real size in the metadata */ *(apr_size_t*)(new_m->base) = new_m->realsize; /* metadata isn't usable */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, apr_pool_cleanup_null); @@ -508,7 +514,7 @@ } /* metadata isn't part of the usable segment */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_attach, apr_pool_cleanup_null); -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 16:38:24 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 83975 invoked by uid 500); 1 Mar 2002 16:38:22 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 83946 invoked from network); 1 Mar 2002 16:38:22 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: justin28@example.net Cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory References: <justin28@example.net> <justin28@example.net> <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 11:35:32 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jeff Trawick <justin28@example.net> writes: > This patch gets me running again: > > Index: srclib/apr/shmem/unix/shm.c > =================================================================== > RCS file: /home/cvs/apr/shmem/unix/shm.c,v > retrieving revision 1.14 > diff -u -r1.14 shm.c > --- srclib/apr/shmem/unix/shm.c 5 Feb 2002 04:32:52 -0000 1.14 > +++ srclib/apr/shmem/unix/shm.c 1 Mar 2002 16:03:33 -0000 > @@ -59,6 +59,12 @@ > #include "apr_user.h" > #include "apr_strings.h" > > +/* APR_ALIGN() is only to be used to align on a power of 2 boundary */ > +#define APR_ALIGN(size, boundary) \ > + (((size) + ((boundary) - 1)) & ~((boundary) - 1)) > + > +#define APR_ALIGN_DEFAULT(size) APR_ALIGN(size, 8) > + > static apr_status_t shm_cleanup_owner(void *m_) > { > apr_shm_t *m = (apr_shm_t *)m_; > @@ -189,7 +195,7 @@ > /* store the real size in the metadata */ > *(apr_size_t*)(new_m->base) = new_m->realsize; > /* metadata isn't usable */ > - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); > + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); but something missing from the patch is taking into account the alignment when calculating new_m->realsize (minor detail :) ) that alignment has to be reflected in other places as well (apr_shm_attach() when we mmap the file) -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 16:49:06 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 93339 invoked by uid 500); 1 Mar 2002 16:49:04 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 93318 invoked from network); 1 Mar 2002 16:49:03 -0000 Date: Fri, 1 Mar 2002 08:49:05 -0800 From: Aaron Bannert <justin28@example.net> To: justin28@example.net, justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory Message-ID: <justin28@example.net> Mail-Followup-To: Aaron Bannert <justin28@example.net>, justin28@example.net, justin28@example.net References: <justin28@example.net> <justin28@example.net> <justin28@example.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <justin28@example.net> User-Agent: Mutt/1.3.23i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I've still got sleep in my eyes, so I might not be seeing this correctly yet, but isn't the problem not that the segment itself is misaligned, but that the structure that is being placed over that segment not properly padded to account for alignment? This looks like the problem to me: AP_DECLARE(int) ap_calc_scoreboard_size(void) { ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit); ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit); scoreboard_size = sizeof(global_score); scoreboard_size += sizeof(process_score) * server_limit; scoreboard_size += sizeof(worker_score) * server_limit * thread_limit; return scoreboard_size; } -aaron On Fri, Mar 01, 2002 at 11:14:05AM -0500, Jeff Trawick wrote: > Jeff Trawick <justin28@example.net> writes: > > > Aaron Bannert <justin28@example.net> writes: > > > > > Could this be what's causing the SIGBUS? My current theory is that > > > there's a size mismatch betwen ws->conn_bytes (an apr_off_t) and > > > the (unsigned long) that only shows up on word-alignment-picky > > > chips like sparcs. > > > > I'm bombing today on Solaris/sparc trying to do > > > > ap_scoreboard_image->global->restart_time = apr_time_now() > > > > That field lives at 0x14 from the start of the page. I would suppose > > that there are alignment requirements that we aren't maintaining. > > ap_scoreboard_image->global is at 0x4 from the start of the page. > > Does anybody know about any documentation on alignment requirements? > > Should the shared memory code return storage on 8-byte alignment? > > This patch gets me running again: > > Index: srclib/apr/shmem/unix/shm.c > =================================================================== > RCS file: /home/cvs/apr/shmem/unix/shm.c,v > retrieving revision 1.14 > diff -u -r1.14 shm.c > --- srclib/apr/shmem/unix/shm.c 5 Feb 2002 04:32:52 -0000 1.14 > +++ srclib/apr/shmem/unix/shm.c 1 Mar 2002 16:03:33 -0000 > @@ -59,6 +59,12 @@ > #include "apr_user.h" > #include "apr_strings.h" > > +/* APR_ALIGN() is only to be used to align on a power of 2 boundary */ > +#define APR_ALIGN(size, boundary) \ > + (((size) + ((boundary) - 1)) & ~((boundary) - 1)) > + > +#define APR_ALIGN_DEFAULT(size) APR_ALIGN(size, 8) > + > static apr_status_t shm_cleanup_owner(void *m_) > { > apr_shm_t *m = (apr_shm_t *)m_; > @@ -189,7 +195,7 @@ > /* store the real size in the metadata */ > *(apr_size_t*)(new_m->base) = new_m->realsize; > /* metadata isn't usable */ > - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); > + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); > > apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, > apr_pool_cleanup_null); > @@ -206,7 +212,7 @@ > /* store the real size in the metadata */ > *(apr_size_t*)(new_m->base) = new_m->realsize; > /* metadata isn't usable */ > - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); > + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); > > apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, > apr_pool_cleanup_null); > @@ -345,7 +351,7 @@ > /* store the real size in the metadata */ > *(apr_size_t*)(new_m->base) = new_m->realsize; > /* metadata isn't usable */ > - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); > + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); > > apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, > apr_pool_cleanup_null); > @@ -508,7 +514,7 @@ > } > > /* metadata isn't part of the usable segment */ > - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); > + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); > > apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_attach, > apr_pool_cleanup_null); > > > -- > Jeff Trawick | justin28@example.net | PGP public key at web site: > http://www.geocities.com/SiliconValley/Park/9289/ > Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 17:37:45 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 39169 invoked by uid 500); 1 Mar 2002 17:37:45 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 39155 invoked from network); 1 Mar 2002 17:37:44 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: Aaron Bannert <justin28@example.net> Cc: justin28@example.net, justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory References: <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 12:34:49 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 81 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Aaron Bannert <justin28@example.net> writes: > I've still got sleep in my eyes, so I might not be seeing this correctly > yet, but isn't the problem not that the segment itself is misaligned, > but that the structure that is being placed over that segment not > properly padded to account for alignment? > > This looks like the problem to me: > > AP_DECLARE(int) ap_calc_scoreboard_size(void) > { > ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit); > ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit); > scoreboard_size = sizeof(global_score); > scoreboard_size += sizeof(process_score) * server_limit; > scoreboard_size += sizeof(worker_score) * server_limit * thread_limit; > return scoreboard_size; > } I'll punt for the moment on whether or not that code is bad. The shared memory code definitely needs to be fixed. Look at this simple test of alignment: #include <stddef.h> #include <stdio.h> int main(void) { struct s1 { char a; char b; } s1; struct s2 { char a; int b; } s2; struct s3 { char a; long long b; } *s3; struct s4 { char a; double b; } s4; printf("%d %d %d %d\n", offsetof(struct s1,b), offsetof(struct s2,b), offsetof(struct s3,b), offsetof(struct s4,b)); s3 = (struct s3 *)((char *)malloc(100) + 4); printf("%p\n",s3); s3->a = 'A'; s3->b = 10241024; return 0; } On my sparc machine it prints 1 4 8 8 for the offsets of the variables of different types. Note that gcc places long long and double on 64-bit boundaries. It then dies with SIGBUS when I trick it into trying to store a 64-bit quantity into storage which s 32-bit aligned but not 64-bit aligned. Back to the code above that you posted: I think that it too needs to take into account alignment. It would need to round the size of each structure up to 64-bit alignmet before multiplying to ensure that objects of any type can live in that storage. This currently isn't causing problems because the size of each structure is consistent with 64-bit alignment (208 bytes for worker_score, 24 bytes for global_score, 16 bytes for process_score), at least in a 32-bit build for Sparc. -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 18:29:27 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 80580 invoked by uid 500); 1 Mar 2002 18:29:24 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 80569 invoked from network); 1 Mar 2002 18:29:23 -0000 Date: Fri, 1 Mar 2002 10:29:27 -0800 From: Aaron Bannert <justin28@example.net> To: justin28@example.net Cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory Message-ID: <justin28@example.net> Mail-Followup-To: Aaron Bannert <justin28@example.net>, justin28@example.net, justin28@example.net References: <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <justin28@example.net> User-Agent: Mutt/1.3.23i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote: > I'll punt for the moment on whether or not that code is bad. The > shared memory code definitely needs to be fixed. Look at this simple > test of alignment: > > #include <stddef.h> > #include <stdio.h> > > int main(void) > { > struct s1 { > char a; > char b; > } s1; > struct s2 { > char a; > int b; > } s2; > struct s3 { > char a; > long long b; > } *s3; > struct s4 { > char a; > double b; > } s4; > > printf("%d %d %d %d\n", > offsetof(struct s1,b), > offsetof(struct s2,b), > offsetof(struct s3,b), > offsetof(struct s4,b)); > > s3 = (struct s3 *)((char *)malloc(100) + 4); Of course it gives us a SIGBUS here, this is guaranteed on a sparc. I'm not entirely sure what you're trying to illustrate here though. > printf("%p\n",s3); > s3->a = 'A'; > s3->b = 10241024; Shouldn't this be: s3->b = 10241024LL; ? (Probably not important.) > return 0; > } > > On my sparc machine it prints > 1 4 8 8 > for the offsets of the variables of different types. Note that gcc > places long long and double on 64-bit boundaries. > > It then dies with SIGBUS when I trick it into trying to store a > 64-bit quantity into storage which s 32-bit aligned but not 64-bit > aligned. As expected. > Back to the code above that you posted: > > I think that it too needs to take into account alignment. It would > need to round the size of each structure up to 64-bit alignmet before > multiplying to ensure that objects of any type can live in that > storage. This currently isn't causing problems because the size of > each structure is consistent with 64-bit alignment (208 bytes for > worker_score, 24 bytes for global_score, 16 bytes for process_score), > at least in a 32-bit build for Sparc. Yes, I completely agree that each structure needs to be 64-bit aligned. I don't see how the shared memory code itself is incorrect. It must be mapping the segment at a properly aligned boundary, so as long as the contents of that segment are accessed in an aligned manner than we're safe, right? -aaron From justin28@example.net Fri Mar 01 18:34:18 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 83210 invoked by uid 500); 1 Mar 2002 18:34:18 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 83168 invoked from network); 1 Mar 2002 18:34:18 -0000 Date: Fri, 1 Mar 2002 13:34:01 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: Aaron Bannert <justin28@example.net> cc: justin28@example.net, <justin28@example.net> Subject: Re: [PATCH] fix alignment on shared memory In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 1 Mar 2002, Aaron Bannert wrote: > Yes, I completely agree that each structure needs to be 64-bit aligned. > I don't see how the shared memory code itself is incorrect. It must be > mapping the segment at a properly aligned boundary, so as long as the > contents of that segment are accessed in an aligned manner than we're > safe, right? That's what I'm thinking, too. I don't see the problem there. It looks to me like you (Aaron) were right on when you suggested that it's ap_calc_scoreboard_size() and ap_init_scoreboard()'s fault. Try this, for example: #include <stddef.h> #include <stdio.h> int main(void) { void *foo; struct s1 { char a; char b; } *s1; struct s2 { char a; int b; } *s2; struct s3 { char a; long long b; } *s3; struct s4 { char a; double b; } *s4; printf("%d %d %d %d\n", offsetof(struct s1,b), offsetof(struct s2,b), offsetof(struct s3,b), offsetof(struct s4,b)); printf(" sizes: %d %d %d %d\n", sizeof(struct s1), sizeof(struct s2), sizeof(struct s3), sizeof(struct s4)); foo = malloc(100); s1 = (struct s1 *)foo; s2 = (struct s2 *)(((char *)s1)+sizeof(s1)*4); s3 = (struct s3 *)(((char *)s2)+sizeof(s2)); printf("%p\n%p\n%p\n",s3,&s3->a,&s3->b); s3->a = 'A'; s3->b = 10241024LL; return 0; } jcw5q@cobra:/uf2/jcw5q$ ./test 1 4 8 8 sizes: 2 8 16 16 20c44 20c44 20c4c Bus Error Except for the times 4, this is very similar to what ap_init_scoreboard() is giving us. Each of the sizeof()'s needs to be padded out because they can interfere with one another when you place the structs back-to-back in memory. --Cliff -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA From justin28@example.net Fri Mar 01 18:40:20 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 87936 invoked by uid 500); 1 Mar 2002 18:40:20 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 87835 invoked from network); 1 Mar 2002 18:40:19 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: justin28@example.net Cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory References: <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 13:37:27 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 76 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Aaron Bannert <justin28@example.net> writes: > On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote: > > > > printf("%d %d %d %d\n", > > offsetof(struct s1,b), > > offsetof(struct s2,b), > > offsetof(struct s3,b), > > offsetof(struct s4,b)); > > > > s3 = (struct s3 *)((char *)malloc(100) + 4); > > Of course it gives us a SIGBUS here, this is guaranteed on a sparc. > I'm not entirely sure what you're trying to illustrate here though. it doesn't give a SIGBUS here.... It gives a SIGBUS when we try to store s3->b. > > > printf("%p\n",s3); > > s3->a = 'A'; > > s3->b = 10241024; > > Shouldn't this be: s3->b = 10241024LL; ? irrelevant > > > return 0; > > } > > > > On my sparc machine it prints > > 1 4 8 8 > > for the offsets of the variables of different types. Note that gcc > > places long long and double on 64-bit boundaries. > > > > It then dies with SIGBUS when I trick it into trying to store a > > 64-bit quantity into storage which s 32-bit aligned but not 64-bit > > aligned. > > As expected. > > > Back to the code above that you posted: > > > > I think that it too needs to take into account alignment. It would > > need to round the size of each structure up to 64-bit alignmet before > > multiplying to ensure that objects of any type can live in that > > storage. This currently isn't causing problems because the size of > > each structure is consistent with 64-bit alignment (208 bytes for > > worker_score, 24 bytes for global_score, 16 bytes for process_score), > > at least in a 32-bit build for Sparc. > > Yes, I completely agree that each structure needs to be 64-bit aligned. > I don't see how the shared memory code itself is incorrect. It is incorrect because it is returning addresses that aren't 64-bit aligned. This code is in error: /* metadata isn't usable */ new_m->usable = (char *)new_m->base + sizeof(apr_size_t); given that new_m->usable is returned to the application as storage that it can use. My test program was intended to show a SIGBUS where it does the same thing that Apache is doing when it gets a SIGBUS. In my test program's case, I added 4 to the result of malloc() to get storage which wasn't aligned. In Apache's case, the code above to set new_m->usable is doing essentially the same thing (adding 4 to a properly-aligned value resulting in a storage address which is not properly aligned). -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 18:45:02 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 95400 invoked by uid 500); 1 Mar 2002 18:45:02 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 95331 invoked from network); 1 Mar 2002 18:45:00 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: justin28@example.net Cc: Aaron Bannert <justin28@example.net>, <justin28@example.net> Subject: Re: [PATCH] fix alignment on shared memory References: <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 13:42:12 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Cliff Woolley <justin28@example.net> writes: > On Fri, 1 Mar 2002, Aaron Bannert wrote: > > > Yes, I completely agree that each structure needs to be 64-bit aligned. > > I don't see how the shared memory code itself is incorrect. It must be > > mapping the segment at a properly aligned boundary, so as long as the > > contents of that segment are accessed in an aligned manner than we're > > safe, right? > > That's what I'm thinking, too. I don't see the problem there. It looks > to me like you (Aaron) were right on when you suggested that it's > ap_calc_scoreboard_size() and ap_init_scoreboard()'s fault. Try this, for > example: Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns addresses which aren't 64-bit aligned. That is broken. End of story. -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 18:45:30 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 96342 invoked by uid 500); 1 Mar 2002 18:45:30 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 96165 invoked from network); 1 Mar 2002 18:45:29 -0000 Date: Fri, 1 Mar 2002 10:45:32 -0800 From: Aaron Bannert <justin28@example.net> To: justin28@example.net Cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory Message-ID: <justin28@example.net> Mail-Followup-To: Aaron Bannert <justin28@example.net>, justin28@example.net, justin28@example.net References: <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> <justin28@example.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <justin28@example.net> User-Agent: Mutt/1.3.23i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, Mar 01, 2002 at 01:37:27PM -0500, Jeff Trawick wrote: > > Yes, I completely agree that each structure needs to be 64-bit aligned. > > I don't see how the shared memory code itself is incorrect. > > It is incorrect because it is returning addresses that aren't 64-bit > aligned. > > This code is in error: > > /* metadata isn't usable */ > new_m->usable = (char *)new_m->base + sizeof(apr_size_t); > > given that new_m->usable is returned to the application as storage > that it can use. > > My test program was intended to show a SIGBUS where it does the same > thing that Apache is doing when it gets a SIGBUS. In my test > program's case, I added 4 to the result of malloc() to get storage > which wasn't aligned. In Apache's case, the code above to set > new_m->usable is doing essentially the same thing (adding 4 to a > properly-aligned value resulting in a storage address which is not > properly aligned). Ah yes, I see what you mean now. Yes this is also a problem and should be aligned just like anything else. Can we put that alignment macro in a common place in APR, since it is not useful to apps and internals? -aaron From justin28@example.net Fri Mar 01 18:48:36 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 99474 invoked by uid 500); 1 Mar 2002 18:48:36 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 99329 invoked from network); 1 Mar 2002 18:48:35 -0000 Date: Fri, 1 Mar 2002 13:48:19 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: justin28@example.net cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 1 Mar 2002, Jeff Trawick wrote: > Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns > addresses which aren't 64-bit aligned. That is broken. End of story. Yeah, your last message cleared a lot up. Thanks. But I believe we're all right. Both things are broken. :) --Cliff -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA From justin28@example.net Fri Mar 01 18:57:13 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 9454 invoked by uid 500); 1 Mar 2002 18:57:13 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 9233 invoked from network); 1 Mar 2002 18:57:11 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: justin28@example.net Cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory References: <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 13:54:23 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 109 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Cliff Woolley <justin28@example.net> writes: > On 1 Mar 2002, Jeff Trawick wrote: > > > Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns > > addresses which aren't 64-bit aligned. That is broken. End of story. > > Yeah, your last message cleared a lot up. Thanks. But I believe we're > all right. Both things are broken. :) Hell, I already agreed that the calc-scoreboard-size stuff was theoretically bad (but not bad with the current structure layouts since we don't currently lose 64-bit alignment) :) Here is my latest patch. Somebody that understands shm.c needs to check it over and see if a seek() is needed before a mmap(). Also, as you suggest the align macro needs to be in an APR header file. Index: srclib/apr/shmem/unix/shm.c =================================================================== RCS file: /home/cvs/apr/shmem/unix/shm.c,v retrieving revision 1.14 diff -u -r1.14 shm.c --- srclib/apr/shmem/unix/shm.c 5 Feb 2002 04:32:52 -0000 1.14 +++ srclib/apr/shmem/unix/shm.c 1 Mar 2002 18:55:59 -0000 @@ -59,6 +59,12 @@ #include "apr_user.h" #include "apr_strings.h" +/* APR_ALIGN() is only to be used to align on a power of 2 boundary */ +#define APR_ALIGN(size, boundary) \ + (((size) + ((boundary) - 1)) & ~((boundary) - 1)) + +#define APR_ALIGN_DEFAULT(size) APR_ALIGN(size, 8) + static apr_status_t shm_cleanup_owner(void *m_) { apr_shm_t *m = (apr_shm_t *)m_; @@ -161,7 +167,8 @@ } new_m->pool = pool; new_m->reqsize = reqsize; - new_m->realsize = reqsize + sizeof(apr_size_t); /* room for metadata */ + new_m->realsize = reqsize + + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); /* room for metadata */ new_m->filename = NULL; #if APR_USE_SHMEM_MMAP_ZERO @@ -189,7 +196,7 @@ /* store the real size in the metadata */ *(apr_size_t*)(new_m->base) = new_m->realsize; /* metadata isn't usable */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, apr_pool_cleanup_null); @@ -206,7 +213,7 @@ /* store the real size in the metadata */ *(apr_size_t*)(new_m->base) = new_m->realsize; /* metadata isn't usable */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, apr_pool_cleanup_null); @@ -274,7 +281,8 @@ new_m->filename = apr_pstrdup(pool, filename); #if APR_USE_SHMEM_MMAP_TMP || APR_USE_SHMEM_MMAP_SHM - new_m->realsize = reqsize + sizeof(apr_size_t); /* room for metadata */ + new_m->realsize = reqsize + + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); /* room for metadata */ /* FIXME: Ignore error for now. * * status = apr_file_remove(file, pool);*/ status = APR_SUCCESS; @@ -345,7 +353,7 @@ /* store the real size in the metadata */ *(apr_size_t*)(new_m->base) = new_m->realsize; /* metadata isn't usable */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner, apr_pool_cleanup_null); @@ -482,6 +490,9 @@ return status; } + XXX use APR_ALIGN_DEFAULT() somewhere here? + XXX do we need to seek() prior to the mmap()? + nbytes = sizeof(new_m->realsize); status = apr_file_read(file, (void *)&(new_m->realsize), &nbytes); @@ -508,7 +519,7 @@ } /* metadata isn't part of the usable segment */ - new_m->usable = (char *)new_m->base + sizeof(apr_size_t); + new_m->usable = (char *)new_m->base + APR_ALIGN_DEFAULT(sizeof(apr_size_t)); apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_attach, apr_pool_cleanup_null); -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Fri Mar 01 19:00:32 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 13551 invoked by uid 500); 1 Mar 2002 19:00:32 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 13435 invoked from network); 1 Mar 2002 19:00:30 -0000 Date: Fri, 1 Mar 2002 14:00:15 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: justin28@example.net cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1887379643-877227168-1015009215=:16457" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to justin28@example.net for more info. ---1887379643-877227168-1015009215=:16457 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Mar 2002, Aaron Bannert wrote: > Can we put that alignment macro in a common place in APR, since it > is not useful to apps and internals? s/not/now/, right? :) Does this look right? (attached to avoid line wrapping) -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA ---1887379643-877227168-1015009215=:16457 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="scoreboard_size.patch" Content-Transfer-Encoding: BASE64 Content-ID: <justin28@example.net> Content-Description: Content-Disposition: attachment; filename="scoreboard_size.patch" SW5kZXg6IHNjb3JlYm9hcmQuYw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC9ob21lL2N2cy9odHRwZC0yLjAvc2VydmVyL3Njb3JlYm9h cmQuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNjANCmRpZmYgLXUgLWQg LXIxLjYwIHNjb3JlYm9hcmQuYw0KLS0tIHNjb3JlYm9hcmQuYyAgICAgICAg MjcgRmViIDIwMDIgMDQ6MTA6MTkgLTAwMDAgICAgICAxLjYwDQorKysgc2Nv cmVib2FyZC5jICAgICAgICAxIE1hciAyMDAyIDE4OjU5OjQyIC0wMDAwDQpA QCAtMTMyLDkgKzEzMiwxMSBAQA0KIHsNCiAgICAgYXBfbXBtX3F1ZXJ5KEFQ X01QTVFfSEFSRF9MSU1JVF9USFJFQURTLCAmdGhyZWFkX2xpbWl0KTsNCiAg ICAgYXBfbXBtX3F1ZXJ5KEFQX01QTVFfSEFSRF9MSU1JVF9EQUVNT05TLCAm c2VydmVyX2xpbWl0KTsNCi0gICAgc2NvcmVib2FyZF9zaXplID0gc2l6ZW9m KGdsb2JhbF9zY29yZSk7DQotICAgIHNjb3JlYm9hcmRfc2l6ZSArPSBzaXpl b2YocHJvY2Vzc19zY29yZSkgKiBzZXJ2ZXJfbGltaXQ7DQotICAgIHNjb3Jl Ym9hcmRfc2l6ZSArPSBzaXplb2Yod29ya2VyX3Njb3JlKSAqIHNlcnZlcl9s aW1pdCAqIHRocmVhZF9saW1pdDsNCisgICAgc2NvcmVib2FyZF9zaXplICA9 IEFQUl9BTElHTl9ERUZBVUxUKHNpemVvZihnbG9iYWxfc2NvcmUpKTsNCisg ICAgc2NvcmVib2FyZF9zaXplICs9IEFQUl9BTElHTl9ERUZBVUxUKHNpemVv Zihwcm9jZXNzX3Njb3JlKSkNCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKiBzZXJ2ZXJfbGltaXQ7DQorICAgIHNjb3JlYm9hcmRfc2l6ZSArPSBB UFJfQUxJR05fREVGQVVMVChzaXplb2Yod29ya2VyX3Njb3JlKSkNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKiBzZXJ2ZXJfbGltaXQgKiB0aHJl YWRfbGltaXQ7DQogICAgIHJldHVybiBzY29yZWJvYXJkX3NpemU7DQogfQ0K DQpAQCAtMTQ0LDE4ICsxNDYsMTkgQEANCiAgICAgaW50IGk7DQoNCiAgICAg YXBfY2FsY19zY29yZWJvYXJkX3NpemUoKTsNCi0gICAgYXBfc2NvcmVib2Fy ZF9pbWFnZSA9DQotICAgICAgICBjYWxsb2MoMSwgc2l6ZW9mKHNjb3JlYm9h cmQpICsgc2VydmVyX2xpbWl0ICogc2l6ZW9mKHdvcmtlcl9zY29yZSAqKSk7 DQorICAgIGFwX3Njb3JlYm9hcmRfaW1hZ2UgPSBjYWxsb2MoMSwgQVBSX0FM SUdOX0RFRkFVTFQoc2l6ZW9mKHNjb3JlYm9hcmQpKSArDQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VydmVyX2xpbWl0ICogc2l6 ZW9mKHdvcmtlcl9zY29yZSAqKSk7DQogICAgIG1vcmVfc3RvcmFnZSA9IHNo YXJlZF9zY29yZTsNCiAgICAgYXBfc2NvcmVib2FyZF9pbWFnZS0+Z2xvYmFs ID0gKGdsb2JhbF9zY29yZSAqKW1vcmVfc3RvcmFnZTsNCi0gICAgbW9yZV9z dG9yYWdlICs9IHNpemVvZihnbG9iYWxfc2NvcmUpOw0KKyAgICBtb3JlX3N0 b3JhZ2UgKz0gQVBSX0FMSUdOX0RFRkFVTFQoc2l6ZW9mKGdsb2JhbF9zY29y ZSkpOw0KICAgICBhcF9zY29yZWJvYXJkX2ltYWdlLT5wYXJlbnQgPSAocHJv Y2Vzc19zY29yZSAqKW1vcmVfc3RvcmFnZTsNCi0gICAgbW9yZV9zdG9yYWdl ICs9IHNpemVvZihwcm9jZXNzX3Njb3JlKSAqIHNlcnZlcl9saW1pdDsNCisg ICAgbW9yZV9zdG9yYWdlICs9IEFQUl9BTElHTl9ERUZBVUxUKHNpemVvZihw cm9jZXNzX3Njb3JlKSkgKiBzZXJ2ZXJfbGltaXQ7DQogICAgIGFwX3Njb3Jl Ym9hcmRfaW1hZ2UtPnNlcnZlcnMgPQ0KLSAgICAgICAgKHdvcmtlcl9zY29y ZSAqKikoKGNoYXIqKWFwX3Njb3JlYm9hcmRfaW1hZ2UgKyBzaXplb2Yoc2Nv cmVib2FyZCkpOw0KKyAgICAgICAgKHdvcmtlcl9zY29yZSAqKikoKGNoYXIq KWFwX3Njb3JlYm9hcmRfaW1hZ2UgKw0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgQVBSX0FMSUdOX0RFRkFVTFQoc2l6ZW9mKHNjb3JlYm9hcmQpKSk7 DQogICAgIGZvciAoaSA9IDA7IGkgPCBzZXJ2ZXJfbGltaXQ7IGkrKykgew0K ICAgICAgICAgYXBfc2NvcmVib2FyZF9pbWFnZS0+c2VydmVyc1tpXSA9ICh3 b3JrZXJfc2NvcmUgKiltb3JlX3N0b3JhZ2U7DQotICAgICAgICBtb3JlX3N0 b3JhZ2UgKz0gdGhyZWFkX2xpbWl0ICogc2l6ZW9mKHdvcmtlcl9zY29yZSk7 DQorICAgICAgICBtb3JlX3N0b3JhZ2UgKz0gdGhyZWFkX2xpbWl0ICogQVBS X0FMSUdOX0RFRkFVTFQoc2l6ZW9mKHdvcmtlcl9zY29yZSkpOw0KICAgICB9 DQogICAgIGFwX2Fzc2VydChtb3JlX3N0b3JhZ2UgPT0gKGNoYXIqKXNoYXJl ZF9zY29yZSArIHNjb3JlYm9hcmRfc2l6ZSk7DQogICAgIGFwX3Njb3JlYm9h cmRfaW1hZ2UtPmdsb2JhbC0+c2VydmVyX2xpbWl0ID0gc2VydmVyX2xpbWl0 Ow0KDQo= ---1887379643-877227168-1015009215=:16457-- From justin28@example.net Fri Mar 01 19:06:07 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 15883 invoked by uid 500); 1 Mar 2002 19:06:05 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 15859 invoked from network); 1 Mar 2002 19:06:04 -0000 Date: Fri, 1 Mar 2002 14:05:49 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: justin28@example.net cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 1 Mar 2002, Cliff Woolley wrote: > Does this look right? (attached to avoid line wrapping) Hmm, no, it doesn't. :-/ Scratch that. Back to the drawing board. --Cliff -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA From justin28@example.net Fri Mar 01 19:10:27 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 18014 invoked by uid 500); 1 Mar 2002 19:10:27 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 17738 invoked from network); 1 Mar 2002 19:10:25 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to justin28@example.net using -f Sender: justin28@example.net To: justin28@example.net Cc: justin28@example.net Subject: Re: [PATCH] fix alignment on shared memory References: <justin28@example.net> From: Jeff Trawick <justin28@example.net> Date: 01 Mar 2002 14:07:37 -0500 In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Cliff Woolley <justin28@example.net> writes: > On Fri, 1 Mar 2002, Aaron Bannert wrote: > > > Can we put that alignment macro in a common place in APR, since it > > is not useful to apps and internals? but where :) apr_lib.h? (duck) > Does this look right? (attached to avoid line wrapping) that is how I would have done it -- Jeff Trawick | justin28@example.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From justin28@example.net Sat Mar 02 04:19:04 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 81523 invoked by uid 500); 2 Mar 2002 04:19:03 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 81512 invoked from network); 2 Mar 2002 04:19:03 -0000 From: "Emery Berger" <justin28@example.net> To: "'Justin Erenkrantz'" <justin28@example.net>, "'Brian Pane'" <justin28@example.net> Cc: <justin28@example.net> Subject: RE: pools + ap_pfree Date: Fri, 1 Mar 2002 22:19:17 -0600 Message-ID: <001801c1c1a1$6ba9cc70$ef801942@ristretto> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <justin28@example.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N High-performance was indeed one of my design goals. What tests would you consider authoritative? I've been using static page loads, driven by a process on the same machine. This was the best way I found to really stress pool allocation. I'd be happy to run any other tests you could recommend. Thanks, -- Emery -- Emery Berger Dept. of Computer Science The University of Texas at Austin www.cs.utexas.edu/users/emery > -----Original Message----- > From: Justin Erenkrantz [mailto:justin28@example.net] > Sent: Friday, March 01, 2002 12:31 AM > To: Brian Pane > Cc: Emery Berger; justin28@example.net > Subject: Re: pools + ap_pfree > > On Thu, Feb 28, 2002 at 10:20:15PM -0800, Brian Pane wrote: > > We saw this with the SMS allocators last year. SMS had a great design: > > a family of interchangeable allocators with different memory management > > implementations, and an single, abstract interface to all of them so > that > > one could easily plug in the right type of allocator for a given app. > > The problem was that the httpd got measurably slower when the SMS > version > > of the simple pool allocator was used in place of the original apr_pool > > code. The reason was that the single extra function call indirection on > > each apr_palloc() (to support the polymorphic interface) was enough to > > negatively impact the performance. > > Yup, and on a tangential note, I'm hoping that this new bucket > freelist API won't have this problem that SMS had. But, in the > bucket case, we are currently using malloc()/free(), so introducing > any freelist should be an improvement. *crosses fingers* > > apr_pfree is a good idea in concept, but we have to measure the > performance impact carefully. > > Perhaps, this is 2.1 material? Certainly not 2.0 and definitely > not 1.3. -- justin From justin28@example.net Sat Mar 02 04:22:45 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 84120 invoked by uid 500); 2 Mar 2002 04:22:45 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 84103 invoked from network); 2 Mar 2002 04:22:44 -0000 Date: Fri, 1 Mar 2002 20:22:53 -0800 From: "'Justin Erenkrantz'" <justin28@example.net> To: Emery Berger <justin28@example.net> Cc: "'Brian Pane'" <justin28@example.net>, justin28@example.net Subject: Re: pools + ap_pfree Message-ID: <justin28@example.net> References: <justin28@example.net> <001801c1c1a1$6ba9cc70$ef801942@ristretto> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c1c1a1$6ba9cc70$ef801942@ristretto> User-Agent: Mutt/1.5.0i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, Mar 01, 2002 at 10:19:17PM -0600, Emery Berger wrote: > High-performance was indeed one of my design goals. What tests would you > consider authoritative? I've been using static page loads, driven by a > process on the same machine. This was the best way I found to really > stress pool allocation. I'd be happy to run any other tests you could > recommend. I believe that we found that mod_include (multiple #includes) or mod_autoindex request (lots of subreqs) really stress the pool code. I think Brian had one test case where ~30 pools were created and destroyed during that one mod_include'd request. -- justin From justin28@example.net Sat Mar 02 07:35:45 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 33092 invoked by uid 500); 2 Mar 2002 07:35:44 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 33081 invoked from network); 2 Mar 2002 07:35:44 -0000 Reply-To: <justin28@example.net> From: "Marc M. Adkins" <justin28@example.net> To: <justin28@example.net> Subject: Logging Date: Fri, 1 Mar 2002 23:40:15 -0800 Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Is there going to be any APR logging functionality? It seems a reasonable addition, and I'm somewhat surprised to not see it yet. Especially since Apache itself obviously does some amount of logging. It's been suggested to me that log4j would be a good set of functionality for this purpose. I took a look and it has a lot of the features that I've come to desire myself (and re-implemented over the years in various languages). Unfortunately the log4c port (of log4j) seems less than optimal. I would think that it could be done somewhat better, retaining more of the original log4j functionality, despite the lack of objects in C. If it's just a matter of finding someone with time and interest I might be willing to have a justin28@example.net. Or is there a reason why this isn't supposed to be a part of the APR? Marc M. Adkins From justin28@example.net Sat Mar 02 22:14:19 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 54822 invoked by uid 500); 2 Mar 2002 22:14:18 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 54811 invoked from network); 2 Mar 2002 22:14:18 -0000 Date: Sat, 02 Mar 2002 14:17:43 -0800 From: Brian Pane <justin28@example.net> Subject: Re: bucket api patch To: Cliff Woolley <justin28@example.net> Cc: justin28@example.net Message-id: <justin28@example.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 References: <{{EMAIL+PHONE}}> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I'm starting to look through the code in detail now, and one aspect of the API bothers me: How is apr_bucket_free() going to figure out which apr_bucket_alloc_t to return the block to? All it has as input is a pointer to a bucket, in void* form. Some of the bucket types contain an apr_bucket_alloc_t*, but not all of them. --Brian Cliff Woolley wrote: >Well, it's not finished yet, but it's something you can look at if you >like. http://icarus.apache.org/~jwoolley/ . > >Things missing: > >(a) calls to apr_bucket_alloc_create() and _destroy() at strategic >locations within the MPMs. I'm hoping that's something one of you guys >can help me with, since I haven't exactly spent a lot of time in the MPMs >lately. > >(b) the actually allocator itself -- right now, it's a wrapper around >malloc() and free() (which is why we can get away without (a) at the >moment) -- this part will fall easily into place as soon as Sander's pool >API change is done. He and I talked about that today and it seems a >perfect fit for the job. > >I've tested the patch as it is right now to compile and run and pass >httpd-test, but more eyes looking for stupid mistakes in largely >uninteresting but widespread changes would be much appreciated. > >Thanks, >Cliff > >-------------------------------------------------------------- > Cliff Woolley > justin28@example.net > Charlottesville, VA > > > From justin28@example.net Sat Mar 02 22:55:14 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 63858 invoked by uid 500); 2 Mar 2002 22:55:13 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 63847 invoked from network); 2 Mar 2002 22:55:13 -0000 Date: Sat, 2 Mar 2002 17:54:39 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: Brian Pane <justin28@example.net> cc: justin28@example.net Subject: Re: bucket api patch In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 2 Mar 2002, Brian Pane wrote: > I'm starting to look through the code in detail now, and one > aspect of the API bothers me: > > How is apr_bucket_free() going to figure out which apr_bucket_alloc_t > to return the block to? All it has as input is a pointer to a > bucket, in void* form. Some of the bucket types contain an > apr_bucket_alloc_t*, but not all of them. apr_bucket_free() knows nothing about buckets, so ignore the fact that a bucket contains an apr_bucket_alloc_t* (see below). The block allocated by apr_bucket_alloc() will have internal information stored immediately prior to (or following?) the location returned from apr_bucket_alloc. In other words, apr_bucket_alloc will over-allocate so that it has a few bytes for its own purposes. You and I had talked about that a while back and agreed that that seemed a reasonable way to handle the problem. The reason for the apr_bucket_alloc_t* in some bucket types is so that apr_bucket_foo_make() can know which allocator to use when the new bucket type needs to allocate storage for private bucket-type-specific structures (eg struct apr_bucket_file). But *all* bucket types should have this pointer... did I miss one? --Cliff -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA From justin28@example.net Sat Mar 02 23:02:22 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 65766 invoked by uid 500); 2 Mar 2002 23:02:21 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 65755 invoked from network); 2 Mar 2002 23:02:21 -0000 Date: Sat, 02 Mar 2002 15:06:07 -0800 From: Brian Pane <justin28@example.net> Subject: Re: bucket api patch To: Cliff Woolley <justin28@example.net> Cc: justin28@example.net Message-id: <justin28@example.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 References: <justin28@example.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Cliff Woolley wrote: >On Sat, 2 Mar 2002, Brian Pane wrote: > >>I'm starting to look through the code in detail now, and one >>aspect of the API bothers me: >> >>How is apr_bucket_free() going to figure out which apr_bucket_alloc_t >>to return the block to? All it has as input is a pointer to a >>bucket, in void* form. Some of the bucket types contain an >>apr_bucket_alloc_t*, but not all of them. >> > >apr_bucket_free() knows nothing about buckets, so ignore the fact that a >bucket contains an apr_bucket_alloc_t* (see below). The block allocated >by apr_bucket_alloc() will have internal information stored immediately >prior to (or following?) the location returned from apr_bucket_alloc. In >other words, apr_bucket_alloc will over-allocate so that it has a few >bytes for its own purposes. You and I had talked about that a while back >and agreed that that seemed a reasonable way to handle the problem. > Cool, I'd forgotten about storing the metadata stored right in front of the block returned by apr_bucket_alloc(); that will solve the problem very cleanly. >The reason for the apr_bucket_alloc_t* in some bucket types is so that >apr_bucket_foo_make() can know which allocator to use when the new bucket >type needs to allocate storage for private bucket-type-specific structures >(eg struct apr_bucket_file). But *all* bucket types should have this >pointer... did I miss one? > apr_bucket_heap and ap_bucket_error, I think --Brian From justin28@example.net Sat Mar 02 23:06:17 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 66337 invoked by uid 500); 2 Mar 2002 23:06:16 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 66326 invoked from network); 2 Mar 2002 23:06:16 -0000 Date: Sat, 2 Mar 2002 18:05:54 -0500 (EST) From: Cliff Woolley <justin28@example.net> X-X-Sender: justin28@example.net To: Brian Pane <justin28@example.net> cc: justin28@example.net Subject: Re: bucket api patch In-Reply-To: <justin28@example.net> Message-ID: <justin28@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 2 Mar 2002, Brian Pane wrote: > apr_bucket_heap and ap_bucket_error, I think Hmmm.. I'll go check it out. Thanks for the review. :) --Cliff -------------------------------------------------------------- Cliff Woolley justin28@example.net Charlottesville, VA From justin28@example.net Sat Mar 02 23:08:13 2002 Return-Path: <justin28@example.net> Delivered-To: justin28@example.net Received: (qmail 66859 invoked by uid 500); 2 Mar 2002 23:08:13 -0000 Mailing-List: contact justin28@example.net; run by ezmlm Precedence: bulk List-Post: <mailto:justin28@example.net> List-Help: <mailto:justin28@example.net> List-Unsubscribe: <mailto:justin28@example.net> List-Subscribe: <mailto:justin28@example.net> Delivered-To: mailing list justin28@example.net Received: (qmail 66848 invoked from network); 2 Mar 2002 23:08:13 -0000 Date: Sat, 02 Mar 2002 15:11:57 -0800 From: Brian Pane <justin28@example.net> Subject: update for bucket api patch To: justin28@example.net Message-id: <justin28@example.net> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GGRN46TX2G7foQD8ddWk/A)" X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 References: <{{EMAIL+PHONE}}> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --Boundary_(ID_GGRN46TX2G7foQD8ddWk/A) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I had to add an allocator as an argument to SPLIT_AND_PASS_PRETAG_BUCKETS to get mod_include and mod_cgi to work (a patch against current CVS head is attached) --Brian --Boundary_(ID_GGRN46TX2G7foQD8ddWk/A) Content-type: text/plain; name=include_alloc_patch.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=include_alloc_patch.txt Index: modules/filters/mod_include.h =================================================================== RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.h,v retrieving revision 1.29 diff -u -r1.29 mod_include.h --- modules/filters/mod_include.h 23 Feb 2002 20:56:36 -0000 1.29 +++ modules/filters/mod_include.h 2 Mar 2002 23:06:41 -0000 @@ -189,7 +189,8 @@ { \ /* XXX: it'd probably be nice to use a pool bucket here */ \ t_buck = apr_bucket_heap_create(cntx->error_str, \ - strlen(cntx->error_str), 1); \ + strlen(cntx->error_str), \ + 1, h_ptr->list); \ APR_BUCKET_INSERT_BEFORE(h_ptr, t_buck); \ \ if (ins_head == NULL) { \ @@ -201,14 +202,14 @@ * than APR_SUCCESS, then you should return this value up the * call chain. */ -#define SPLIT_AND_PASS_PRETAG_BUCKETS(brgd, cntxt, next, rc) \ +#define SPLIT_AND_PASS_PRETAG_BUCKETS(brgd, cntxt, next, rc, alloc) \ if ((APR_BRIGADE_EMPTY(cntxt->ssi_tag_brigade)) && \ (cntxt->head_start_bucket != NULL)) { \ apr_bucket_brigade *tag_plus; \ \ tag_plus = apr_brigade_split(brgd, cntxt->head_start_bucket); \ if (cntxt->output_flush) { \
{'source': 'Apache Software Foundation Public Mail Archives'}