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
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 uns
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
w 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.
--
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
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 su
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
>
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
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 wa
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
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 wo
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 gener
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 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 applie
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:
>
>>> 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 compa
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. S
>> [...]
>> 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 prer
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 defini
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 re
Junio C Hamano 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 01:36:38AM -0500, Jeff King wrote:
> On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano 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
> > > clea
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 t
On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano 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.
허종만 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 from this list:
>
[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 somethin
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 initializ
Jeff King 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 string-lis
> 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
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 a
On Thu, Jan 31, 2013 at 08:02:06AM +0100, Antoine Pelisse wrote:
> 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
> whic
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: Juni
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 (
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
> Date: Mon Jan 7 12:24:55 2013 -0800
>
>
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
Date: Mon Jan 7 12:24:55 2013 -0800
string-list: allow case-insensitive string list
In my case, li
34 matches
Mail list logo
