# Re: Re: Segmentation fault with latest git (070c57df) 13 messages from 2013-02-04 to 2013-05-16. Participants: Jongman Heo, Junio C Hamano, Jeff King, Jonathan Nieder, sam, Ramkumar Ramachandra. Thread: https://gitlist.dev/t/32822 ## Jongman Heo, 2013-02-04 06:58 Subject: Re: Re: Segmentation fault with latest git (070c57df) Message-ID: <12070540.431901359961105650.JavaMail.weblogic@epml10> URL: https://gitlist.dev/e/12070540.431901359961105650.JavaMail.weblogic%40epml10 ``` Jonathan Nieder wrote: > Jongman Heo wrote: > >> Unfortunately, the patch didn't help to me. > >Thanks for testing. Did you apply the patch to the older version of >git that generates builtin/.depend/fetch.o.d or the newer version that >consumes it? > >Curious, >Jonathan Hi, Jonathan, I applied the patch to newer version. This time, I tried to apply the patch to older version of Makefile, and now the issue is fixed~. Thanks~! Best regards, Jongman Heo ``` ## Junio C Hamano, 2013-02-04 07:13 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <7vehgw5z7n.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vehgw5z7n.fsf%40alter.siamese.dyndns.org In-Reply-To: <12070540.431901359961105650.JavaMail.weblogic@epml10> ``` Jongman Heo writes: > Jonathan Nieder wrote: >> Jongman Heo wrote: >> >>> Unfortunately, the patch didn't help to me. >> >>Thanks for testing. Did you apply the patch to the older version of >>git that generates builtin/.depend/fetch.o.d or the newer version that >>consumes it? >> >>Curious, >>Jonathan > > Hi, Jonathan, > > I applied the patch to newer version. > > This time, I tried to apply the patch to older version of Makefile, and now the issue is fixed~. > Thanks~! Yeah, that result is understandable, as .depend/*.o.d files will not be rebuilt when the rules to build them changes in the Makefile. Applying the patch to the Makefile in the pristine old tree, run the build (which will generate .depend/*.o.d files with the corrected rules), then checking out the new tree and running the build again without "make clean", with or with the patch applied, would validate that the patch fixes the issue for old ccache. Thanks Jonathan for diagnosing, fixing, and thanks Jongman for testing. ``` ## Jeff King, 2013-02-04 08:37 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <20130204083701.GA30835@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130204083701.GA30835%40sigill.intra.peff.net In-Reply-To: <7vehgw5z7n.fsf@alter.siamese.dyndns.org> ``` On Sun, Feb 03, 2013 at 11:13:00PM -0800, Junio C Hamano wrote: > Yeah, that result is understandable, as .depend/*.o.d files will not > be rebuilt when the rules to build them changes in the Makefile. > Applying the patch to the Makefile in the pristine old tree, run the > build (which will generate .depend/*.o.d files with the corrected > rules), then checking out the new tree and running the build again > without "make clean", with or with the patch applied, would validate > that the patch fixes the issue for old ccache. > > Thanks Jonathan for diagnosing, fixing, and thanks Jongman for > testing. Do we want to do anything with the other dependency hole I found here: http://article.gmane.org/gmane.comp.version-control.git/215211 It's definitely a potential problem, but I don't think we have any reports of it happening in practice, so it might not be worth worrying about. Doing a clean version of the fix here: http://article.gmane.org/gmane.comp.version-control.git/215212 would probably involve reorganizing our .depend directory structure, unless somebody can cook up some clever use of make's patsubst. -Peff ``` ## Junio C Hamano, 2013-02-04 09:16 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <7vsj5c4exz.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsj5c4exz.fsf%40alter.siamese.dyndns.org In-Reply-To: <20130204083701.GA30835@sigill.intra.peff.net> ``` Jeff King writes: > Do we want to do anything with the other dependency hole I found here: > > http://article.gmane.org/gmane.comp.version-control.git/215211 > > It's definitely a potential problem, but I don't think we have any > reports of it happening in practice, so it might not be worth worrying > about. Doing a clean version of the fix here: > > http://article.gmane.org/gmane.comp.version-control.git/215212 > > would probably involve reorganizing our .depend directory structure, > unless somebody can cook up some clever use of make's patsubst. As I understand how the current set-up works: * Initially, we do not have foo.o but foo.c. We automatically build foo.o because it depends on foo.c via the "%.o : %.c" rule, and as a side effect, we also build .depend/foo.o.d file; * Then, if any real dependency used to build the existing foo.o that is recorded in .depend/foo.o.d file changes, foo.o gets rebuilt, which would update .depend/foo.o.d again for the next invocation. The case where you lose .depend/foo.o.d is a special case of getting a wrong information in .depend/foo.o.d, which may happen by using a broken compiler during the initial build, or going over quota and getting .depend/foo.o.d truncated, or by other breakages. The user may have done "rm -rf .depend" to lose it, or the user may have done something like this to munge it: find -name '.git' -type d -prune -o -print0 | xargs -0 sed -i -e 's/foo/bar/g' forgetting that just like .git, .depend is precious and should not be touched. I think this really boils down to where we draw the "this is good enough" line. I am not sure if losing the file as in $gmane/215211 is common enough to be special cased to buy us much, while leaving other ".depend/foo.o.d was updated to contain a wrong info" cases still broken. And of course the case where .depend/foo.o.d is munged by mistake cannot be solved without recompiling everything all the time, so... ``` ## Junio C Hamano, 2013-02-04 09:29 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <7vobg04ebe.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vobg04ebe.fsf%40alter.siamese.dyndns.org In-Reply-To: <7vsj5c4exz.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > As I understand how the current set-up works: > > * Initially, we do not have foo.o but foo.c. We automatically > build foo.o because it depends on foo.c via the "%.o : %.c" rule, > and as a side effect, we also build .depend/foo.o.d file; > > * Then, if any real dependency used to build the existing foo.o > that is recorded in .depend/foo.o.d file changes, foo.o gets > rebuilt, which would update .depend/foo.o.d again for the next > invocation. This is unrelated to the case you mentioned, but I wonder what happens if you did this: * You are on branch 'next', where foo.c includes (perhaps indirectly) frotz.h. Compile and you get foo.o and also the dependency recorded for it, "foo.o: foo.c frotz.h", in the .depend/foo.o.d file. * You check out branch 'master', where foo.c does not include frotz.h. Indeed, the include file does not even exist on the branch. Do we get confused, because Makefile includes the depend file from the previous build, finds that you need foo.c and frotz.h up to date in order to get foo.o, but there is no rule to generate frotz.h? ``` ## Jeff King, 2013-02-04 09:38 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <20130204093821.GA32095@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130204093821.GA32095%40sigill.intra.peff.net In-Reply-To: <7vsj5c4exz.fsf@alter.siamese.dyndns.org> ``` On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote: > I think this really boils down to where we draw the "this is good > enough" line. I am not sure if losing the file as in $gmane/215211 > is common enough to be special cased to buy us much, while leaving > other ".depend/foo.o.d was updated to contain a wrong info" cases > still broken. Hmm. Yeah, I was thinking it might be more common than ordinary munging due to something like an interrupted "git clean -x". But given that: 1. As far as I can tell, it is not a situation that can happen through regular use of checkout/make/etc, and... 2. We have zero reports of it happening in practice (I only discovered it while explicitly trying to break the Makefile), and... 3. It is just one of many possible breakages, all of which can be fixed by "git clean -dx" if you suspect issues... let's just leave it. Thanks for a sanity check. -Peff ``` ## Jeff King, 2013-02-04 09:45 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <20130204094526.GB32095@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130204094526.GB32095%40sigill.intra.peff.net In-Reply-To: <7vobg04ebe.fsf@alter.siamese.dyndns.org> ``` On Mon, Feb 04, 2013 at 01:29:41AM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > As I understand how the current set-up works: > > > > * Initially, we do not have foo.o but foo.c. We automatically > > build foo.o because it depends on foo.c via the "%.o : %.c" rule, > > and as a side effect, we also build .depend/foo.o.d file; > > > > * Then, if any real dependency used to build the existing foo.o > > that is recorded in .depend/foo.o.d file changes, foo.o gets > > rebuilt, which would update .depend/foo.o.d again for the next > > invocation. > > This is unrelated to the case you mentioned, but I wonder what > happens if you did this: > > * You are on branch 'next', where foo.c includes (perhaps > indirectly) frotz.h. Compile and you get foo.o and also the > dependency recorded for it, "foo.o: foo.c frotz.h", in the > .depend/foo.o.d file. > > * You check out branch 'master', where foo.c does not include > frotz.h. Indeed, the include file does not even exist on the > branch. > > Do we get confused, because Makefile includes the depend file from > the previous build, finds that you need foo.c and frotz.h up to date > in order to get foo.o, but there is no rule to generate frotz.h? No, because the .d files look like this: foo.o: frotz.h frotz.h: So make sees that it can build frotz.h, which of course does nothing. But that's OK, because foo.c doesn't actually include it anymore, and when we recompile it (as we must, since it is different between the two branches), we will rewrite the .d file without frotz.h. -Peff ``` ## Junio C Hamano, 2013-02-04 16:46 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <7vboc03u3e.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vboc03u3e.fsf%40alter.siamese.dyndns.org In-Reply-To: <20130204093821.GA32095@sigill.intra.peff.net> ``` Jeff King writes: > On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote: > >> I think this really boils down to where we draw the "this is good >> enough" line. I am not sure if losing the file as in $gmane/215211 >> is common enough to be special cased to buy us much, while leaving >> other ".depend/foo.o.d was updated to contain a wrong info" cases >> still broken. > > Hmm. Yeah, I was thinking it might be more common than ordinary munging > due to something like an interrupted "git clean -x". But given that: > > 1. As far as I can tell, it is not a situation that can happen through > regular use of checkout/make/etc, and... > > 2. We have zero reports of it happening in practice (I only discovered > it while explicitly trying to break the Makefile), and... > > 3. It is just one of many possible breakages, all of which can be > fixed by "git clean -dx" if you suspect issues... > > let's just leave it. Thanks for a sanity check. The only case that worries me is when make or cc gets interrupted. As long as make removes the ultimate target *.o in such a case, it is fine to leave a half-written .depend/foo.o.d (or getting it removed) behind. How expensive to generate the dependency for a single foo.c file into a temporary without compiling it into foo.o, and comparing the resulting dependency with existing .depend/foo.o.d? If it is very cheap, it might be worth doing it before linking the final build product and error the build out when we see discrepancies. I dunno. ``` ## Jonathan Nieder, 2013-02-04 18:34 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <20130204183437.GA15552@google.com> URL: https://gitlist.dev/e/20130204183437.GA15552%40google.com In-Reply-To: <7vboc03u3e.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano wrote: > The only case that worries me is when make or cc gets interrupted. > As long as make removes the ultimate target *.o in such a case, it > is fine to leave a half-written .depend/foo.o.d (or getting it > removed) behind. gcc removes the target .o in its signal handler in such a case. In cases where it doesn't get a chance to (e.g., sudden power failure), there is a partially written .o file already in place, the linker produces errors, and the operator is convinced to run "make clean", all without .depend's help. ``` ## sam, 2013-05-15 03:14 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <1368587682499-7585906.post@n2.nabble.com> URL: https://gitlist.dev/e/1368587682499-7585906.post%40n2.nabble.com In-Reply-To: <20130204183437.GA15552@google.com> ``` Hi, Has there been any further progress on this. I just encountered a SEGV with a git apply. This is the latest git version running on Ubuntu 13.04 cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=13.04 DISTRIB_CODENAME=raring DISTRIB_DESCRIPTION="Ubuntu 13.04" uname -a Linux sam-mac 3.8.0-20-generic #31-Ubuntu SMP Mon May 6 17:03:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux git --version git version 1.8.2.2 samueldoyle@sam-MacBookPro:~/Projects/VMware/perforce_repos/esx50u3ps$ sudo gdb /usr/bin/git core GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/bin/git...(no debugging symbols found)...done. [New LWP 28634] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff94d1a000 Core was generated by `git apply --verbose --check --ignore-whitespace --directory=/home/sam/P'. Program terminated with signal 11, Segmentation fault. #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. (gdb) bt 10 #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 #1 0x00007f06ba7c28c6 in __GI___strdup (s=0x0) at strdup.c:41 #2 0x00000000004f4449 in ?? () #3 0x000000000040eab0 in ?? () #4 0x000000000040f6f5 in ?? () #5 0x0000000000405a88 in ?? () #6 0x0000000000404ee2 in ?? () #7 0x00007f06ba75aea5 in __libc_start_main (main=0x404e30, argc=7, ubp_av=0x7fff94c3bd08, init=, fini=, rtld_fini=, stack_end=0x7fff94c3bcf8) at libc-start.c:260 #8 0x0000000000405329 in ?? () A quick search turned up this post that appears to provide the cause: http://stackoverflow.com/questions/3608931/why-is-this-program-segfaulting -- View this message in context: http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585906.html Sent from the git mailing list archive at Nabble.com. ``` ## sam, 2013-05-15 03:22 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: <1368588136231-7585907.post@n2.nabble.com> URL: https://gitlist.dev/e/1368588136231-7585907.post%40n2.nabble.com In-Reply-To: <1368587682499-7585906.post@n2.nabble.com> ``` Hmmm nabble embed didn't provide much value there :) http://pastebin.com/RC8mUPF3 -- View this message in context: http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585907.html Sent from the git mailing list archive at Nabble.com. ``` ## Ramkumar Ramachandra, 2013-05-16 13:12 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: URL: https://gitlist.dev/e/CALkWK0mrofeL7u4GCd_2k3%2BX-hQ6FeZ0kLhYShbCjgnomD3%2BsQ%40mail.gmail.com In-Reply-To: <1368587682499-7585906.post@n2.nabble.com> ``` sam wrote: > gdb /usr/bin/git core What exactly are you doing? Is core aliased to something? > [...] > Core was generated by `git apply --verbose --check --ignore-whitespace > --directory=/home/sam/P'. What is this? Can you give us clear instructions on how to reproduce the segfault? ``` ## Ramkumar Ramachandra, 2013-05-16 13:21 Subject: Re: Segmentation fault with latest git (070c57df) Message-ID: URL: https://gitlist.dev/e/CALkWK0nQt2X4%2BiMTtMYT4XJ7xQt00-Q2sPmsrQiZX%2BbuSkzvTw%40mail.gmail.com In-Reply-To: ``` Ramkumar Ramachandra wrote: > sam wrote: >> gdb /usr/bin/git core > > What exactly are you doing? Is core aliased to something? Sorry about that. I just realized you're loading a core dump. Please tell us how to reproduce this, or give us the backtrace with debugging symbols. ```