<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 24, 2022 at 1:26 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/22/22 10:39, enh via Toybox wrote:<br>
> On Sun, Aug 21, 2022 at 9:12 AM Ray Gardner <<a href="mailto:raygard@gmail.com" target="_blank">raygard@gmail.com</a><br>
> <mailto:<a href="mailto:raygard@gmail.com" target="_blank">raygard@gmail.com</a>>> wrote:<br>
> <br>
>     I guess I'll skip writing up an explanation of these algos then; I<br>
>     thought you were looking for a less "mathematical" explanation ("why<br>
>     can nobody explain what the old stuff is doing without pretending it's<br>
>     math instead of an algorithm?" "Doug McIlroy's old diff paper from<br>
>     1976 is still written in math-ese. It SEEMS to be describing very<br>
>     simple concepts but it's trying to explain them as if this is<br>
>     calculus, which it is not." etc.) But that's moot if you're going with<br>
>     what appears to be the old "look ahead a little for matching lines to<br>
>     re-sync on" heuristic diff method.<br>
> <br>
> (fwiw, i think such a document would be a useful thing to leave lying around on<br>
> the internet ... someone will want it sooner or later :-) )<br>
<br>
I'm also interested. I've just been a bit distracted because my air conditioner<br>
broke over the weekend (soonest somebody can come fix it is thursday. It's<br>
August in Texas...) and because my diff code isn't quite ready to go back and<br>
run this new test through yet, and I wanted to include that in my reply.<br>
<br>
By the way, using ASAN in testing is kind of annoying. I thought running it on<br>
the "it finally compiled, no idea if anything works" stage might be quicker than<br>
my usual "lots of test data and sticking a zillion printf()s into stuff", but..<br>
<br>
=================================================================<br>
==12782==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000071<br>
at pc 0x7fdb0f844514 bp 0x7ffd8096d900 sp 0x7ffd8096d0b0<br>
READ of size 2 at 0x602000000071 thread T0<br>
    #0 0x7fdb0f844513  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x53513)<br>
    #1 0x7fdb0f84502a in __interceptor_vprintf<br>
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x5402a)<br>
    #2 0x55c63a9693af in xprintf lib/xwrap.c:158<br>
<br>
0x602000000071 is located 0 bytes to the right of 1-byte region<br>
[0x602000000070,0x602000000071)<br>
allocated by thread T0 here:<br>
    #0 0x7fdb0f8da330 in __interceptor_malloc<br>
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)<br>
    #1 0x55c63a968fc1 in xmalloc lib/xwrap.c:71<br>
<br>
So "zero bytes to the right" is bad,</blockquote><div><br></div><div>i've complained to the relevant authorities many times about the wording of these error messages. "strictly correct, but very unclear". i'll pass your complaint along too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">xprintf() was called BY NOTHING, and<br>
there's no dump of the data IN the region but there is:<br></blockquote><div><br></div><div>did you compile everything with `-fno-omit-frame-pointer`? iirc asan's unwinder needs frame pointers (because you want it to be fast, because it's recording a lot of stacks). works for free on arm64, but on the z80 with no registers that you're using, you'll need to tell the compiler. (if you're using my ASAN=1 support in toybox you should get that, but maybe you need to do a clean rebuild?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Shadow bytes around the buggy address:<br>
...<br>
=>0x0c047fff8000: fa fa fd fa fa fa 00 04 fa fa 00 04 fa fa[01]fa<br>
<br>
Which is completely unrelated to ANY of the above addresses?<br></blockquote><div><br></div><div>i never use the shadow so i've never noticed that myself, but i assume it's just because it's showing the _shadow_ address, and (since the shadow is smaller than the real memory) it can't really show corresponding addresses.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(The bug is I had a missing test so "diff one two" was trying to report "Only in<br>
%(dir): %(file)" for both one and two but the dir part of each was being<br>
calculated on the null terminator for the empty list of directories (not IN a<br>
subdir yet) which should never happen because the missing test would prevent it.<br>
But "ASAN was remarkably unhelpful" was the point of my remark above.)<br></blockquote><div><br></div><div>yeah, it's not just you. you do get used to them -- since they all look roughly the same -- but it's unfortunate you have to. (i think just "before" or "after" would be good steps forward.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     Anyway, I applied your 1-or-2 line patch to the Aug. 8 attachment.c<br>
>     you posted and it still chokes on the two files I sent you (dif_old2.c<br>
>     and dif_new.c). So maybe you've made some other significant changes to<br>
>     that code, if it works for you? It appeared to be stuck in dump_hunk()<br>
>     but I didn't look any deeper.<br>
<br>
Lemme get back to you on this. (I'm to the "it compiles but that segfault was<br>
because if (s) should have been if (!s) and now there's another crash later"<br>
stage...)<br>
<br>
Sorry I'm not faster. Working on it...<br>
<br>
Rob<br>
</blockquote></div></div>