Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Warren Young on Wed, 05 Oct 2016 09:04:57 -0600:

> That's  a nice  bit  of detective  work, Andy!  I  can't imagine  what
> possessed you to keep pursuing it for 8 months, but thank you. :)

Haha, well, it was a bit less glamorous than 8 months of investigations.
:-) I was trying  to get the stash-fixes branch ready  to merge to trunk
and the first thing I did was  create an empty file, rename it, and then
attempt to stash it. I got the  assert and remembered that we hadn't yet
solved the problem, primarily because  nobody was ever able to reproduce
it, so I dug up the old thread.

Thanks,

Andy
-- 
TAI64 timestamp: 400057f557db


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

On Oct 5, 2016, at 12:59 AM, Andy Bradford  wrote:
> 
> I propose that blob_delta_create  should use blob_materialize instead of
> blob_buffer here:
> 
> http://www.fossil-scm.org/index.html/info/75ddc3687acbdb32

That’s a nice bit of detective work, Andy!  I can’t imagine what possessed you 
to keep pursuing it for 8 months, but thank you. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Richard Hipp on Tue, 09 Feb 2016 07:39:57 -0500:

> The  input to  checksum() should  normally be  a pointer  to a  buffer
> obtained  from malloc().  And  such buffers  should  always be  8-byte
> aligned (or  4-byte aligned on Windows).  So I'm not sure  how this is
> happening.  There  must  be  some path  somewhere  in  Fossil  whereby
> delta_create()  or delta_apply()  is called  with a  pointer into  the
> middle of an allocated buffer, rather  than a pointer to the beginning
> of the buffer.

In  some cases,  the input  to checksum(),  specifically, zIn  (which is
actually zOut in the caller  delta_create), may not actually be obtained
from malloc(). I am able to reproduce this particular assertion with the
following:

$ touch file
$ fossil add file
ADDED  file
$ fossil commit -m added
New_Version: 5c966f6fe56d2efd262865f0a504fd102bb0c078
$ fossil mv file other
RENAME file other
$ mv file other
$ fossil stash save -m renamed
assertion "(z - (const unsigned char*)0)%4==0" failed: file "./src/delta.c", 
line 231, function "checksum"
Abort trap (core dumped) 

Given that blob_zero initializes pBlob->aData here:

http://www.fossil-scm.org/index.html/artifact/831a63c8c61dbfdb5fe629a473cd7b01104478fc?txt=1=262+266

Then, stash tries to read a file that is empty:

http://www.fossil-scm.org/index.html/artifact/ced32acae9b125f723c6473f30cdfdf8b530dc37?txt=1=123+126

In this  case, pBlob->aData has  not been allocated by  malloc() because
the file was  empty (file size of  0 so the blob was  never altered from
its initial  state). And sure enough,  the address of memory  for zIn (a
buffer pointing to pBlob->aData) on one invocation on my system:

