Am 09.07.2014 03:18, schrieb David Turner:
On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:
On 3 July 2014 23:55, Øyvind A. Holm <sunny@xxxxxxxxxxx> wrote:
When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
(64-bit), t5150-request-pull.sh fails when compiling with
$ make configure
$ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
$ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
$ cd t
$ ./t5150-request-pull.sh
FYI, t5150-request-pull.sh passes all tests now on newest master
(v2.0.1-474-g72c7794) in Debian. There are two new commits on master
since I wrote this, and the commit that makes things work again is
4602f1a ("diff-tree: call free_commit_list() instead of duplicating
its code"). Reverting this commit brings the failure back.
The whole thing is still a mystery to me, though. I can't see why this
should have anything to do with the use of ./configure --prefix.
The problem only happens when a ref with an allowed wildcard winds up on
a page boundary (with the wildcard before the page boundary). This
depends intricately on the details of memory allocation, so pretty much
anything could make it come and go.
Does the fix I posted work for you? If not, let me know and I'll look
into it more.
Sounds fragile overall. How could a test program look like? All I can
think of is a brute force check of all combinations of three characters
(is that enough?), PAGE_SIZE offsets, three flags, with and without
".lock" appended (and embedded?) against the old implementation, which
must be quite expensive.
Some callers of check_refname_format() know the length of the string or
can determine it cheaply because they copy the whole string anyway.
Would it make sense to do away with the page boundary magic and require
the callers of the fast version to pass that length? The tailing bytes
(up to 15) would have to be loaded carefully, though. Not sure.
René
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html