On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote:
Nicholas Clark wrote:
I can only reproduce this on one instance of one test, but on that test
it can be reproduced every time.
In your previous messages I couldn't spot whether you said which test.
Is there some quick way
Nicholas Clark wrote:
On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote:
Nicholas Clark wrote:
I can only reproduce this on one instance of one test, but on that test
it can be reproduced every time.
In your previous messages I couldn't spot whether you said which test.
Nicholas Clark wrote:
On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote:
Nicholas Clark wrote:
I can only reproduce this on one instance of one test, but on that test
it can be reproduced every time.
As of [EMAIL PROTECTED], I can not reproduce the corruption anymore.
On Sat, Aug 20, 2005 at 05:25:02PM -0400, John E. Malmberg wrote:
Nicholas Clark wrote:
On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote:
Nicholas Clark wrote:
I can only reproduce this on one instance of one test, but on that test
it can be reproduced every time.
As
Nicholas Clark wrote:
On Sat, Aug 20, 2005 at 05:25:02PM -0400, John E. Malmberg wrote:
Bah.
If you still have the build tree for the version that reliably shows it,
what happens if you apply just patch 25297 to it, and recompile:
No, it is gone.
I'm wondering if it was something about
Sorry about the delay in replying. I've had a lot on, and wanted to find
the time to confirm my suspicions.
On Sat, Jul 30, 2005 at 09:50:40PM -0400, John E. Malmberg wrote:
What I have found is that in this case is that the allocation size for
the sv_u.svu_array member appears to be too
Nicholas Clark wrote:
Sorry about the delay in replying. I've had a lot on, and wanted to find
the time to confirm my suspicions.
On Sat, Jul 30, 2005 at 09:50:40PM -0400, John E. Malmberg wrote:
What I have found is that in this case is that the allocation size for
the sv_u.svu_array member