Breakpoint 4, checksum (zIn=0x36127dfb "", N=0) at delta.c:226
226 static unsigned int checksum(const char *zIn, size_t N){

$ echo 'puts [expr {0x36127dfb % 4}]' | tclsh
3

Which is why the assertion fails.

I propose that blob_delta_create  should use blob_materialize instead of
blob_buffer here:

http://www.fossil-scm.org/index.html/info/75ddc3687acbdb32

Thanks,

Andy
-- 
TAI64 timestamp: 400057f4a4f8


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

On Feb 19, 2016, at 9:04 PM, Andy Bradford  wrote:
> 
> Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
> pTarget=0x7fffaf5dccd0:

I’m on a 64-bit machine.  If yours OS or executable is 32-bit, that explains it.

Also, different OSes use different defaults in how they present the address 
space to applications.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Stephan Beal on Sat, 20 Feb 2016 04:46:51 +0100:

> i  see lots  of 0x7ffs  in there,  and i  happen to  know that
> se=... is  indeed a stack-allocated  object. i'm a bit  surprised that
> argv is, but not overly so.

Yeah, I guess it's  more common than I thought and I'm  not used to such
big stack values.

$ echo 16i7FFFE330p | dc
140737488347952

Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
pTarget=0x7fffaf5dccd0:

Breakpoint 4, blob_delta_create (pOriginal=0xcf7c6318, pTarget=0xcf7c6300, 
pDelta=0xcf7c6330) at deltacmd.c:28
28  int blob_delta_create(Blob *pOriginal, Blob *pTarget, Blob *pDelta){
(gdb) bt
#0  blob_delta_create (pOriginal=0xcf7c6318, pTarget=0xcf7c6300, 
pDelta=0xcf7c6330) at deltacmd.c:28
#1  0x146000c0 in stash_add_file_or_dir (stashid=1, vid=Variable "vid" is not 
available.
) at stash.c:126
#2  0x146002dc in stash_create () at stash.c:195
#3  0x14600a3a in stash_cmd () at stash.c:499
#4  0x145d48c9 in main (argc=5, argv=0xcf7c66b4) at main.c:804

Sorry for wasting everyone's time, I  just noticed that there was a huge
difference in  what the OP reported  and what I was  seeing, but clearly
there  are some  architectural differences  that  lead to  a huge  stack
address  in some  cases and  I wondered  if somehow  the addresses  were
wrong---case ignored. :-)

Thanks,

Andy
-- 
TAI64 timestamp: 400056c7e5e7


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Sat, Feb 20, 2016 at 4:42 AM, Andy Bradford 
wrote:

> Thus said Martin Gagnon on Fri, 19 Feb 2016 20:56:47 -0500:
>
> > This is not usually stack addresses?
>
> Yes, for  allocated memory, but  how big is  the stack that  supports an
> address that big?
>


Dunno. Just kinda randomly taking a backtrace from a random program...

#0  0x776b6810 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1  0x779b9a7d in rl_getc () from
/lib/x86_64-linux-gnu/libreadline.so.6
#2  0x779ba2ae in rl_read_key () from
/lib/x86_64-linux-gnu/libreadline.so.6
#3  0x779a3edc in readline_internal_char () from
/lib/x86_64-linux-gnu/libreadline.so.6
#4  0x779a4625 in readline () from
/lib/x86_64-linux-gnu/libreadline.so.6
#5  0x0040c4a8 in s2sh_line_read (prompt=0x48051d "s2> ") at
shell.c:636
#6  0x0040cc8d in s2sh_interactive (se=0x7fffcfb0) at
shell.c:842
#7  0x0040d217 in s2sh_main2 (se=0x7fffcfb0) at shell.c:1021
#8  0x0040d933 in s2sh_main (argc=1, argv=0x7fffdb78) at
shell.c:1157
#9  0x0040eaaf in main (argc=1, argv=0x7fffdb78) at shell.c:1555

i see lots of 0x7ffs in there, and i happen to know that se=... is
indeed a stack-allocated object. i'm a bit surprised that argv is, but not
overly so.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Martin Gagnon on Fri, 19 Feb 2016 20:56:47 -0500:

> This is not usually stack addresses?

Yes, for  allocated memory, but  how big is  the stack that  supports an
address that big?

Andy
-- 
TAI64 timestamp: 400056c7e0c0


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Sat, Feb 20, 2016 at 2:53 AM, Andy Bradford 
wrote:

> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
>
> > #5  0x004237f6 in blob_delta_create (pOriginal= out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
>
> I could be wrong, but those seem like extreme memory addresses...
>
> Anyone?
>

Stack-allocated. All buffers are.



-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Martin Gagnon]

> Le 19 févr. 2016 à 20:53, Andy Bradford  a écrit :
> 
> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
> 
>> #5  0x004237f6 in blob_delta_create (pOriginal=> out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
> 
> I could be wrong, but those seem like extreme memory addresses...
> 
> Anyone?
> 

