Re: Bug in reflog of length 0x2BFF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 04.12.14 21:18, schrieb Junio C Hamano:
> Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
>> Could you make a test script that illustrates and reproduces the
>> problem?  I.e., a patch to a file like t/t1410-reflog.sh, such that
>> if I run
>>
>> 	cd git
>> 	make
>> 	cd t
>> 	./t1410-reflog.sh
>>
>> then I can reproduce the bug?
> 
> Amen to that.  I am getting the same thing.

I ran reproduce it reliably on multiple machines (OS X, FreeBSD, ia32,
amd64), a friend of mine can, too.
I already sent a test-patch, here it is again:
	http://tron.yamagi.org/zeug/0001-t1410-Test-erroneous-skipping-of-reflog-entries.patch
Using this test, bisect reliably gives
	4207ed285f31ad3e04f08254237c0c1a1609642b
as culprit.
It seems that Linux does not exhibit this particular behaviour.
Maybe there are differences in memory allocation, which mask the symptom.
Stefan Beller experienced some other sporadic bug regarding the reflog:
	http://marc.info/?l=git&m=141748434801505&w=2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]