threads / discuss / 37054

t5150-request-pull.sh fails on newest master in Debian

Subject: t5150-request-pull.sh fails on newest master in Debian

## tl;dr

14 messages between Jul 3, 2014 and Jul 9, 2014.

replies: 13people: 3as markdown or json

Øyvind A. Holm· Jul 3, 2014, 21:55 UTC · lore

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 $ make $ cd t $ ./t5150-request-pull.sh

I have attached the output of t5150-request-pull.sh, but in case the attachment doesn't go through, I've also pasted it at <https://gist.github.com/sunny256/0f6ff7ffee26224dbe12>. This happened on two virtual servers (64 bit) hosted on Linode, with this configuration:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.5 (wheezy)
Release:        7.5
Codename:       wheezy

$ gcc --version gcc (Debian 4.7.2-5) 4.7.2

Both servers are (of course) updated with new packages from apt-get.

The test worked on my laptop which runs Ubuntu Studio 13.10. Have tried recompiling several times, and it fails on Debian every time.

git bisect says the bad commit is 6f92e5ff3 ("Merge branch 'dt/refs-check-refname-component-sse", 2014-07-02 12:53:07 -0700), but that's a merge. Both parent commits works, so could this be an evil merge?

When compiling parent commit 745224e test 6 is disabled, could that be the reason?

Parent commit a02ad88 passes all 7 tests.

Cheers, Øyvind

*** t5150-request-pull.sh *** not ok 1 - setup # # # git init --bare upstream.git && # git init --bare downstream.git && # git clone upstream.git upstream-private && # git clone downstream.git local && # # trash_url="file://$TRASH_DIRECTORY" && # downstream_url="$trash_url/downstream.git/" && # upstream_url="$trash_url/upstream.git/" && # # ( # cd upstream-private && # cat <<-\EOT >mnemonic.txt && # Thirtey days hath November, # Aprile, June, and September: # EOT # git add mnemonic.txt && # test_tick && # git commit -m "\"Thirty days\", a reminder of month lengths" && # git tag -m "version 1" -a initial && # git push --tags origin master # ) && # ( # cd local && # git remote add upstream "$trash_url/upstream.git" && # git fetch upstream && # git pull upstream master && # cat <<-\EOT >>mnemonic.txt && # Of twyecescore-eightt is but eine, # And all the remnante be thrycescore-eine. # O’course Leap yare comes an’pynes, # Ev’rie foure yares, gote it ryghth. # An’twyecescore-eight is but twyecescore-nyne. # EOT # git add mnemonic.txt && # test_tick && # git commit -m "More detail" && # git tag -m "version 2" -a full && # git checkout -b simplify HEAD^ && # mv mnemonic.txt mnemonic.standard && # cat <<-\EOT >mnemonic.clarified && # Thirty days has September, # All the rest I can’t remember. # EOT # git add -N mnemonic.standard mnemonic.clarified && # git commit -a -m "Adapt to use modern, simpler English # # But keep the old version, too, in case some people prefer it." && # git checkout master # ) # # ok 2 - setup: two scripts for reading pull requests not ok 3 - pull request when forgot to push # # # rm -fr downstream.git && # git init --bare downstream.git && # ( # cd local && # git checkout initial && # git merge --ff-only master && # test_must_fail git request-pull initial "$downstream_url" \ # 2>../err # ) && # grep "No match for commit .*" err && # grep "Are you sure you pushed" err # # not ok 4 - pull request after push # # # rm -fr downstream.git && # git init --bare downstream.git && # ( # cd local && # git checkout initial && # git merge --ff-only master && # git push origin master:for-upstream && # git request-pull initial origin master:for-upstream >../request # ) && # sed -nf read-request.sed <request >digest && # cat digest && # { # read task && # read repository && # read branch # } <digest && # ( # cd upstream-private && # git checkout initial && # git pull --ff-only "$repository" "$branch" # ) && # test "$branch" = for-upstream && # test_cmp local/mnemonic.txt upstream-private/mnemonic.txt # # not ok 5 - request asks HEAD to be pulled # # # rm -fr downstream.git && # git init --bare downstream.git && # ( # cd local && # git checkout initial && # git merge --ff-only master && # git push --tags origin master simplify && # git push origin master:for-upstream && # git request-pull initial "$downstream_url" >../request # ) && # sed -nf read-request.sed <request >digest && # cat digest && # { # read task && # read repository && # read branch # } <digest && # test -z "$branch" # # not ok 6 - pull request format # # # rm -fr downstream.git && # git init --bare downstream.git && # cat <<-\EOT >expect && # The following changes since commit OBJECT_NAME: # # SUBJECT (DATE) # # are available in the git repository at: # # URL BRANCH # # for you to fetch changes up to OBJECT_NAME: # # SUBJECT (DATE) # # ---------------------------------------------------------------- # VERSION # # ---------------------------------------------------------------- # SHORTLOG # # DIFFSTAT # EOT # ( # cd local && # git checkout initial && # git merge --ff-only master && # git push origin tags/full && # git request-pull initial "$downstream_url" tags/full >../request # ) && # <request sed -nf fuzz.sed >request.fuzzy && # test_i18ncmp expect request.fuzzy && # # ( # cd local && # git request-pull initial "$downstream_url" tags/full:refs/tags/full # ) >request && # sed -nf fuzz.sed <request >request.fuzzy && # test_i18ncmp expect request.fuzzy && # # ( # cd local && # git request-pull initial "$downstream_url" full # ) >request && # grep " tags/full\$" request # not ok 7 - request-pull ignores OPTIONS_KEEPDASHDASH poison # # # ( # cd local && # OPTIONS_KEEPDASHDASH=Yes && # export OPTIONS_KEEPDASHDASH && # git checkout initial && # git merge --ff-only master && # git push origin master:for-upstream && # git request-pull -- initial "$downstream_url" master:for-upstream >../request # ) # # # failed 6 among 7 test(s) 1..7 make[2]: *** [t5150-request-pull.sh] Error 1 make[2]: Leaving directory `/home/sunny/src/other/git/build-git/t' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/sunny/src/other/git/build-git/t' make: *** [test] Error 2