This is not usually stack addresses?

-- 
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:

> #5  0x004237f6 in blob_delta_create (pOriginal=, 
> pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40

I could be wrong, but those seem like extreme memory addresses...

Anyone?

Andy
--
TAI64 timestamp: 400056c7c72c
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

On Feb 11, 2016, at 6:05 AM, Richard Hipp  wrote:
> 
> On 2/10/16, Warren Young  wrote:
>> On Feb 9, 2016, at 5:50 AM, Stephan Beal  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 
0x2aaab000
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned 
char*)0)%4==0' failed.

Program received signal SIGABRT, Aborted.
0x0035fee2ffc5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0035fee2ffc5 in raise () from /lib64/libc.so.6
#1  0x0035fee31a70 in abort () from /lib64/libc.so.6
#2  0x0035fee29466 in __assert_fail () from /lib64/libc.so.6
#3  0x00422c72 in checksum (zIn=, N=) at ./src/delta.c:231
#4  0x00422f4f in delta_create (zSrc=0xbb3f60 "", lenSrc=0, 
zOut=0x54183f "", lenOut=0, zDelta=0xb6b4b4 "5") at ./src/delta.c:372
#5  0x004237f6 in blob_delta_create (pOriginal=, 
pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
#6  0x0046a833 in stash_add_file_or_dir (stashid=, 
vid=, zFName=) at ./src/stash.c:126
#7  0x0046a9d5 in stash_create () at ./src/stash.c:195
#8  0x0046af08 in stash_cmd () at ./src/stash.c:494
#9  0x00447e55 in main (argc=, argv=) 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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Richard Hipp]

On 2/10/16, Warren Young  wrote:
> On Feb 9, 2016, at 5:50 AM, Stephan Beal  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.

Can you please run your example for me, capture the failure in a
debugger, and send a stack trace?
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Ross Berteig]

On 2/11/2016 10:06 AM, Ross Berteig wrote:

What does fossil revert do in this circumstance?
It says:

   REVERT f1
   DELETE f1new
"fossil undo" is available to undo changes to the working checkout.

and has now forgotten the pending rename.

I think that fossil stash save *should* do the same thing. It doesn't.


I've updated the test case in stash.test to call this a knownBug.

While looking at revert.test, I noticed another interesting edge case 
surrounding renames:


$ fossil mv f1 f1old
$ mv f1 f1old
$ echo "hi" > f1
$ fossil add f1
$ fossil revert

Replacing "revert" with "stash" causes SQLite to freak out:

SQLITE_CONSTRAINT: {abort at 19 in [INSERT INTO stashfile(stashid, 
rid, isAdded, isRemoved, isExec, isLink,origname, newname, 
delta)VALUES(1,:rid,:isadd,:isrm,:isexe,:islink,:orig,:new,:content)]: 
UNIQUE constraint failed: stashf}


This is now tested in stash.test, and also marked as a knownBug.

--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Ross Berteig]

On 2/10/2016 10:41 PM, Andy Bradford wrote:

Thus said Ross Berteig on Wed, 10 Feb 2016 15:48:40 -0800:


which as  expected renamed the file  in the repository but  not on the
disk. It then says

fossil stash -m "B 2016-02-09"


Did you mean:

fossil stash save -m "B 2016-02-09"


Yes, typo in transcribing to email. The actual command is buried inside 
test/stash.test inside a call to stash-test. (In the current checkin, 
hidden inside an if {false} {} block pending this discussion.)



ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new
What was fossil stash supposed to do in this circumstance?


It marked  the file  as being renamed  but did not  change the  disk, as
documented in ``fossil help mv'': 


Right. "It" being fossil mv, not fossil stash save. That seems to be the 
condition in which the OP reports seeing the assertion fail at 
delta.c:231, which I'm trying to replicate in a test case.




