{"thread":{"id":"37054","subject":"t5150-request-pull.sh fails on newest master in Debian","startedAt":"2014-07-03T21:55:27Z","lastAt":"2014-07-09T14:52:00Z","messageCount":14,"participants":["Øyvind A. Holm","David Turner","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"245392","messageId":"CAA787r=78UWio3E==s+J2PbVqshQdWXpS9hiJrmNz+F0vLiuGg@mail.gmail.com","threadId":"37054","inReplyTo":null,"subject":"t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-03T21:55:27Z","receivedAt":"2014-07-03T21:55:27Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n(64-bit), t5150-request-pull.sh fails when compiling with\n\n$ make configure\n$ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n$ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n$ make\n$ cd t\n$ ./t5150-request-pull.sh\n\nI have attached the output of t5150-request-pull.sh, but in case the\nattachment doesn't go through, I've also pasted it at\n. This happened\non two virtual servers (64 bit) hosted on Linode, with this\nconfiguration:\n\n$ lsb_release -a\nNo LSB modules are available.\nDistributor ID: Debian\nDescription: Debian GNU/Linux 7.5 (wheezy)\nRelease: 7.5\nCodename: wheezy\n\n$ gcc --version\ngcc (Debian 4.7.2-5) 4.7.2\n\nBoth servers are (of course) updated with new packages from apt-get.\n\nThe test worked on my laptop which runs Ubuntu Studio 13.10. Have tried\nrecompiling several times, and it fails on Debian every time.\n\ngit bisect says the bad commit is 6f92e5ff3 (\"Merge branch\n'dt/refs-check-refname-component-sse\", 2014-07-02 12:53:07 -0700), but\nthat's a merge. Both parent commits works, so could this be an evil\nmerge?\n\nWhen compiling parent commit 745224e test 6 is disabled, could that be\nthe reason?\n\nParent commit a02ad88 passes all 7 tests.\n\nCheers,\nØyvind\n\n\n*** t5150-request-pull.sh ***\nnot ok 1 - setup\n#\n#\n# git init --bare upstream.git &&\n# git init --bare downstream.git &&\n# git clone upstream.git upstream-private &&\n# git clone downstream.git local &&\n#\n# trash_url=\"file://$TRASH_DIRECTORY\" &&\n# downstream_url=\"$trash_url/downstream.git/\" &&\n# upstream_url=\"$trash_url/upstream.git/\" &&\n#\n# (\n# cd upstream-private &&\n# cat <<-\\EOT >mnemonic.txt &&\n# Thirtey days hath November,\n# Aprile, June, and September:\n# EOT\n# git add mnemonic.txt &&\n# test_tick &&\n# git commit -m \"\\\"Thirty days\\\", a reminder of month lengths\" &&\n# git tag -m \"version 1\" -a initial &&\n# git push --tags origin master\n# ) &&\n# (\n# cd local &&\n# git remote add upstream \"$trash_url/upstream.git\" &&\n# git fetch upstream &&\n# git pull upstream master &&\n# cat <<-\\EOT >>mnemonic.txt &&\n# Of twyecescore-eightt is but eine,\n# And all the remnante be thrycescore-eine.\n# O’course Leap yare comes an’pynes,\n# Ev’rie foure yares, gote it ryghth.\n# An’twyecescore-eight is but twyecescore-nyne.\n# EOT\n# git add mnemonic.txt &&\n# test_tick &&\n# git commit -m \"More detail\" &&\n# git tag -m \"version 2\" -a full &&\n# git checkout -b simplify HEAD^ &&\n# mv mnemonic.txt mnemonic.standard &&\n# cat <<-\\EOT >mnemonic.clarified &&\n# Thirty days has September,\n# All the rest I can’t remember.\n# EOT\n# git add -N mnemonic.standard mnemonic.clarified &&\n# git commit -a -m \"Adapt to use modern, simpler English\n#\n# But keep the old version, too, in case some people prefer it.\" &&\n# git checkout master\n# )\n#\n#\nok 2 - setup: two scripts for reading pull requests\nnot ok 3 - pull request when forgot to push\n#\n#\n# rm -fr downstream.git &&\n# git init --bare downstream.git &&\n# (\n# cd local &&\n# git checkout initial &&\n# git merge --ff-only master &&\n# test_must_fail git request-pull initial \"$downstream_url\" \\\n# 2>../err\n# ) &&\n# grep \"No match for commit .*\" err &&\n# grep \"Are you sure you pushed\" err\n#\n#\nnot ok 4 - pull request after push\n#\n#\n# rm -fr downstream.git &&\n# git init --bare downstream.git &&\n# (\n# cd local &&\n# git checkout initial &&\n# git merge --ff-only master &&\n# git push origin master:for-upstream &&\n# git request-pull initial origin master:for-upstream >../request\n# ) &&\n# sed -nf read-request.sed digest &&\n# cat digest &&\n# {\n# read task &&\n# read repository &&\n# read branch\n# } ../request\n# ) &&\n# sed -nf read-request.sed digest &&\n# cat digest &&\n# {\n# read task &&\n# read repository &&\n# read branch\n# } expect &&\n# The following changes since commit OBJECT_NAME:\n#\n# SUBJECT (DATE)\n#\n# are available in the git repository at:\n#\n# URL BRANCH\n#\n# for you to fetch changes up to OBJECT_NAME:\n#\n# SUBJECT (DATE)\n#\n# ----------------------------------------------------------------\n# VERSION\n#\n# ----------------------------------------------------------------\n# SHORTLOG\n#\n# DIFFSTAT\n# EOT\n# (\n# cd local &&\n# git checkout initial &&\n# git merge --ff-only master &&\n# git push origin tags/full &&\n# git request-pull initial \"$downstream_url\" tags/full >../request\n# ) &&\n# request.fuzzy &&\n# test_i18ncmp expect request.fuzzy &&\n#\n# (\n# cd local &&\n# git request-pull initial \"$downstream_url\" tags/full:refs/tags/full\n# ) >request &&\n# sed -nf fuzz.sed request.fuzzy &&\n# test_i18ncmp expect request.fuzzy &&\n#\n# (\n# cd local &&\n# git request-pull initial \"$downstream_url\" full\n# ) >request &&\n# grep \" tags/full\\$\" request\n#\nnot ok 7 - request-pull ignores OPTIONS_KEEPDASHDASH poison\n#\n#\n# (\n# cd local &&\n# OPTIONS_KEEPDASHDASH=Yes &&\n# export OPTIONS_KEEPDASHDASH &&\n# git checkout initial &&\n# git merge --ff-only master &&\n# git push origin master:for-upstream &&\n# git request-pull -- initial \"$downstream_url\" master:for-upstream >../request\n# )\n#\n#\n# failed 6 among 7 test(s)\n1..7\nmake[2]: *** [t5150-request-pull.sh] Error 1\nmake[2]: Leaving directory `/home/sunny/src/other/git/build-git/t'\nmake[1]: *** [test] Error 2\nmake[1]: Leaving directory `/home/sunny/src/other/git/build-git/t'\nmake: *** [test] Error 2\n"},{"id":"245393","messageId":"1404425782.3109.12.camel@stross","threadId":"37054","inReplyTo":"CAA787r=78UWio3E==s+J2PbVqshQdWXpS9hiJrmNz+F0vLiuGg@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-07-03T22:16:22Z","receivedAt":"2014-07-03T22:16:22Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"Interesting! I wonder if the problem is with the compiler or with my\ncode. I don't happen to have a Debian box handy; would it be possible\nfor you to compile refs.c to assembly language (gcc -S) and send me the\noutput? That would help me track down the problem.\n\nOn Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:\n> When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> (64-bit), t5150-request-pull.sh fails when compiling with\n> \n> $ make configure\n> $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make\n> $ cd t\n> $ ./t5150-request-pull.sh\n> \n> I have attached the output of t5150-request-pull.sh, but in case the\n> attachment doesn't go through, I've also pasted it at\n> . This happened\n> on two virtual servers (64 bit) hosted on Linode, with this\n> configuration:\n> \n> $ lsb_release -a\n> No LSB modules are available.\n> Distributor ID: Debian\n> Description: Debian GNU/Linux 7.5 (wheezy)\n> Release: 7.5\n> Codename: wheezy\n> \n> $ gcc --version\n> gcc (Debian 4.7.2-5) 4.7.2\n> \n> Both servers are (of course) updated with new packages from apt-get.\n> \n> The test worked on my laptop which runs Ubuntu Studio 13.10. Have tried\n> recompiling several times, and it fails on Debian every time.\n> \n> git bisect says the bad commit is 6f92e5ff3 (\"Merge branch\n> 'dt/refs-check-refname-component-sse\", 2014-07-02 12:53:07 -0700), but\n> that's a merge. Both parent commits works, so could this be an evil\n> merge?\n> \n> When compiling parent commit 745224e test 6 is disabled, could that be\n> the reason?\n> \n> Parent commit a02ad88 passes all 7 tests.\n> \n> Cheers,\n> Øyvind\n"},{"id":"245394","messageId":"CAA787rm6Q_r-kec+37YF28hBL0Z6nfgtvgfvhvTYGycbajUEiA@mail.gmail.com","threadId":"37054","inReplyTo":"CAA787r=78UWio3E==s+J2PbVqshQdWXpS9hiJrmNz+F0vLiuGg@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-03T22:19:41Z","receivedAt":"2014-07-03T22:19:41Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 3 July 2014 23:55, Øyvind A. Holm wrote:\n> When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> (64-bit), t5150-request-pull.sh fails when compiling with\n>\n> $ make configure\n> $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make\n> $ cd t\n> $ ./t5150-request-pull.sh\n\nThat's a copy+paste error, ignore the second make. :-P\n\nCheers,\nØyvind\n"},{"id":"245400","messageId":"CAA787rkrZ8o=oN3VmvwLR89KfjAY95qwjJdMbbUUM4+fYfQdow@mail.gmail.com","threadId":"37054","inReplyTo":"CAA787rmroFsjk9=ar0e_4o3hUpfDBi+9J4nrNyHHMZq-5q4skw@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-03T23:02:14Z","receivedAt":"2014-07-03T23:02:14Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 4 July 2014 00:34, Øyvind A. Holm wrote:\n> On 4 July 2014 00:16, David Turner wrote:\n> > On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:\n> > > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> > > (64-bit), t5150-request-pull.sh fails when compiling with\n> > > [...]\n> >\n> > Interesting! I wonder if the problem is with the compiler or with\n> > my code. I don't happen to have a Debian box handy; would it be\n> > possible for you to compile refs.c to assembly language (gcc -S) and\n> > send me the output? That would help me track down the problem.\n> >\n> Sure! I have attached refs.s from v2.0.1-472-g6f92e5f .\n\nIf someone else is interested in the assembly output, it's available\nfrom . Didn't send it to the\nlist, it's 128KB.\n\nCheers again,\nØyvind\n"},{"id":"245410","messageId":"1404505370.3109.15.camel@stross","threadId":"37054","inReplyTo":"CAA787r=78UWio3E==s+J2PbVqshQdWXpS9hiJrmNz+F0vLiuGg@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-07-04T20:22:50Z","receivedAt":"2014-07-04T20:22:50Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:\n> When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> (64-bit), t5150-request-pull.sh fails when compiling with\n> \n> $ make configure\n> $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make\n> $ cd t\n> $ ./t5150-request-pull.sh\n\nAre you sure you're not running under valgrind? I can reproduce the test\nfailures when I run under valgrind because I didn't add the right stuff\nto the suppression files (patch to follow). \n\nI also just went ahead and got a Linode running Debian 7.5 (64-bit), and\nI still can't reproduce the problem. Do you have any additional\nreproduction info that I need here?\n"},{"id":"245421","messageId":"CAA787rmf36V1=Sd8TZrc7DboTkeJDYKuEGgCe90mZLLKSp6=tw@mail.gmail.com","threadId":"37054","inReplyTo":"1404505370.3109.15.camel@stross","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-05T00:09:57Z","receivedAt":"2014-07-05T00:09:57Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 4 July 2014 22:22, David Turner wrote:\n> On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:\n> > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> > (64-bit), t5150-request-pull.sh fails when compiling with\n> >\n> > $ make configure\n> > $ ./configure\n> > --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> > $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> > $ make\n> > $ cd t\n> > $ ./t5150-request-pull.sh\n>\n> Are you sure you're not running under valgrind? I can reproduce the\n> test failures when I run under valgrind because I didn't add the right\n> stuff to the suppression files (patch to follow).\n\nNope, no valgrind involved here, it's not even installed on those two\nservers. The two server setups differ quite much, one of them I use for\nall kind of things, the other is a dedicated web server with not much\nelse except Apache and some essential stuff I can't live without\ninstalled.\n\n> I also just went ahead and got a Linode running Debian 7.5 (64-bit),\n> and I still can't reproduce the problem.\n\nNow that's what I call commitment. :)\n\n> Do you have any additional reproduction info that I need here?\n\nI build new gits pretty much every time Junio pushes new stuff to\nkernel.org, and I'm using this script which takes care of everything:\n\n https://github.com/sunny256/utils/blob/master/build-git\n\nI have a README at\n\n https://github.com/sunny256/utils/blob/master/README.build-git.md\n\nwhere I have listed all packages I install from apt-get before I build\nthe thing. The script I used to test with git bisect is at\n\n https://github.com/sunny256/utils/blob/testfail.t5150-fail-g6f92e5f/testfail\n\n, it simulates what the \"build-git\" script does.\n\nThe test works if I run a plain \"make\" using the standard Makefile\nwithout ./configure .\n\nHm, interesting. When I don't use --prefix as mentioned above, just a\n\n $ make configure\n $ ./configure\n $ make\n $ cd t\n $ ./t5150-request-pull.sh\n\nThe test works. Seems as there's something fishy about the use of\n--prefix in this specific commit (v2.0.1-472-g6f92e5f).\n\nI'll dig more into this thing now to see what's going on.\n\nСенсорно Ваш,\nØyvind\n"},{"id":"245422","messageId":"1404525502.3109.25.camel@stross","threadId":"37054","inReplyTo":"CAA787rmf36V1=Sd8TZrc7DboTkeJDYKuEGgCe90mZLLKSp6=tw@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-07-05T01:58:22Z","receivedAt":"2014-07-05T01:58:22Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote:\n\n> The test works. Seems as there's something fishy about the use of\n> --prefix in this specific commit (v2.0.1-472-g6f92e5f).\n\nOk, now I can reproduce on my linode box (haven't tried it locally yet).\nI'll try to get a fix up once I figure out what's up.\n\nThanks for the report.\n"},{"id":"245425","messageId":"CAA787rnMonCuON+C0U5FDXKzjTBdpOusCpGLeWytDWaA1torEw@mail.gmail.com","threadId":"37054","inReplyTo":"1404525502.3109.25.camel@stross","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-05T14:24:52Z","receivedAt":"2014-07-05T14:24:52Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 5 July 2014 03:58, David Turner wrote:\n> On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote:\n> \n> > The test works. Seems as there's something fishy about the use of\n> > --prefix in this specific commit (v2.0.1-472-g6f92e5f).\n>\n> Ok, now I can reproduce on my linode box (haven't tried it locally\n> yet). I'll try to get a fix up once I figure out what's up.\n\nAwesome. I've done some more \"./configure --prefix\" testing, and this is\nthe result:\n\n # --prefix is set to non-existing directory\n ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n # ./t5150-request-pull.sh fails.\n\n # --prefix is set to non-existing directory, use trailing slash\n ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f/\n # ./t5150-request-pull.sh fails.\n\n # --prefix is set to existing directory\n ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-442-g7fe6834\n # ./t5150-request-pull.sh fails.\n\n # --prefix is set to existing directory\n ./configure --prefix=/usr/local\n # ./t5150-request-pull.sh succeeds.\n\n # --prefix is set to existing directory\n ./configure --prefix=/usr/local/varprg\n # ./t5150-request-pull.sh succeeds.\n\n # --prefix is set to non-existing directory\n ./configure --prefix=/usr/local/varprg/a-long-directory-name-which-does-not-exist\n # ./t5150-request-pull.sh succeeds.\n\n ./configure --prefix=/usr/local/varprg/git.master.a-long-directory-name-which-does-not-exist\n # ./t5150-request-pull.sh succeeds.\n\nSo it's something with names like \"git.master.v2.0.1-472-g6f92e5f\" that\n\"./configure --prefix\" is picky about.\n\nWhen testing this last night, I pushed the following branches to\n where I added all compiled files in\nvarious stages with \"git add -f .\":\n\n t5150-fail.configure-without-prefix\n Succeeds.\n \"./configure\"\n\n t5150-fail.configure-with-prefix\n Fails.\n \"./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\"\n\n t5150-fail.configure-prefix-usr-local\n Succeeds.\n \"./configure --prefix=/usr/local\"\n\nMaybe something will turn up by diffing those branches. I've got to\nleave for now, but will have a look at this later tonight.\n\nCheers,\nØyvind\n"},{"id":"245427","messageId":"1404586859-24464-1-git-send-email-dturner@twitter.com","threadId":"37054","inReplyTo":"CAA787rnMonCuON+C0U5FDXKzjTBdpOusCpGLeWytDWaA1torEw@mail.gmail.com","subject":"[PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-07-05T19:00:59Z","receivedAt":"2014-07-05T19:00:59Z","isPatch":true,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"When a ref crosses a memory page boundary, we restart the parsing\nat the beginning with the bytewise code. Pass the original flags\nto that code, rather than the current flags.\n\nSigned-off-by: David Turner \n---\n refs.c | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/refs.c b/refs.c\nindex 20e2bf1..82e4842 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -153,6 +153,7 @@ int check_refname_format(const char *refname, int flags)\n \tconst __m128i tilde_lb = _mm_set1_epi8('~' - 1);\n \n \tint component_count = 0;\n+\tint orig_flags = flags;\n \n \tif (refname[0] == 0 || refname[0] == '/') {\n \t\t/* entirely empty ref or initial ref component */\n@@ -178,7 +179,7 @@ int check_refname_format(const char *refname, int flags)\n \t\t\t * End-of-page; fall back to slow method for\n \t\t\t * this entire ref.\n \t\t\t */\n-\t\t\treturn check_refname_format_bytewise(refname, flags);\n+\t\t\treturn check_refname_format_bytewise(refname, orig_flags);\n \n \t\ttmp = _mm_loadu_si128((__m128i *)cp);\n \t\ttmp1 = _mm_loadu_si128((__m128i *)(cp + 1));\n-- \n2.0.0.390.gcb682f8\n"},{"id":"245562","messageId":"CAA787r=Q5B7R1sxiVhRgobPHHPro6D5YyqVO+P_MZC=aGa+ZHw@mail.gmail.com","threadId":"37054","inReplyTo":"CAA787rnMonCuON+C0U5FDXKzjTBdpOusCpGLeWytDWaA1torEw@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-09T00:52:49Z","receivedAt":"2014-07-09T00:52:49Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 3 July 2014 23:55, Øyvind A. Holm wrote:\n> When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> (64-bit), t5150-request-pull.sh fails when compiling with\n>\n> $ make configure\n> $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> $ cd t\n> $ ./t5150-request-pull.sh\n\nFYI, t5150-request-pull.sh passes all tests now on newest master\n(v2.0.1-474-g72c7794) in Debian. There are two new commits on master\nsince I wrote this, and the commit that makes things work again is\n4602f1a (\"diff-tree: call free_commit_list() instead of duplicating\nits code\"). Reverting this commit brings the failure back.\n\nThe whole thing is still a mystery to me, though. I can't see why this\nshould have anything to do with the use of ./configure --prefix. I\ntested several variants with and without ./configure --prefix, all\ntests were run several times and were reproducible every time. Was\nthis --prefix thing just a red herring, or is it linked to this in\nsome way?\n\nAlso, the only file this commit touches is builtin/diff-tree.c, and\nthis file hasn't been modified since 2011. Does anyone know what's\ngoing on here?\n\nCheers,\nØyvind\n"},{"id":"245563","messageId":"1404868702.3775.2.camel@stross","threadId":"37054","inReplyTo":"CAA787r=Q5B7R1sxiVhRgobPHHPro6D5YyqVO+P_MZC=aGa+ZHw@mail.gmail.com","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-07-09T01:18:22Z","receivedAt":"2014-07-09T01:18:22Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:\n> On 3 July 2014 23:55, Øyvind A. Holm wrote:\n> > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> > (64-bit), t5150-request-pull.sh fails when compiling with\n> >\n> > $ make configure\n> > $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> > $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n> > $ cd t\n> > $ ./t5150-request-pull.sh\n> \n> FYI, t5150-request-pull.sh passes all tests now on newest master\n> (v2.0.1-474-g72c7794) in Debian. There are two new commits on master\n> since I wrote this, and the commit that makes things work again is\n> 4602f1a (\"diff-tree: call free_commit_list() instead of duplicating\n> its code\"). Reverting this commit brings the failure back.\n> \n> The whole thing is still a mystery to me, though. I can't see why this\n> should have anything to do with the use of ./configure --prefix.\n\nThe problem only happens when a ref with an allowed wildcard winds up on\na page boundary (with the wildcard before the page boundary). This\ndepends intricately on the details of memory allocation, so pretty much\nanything could make it come and go.\n\nDoes the fix I posted work for you? If not, let me know and I'll look\ninto it more.\n"},{"id":"245623","messageId":"CAA787rnpHTiaV3KndmVqiTF_kzpcptbrTfWBnFVh0W_Rzyw8ww@mail.gmail.com","threadId":"37054","inReplyTo":"1404868702.3775.2.camel@stross","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-09T11:44:21Z","receivedAt":"2014-07-09T11:44:21Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 9 July 2014 03:18, David Turner wrote:\n> On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:\n> > On 3 July 2014 23:55, Øyvind A. Holm wrote:\n> > > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n> > > (64-bit), t5150-request-pull.sh fails when compiling with\n> > > [snip]\n> >\n> > FYI, t5150-request-pull.sh passes all tests now on newest master\n> > (v2.0.1-474-g72c7794) in Debian. There are two new commits on master\n> > since I wrote this, and the commit that makes things work again is\n> > 4602f1a (\"diff-tree: call free_commit_list() instead of duplicating\n> > its code\"). Reverting this commit brings the failure back.\n> >\n> > The whole thing is still a mystery to me, though. I can't see why\n> > this should have anything to do with the use of ./configure\n> > --prefix.\n>\n> The problem only happens when a ref with an allowed wildcard winds up\n> on a page boundary (with the wildcard before the page boundary). This\n> depends intricately on the details of memory allocation, so pretty\n> much anything could make it come and go.\n\nAha, that makes sense. Sheer luck that the results were that consistent\nduring testing, then.\n\n> Does the fix I posted work for you? If not, let me know and I'll look\n> into it more.\n\nSorry, didn't notice you posted that to the list. Today I learned that\nGmail doesn't put mails adressed to me and the list in the inbox. :(\n\nThe commit fixed it, yes. Thanks for the patch. It now works on both\nDebian servers. Have run all tests on one of the servers, and will\nrepeat on other machines, too.\n\nThanks,\nØyvind\n"},{"id":"245624","messageId":"CAA787rn-jD_QpeDOxLU2D+_nV0GjFpXr9NaNpZ2L++1sn_gOag@mail.gmail.com","threadId":"37054","inReplyTo":"xmqq7g3pdoy7.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] refs.c: handle REFNAME_REFSPEC_PATTERN at end of page","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2014-07-09T11:48:35Z","receivedAt":"2014-07-09T11:48:35Z","isPatch":true,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 7 July 2014 20:05, Junio C Hamano wrote:\n> David Turner writes:\n> > When a ref crosses a memory page boundary, we restart the parsing at\n> > the beginning with the bytewise code. Pass the original flags to\n> > that code, rather than the current flags.\n>\n> Good.\n\nI've run the whole test suite with this patch applied, and it fixes the\nproblem on 64-bit Debian 7.5.\n\n> I probably should add:\n> Reported-by: Øyvind A. Holm \n>\n> before your sign-off.\n\nThanks. :)\n\nCheers,\nØyvind\n"},{"id":"245631","messageId":"53BD5710.7040409@web.de","threadId":"37054","inReplyTo":"1404868702.3775.2.camel@stross","subject":"Re: t5150-request-pull.sh fails on newest master in Debian","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2014-07-09T14:52:00Z","receivedAt":"2014-07-09T14:52:00Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 09.07.2014 03:18, schrieb David Turner:\n> On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote:\n>> On 3 July 2014 23:55, Øyvind A. Holm wrote:\n>>> When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5\n>>> (64-bit), t5150-request-pull.sh fails when compiling with\n>>>\n>>> $ make configure\n>>> $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n>>> $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f\n>>> $ cd t\n>>> $ ./t5150-request-pull.sh\n>>\n>> FYI, t5150-request-pull.sh passes all tests now on newest master\n>> (v2.0.1-474-g72c7794) in Debian. There are two new commits on master\n>> since I wrote this, and the commit that makes things work again is\n>> 4602f1a (\"diff-tree: call free_commit_list() instead of duplicating\n>> its code\"). Reverting this commit brings the failure back.\n>>\n>> The whole thing is still a mystery to me, though. I can't see why this\n>> should have anything to do with the use of ./configure --prefix.\n>\n> The problem only happens when a ref with an allowed wildcard winds up on\n> a page boundary (with the wildcard before the page boundary). This\n> depends intricately on the details of memory allocation, so pretty much\n> anything could make it come and go.\n>\n> Does the fix I posted work for you? If not, let me know and I'll look\n> into it more.\n\nSounds fragile overall. How could a test program look like? All I can \nthink of is a brute force check of all combinations of three characters \n(is that enough?), PAGE_SIZE offsets, three flags, with and without \n\".lock\" appended (and embedded?) against the old implementation, which \nmust be quite expensive.\n\nSome callers of check_refname_format() know the length of the string or \ncan determine it cheaply because they copy the whole string anyway. \nWould it make sense to do away with the page boundary magic and require \nthe callers of the fast version to pass that length? The tailing bytes \n(up to 15) would have to be loaded carefully, though. Not sure.\n\nRené\n"}]}