You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2001/12/17 12:36:46 UTC

The smoking gun? was: make check failing on log_tests.py

"Sander Striker" <st...@apache.org> writes:

> Ofcourse we tried to reproduce this behaviour (wanting to rule out the
> pools bug).  I failed, Justin succeeded.

Revision 631 passes the log tests, revision 632 fails. Now this may be
coincidence, it is possible that the memory overwrite is just moving
around and also exists in rev 631. However rev 632 says

> Log:
> Part III of the New Commit System - the conversion of ra_local.  More
> to follow.

so it certainly affects the code that is failing.

-- 
Philip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The smoking gun? was: make check failing on log_tests.py

Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> > Err, the latest apr (with new pools) doesn't play nice with the test
> > code before rev 647 of subversion.  You should be seeing segfaults,
> > just like cmpilato had before he fixed subversions pools.
> > Or are you using an old apr against the earlier revisions?
> 
> No, I am using apr checked out on Dec 16 at about 22:48 GMT in all
> tests, and it doesn't segfault. When I run log_tests.py with rev 632
> it makes three commits successfully and fails with "out of date" on
> the fourth, just like rev 652. When run with rev 631 log_tests.py
> completes successfully.

Philip, could Mike's soon-to-be-committed fixes for
svn_fs_created_rev() be related to this?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The smoking gun? was: make check failing on log_tests.py

Posted by Philip Martin <ph...@codematters.co.uk>.
"Sander Striker" <st...@apache.org> writes:

> Err, the latest apr (with new pools) doesn't play nice with the test
> code before rev 647 of subversion.  You should be seeing segfaults,
> just like cmpilato had before he fixed subversions pools.
> Or are you using an old apr against the earlier revisions?

No, I am using apr checked out on Dec 16 at about 22:48 GMT in all
tests, and it doesn't segfault. When I run log_tests.py with rev 632
it makes three commits successfully and fails with "out of date" on
the fourth, just like rev 652. When run with rev 631 log_tests.py
completes successfully.

-- 
Philip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: The smoking gun? was: make check failing on log_tests.py

Posted by Sander Striker <st...@apache.org>.
> From: Philip Martin [mailto:philip@codematters.co.uk]
> Sent: 17 December 2001 13:37

> "Sander Striker" <st...@apache.org> writes:
> 
> > Ofcourse we tried to reproduce this behaviour (wanting to rule out the
> > pools bug).  I failed, Justin succeeded.
> 
> Revision 631 passes the log tests, revision 632 fails. Now this may be
> coincidence, it is possible that the memory overwrite is just moving
> around and also exists in rev 631. However rev 632 says
> 
> > Log:
> > Part III of the New Commit System - the conversion of ra_local.  More
> > to follow.
> 
> so it certainly affects the code that is failing.

Err, the latest apr (with new pools) doesn't play nice with the test
code before rev 647 of subversion.  You should be seeing segfaults,
just like cmpilato had before he fixed subversions pools.
Or are you using an old apr against the earlier revisions?
 
> -- 
> Philip

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org