You asked  Fossil to prepare the  repository for a file  move, but never
moved the  files. Then when  you attempted  to stash the  change, Fossil
complained because it  expected to find f1new, but you  never renamed f1
to f1new.  If you  had also  then done ``fossil  status'' it  would have
reported f1new as MISSING.


So is this the expected behavior then?

Fossil help stash says "save the current changes... as a new stash" but 
is silent about the case of a rename marked in the repo but not 
completed on disk.


Since the purpose (as I understand it) of the fossil stash command is to 
allow partially completed work to be set aside and recalled later, it 
seems logical (and necessary) that renames are part of what it saves.


What does fossil revert do in this circumstance?

It says:

  REVERT f1
  DELETE f1new
   "fossil undo" is available to undo changes to the working checkout.

and has now forgotten the pending rename.

I think that fossil stash save *should* do the same thing. It doesn't.

So what I'm really asking here is whether that MISSING error produced by 
fossil stash save represents a bug (shortcoming at least) in the 
documentation or a bug in the stash itself?


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

On Feb 9, 2016, at 5:50 AM, Stephan Beal  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 always enable --with-legacy-mv-rm in my Fossil builds, and always set the 
option to make fossil mv/rm behave like POSIX mv/rm.

However, this nonstandard option is not at fault per se.  This also triggers it 
with a default build:

mv foo.c bar.c
f mv --soft foo.c bar.c
f stash

So, the problem is trying to stash a renamed file.

If it matters — since alignment was brought up — this is a 64-bit Intel box.  
This program prints “8, 4” here:

#include 

int main(void)
{
printf("%d, %d\n", sizeof(unsigned char*), sizeof(int));
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Andy Bradford]

Thus said Ross Berteig on Wed, 10 Feb 2016 15:48:40 -0800:

> which as  expected renamed the file  in the repository but  not on the
> disk. It then says
>
>   fossil stash -m "B 2016-02-09"

Did you mean:

fossil stash save -m "B 2016-02-09"


>   ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new
> 
> What was fossil stash supposed to do in this circumstance?

It marked  the file  as being renamed  but did not  change the  disk, as
documented in ``fossil help mv'':

WARNING: If the "--hard" option is specified -OR- the "mv-rm-files"
 setting is non-zero, files WILL BE renamed or moved on disk
 as well.  This does NOT apply to the 'rename' command.

Options:
  --soft  Skip moving files within the checkout.
  This supersedes the --hard option.
  --hard  Move files within the checkout.


You asked  Fossil to prepare the  repository for a file  move, but never
moved the  files. Then when  you attempted  to stash the  change, Fossil
complained because it  expected to find f1new, but you  never renamed f1
to f1new.  If you  had also  then done ``fossil  status'' it  would have
reported f1new as MISSING.

Andy
-- 
TAI64 timestamp: 400056bc2d39


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Ross Berteig]

On 2/10/2016 7:35 AM, Warren Young wrote:


However, this nonstandard option is not at fault per se.  This also triggers it 
with a default build:

 mv foo.c bar.c
 f mv --soft foo.c bar.c
 f stash

So, the problem is trying to stash a renamed file.


Given this nice, concise, and obviously minimal script to cause fossil 
stash to fail, I added it to our regression tests. First I had to create 
test/stash.test which I modeled after test/revert.test since there are 
huge similarities between fossil stash save and fossil revert both in 
function and in output.


Two interesting results turn up from that effort.

First, I don't reproduce the assertion failure on my 32-bit Windows 
build. This might not be surprising at all, it could absolutely be a 
quirk of having 32-bit integers and 64-bit pointers as documented for 
the OP's configuration.


Second, I don't get a stash saved at all.

My case starts from a clean checkout that has three unedited files. It does

fossil mv --soft f1 f1new

which as expected renamed the file in the repository but not on the 
disk. It then says


fossil stash -m "B 2016-02-09"

which says

ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new

and does not create any stash entry.


