On 09/22/06 16:32, Philip Martin wrote:
> The first time the breakpoint is reached it's from the
> svn_test__create_fs line, the second time it's from the
> svn_fs_open_berkeley line. The key has the same value in each case,
> and the second time that value is present in the cache, so the hash
> l
Troy Heber <[EMAIL PROTECTED]> writes:
> It's not an optimization bug, compiling O0 does not help. We know that
> lt-fs-base-test 2, creates and closes a new db, it then creates a new
> fs object and tries to re-open the db. The call to apr_hash_get
> returns NULL, so it's not finding the object i
On 09/22/06 00:04, Philip Martin wrote:
> The error message is the one that would occur if Subversion's DB_ENV
> cache failed in some way, and since most of the tests are being run
> with FSFS the failing test might be the only one that exercises the
> cache. Perhaps gcc is miscompiling Subversion
The error message is the one that would occur if Subversion's DB_ENV
cache failed in some way, and since most of the tests are being run
with FSFS the failing test might be the only one that exercises the
cache. Perhaps gcc is miscompiling Subversion's cache code; how about
building without optimi
Package: subversion
Version: 1.4.0-1
Severity: serious
Tags: help
subversion 1.4.0 FTBFS on ia64 with the appended error. I don't
understand the code in question at all, either on the subversion side
or on the libdb4.4 side. I particularly don't understand why an error
of this nature would only
5 matches
Mail list logo
