<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 26, 2022 at 2:41 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/25/22 09:43, enh wrote:<br>
> *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>
> <br>
> yeah, although it's not nearly as cool without the stacks, just knowing you have<br>
> a problem is step 1.<br>
<br>
It's a hang without ASAN. Not exactly subtle. :)<br>
<br>
The immediate problem is that my dump_hunks() is getting lines out of sync and<br>
falling off the end of one of the arrays. The more INTERESTING problem is that<br>
debian's diff says the failing hunk is:<br>
<br>
--- dif1.c 2022-08-26 00:54:19.827964685 -0500<br>
+++ dif2.c 2022-08-26 00:54:41.231964278 -0500<br>
@@ -8,30 +8,15 @@<br>
return strcmp(ln1->linedata, ln2->linedata) == MATCH;<br>
}<br>
<br>
-BOOL match(LINE *oldp, LINE *newp)<br>
+bool match(LINE *oldp, LINE *newp)<br>
{<br>
int i;<br>
for ( i=0; i < minmatch; i++, oldp = oldp->next, newp = newp->next )<br>
if ( !eq(oldp, newp) )<br>
- return FALSE;<br>
- return TRUE;<br>
+ return false;<br>
+ return true;<br>
}<br>
<br>
-#if 00<br>
-void putqln(LINE *pln, DFILE *file)<br>
-{<br>
- if ( ! pln->lneof ) {<br>
- if ( in_context_sw )<br>
- if ( file == oldf )<br>
- printf("<<< ");<br>
- else<br>
- printf("| ");<br>
- printf("%s\n", pln->linedata);<br>
- }<br>
- freeln(pln);<br>
-}<br>
-#endif<br>
-<br>
void putqln(LINE *pln, DFILE *file)<br>
{<br>
if ( ! pln->lneof ) {<br>
<br>
Which if you'll notice repeats the last three lines: they're removed right after<br>
the #if and also occur after the #endif as the last three lines. And my<br>
simple/greedy algorithm is trying to call the first three _matches_ and then<br>
have the rest of the file be one big subtraction, which means it's not nicely<br>
bracketd with matching intro/exit lines. (The find_hunk() logic ensures such a<br>
bracketing, but the dump_hunk() logic's simplistic decision on how to display it<br>
does not.)<br>
<br>
Also, debian is saying -8,30 +8,15 and mine's saying -8,29 +8,14 which I'm still<br>
trying to track down....<br>
<br>
On the whole, good test case. :)<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>
> <br>
> yeah, like i say --- i've been a heavy asan/hwasan user for years but i don't<br>
> think i've _once_ used the shadow map. as far as i'm concerned it's just "how it<br>
> works", so none of my business. (though when i talked to them about the error<br>
> wording [for which there are now llvm patches up], they said they should fix the<br>
> addresses in the dump to be the actual heap addresses, not the shadow addresses.)<br>
<br>
People have done things like "electric fence" for decades, usually with a<br>
horrible performance penalty. After QEMU and xen/kvm got popular intel and arm<br>
got into a race to improve their mmu capabilities and people started trying to<br>
apply that to the memory access pattern validation problems (multiple <a href="http://lwn.net" rel="noreferrer" target="_blank">lwn.net</a><br>
articles about that a decade or so back) with the dream of making it cheap<br>
enough to leave on at deployment, and it's nice to see that stuff finally bear<br>
fruit. But it's not exactly new. :)<br>
<br>
I first wrote my own heap walker to periodically validate its integrity back<br>
under OS/2. (The codebase I inherited had _five_ alloc/free contexts in play all<br>
at once and every once in a while the OS/2 equivalent of MMAP_ANONYMOUS would<br>
get passed to SOM_free() and it would quietly swallow it and continue for 5<br>
seconds or so and then an unrelated thread would explode. Yes that was in a<br>
heavily threaded environment. The OS/2 desktop ("workplace shell") instantiated<br>
new objects by loading shared libraries into a giant shared process space. (And<br>
I think firing up a new thread to run its constructor function? It's been a<br>
while. I worked on their new package management system, "Feature install", which<br>
was a subclass of the "folder" object in the workplace shell which was built on<br>
top of IBM's System Object Model (one of the first implementations of the Common<br>
Object Request Broker Architecture which was just horrific) which had metaclass<br>
instance objects acting as factories (java did NOT have proper metaclasses, at<br>
least not for many years), but ultimately it all got its memory from the heap<br>
maintained by the C library which got memory from the OS. Of COURSE I<br>
independently invented page poisoning without knowing what it was called. I did<br>
the same for "linked lists" as a teenager. Heck, in college I reinvented<br>
bytecode and was all excited about it until I got introduced to java a few years<br>
later.)<br>
<br>
This is one of the reasons computer history interests me. The new people<br>
reinveting the wheel for the 50th time mistake the ruts from heavily trodden<br>
ground for geology. </blockquote><div><br></div><div>i don't think that's true of any of the asan/hwasn/mte folks ... my feeling from working with them for years is that they were quite clear that their mission was "how do we make these abilities mainstream --- something that everyone's using, all the time, everywhere?". (aka "your umbrella's no use if you left it at home" :-) )</div><div><br></div><div>to me that's the flip side of the william gibson "the future's already here, it's just unevenly distributed" quote --- the most useful and impactful work you can be doing at any given time is making something good cheap enough that everyone can have one. (obviously that's not an unalloyed good: i'm happier about bicycle proliferation than car proliferation, for example, and belatedly moving away from the ICE only solves one of the problems with cars, but at least down in my corner of the tech world it's hard to argue against robustness and security. our negative side-effects are mainly just "cheap != free". a $30 phone still isn't as secure as a $100 phone, for example [though of course there are positive side-effects for the less protected devices of having found and fixed more bugs on the more protected devices and sharing the code].)</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">You want to find the REALLY fun ideas, ask why Grace Hopper<br>
did what she did when inventing shared libraries. (She talked about it in the<br>
HOPL keynote talk, which is in a book in the UT library I photocopied a bunch of<br>
pages out of, but not available online that I know of? In theory the talk is on<br>
video, in PRACTICE I went to the library that claimed to have it and they didn't<br>
want to dig the old VHS tapes out of the back room because they were too fragile<br>
or something... Ah, looks like it might be available online?<br>
<a href="https://dl.acm.org/doi/10.1145/800025.1198341" rel="noreferrer" target="_blank">https://dl.acm.org/doi/10.1145/800025.1198341</a> )<br>
<br>
Anyway, back to poking at diff...<br>
<br>
Rob<br>
</blockquote></div></div>