All of lore.kernel.org
 help / color / mirror / Atom feed
* t5150-request-pull.sh fails on newest master in Debian
@ 2014-07-03 21:55 Øyvind A. Holm
  2014-07-03 22:16 ` David Turner
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-03 21:55 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

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

[-- Attachment #2: t5150-output.txt --]
[-- Type: text/plain, Size: 7312 bytes --]

*** 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-03 21:55 t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
@ 2014-07-03 22:16 ` David Turner
       [not found]   ` <CAA787rmroFsjk9=ar0e_4o3hUpfDBi+9J4nrNyHHMZq-5q4skw@mail.gmail.com>
  2014-07-03 22:19 ` Øyvind A. Holm
  2014-07-04 20:22 ` David Turner
  2 siblings, 1 reply; 14+ messages in thread
From: David Turner @ 2014-07-03 22:16 UTC (permalink / raw)
  To: Øyvind A. Holm; +Cc: git

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:
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-03 21:55 t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
  2014-07-03 22:16 ` David Turner
@ 2014-07-03 22:19 ` Øyvind A. Holm
  2014-07-04 20:22 ` David Turner
  2 siblings, 0 replies; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-03 22:19 UTC (permalink / raw)
  To: git, Junio C Hamano

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

That's a copy+paste error, ignore the second make. :-P

Cheers,
Øyvind

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
       [not found]   ` <CAA787rmroFsjk9=ar0e_4o3hUpfDBi+9J4nrNyHHMZq-5q4skw@mail.gmail.com>
@ 2014-07-03 23:02     ` Øyvind A. Holm
  0 siblings, 0 replies; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-03 23:02 UTC (permalink / raw)
  To: git

On 4 July 2014 00:34, Øyvind A. Holm <sunny@sunbase.org> wrote:
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-03 21:55 t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
  2014-07-03 22:16 ` David Turner
  2014-07-03 22:19 ` Øyvind A. Holm
@ 2014-07-04 20:22 ` David Turner
  2014-07-05  0:09   ` Øyvind A. Holm
  2 siblings, 1 reply; 14+ messages in thread
From: David Turner @ 2014-07-04 20:22 UTC (permalink / raw)
  To: Øyvind A. Holm; +Cc: git

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).  

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?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-04 20:22 ` David Turner
@ 2014-07-05  0:09   ` Øyvind A. Holm
  2014-07-05  1:58     ` David Turner
  0 siblings, 1 reply; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-05  0:09 UTC (permalink / raw)
  To: David Turner; +Cc: git

On 4 July 2014 22:22, 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
> >
> > $ 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-05  0:09   ` Øyvind A. Holm
@ 2014-07-05  1:58     ` David Turner
  2014-07-05 14:24       ` Øyvind A. Holm
  0 siblings, 1 reply; 14+ messages in thread
From: David Turner @ 2014-07-05  1:58 UTC (permalink / raw)
  To: Øyvind A. Holm; +Cc: git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-05  1:58     ` David Turner
@ 2014-07-05 14:24       ` Øyvind A. Holm
  2014-07-05 19:00         ` [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page David Turner
  2014-07-09  0:52         ` t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
  0 siblings, 2 replies; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-05 14:24 UTC (permalink / raw)
  To: David Turner; +Cc: git

On 5 July 2014 03:58, David Turner <dturner@twopensource.com> wrote:
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page
  2014-07-05 14:24       ` Øyvind A. Holm
@ 2014-07-05 19:00         ` David Turner
       [not found]           ` <xmqq7g3pdoy7.fsf@gitster.dls.corp.google.com>
  2014-07-09  0:52         ` t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
  1 sibling, 1 reply; 14+ messages in thread
From: David Turner @ 2014-07-05 19:00 UTC (permalink / raw)
  To: git, Øyvind A . Holm; +Cc: David Turner

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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-05 14:24       ` Øyvind A. Holm
  2014-07-05 19:00         ` [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page David Turner
@ 2014-07-09  0:52         ` Øyvind A. Holm
  2014-07-09  1:18           ` David Turner
  1 sibling, 1 reply; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-09  0:52 UTC (permalink / raw)
  To: David Turner, René Scharfe; +Cc: git

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. 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-09  0:52         ` t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
@ 2014-07-09  1:18           ` David Turner
  2014-07-09 11:44             ` Øyvind A. Holm
  2014-07-09 14:52             ` René Scharfe
  0 siblings, 2 replies; 14+ messages in thread
From: David Turner @ 2014-07-09  1:18 UTC (permalink / raw)
  To: Øyvind A. Holm; +Cc: René Scharfe, git

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-09  1:18           ` David Turner
@ 2014-07-09 11:44             ` Øyvind A. Holm
  2014-07-09 14:52             ` René Scharfe
  1 sibling, 0 replies; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-09 11:44 UTC (permalink / raw)
  To: David Turner; +Cc: git

On 9 July 2014 03:18, David Turner <dturner@twopensource.com> wrote:
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page
       [not found]           ` <xmqq7g3pdoy7.fsf@gitster.dls.corp.google.com>
@ 2014-07-09 11:48             ` Øyvind A. Holm
  0 siblings, 0 replies; 14+ messages in thread
From: Øyvind A. Holm @ 2014-07-09 11:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: David Turner, git, David Turner

On 7 July 2014 20:05, Junio C Hamano <gitster@pobox.com> wrote:
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: t5150-request-pull.sh fails on newest master in Debian
  2014-07-09  1:18           ` David Turner
  2014-07-09 11:44             ` Øyvind A. Holm
@ 2014-07-09 14:52             ` René Scharfe
  1 sibling, 0 replies; 14+ messages in thread
From: René Scharfe @ 2014-07-09 14:52 UTC (permalink / raw)
  To: David Turner; +Cc: "Øyvind \"A. Holm\"", git

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@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é

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-07-09 14:52 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-03 21:55 t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
2014-07-03 22:16 ` David Turner
     [not found]   ` <CAA787rmroFsjk9=ar0e_4o3hUpfDBi+9J4nrNyHHMZq-5q4skw@mail.gmail.com>
2014-07-03 23:02     ` Øyvind A. Holm
2014-07-03 22:19 ` Øyvind A. Holm
2014-07-04 20:22 ` David Turner
2014-07-05  0:09   ` Øyvind A. Holm
2014-07-05  1:58     ` David Turner
2014-07-05 14:24       ` Øyvind A. Holm
2014-07-05 19:00         ` [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page David Turner
     [not found]           ` <xmqq7g3pdoy7.fsf@gitster.dls.corp.google.com>
2014-07-09 11:48             ` Øyvind A. Holm
2014-07-09  0:52         ` t5150-request-pull.sh fails on newest master in Debian Øyvind A. Holm
2014-07-09  1:18           ` David Turner
2014-07-09 11:44             ` Øyvind A. Holm
2014-07-09 14:52             ` René Scharfe

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.