Re: t5150-request-pull.sh fails on newest master in Debian
On 9 July 2014 03:18, David Turner dtur...@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 su...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
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 su...@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é -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
On 3 July 2014 23:55, Øyvind A. Holm su...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
On Wed, 2014-07-09 at 02:52 +0200, Øyvind A. Holm wrote: On 3 July 2014 23:55, Øyvind A. Holm su...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
On 5 July 2014 03:58, David Turner dtur...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
On 4 July 2014 22:22, David Turner dtur...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
On 3 July 2014 23:55, Øyvind A. Holm su...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5150-request-pull.sh fails on newest master in Debian
On 4 July 2014 00:34, Øyvind A. Holm su...@sunbase.org wrote: On 4 July 2014 00:16, David Turner dtur...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