What was fossil stash supposed to do in this circumstance? The early 
test case (modeled after fossil revert's behavior) modeled the stashed 
rename oddly as well, but at least it did model it.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

On Feb 10, 2016, at 4:48 PM, Ross Berteig  wrote:
> 
> What was fossil stash supposed to do in this circumstance?

OP expects the stash to be as capable as bundles, differing only in where the 
archived data are stored and how each archive is named.  (Stash IDs vs bundle 
file names.)  If bundles can remember a moved or deleted file, the stash 
should, too.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Warren Young]

I was getting this from “fossil stash” for no obvious reason:

  fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned 
char*)0)%4==0' failed.

Rebuilding both the local repo and the master repo didn’t help.  Closing the 
current checkout and re-opening it did.

The number of uncommitted changes was rather large, so instead of attempting to 
put the fresh checkout back into the pre-failure state, I just backed up my 
changes outside of Fossil and let Fossil overwrite the changed files.  (I 
re-opened the repo over the top of the previous checkout rather than do all of 
this in a new tree.)

As a test after re-opening the repo, I deleted part of a function and stashed 
that, then removed it from the stash.  Stashing seems to work fine now.

Here’s the backtrace from the resulting SIGABRT core dump:


#0  0x0035fee2ffc5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0035fee2ffc5 in raise () from /lib64/libc.so.6
#1  0x0035fee31a70 in abort () from /lib64/libc.so.6
#2  0x0035fee29466 in __assert_fail () from /lib64/libc.so.6
#3  0x00422c72 in checksum (zIn=, N=) at ./src/delta.c:231
#4  0x00422f4f in delta_create (zSrc=0x13e8dde0 "", lenSrc=0, 
zOut=0x54183f "", lenOut=0, zDelta=0x13e8cf14 "5") at ./src/delta.c:372
#5  0x004237f6 in blob_delta_create (pOriginal=, 
pTarget=0x7fffaf5dccd0, pDelta=0x7fffaf5dcd10) at ./src/deltacmd.c:40
#6  0x0046a833 in stash_add_file_or_dir (stashid=, 
vid=, zFName=) at ./src/stash.c:126
#7  0x0046a9d5 in stash_create () at ./src/stash.c:195
#8  0x0046af08 in stash_cmd () at ./src/stash.c:494
#9  0x00447e55 in main (argc=, argv=) at ./src/main.c:804


This was with version [b8c7af5bd9], plus the patch I recently sent to the list, 
running on CentOS 5.

Since I purposely did not leave my local repo in a state where I can reproduce 
this, I don’t know if there’s any more help I can provide in tracking this down.

When I say that this happened for no obvious reason, I mean that I can’t tie 
this event to a prior event.  The system didn’t crash, it was working just fine 
prior to the error, etc.  This failure just seemed to come out of the blue.

The only odd thing is that this is probably the largest stash I’ve ever 
attempted.  38 files changed, and coming to about 2300 lines of diffs.

(Ever gone down a rat hole, got lost, and needed to teleport back to the 
surface?  Yeah, one of those.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Tue, Feb 9, 2016 at 1:43 PM, Stephan Beal  wrote:

> On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp  wrote:
>
>> work regardless on Intel, but other platforms (ARM, Sparc) have
>> stricter alignment requirements.
>>
>
> i'm powering up the ARM now to try to reproduce it.
>
> But how does the (unsigned char *) cast on the NULL pointer affect the
> result of (z-0)?
>

Isn't there a danger of the compiler optimizing out that -0? Or is that the
reason for the cast?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Richard Hipp]

On 2/9/16, Stephan Beal  wrote:
>
> But how does the (unsigned char *) cast on the NULL pointer affect the
> result of (z-0)?

That was my effort to convert a pointer into an integer in a way that
is portable across a variety of compilers.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Tue, Feb 9, 2016 at 1:43 PM, Stephan Beal  wrote:

> On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp  wrote:
>
>> work regardless on Intel, but other platforms (ARM, Sparc) have
>> stricter alignment requirements.
>>
>
> i'm powering up the ARM now to try to reproduce it.
>

Unfortunately no such luck:

i mangled 75 files (some replaced completely, some trimmed to their own
head -20/tail -10 lines) and was able to stash and unstash:

[odroid@host:~/fossil/fossil/www]$ f diff | wc -l
51302
[odroid@host:~/fossil/fossil/www]$ fst | grep MOD -c
75
[odroid@host:~/fossil/fossil/www]$ f stash save -m 'assert test'
REVERT   test/amend.test
REVERT   test/clean.test
REVERT   test/cmdline.test
REVERT   test/comment.test
...
[odroid@host:~/fossil/fossil/www]$ f stash pop
UPDATE test/amend.test
UPDATE test/clean.test
UPDATE test/cmdline.test
UPDATE test/comment.test
UPDATE test/contains-selector
...

[odroid@host:~/fossil/fossil/www]$ f ver
This is fossil version 1.35 [7cadfc9736] 2016-02-07 23:35:16 UTC


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Richard Hipp]

On 2/9/16, Stephan Beal  wrote:
> On Tue, Feb 9, 2016 at 12:51 PM, Richard Hipp  wrote:
>
>> On 2/9/16, Warren Young  wrote:
>> > I was getting this from “fossil stash” for no obvious reason:
>> >
>> >   fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
>> > char*)0)%4==0' failed.
>>
>> I wish you could reproduce this, because that is an important
>> assertion and I would really like to chase this to ground.
>>
>
> Out of curiosity: what is the purpose of the type cast for the 0/NULL?
>
> i've never seen that construct before except when required for overload
> disambiguation in C++.

The assert() is checking to ensure that its input buffer has the
correct alignment to allow the content to be access as an array of
32-bit integers.  Accessing the input as an array of integers would
work regardless on Intel, but other platforms (ARM, Sparc) have
stricter alignment requirements.

The input to checksum() should normally be a pointer to a buffer
obtained from malloc().  And such buffers should always be 8-byte
aligned (or 4-byte aligned on Windows).  So I'm not sure how this is
happening.  There must be some path somewhere in Fossil whereby
delta_create() or delta_apply() is called with a pointer into the
middle of an allocated buffer, rather than a pointer to the beginning
of the buffer.

Any help in tracking down that call is appreciated.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp  wrote:

> work regardless on Intel, but other platforms (ARM, Sparc) have
> stricter alignment requirements.
>

i'm powering up the ARM now to try to reproduce it.

But how does the (unsigned char *) cast on the NULL pointer affect the
result of (z-0)?


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Tue, Feb 9, 2016 at 12:51 PM, Richard Hipp  wrote:

> On 2/9/16, Warren Young  wrote:
> > I was getting this from “fossil stash” for no obvious reason:
> >
> >   fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
> > char*)0)%4==0' failed.
>
> I wish you could reproduce this, because that is an important
> assertion and I would really like to chase this to ground.
>

Out of curiosity: what is the purpose of the type cast for the 0/NULL?

i've never seen that construct before except when required for overload
disambiguation in C++.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Richard Hipp]

On 2/9/16, Warren Young  wrote:
> I was getting this from “fossil stash” for no obvious reason:
>
>   fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
> char*)0)%4==0' failed.

I wish you could reproduce this, because that is an important
assertion and I would really like to chase this to ground.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

[Stephan Beal]

On Tue, Feb 9, 2016 at 9:22 AM, Warren Young  wrote:

>
> This was with version [b8c7af5bd9], plus the patch I recently sent to the
> list, running on CentOS 5.
>

Can you post the configure/build options you used?

The trunk tests are currently running on my ARM (no idea how long that will
take), and then i'll try it out with a large stash of diffs, but it
might(?) only happen with certain build options.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users