David Turner· Jul 3, 2014, 22:16 UTC · re: Øyvind A. Holm · lore

Re: t5150-request-pull.sh fails on newest master in Debian

Interesting! I wonder if the problem is with the compiler or with my code. I don't happen to have a Debian box handy; would it be possible for you to compile refs.c to assembly language (gcc -S) and send me the output? That would help me track down the problem.

On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:
Show 43 quoted lines
> 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
> $ make
> $ cd t
> $ ./t5150-request-pull.sh
> 
> I have attached the output of t5150-request-pull.sh, but in case the
> attachment doesn't go through, I've also pasted it at
> <https://gist.github.com/sunny256/0f6ff7ffee26224dbe12>. This happened
> on two virtual servers (64 bit) hosted on Linode, with this
> configuration:
> 
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:    Debian GNU/Linux 7.5 (wheezy)
> Release:        7.5
> Codename:       wheezy
> 
> $ gcc --version
> gcc (Debian 4.7.2-5) 4.7.2
> 
> Both servers are (of course) updated with new packages from apt-get.
> 
> The test worked on my laptop which runs Ubuntu Studio 13.10. Have tried
> recompiling several times, and it fails on Debian every time.
> 
> git bisect says the bad commit is 6f92e5ff3 ("Merge branch
> 'dt/refs-check-refname-component-sse", 2014-07-02 12:53:07 -0700), but
> that's a merge. Both parent commits works, so could this be an evil
> merge?
> 
> When compiling parent commit 745224e test 6 is disabled, could that be
> the reason?
> 
> Parent commit a02ad88 passes all 7 tests.
> 
> Cheers,
> Øyvind
Øyvind A. Holm· Jul 3, 2014, 22:19 UTC · re: Øyvind A. Holm · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On 3 July 2014 23:55, Øyvind A. Holm <sunny@sunbase.org> wrote:
Show 9 quoted lines
> 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
> $ make
> $ cd t
> $ ./t5150-request-pull.sh
That's a copy+paste error, ignore the second make. :-P

Cheers, Øyvind

David Turner· Jul 4, 2014, 20:22 UTC · re: Øyvind A. Holm · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:
Show 9 quoted lines
> 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
> $ make
> $ cd t
> $ ./t5150-request-pull.sh

Are you sure you're not running under valgrind? I can reproduce the test failures when I run under valgrind because I didn't add the right stuff to the suppression files (patch to follow).

I also just went ahead and got a Linode running Debian 7.5 (64-bit), and I still can't reproduce the problem. Do you have any additional reproduction info that I need here?

Øyvind A. Holm· Jul 5, 2014, 00:09 UTC · re: David Turner · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On 4 July 2014 22:22, David Turner <dturner@twopensource.com> wrote:
Show 15 quoted lines
> On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm 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
> > $ make
> > $ cd t
> > $ ./t5150-request-pull.sh
>
> Are you sure you're not running under valgrind? I can reproduce the
> test failures when I run under valgrind because I didn't add the right
> stuff to the suppression files (patch to follow).

Nope, no valgrind involved here, it's not even installed on those two servers. The two server setups differ quite much, one of them I use for all kind of things, the other is a dedicated web server with not much else except Apache and some essential stuff I can't live without installed.

> I also just went ahead and got a Linode running Debian 7.5 (64-bit),
> and I still can't reproduce the problem.
Now that's what I call commitment. :)
> Do you have any additional reproduction info that I need here?

I build new gits pretty much every time Junio pushes new stuff to kernel.org, and I'm using this script which takes care of everything:

  https://github.com/sunny256/utils/blob/master/build-git
I have a README at
  https://github.com/sunny256/utils/blob/master/README.build-git.md

where I have listed all packages I install from apt-get before I build the thing. The script I used to test with git bisect is at

  https://github.com/sunny256/utils/blob/testfail.t5150-fail-g6f92e5f/testfail
, it simulates what the "build-git" script does.

The test works if I run a plain "make" using the standard Makefile without ./configure .

Hm, interesting. When I don't use --prefix as mentioned above, just a
  $ make configure
  $ ./configure
  $ make
  $ cd t
  $ ./t5150-request-pull.sh

The test works. Seems as there's something fishy about the use of --prefix in this specific commit (v2.0.1-472-g6f92e5f).

I'll dig more into this thing now to see what's going on.

Сенсорно Ваш, Øyvind

David Turner· Jul 5, 2014, 01:58 UTC · re: Øyvind A. Holm · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote: <snip>

> The test works. Seems as there's something fishy about the use of
> --prefix in this specific commit (v2.0.1-472-g6f92e5f).

Ok, now I can reproduce on my linode box (haven't tried it locally yet). I'll try to get a fix up once I figure out what's up.

Thanks for the report.
Øyvind A. Holm· Jul 5, 2014, 14:24 UTC · re: David Turner · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On 5 July 2014 03:58, David Turner <dturner@twopensource.com> wrote:
Show 7 quoted lines
> On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote:
> <snip>
> > The test works. Seems as there's something fishy about the use of
> > --prefix in this specific commit (v2.0.1-472-g6f92e5f).
>
> Ok, now I can reproduce on my linode box (haven't tried it locally
> yet). I'll try to get a fix up once I figure out what's up.

Awesome. I've done some more "./configure --prefix" testing, and this is the result:

  # --prefix is set to non-existing directory
  ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
    # ./t5150-request-pull.sh fails.
  # --prefix is set to non-existing directory, use trailing slash
  ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f/
    # ./t5150-request-pull.sh fails.
  # --prefix is set to existing directory
  ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-442-g7fe6834
    # ./t5150-request-pull.sh fails.
  # --prefix is set to existing directory
  ./configure --prefix=/usr/local
    # ./t5150-request-pull.sh succeeds.
  # --prefix is set to existing directory
  ./configure --prefix=/usr/local/varprg
    # ./t5150-request-pull.sh succeeds.
  # --prefix is set to non-existing directory
  ./configure --prefix=/usr/local/varprg/a-long-directory-name-which-does-not-exist
    # ./t5150-request-pull.sh succeeds.
  ./configure --prefix=/usr/local/varprg/git.master.a-long-directory-name-which-does-not-exist
    # ./t5150-request-pull.sh succeeds.

So it's something with names like "git.master.v2.0.1-472-g6f92e5f" that "./configure --prefix" is picky about.

When testing this last night, I pushed the following branches to <https://github.com/sunny256/git> where I added all compiled files in various stages with "git add -f .":

  t5150-fail.configure-without-prefix
    Succeeds.
    "./configure"
  t5150-fail.configure-with-prefix
    Fails.
    "./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f"
  t5150-fail.configure-prefix-usr-local
    Succeeds.
    "./configure --prefix=/usr/local"

Maybe something will turn up by diffing those branches. I've got to leave for now, but will have a look at this later tonight.

Cheers, Øyvind

David Turner· Jul 5, 2014, 19:00 UTC · re: Øyvind A. Holm · lore

[PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page

When a ref crosses a memory page boundary, we restart the parsing at the beginning with the bytewise code. Pass the original flags to that code, rather than the current flags.

Signed-off-by: David Turner <dturner@twitter.com>
---
 refs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 20e2bf1..82e4842 100644
--- a/refs.c
+++ b/refs.c
@@ -153,6 +153,7 @@ int check_refname_format(const char *refname, int flags)
 	const __m128i tilde_lb = _mm_set1_epi8('~' - 1);
 
 	int component_count = 0;
+	int orig_flags = flags;
 
 	if (refname[0] == 0 || refname[0] == '/') {
 		/* entirely empty ref or initial ref component */
@@ -178,7 +179,7 @@ int check_refname_format(const char *refname, int flags)
 			 * End-of-page; fall back to slow method for
 			 * this entire ref.
 			 */
-			return check_refname_format_bytewise(refname, flags);
+			return check_refname_format_bytewise(refname, orig_flags);
 
 		tmp = _mm_loadu_si128((__m128i *)cp);
 		tmp1 = _mm_loadu_si128((__m128i *)(cp + 1));
-- 
2.0.0.390.gcb682f8
Øyvind A. Holm· Jul 9, 2014, 00:52 UTC · re: Øyvind A. Holm · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On 3 July 2014 23:55, Øyvind A. Holm <sunny@sunbase.org> wrote:
Show 8 quoted lines
> 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. I tested several variants with and without ./configure --prefix, all tests were run several times and were reproducible every time. Was this --prefix thing just a red herring, or is it linked to this in some way?

Also, the only file this commit touches is builtin/diff-tree.c, and this file hasn't been modified since 2011. Does anyone know what's going on here?

Cheers, Øyvind

David Turner· Jul 9, 2014, 01:18 UTC · re: Øyvind A. Holm · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:
Show 18 quoted lines
> On 3 July 2014 23:55, Øyvind A. Holm <sunny@sunbase.org> 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.

Øyvind A. Holm· Jul 9, 2014, 11:44 UTC · re: David Turner · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On 9 July 2014 03:18, David Turner <dturner@twopensource.com> wrote:
Show 20 quoted lines
> On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:
> > On 3 July 2014 23:55, Øyvind A. Holm <sunny@sunbase.org> wrote:
> > > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
> > > (64-bit), t5150-request-pull.sh fails when compiling with
> > > [snip]
> >
> > 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.

Aha, that makes sense. Sheer luck that the results were that consistent during testing, then.

> Does the fix I posted work for you?  If not, let me know and I'll look
> into it more.

Sorry, didn't notice you posted that to the list. Today I learned that Gmail doesn't put mails adressed to me and the list in the inbox. :(

The commit fixed it, yes. Thanks for the patch. It now works on both Debian servers. Have run all tests on one of the servers, and will repeat on other machines, too.

Thanks, Øyvind

René Scharfe· Jul 9, 2014, 14:52 UTC · re: David Turner · lore

Re: t5150-request-pull.sh fails on newest master in Debian

Am 09.07.2014 03:18, schrieb David Turner:
Show 27 quoted lines
> On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:
>> On 3 July 2014 23:55, Øyvind A. Holm <sunny@sunbase.org> 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é
Øyvind A. Holm· Jul 3, 2014, 23:02 UTC · lore

Re: t5150-request-pull.sh fails on newest master in Debian

On 4 July 2014 00:34, Øyvind A. Holm <sunny@sunbase.org> wrote:
Show 12 quoted lines
> On 4 July 2014 00:16, David Turner <dturner@twopensource.com> wrote:
> > On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:
> > > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
> > > (64-bit), t5150-request-pull.sh fails when compiling with
> > > [...]
> >
> > Interesting!  I wonder if the problem is with the compiler or with
> > my code.  I don't happen to have a Debian box handy; would it be
> > possible for you to compile refs.c to assembly language (gcc -S) and
> > send me the output?  That would help me track down the problem.
> >
> Sure! I have attached refs.s from v2.0.1-472-g6f92e5f .

If someone else is interested in the assembly output, it's available from <http://sunbase.org/t5150-fail/refs.s.gz>. Didn't send it to the list, it's 128KB.

Cheers again, Øyvind

Øyvind A. Holm· Jul 9, 2014, 11:48 UTC · lore

Re: [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page

On 7 July 2014 20:05, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> David Turner <dturner@twopensource.com> writes:
> > When a ref crosses a memory page boundary, we restart the parsing at
> > the beginning with the bytewise code.  Pass the original flags to
> > that code, rather than the current flags.
>
> Good.

I've run the whole test suite with this patch applied, and it fixes the problem on 64-bit Debian 7.5.

> I probably should add:
>     Reported-by: Øyvind A. Holm <sunny@sunbase.org>
>
> before your sign-off.
Thanks. :)

Cheers, Øyvind

← back to recent threads