{"thread":{"id":"32822","subject":"Re: Re: Segmentation fault with latest git (070c57df)","startedAt":"2013-02-04T06:58:27Z","lastAt":"2013-05-16T13:21:44Z","messageCount":13,"participants":["Jongman Heo","Junio C Hamano","Jeff King","Jonathan Nieder","sam","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"208589","messageId":"12070540.431901359961105650.JavaMail.weblogic@epml10","threadId":"32822","inReplyTo":null,"subject":"Re: Re: Segmentation fault with latest git (070c57df)","fromName":"Jongman Heo","fromEmail":"jongman.heo@samsung.com","sentAt":"2013-02-04T06:58:27Z","receivedAt":"2013-02-04T06:58:27Z","isPatch":false,"sender":{"key":"jongman.heo@samsung.com","avatar":null},"body":"\nJonathan Nieder wrote:\n> Jongman Heo wrote:\n> \n>> Unfortunately, the patch didn't help to me.\n>\n>Thanks for testing. Did you apply the patch to the older version of\n>git that generates builtin/.depend/fetch.o.d or the newer version that\n>consumes it?\n>\n>Curious,\n>Jonathan\n\nHi, Jonathan,\n\nI applied the patch to newer version. \n\nThis time, I tried to apply the patch to older version of Makefile, and now the issue is fixed~. \nThanks~!\n\nBest regards,\nJongman Heo\n"},{"id":"208590","messageId":"7vehgw5z7n.fsf@alter.siamese.dyndns.org","threadId":"32822","inReplyTo":"12070540.431901359961105650.JavaMail.weblogic@epml10","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T07:13:00Z","receivedAt":"2013-02-04T07:13:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jongman Heo writes:\n\n> Jonathan Nieder wrote:\n>> Jongman Heo wrote:\n>> \n>>> Unfortunately, the patch didn't help to me.\n>>\n>>Thanks for testing. Did you apply the patch to the older version of\n>>git that generates builtin/.depend/fetch.o.d or the newer version that\n>>consumes it?\n>>\n>>Curious,\n>>Jonathan\n>\n> Hi, Jonathan,\n>\n> I applied the patch to newer version. \n>\n> This time, I tried to apply the patch to older version of Makefile, and now the issue is fixed~. \n> Thanks~!\n\nYeah, that result is understandable, as .depend/*.o.d files will not\nbe rebuilt when the rules to build them changes in the Makefile.\nApplying the patch to the Makefile in the pristine old tree, run the\nbuild (which will generate .depend/*.o.d files with the corrected\nrules), then checking out the new tree and running the build again\nwithout \"make clean\", with or with the patch applied, would validate\nthat the patch fixes the issue for old ccache.\n\nThanks Jonathan for diagnosing, fixing, and thanks Jongman for\ntesting.\n"},{"id":"208594","messageId":"20130204083701.GA30835@sigill.intra.peff.net","threadId":"32822","inReplyTo":"7vehgw5z7n.fsf@alter.siamese.dyndns.org","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-04T08:37:01Z","receivedAt":"2013-02-04T08:37:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 03, 2013 at 11:13:00PM -0800, Junio C Hamano wrote:\n\n> Yeah, that result is understandable, as .depend/*.o.d files will not\n> be rebuilt when the rules to build them changes in the Makefile.\n> Applying the patch to the Makefile in the pristine old tree, run the\n> build (which will generate .depend/*.o.d files with the corrected\n> rules), then checking out the new tree and running the build again\n> without \"make clean\", with or with the patch applied, would validate\n> that the patch fixes the issue for old ccache.\n> \n> Thanks Jonathan for diagnosing, fixing, and thanks Jongman for\n> testing.\n\nDo we want to do anything with the other dependency hole I found here:\n\n http://article.gmane.org/gmane.comp.version-control.git/215211\n\nIt's definitely a potential problem, but I don't think we have any\nreports of it happening in practice, so it might not be worth worrying\nabout. Doing a clean version of the fix here:\n\n http://article.gmane.org/gmane.comp.version-control.git/215212\n\nwould probably involve reorganizing our .depend directory structure,\nunless somebody can cook up some clever use of make's patsubst.\n\n-Peff\n"},{"id":"208597","messageId":"7vsj5c4exz.fsf@alter.siamese.dyndns.org","threadId":"32822","inReplyTo":"20130204083701.GA30835@sigill.intra.peff.net","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T09:16:08Z","receivedAt":"2013-02-04T09:16:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Do we want to do anything with the other dependency hole I found here:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/215211\n>\n> It's definitely a potential problem, but I don't think we have any\n> reports of it happening in practice, so it might not be worth worrying\n> about. Doing a clean version of the fix here:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/215212\n>\n> would probably involve reorganizing our .depend directory structure,\n> unless somebody can cook up some clever use of make's patsubst.\n\nAs I understand how the current set-up works:\n\n * Initially, we do not have foo.o but foo.c. We automatically\n build foo.o because it depends on foo.c via the \"%.o : %.c\" rule,\n and as a side effect, we also build .depend/foo.o.d file;\n\n * Then, if any real dependency used to build the existing foo.o\n that is recorded in .depend/foo.o.d file changes, foo.o gets\n rebuilt, which would update .depend/foo.o.d again for the next\n invocation.\n\nThe case where you lose .depend/foo.o.d is a special case of getting\na wrong information in .depend/foo.o.d, which may happen by using a\nbroken compiler during the initial build, or going over quota and\ngetting .depend/foo.o.d truncated, or by other breakages. The user\nmay have done \"rm -rf .depend\" to lose it, or the user may have done\nsomething like this to munge it:\n\n\tfind -name '.git' -type d -prune -o -print0 |\n xargs -0 sed -i -e 's/foo/bar/g'\n\nforgetting that just like .git, .depend is precious and should not\nbe touched.\n\nI think this really boils down to where we draw the \"this is good\nenough\" line. I am not sure if losing the file as in $gmane/215211\nis common enough to be special cased to buy us much, while leaving\nother \".depend/foo.o.d was updated to contain a wrong info\" cases\nstill broken.\n\nAnd of course the case where .depend/foo.o.d is munged by mistake\ncannot be solved without recompiling everything all the time, so...\n"},{"id":"208598","messageId":"7vobg04ebe.fsf@alter.siamese.dyndns.org","threadId":"32822","inReplyTo":"7vsj5c4exz.fsf@alter.siamese.dyndns.org","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T09:29:41Z","receivedAt":"2013-02-04T09:29:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> As I understand how the current set-up works:\n>\n> * Initially, we do not have foo.o but foo.c. We automatically\n> build foo.o because it depends on foo.c via the \"%.o : %.c\" rule,\n> and as a side effect, we also build .depend/foo.o.d file;\n>\n> * Then, if any real dependency used to build the existing foo.o\n> that is recorded in .depend/foo.o.d file changes, foo.o gets\n> rebuilt, which would update .depend/foo.o.d again for the next\n> invocation.\n\nThis is unrelated to the case you mentioned, but I wonder what\nhappens if you did this:\n\n * You are on branch 'next', where foo.c includes (perhaps\n indirectly) frotz.h. Compile and you get foo.o and also the\n dependency recorded for it, \"foo.o: foo.c frotz.h\", in the\n .depend/foo.o.d file.\n\n * You check out branch 'master', where foo.c does not include\n frotz.h. Indeed, the include file does not even exist on the\n branch.\n\nDo we get confused, because Makefile includes the depend file from\nthe previous build, finds that you need foo.c and frotz.h up to date\nin order to get foo.o, but there is no rule to generate frotz.h?\n"},{"id":"208599","messageId":"20130204093821.GA32095@sigill.intra.peff.net","threadId":"32822","inReplyTo":"7vsj5c4exz.fsf@alter.siamese.dyndns.org","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-04T09:38:21Z","receivedAt":"2013-02-04T09:38:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:\n\n> I think this really boils down to where we draw the \"this is good\n> enough\" line. I am not sure if losing the file as in $gmane/215211\n> is common enough to be special cased to buy us much, while leaving\n> other \".depend/foo.o.d was updated to contain a wrong info\" cases\n> still broken.\n\nHmm. Yeah, I was thinking it might be more common than ordinary munging\ndue to something like an interrupted \"git clean -x\". But given that:\n\n 1. As far as I can tell, it is not a situation that can happen through\n regular use of checkout/make/etc, and...\n\n 2. We have zero reports of it happening in practice (I only discovered\n it while explicitly trying to break the Makefile), and...\n\n 3. It is just one of many possible breakages, all of which can be\n fixed by \"git clean -dx\" if you suspect issues...\n\nlet's just leave it. Thanks for a sanity check.\n\n-Peff\n"},{"id":"208600","messageId":"20130204094526.GB32095@sigill.intra.peff.net","threadId":"32822","inReplyTo":"7vobg04ebe.fsf@alter.siamese.dyndns.org","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-04T09:45:26Z","receivedAt":"2013-02-04T09:45:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 04, 2013 at 01:29:41AM -0800, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > As I understand how the current set-up works:\n> >\n> > * Initially, we do not have foo.o but foo.c. We automatically\n> > build foo.o because it depends on foo.c via the \"%.o : %.c\" rule,\n> > and as a side effect, we also build .depend/foo.o.d file;\n> >\n> > * Then, if any real dependency used to build the existing foo.o\n> > that is recorded in .depend/foo.o.d file changes, foo.o gets\n> > rebuilt, which would update .depend/foo.o.d again for the next\n> > invocation.\n> \n> This is unrelated to the case you mentioned, but I wonder what\n> happens if you did this:\n> \n> * You are on branch 'next', where foo.c includes (perhaps\n> indirectly) frotz.h. Compile and you get foo.o and also the\n> dependency recorded for it, \"foo.o: foo.c frotz.h\", in the\n> .depend/foo.o.d file.\n> \n> * You check out branch 'master', where foo.c does not include\n> frotz.h. Indeed, the include file does not even exist on the\n> branch.\n> \n> Do we get confused, because Makefile includes the depend file from\n> the previous build, finds that you need foo.c and frotz.h up to date\n> in order to get foo.o, but there is no rule to generate frotz.h?\n\nNo, because the .d files look like this:\n\n foo.o: frotz.h\n\n frotz.h:\n\nSo make sees that it can build frotz.h, which of course does nothing.\nBut that's OK, because foo.c doesn't actually include it anymore, and\nwhen we recompile it (as we must, since it is different between the two\nbranches), we will rewrite the .d file without frotz.h.\n\n-Peff\n"},{"id":"208620","messageId":"7vboc03u3e.fsf@alter.siamese.dyndns.org","threadId":"32822","inReplyTo":"20130204093821.GA32095@sigill.intra.peff.net","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T16:46:29Z","receivedAt":"2013-02-04T16:46:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:\n>\n>> I think this really boils down to where we draw the \"this is good\n>> enough\" line. I am not sure if losing the file as in $gmane/215211\n>> is common enough to be special cased to buy us much, while leaving\n>> other \".depend/foo.o.d was updated to contain a wrong info\" cases\n>> still broken.\n>\n> Hmm. Yeah, I was thinking it might be more common than ordinary munging\n> due to something like an interrupted \"git clean -x\". But given that:\n>\n> 1. As far as I can tell, it is not a situation that can happen through\n> regular use of checkout/make/etc, and...\n>\n> 2. We have zero reports of it happening in practice (I only discovered\n> it while explicitly trying to break the Makefile), and...\n>\n> 3. It is just one of many possible breakages, all of which can be\n> fixed by \"git clean -dx\" if you suspect issues...\n>\n> let's just leave it. Thanks for a sanity check.\n\nThe only case that worries me is when make or cc gets interrupted.\nAs long as make removes the ultimate target *.o in such a case, it\nis fine to leave a half-written .depend/foo.o.d (or getting it\nremoved) behind.\n\nHow expensive to generate the dependency for a single foo.c file\ninto a temporary without compiling it into foo.o, and comparing the\nresulting dependency with existing .depend/foo.o.d? If it is very\ncheap, it might be worth doing it before linking the final build\nproduct and error the build out when we see discrepancies. I dunno.\n"},{"id":"208634","messageId":"20130204183437.GA15552@google.com","threadId":"32822","inReplyTo":"7vboc03u3e.fsf@alter.siamese.dyndns.org","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-04T18:34:37Z","receivedAt":"2013-02-04T18:34:37Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> The only case that worries me is when make or cc gets interrupted.\n> As long as make removes the ultimate target *.o in such a case, it\n> is fine to leave a half-written .depend/foo.o.d (or getting it\n> removed) behind.\n\ngcc removes the target .o in its signal handler in such a case. In\ncases where it doesn't get a chance to (e.g., sudden power failure),\nthere is a partially written .o file already in place, the linker\nproduces errors, and the operator is convinced to run \"make clean\",\nall without .depend's help.\n"},{"id":"217406","messageId":"1368587682499-7585906.post@n2.nabble.com","threadId":"32822","inReplyTo":"20130204183437.GA15552@google.com","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"sam","fromEmail":"sdoyle_2@yahoo.com","sentAt":"2013-05-15T03:14:42Z","receivedAt":"2013-05-15T03:14:42Z","isPatch":false,"sender":{"key":"sdoyle_2@yahoo.com","avatar":null},"body":"Hi,\n\nHas there been any further progress on this. I just encountered a SEGV with\na git apply. This is the latest git version running on Ubuntu 13.04\n\ncat /etc/lsb-release \nDISTRIB_ID=Ubuntu\nDISTRIB_RELEASE=13.04\nDISTRIB_CODENAME=raring\nDISTRIB_DESCRIPTION=\"Ubuntu 13.04\"\n\nuname -a\nLinux sam-mac 3.8.0-20-generic #31-Ubuntu SMP Mon May 6 17:03:32 UTC 2013\nx86_64 x86_64 x86_64 GNU/Linux\n\ngit --version\ngit version 1.8.2.2\n\n\nsamueldoyle@sam-MacBookPro:~/Projects/VMware/perforce_repos/esx50u3ps$ sudo\ngdb /usr/bin/git core\nGNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu\nCopyright (C) 2013 Free Software Foundation, Inc.\nLicense GPLv3+: GNU GPL version 3 or later\n\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\nThis GDB was configured as \"x86_64-linux-gnu\".\nFor bug reporting instructions, please see:\n...\nReading symbols from /usr/bin/git...(no debugging symbols found)...done.\n[New LWP 28634]\n\nwarning: Can't read pathname for load map: Input/output error.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n\nwarning: no loadable sections found in added symbol-file system-supplied DSO\nat 0x7fff94d1a000\nCore was generated by `git apply --verbose --check --ignore-whitespace\n--directory=/home/sam/P'.\nProgram terminated with signal 11, Segmentation fault.\n#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31\n31\t../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.\n(gdb) bt 10\n#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31\n#1 0x00007f06ba7c28c6 in __GI___strdup (s=0x0) at strdup.c:41\n#2 0x00000000004f4449 in ?? ()\n#3 0x000000000040eab0 in ?? ()\n#4 0x000000000040f6f5 in ?? ()\n#5 0x0000000000405a88 in ?? ()\n#6 0x0000000000404ee2 in ?? ()\n#7 0x00007f06ba75aea5 in __libc_start_main (main=0x404e30, argc=7,\nubp_av=0x7fff94c3bd08, init=, fini=, \n rtld_fini=, stack_end=0x7fff94c3bcf8) at libc-start.c:260\n#8 0x0000000000405329 in ?? ()\n\n\nA quick search turned up this post that appears to provide the cause:\nhttp://stackoverflow.com/questions/3608931/why-is-this-program-segfaulting\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585906.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"217407","messageId":"1368588136231-7585907.post@n2.nabble.com","threadId":"32822","inReplyTo":"1368587682499-7585906.post@n2.nabble.com","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"sam","fromEmail":"sdoyle_2@yahoo.com","sentAt":"2013-05-15T03:22:16Z","receivedAt":"2013-05-15T03:22:16Z","isPatch":false,"sender":{"key":"sdoyle_2@yahoo.com","avatar":null},"body":"Hmmm nabble embed didn't provide much value there :)\n\nhttp://pastebin.com/RC8mUPF3\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585907.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"217589","messageId":"CALkWK0mrofeL7u4GCd_2k3+X-hQ6FeZ0kLhYShbCjgnomD3+sQ@mail.gmail.com","threadId":"32822","inReplyTo":"1368587682499-7585906.post@n2.nabble.com","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-16T13:12:20Z","receivedAt":"2013-05-16T13:12:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"sam wrote:\n> gdb /usr/bin/git core\n\nWhat exactly are you doing? Is core aliased to something?\n\n> [...]\n> Core was generated by `git apply --verbose --check --ignore-whitespace\n> --directory=/home/sam/P'.\n\nWhat is this?\n\nCan you give us clear instructions on how to reproduce the segfault?\n"},{"id":"217590","messageId":"CALkWK0nQt2X4+iMTtMYT4XJ7xQt00-Q2sPmsrQiZX+buSkzvTw@mail.gmail.com","threadId":"32822","inReplyTo":"CALkWK0mrofeL7u4GCd_2k3+X-hQ6FeZ0kLhYShbCjgnomD3+sQ@mail.gmail.com","subject":"Re: Segmentation fault with latest git (070c57df)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-16T13:21:44Z","receivedAt":"2013-05-16T13:21:44Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> sam wrote:\n>> gdb /usr/bin/git core\n>\n> What exactly are you doing? Is core aliased to something?\n\nSorry about that. I just realized you're loading a core dump.\n\nPlease tell us how to reproduce this, or give us the backtrace with\ndebugging symbols.\n"}]}