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?
--
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.
--
To unsubscribe from
.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585906.html
Sent from the git mailing list archive at Nabble.com.
--
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
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.
--
To unsubscribe from
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
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com 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
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
On Mon, Feb 04, 2013 at 01:29:41AM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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,
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
Jonathan Nieder wrote:
Jongman Heo wrote:
But it doesn't stimulate any prerequisites in make, which is weird.
What's in builtin/.depend/fetch.o.d?
[...]
please see below~.
$ cat builtin/.depend/fetch.o.d
fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
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
--
To unsubscribe from this list: send the line unsubscribe
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
Jongman Heo jongman@samsung.com 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?
Junio C Hamanogits...@pobox.com wrote :
허종만 writes:
But usually when I build upstream Linux kernel, I don't do make
clean after git pull.. I didn't expect that I needed make
clean for git build.
We don't expect anybody need make clean, either. There is
something wrong in the dependency.
On Fri, Feb 01, 2013 at 09:14:41AM +, Jongman Heo wrote:
I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as
follows.
Great, thanks for taking the time to reproduce.
But in my different machine (Fedora 16 x86) I can't reproduce.
That makes me wonder if it is
On Fri, Feb 01, 2013 at 10:30:24AM +, Jongman Heo wrote:
Short answer;
* Version of make is 3.81 on both machines
* builtin/fetch.o is not rebuilt (see entire log below)
* git works fine with make all install COMPUTE_HEADER_DEPENDENCIES=no
OK, that gets us closer. It's definitely a
[...]
Finished prerequisites of target file `builtin/fetch.o'.
Prerequisite `builtin/fetch.c' is older than target `builtin/fetch.o'.
Prerequisite `GIT-CFLAGS' is older than target `builtin/fetch.o'.
No need to remake target `builtin/fetch.o'.
But it doesn't stimulate any prerequisites
Jongman Heo wrote:
But it doesn't stimulate any prerequisites in make, which is weird.
What's in builtin/.depend/fetch.o.d?
[...]
please see below~.
$ cat builtin/.depend/fetch.o.d
fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
That's the problem. See the
It's almost like the compiler is getting the initializer wrong. It's a
long shot, but I wonder if the presence of the bitfield could be
triggering a compiler bug (or there is a subtle C rule about bitfield
initializations that I do not know). Just for the sake of my sanity,
what does the
Jeff King p...@peff.net writes:
On Thu, Jan 31, 2013 at 07:27:04AM +, Jongman Heo wrote:
FYI, gdb backtrace and valgrind output attached below, Thanks.
Thanks, that's helpful.
#4 0x0812bda0 in string_list_insert (list=0xbfffe7c0,
string=0x821ec3c refs/remotes/origin/HEAD) at
On Thu, Jan 31, 2013 at 09:42:07AM +0100, Thomas Rast wrote:
int main(void)
{
struct foo f = { NULL, 0, 0, 0 };
printf(cmp is %lu\n, (unsigned long)f.cmp);
return 0;
}
I doubt that would help because that stack region would be 0 anyway due
to kernel initialization of new
[snip]
Good point. Unfortunately, I can't get either yours or mine to fail,
neither with a recent version of gcc nor with gcc-4.1. But I can't
convince git to fail, either. The only gcc-4.1 I have is Debian's
4.1.3 release, which is not quite what the OP has.
Or perhaps something in
허종만 jongman@samsung.com writes:
But usually when I build upstream Linux kernel, I don't do make
clean after git pull.. I didn't expect that I needed make
clean for git build.
We don't expect anybody need make clean, either. There is
something wrong in the dependency.
--
To unsubscribe
On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote:
허종만 jongman@samsung.com writes:
But usually when I build upstream Linux kernel, I don't do make
clean after git pull.. I didn't expect that I needed make
clean for git build.
We don't expect anybody need make clean,
On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote:
It seems like building each object file should depend on its dependency
file (but only when COMPUTE_HEADER_DEPENDENCIES is on, of course), since
otherwise we cannot know if we have the right dependencies or not.
Something like this
On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote:
On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote:
허종만 jongman@samsung.com writes:
But usually when I build upstream Linux kernel, I don't do make
clean after git pull.. I didn't expect that I needed make
Hi all,
Looks like following commit causes a segmentation fault in my machine (when
running git pull or git fetch);
commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
Author: Junio C Hamano gits...@pobox.com
Date: Mon Jan 7 12:24:55 2013 -0800
string-list: allow case-insensitive string
On Thu, Jan 31, 2013 at 01:35:21AM +, Jongman Heo wrote:
Looks like following commit causes a segmentation fault in my machine
(when running git pull or git fetch);
commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
Author: Junio C Hamano gits...@pobox.com
Date: Mon Jan 7 12:24:55 2013
In clean.c we have a string_list created on the stack with
STRING_LIST_INIT_NODUP (there are probably others, I stopped at the
first occurrence).
But, STRING_LIST_INIT_NODUP doesn't init the list-cmp pointer
which can thus be random.
I don't have much time to provide a patch right now (have to go
On Thu, Jan 31, 2013 at 7:49 AM, Jeff King wrote:
On Thu, Jan 31, 2013 at 01:35:21AM +, Jongman Heo wrote:
Looks like following commit causes a segmentation fault in my machine
(when running git pull or git fetch);
commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
Author: Junio C Hamano
On Thu, Jan 31, 2013 at 07:27:04AM +, Jongman Heo wrote:
FYI, gdb backtrace and valgrind output attached below, Thanks.
Thanks, that's helpful.
#4 0x0812bda0 in string_list_insert (list=0xbfffe7c0, string=0x821ec3c
refs/remotes/origin/HEAD) at string-list.c:57
#5 0x08071838 in
32 matches
Mail list logo
