On Feb 22, 2008, at 5:21 PM, Ruediger Pluem wrote:
On 02/22/2008 07:40 PM, William A. Rowe, Jr. wrote:
Joe Orton wrote:
CC'ing [EMAIL PROTECTED] since the code in question is in APR.
On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group
wrote:
On Feb 22, 2008, at 9:27 AM,
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Sonntag, 24. Februar 2008 18:11
An: dev@httpd.apache.org
Cc: APR Developer List
Betreff: Re: httpd 2.2.8 segfaults
On Sun, 24 Feb 2008, Ruediger Pluem wrote:
It seems to work after fixing the
APR_SIZE_MAX
On Sat, 23 Feb 2008, Ruediger Pluem wrote:
I'm still not liking the casts and the mixed -1's, APR_SIZE_MAX and
MAX_APR_SIZE_T...
In any case, I'll be busy for most of this weekend so I probably won't have
time to try patches until monday...
Thats fine. Looking forward to your test results.
On 02/24/2008 03:16 PM, Niklas Edmundsson wrote:
On Sat, 23 Feb 2008, Ruediger Pluem wrote:
I'm still not liking the casts and the mixed -1's, APR_SIZE_MAX and
MAX_APR_SIZE_T...
In any case, I'll be busy for most of this weekend so I probably
won't have time to try patches until monday...
On Sun, 24 Feb 2008, Ruediger Pluem wrote:
It seems to work after fixing the APR_SIZE_MAX/MAX_APR_SIZE_T thing, this
is (still) httpd-2.2.8 on Ubuntu 32bit LFS-enabled.
Just for clarification: The crashes are gone with this patch?
Then I would commit to apr-util trunk.
I can't reproduce
On Fri, 22 Feb 2008, Plüm, Rüdiger, VF-Group wrote:
| type (address)| length | data addr
---
0 | FILE (0x0815db00) | 16777216 | 0x0815daa8
1 | FILE (0x0815db58) | 16777216 | 0x0815daa8
snip
265 | FILE (0x081699f8) |
On Fri, 22 Feb 2008, Plüm, Rüdiger, VF-Group wrote:
In general, that patch looks truly suspicious since it seems to me
it's typecasting wildly and not even using its newly invented
MAX_APR_SIZE_T in all places, because (apr_size_t)(-1)
really is the
same thing, right?
No, MAX_APR_SIZE_T and
On 02/23/2008 09:46 AM, Niklas Edmundsson wrote:
On Fri, 22 Feb 2008, Plüm, Rüdiger, VF-Group wrote:
| type (address)| length | data addr
---
0 | FILE (0x0815db00) | 16777216 | 0x0815daa8
1 | FILE (0x0815db58) | 16777216
On 02/23/2008 09:54 AM, Niklas Edmundsson wrote:
I'm still not liking the casts and the mixed -1's, APR_SIZE_MAX and
MAX_APR_SIZE_T...
In any case, I'll be busy for most of this weekend so I probably won't
have time to try patches until monday...
Thats fine. Looking forward to your
On Thu, 21 Feb 2008, Ruediger Pluem wrote:
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this
thing. All coredumps I've looked at have been when serving DVD images,
which of
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Freitag, 22. Februar 2008 11:04
An: dev@httpd.apache.org
Betreff: Re: httpd 2.2.8 segfaults
On Thu, 21 Feb 2008, Ruediger Pluem wrote:
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008
On Fri, 22 Feb 2008, Plüm, Rüdiger, VF-Group wrote:
In general, that patch looks truly suspicious since it seems to me
it's typecasting wildly and not even using its newly invented
MAX_APR_SIZE_T in all places, because (apr_size_t)(-1) really is the
same thing, right?
No, MAX_APR_SIZE_T and
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Freitag, 22. Februar 2008 13:45
An: dev@httpd.apache.org
Betreff: Re: httpd 2.2.8 segfaults
On Fri, 22 Feb 2008, Plüm, Rüdiger, VF-Group wrote:
In general, that patch looks truly suspicious since it seems to me
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Donnerstag, 21. Februar 2008 22:10
An: dev@httpd.apache.org
Betreff: Re: httpd 2.2.8 segfaults
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to
reproduce
On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Try to reduce the following casting mess: We know that point
will be
+ * larger equal 0 now and forever and thus that point
(apr_off_t) and
+ * apr_size_t will fit into apr_uint64_t in any case.
+ */
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Freitag, 22. Februar 2008 17:41
An: dev@httpd.apache.org
Betreff: Re: httpd 2.2.8 segfaults
On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Try to reduce the following casting mess: We
CC'ing [EMAIL PROTECTED] since the code in question is in APR.
On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Try to reduce the following casting mess: We know that point will
be
+
Joe Orton wrote:
CC'ing [EMAIL PROTECTED] since the code in question is in APR.
On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Try to reduce the following casting mess: We know that point
On 02/22/2008 07:40 PM, William A. Rowe, Jr. wrote:
Joe Orton wrote:
CC'ing [EMAIL PROTECTED] since the code in question is in APR.
On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Try to
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this thing.
All coredumps I've looked at have been when serving DVD images, which of
course works flawlessly when I try it...
OK, I've been able to reproduce this, and it looks
On Thu, Feb 21, 2008 at 1:09 PM, Niklas Edmundsson [EMAIL PROTECTED] wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this
thing.
All coredumps I've looked at have been when serving DVD images, which of
course works
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this
thing. All coredumps I've looked at have been when serving DVD images,
which of course works flawlessly when I try it...
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this
thing. All coredumps I've looked at have been when serving DVD images,
which of course works flawlessly when I try it...
On 02/21/2008 10:33 PM, Ruediger Pluem wrote:
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce
this thing. All coredumps I've looked at have been when serving DVD
images, which
On 02/21/2008 10:33 PM, Ruediger Pluem wrote:
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce
this thing. All coredumps I've looked at have been when serving DVD
images, which
On Thu, 21 Feb 2008, Ruediger Pluem wrote:
Quick, maybe completely stupid question as I suspect the problem in
apr_brigade_partition:
Quick answer before I go to bed :)
I always thought that apr_off_t and apr_size_t are *always* of the
same size and that the only difference between them is
On 02/21/2008 11:59 PM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
I always thought that apr_off_t and apr_size_t are *always* of the
same size and that the
only difference between them is that apr_size_t is unsigned whereas
apr_off_t is signed.
Is this thought correct?
NO NO NO
Ruediger Pluem wrote:
I always thought that apr_off_t and apr_size_t are *always* of the same
size and that the
only difference between them is that apr_size_t is unsigned whereas
apr_off_t is signed.
Is this thought correct?
NO NO NO no no.
off_t represents an index to storage (io
28 matches
Mail list logo
