On Feb 11, 2016, at 6:05 AM, Richard Hipp <d...@sqlite.org> wrote:
>
> On 2/10/16, Warren Young <w...@etr-usa.com> wrote:
>> On Feb 9, 2016, at 5:50 AM, Stephan Beal <sgb...@googlemail.com> wrote:
>>>
>>> Can you post the configure/build options you used?
>>
>> Well, you kind of nailed it. I’ve reproduced the problem thusly:
>>
>> f set mv-rm-files 1
>> f mv foo.c bar.c
>> f stash
>
> I cannot seem to repro the problem.
It seems the problem is repository-specific. I also fail to reproduce it in a
fresh repository and in a different long-running (but smaller) Fossil repo I
have here.
> Can you please run your example for me, capture the failure in a
> debugger, and send a stack trace?
I ran it inside a debugger this time instead of doing a post-hoc core file
analysis. Here’s the transcript, which gives a backtrace pretty much identical
to the one in the initial post:
$ fossil move --hard something other-thing
$ gdb `which fossil`
(gdb) run stash save -m 'reverted file rename'
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x2aaaaaaab000
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
char*)0)%4==0' failed.
Program received signal SIGABRT, Aborted.
0x00000035fee2ffc5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00000035fee2ffc5 in raise () from /lib64/libc.so.6
#1 0x00000035fee31a70 in abort () from /lib64/libc.so.6
#2 0x00000035fee29466 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000422c72 in checksum (zIn=<value optimized out>, N=<value
optimized out>) at ./src/delta.c:231
#4 0x0000000000422f4f in delta_create (zSrc=0xbb3f60 "", lenSrc=0,
zOut=0x54183f "", lenOut=0, zDelta=0xb6b4b4 "5") at ./src/delta.c:372
#5 0x00000000004237f6 in blob_delta_create (pOriginal=<value optimized out>,
pTarget=0x7fffffffe330, pDelta=0x7fffffffe370) at ./src/deltacmd.c:40
#6 0x000000000046a833 in stash_add_file_or_dir (stashid=<value optimized out>,
vid=<value optimized out>, zFName=<value optimized out>) at ./src/stash.c:126
#7 0x000000000046a9d5 in stash_create () at ./src/stash.c:195
#8 0x000000000046af08 in stash_cmd () at ./src/stash.c:494
#9 0x0000000000447e55 in main (argc=<value optimized out>, argv=<value
optimized out>) at ./src/main.c:804
I ran the second fossil command under valgrind and didn’t get any earlier
failure, so we’re probably not dealing with secondary damage due to memory
corruption.
In the interest of science, I did the above tests with the same version of
Fossil as originally reported, but then retested with tip of trunk, with no
change.
I’ve also tested this on 64-bit CentOS 7 with a recent Fossil 1.35 build, and
it reproduces with this same repository over there, too. That’s two very
different glibcs and kernels, for what that’s worth. (About 7 years apart.)
I then attempted to reproduce it on OS X 10.10, but got a very different
result, which I will detail in a separate email, titled “Further rename
stashing oddities”. For now, just consider it “correct” with respect to the
behavior expressed in the existing Fossil code.
Thinking, then, that the assertion failure might somehow be a Linux-specific
thing, I tried all of this on an Ubuntu Server 14.04 LTS test VM which has
never seen Fossil *or* this problem repository. Lo and behold, the problem
reproduced.
To test the “Linux-specific” hypothesis, I tried it on a FreeBSD 10 box and got
exactly the same behavior as on OS X.
And finally, to round things off, I tried it on a 64-bit Windows 10 machine,
with both a Cygwin build from source (~3 weeks old) and the native fossil.exe
v1.34 downloaded from fossil-scm.org. The Cygwin build gave the Linux
behavior, while the native build gave the more correct (but still not entirely
kosher) BSD behavior.
I’ve run fossil test-integrity on one of the problem Linux boxes, and it runs
without error:
104007 non-phantom blobs (out of 104007 total) checked: 0 errors
low-level database integrity-check: ok
So what next? Maybe set a breakpoint somewhere in delta_create() and dump some
variables?
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
