<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 25, 2022 at 4:18 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">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/24/22 10:22, enh wrote:<br>
> xprintf() was called BY NOTHING, and<br>
> there's no dump of the data IN the region but there is:<br>
> <br>
> did you compile everything with `-fno-omit-frame-pointer`? iirc asan's unwinder<br>
> needs frame pointers (because you want it to be fast, because it's recording a<br>
> lot of stacks). works for free on arm64, but on the z80 with no registers that<br>
> you're using, you'll need to tell the compiler. (if you're using my ASAN=1<br>
> support in toybox you should get that, but maybe you need to do a clean rebuild?)<br>
<br>
I've made it to poking at Ray Gardner's test case, and:<br>
<br>
$ ASAN=1 make clean diff && ./diff thingy1 thingy2<br>
...<br>
==24453==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c00002643f<br>
at pc 0x563d7667e9e9 bp 0x7ffe72b18420 sp 0x7ffe72b18418<br>
READ of size 1 at 0x60c00002643f thread T0<br>
#0 0x563d7667e9e8 in diffcmp toys/pending/diff.c:69<br>
<br>
Which is diffcmp(), which was called by nothing. (Rather than by qsort(), which<br>
is normally what calls it?) It did a clean and then rebuilt everything. Maybe<br>
glibc is built without frame pointers?<br></blockquote><div><br></div><div>ugh. not being a glibc person, i hadn't thought of this. (there are so many reasons i can't wait for [non-mac] arm64 laptops to come down to sensible prices, and having enough registers not to scrimp and save is one of them!)</div><div><br></div><div>i'll ask, but since google3 builds its own libc and android _has_ its own libc, i don't know what the answer will be. (something to add to your musl build flags though :-) )</div><div><br></div><div>(amusingly, a quick web search found a thread where they were talking to glibc folks about not just building glibc with frame pointers but building it with asan instrumentation, and were finding memory bugs _in_ glibc that were getting in the way... that was 2016 though.)</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">
*shrug* I've been tracking these things down for years without this tool, it's<br>
not a blocker. But the callstack would save time bisecting the code with printfs<br>
to figure out where it went off the rails...<br></blockquote><div><br></div><div>yeah, although it's not nearly as cool without the stacks, just knowing you have a problem is step 1.</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>
> <br>
> i never use the shadow so i've never noticed that myself, but i assume it's just<br>
> because it's showing the _shadow_ address, and (since the shadow is smaller than<br>
> the real memory) it can't really show corresponding addresses.<br>
<br>
Dunno what a shadow address is... it's the address of a shadow byte. Lovely.<br>
What is...<br>
<br>
<a href="https://stackoverflow.com/questions/61674317/what-are-shadow-bytes-in-addresssanitizer-and-how-should-i-interpret-them" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/61674317/what-are-shadow-bytes-in-addresssanitizer-and-how-should-i-interpret-them</a><br>
<br>
I made it as far as 'both of those have value fa, meaning "Heap left redzone"'<br>
and stopped because I have other things to do. This goes on the todo heap with<br>
valgrind and making better use of gdb and so on.<br></blockquote><div><br></div><div>yeah, like i say --- i've been a heavy asan/hwasan user for years but i don't think i've _once_ used the shadow map. as far as i'm concerned it's just "how it works", so none of my business. (though when i talked to them about the error wording [for which there are now llvm patches up], they said they should fix the addresses in the dump to be the actual heap addresses, not the shadow 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">
My first job out of college, I came fully up to speed on the debugger built into<br>
the IDE in IBM's OS/2 compiler (as opposed to EMX, the OS/2 port of gcc I'd been<br>
using before), and I used it for EVERYTHING... until I left that job and had to<br>
leave that toolset behind.<br>
<br>
Since then?<br>
<br>
<a href="https://www.youtube.com/watch?v=nCKkHqlx9dE" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=nCKkHqlx9dE</a><br>
<br>
If you can't reproduce it from first principles, you're not doing science. (Yes<br>
I built the OS from source. Yes I maintained a C compiler fork. Yes I worked on<br>
a CPU implementation in VHDL. There's a theme here...)<br>
<br>
> yeah, it's not just you. you do get used to them -- since they all look roughly<br>
> the same -- but it's unfortunate you have to. (i think just "before" or "after"<br>
> would be good steps forward.)<br>
<br>
I lean towards depth first rather than breadth first searches, and I'm just<br>
climbing OUT of the diff rathole. Trying to close tabs...<br>
<br>
Rob<br>
</blockquote></div></div>
</div>