Joe Schaefer <[EMAIL PROTECTED]> writes:
> Markus Wichitill <[EMAIL PROTECTED]> writes:
[...]
>> Doesn't fix the original problem for me either.
>
> Thanks. What's troubling me though is that while both you and Ville
> are seeing the leak, you're not reporting consistent behavior with
> the tempfile creation. So although we know it's the prefetch code
> that's gobbling up memory (since calling discard_request_body fixes
> the leak), I really don't know where to look for it.
WAG #2: please test (yeah or nay) with this patch. This fixes at least
one corner case bug, but I don't know if it plugs your leak as well.
Index: library/util.c
===================================================================
--- library/util.c (revision 171027)
+++ library/util.c (working copy)
@@ -1091,7 +1091,7 @@
#define BUCKET_IS_SPOOL(e) ((e)->type == &spool_bucket_type)
-#define FILE_BUCKET_LIMIT ((apr_size_t)-1 - 1)
+#define FILE_BUCKET_LIMIT (1024 * 1024 * 1024) /* 1 GB for simplicity */
static
void spool_bucket_destroy(void *data)
@@ -1171,14 +1171,14 @@
return s;
/* This cast, when out_len = -1, is intentional */
- if ((apr_uint64_t)out_len < heap_limit) {
+ if ((apr_size_t)out_len < heap_limit) {
s = apr_brigade_length(in, 0, &in_len);
if (s != APR_SUCCESS)
return s;
/* This cast, when in_len = -1, is intentional */
- if ((apr_uint64_t)in_len < heap_limit - (apr_uint64_t)out_len) {
+ if ((apr_size_t)in_len < heap_limit - (apr_size_t)out_len) {
APR_BRIGADE_CONCAT(out, in);
return APR_SUCCESS;
}
@@ -1229,7 +1229,7 @@
* temp_file bucket.
*/
- while ((apr_uint64_t)wlen > FILE_BUCKET_LIMIT - last_out->length) {
+ while ((apr_size_t)wlen > FILE_BUCKET_LIMIT - last_out->length) {
apr_bucket *e;
apr_bucket_copy(last_out, &e);
@@ -1238,6 +1238,7 @@
wlen -= FILE_BUCKET_LIMIT - last_out->length;
last_out->length = FILE_BUCKET_LIMIT;
last_out->type = &apr_bucket_type_file;
+ e->type = &spool_bucket_type;
APR_BRIGADE_INSERT_TAIL(out, e);
last_out = e;
--
Joe Schaefer
