3 ms·

This is not Google's project from what I see. Also its just another version of electric fence which existed ever since I started debugging code. Correct me if

by yalogin 15y ago

This is not Google's project from what I see. Also its just another version of electric fence which existed ever since I started debugging code. Correct me if I am wrong.

justinschuh 15y ago
I've worked with the team that built it, so I can verify that ASAN is definitely a Google project. Also, some other people have posted comments to links that verify the association. As for the electric fence comparison, ASANs strengths are that it provides more detailed reports and detects more types of errors, but is still very fast. For example, ASAN will detect stack and global boundary violations, whereas electric fence will not.
vidarh 15y ago
> Also its just another version of electric fence which existed ever since I started debugging code. Correct me if I am wrong. I was about to say the same thing (though comparing it to Mungwall and Enforcer on AmigaOS), but then I read through it in more detail. There are significant differences: Electric Fence/Mungwall/Enforcer type systems rely on one or both of poisoning and using the MMU to trap accesses. But the MMU approach only works fast if you only trap access to unallocated pages, not if you try to trap every access. That's where the comparison to Valgrind comes in - Valgrind checks every memory access precisely. But it's ridiculously slow. So you get immediate feedback for accesses to unallocated pages from the simpler tools, and very quickly, since it's no slower than any other memory access through the MMU, except when there's a hit. Tools like this may or may not try to be more precise by trapping accesses to partially allocated pages, but if they do, performance drops dramatically. Then they can trap writes to poisoned areas where they don't trap reads by running checks for magic values at specific times - typically at least on free() and program exit. The problem with this is that it won't pinpoint where the write happened, and it won't catch reads of unallocated memory. But this tool inlines code during compilation that checks every dereferencing of every pointer, as far as I understand, by maintaining a lookup table that says whether or not a specific byte is allocated or not. The upside is that they can be as precise as Valgrind.
- yalogin 15y ago
  Oh. Thanks for the clarification.

by yalogin 15y ago

This is not Google's project from what I see. Also its just another version of electric fence which existed ever since I started debugging code. Correct me if I am wrong.

justinschuh 15y ago

I've worked with the team that built it, so I can verify that ASAN is definitely a Google project. Also, some other people have posted comments to links that verify the association. As for the electric fence comparison, ASANs strengths are that it provides more detailed reports and detects more types of errors, but is still very fast. For example, ASAN will detect stack and global boundary violations, whereas electric fence will not.

vidarh 15y ago

> Also its just another version of electric fence which existed ever since I started debugging code. Correct me if I am wrong. I was about to say the same thing (though comparing it to Mungwall and Enforcer on AmigaOS), but then I read through it in more detail. There are significant differences: Electric Fence/Mungwall/Enforcer type systems rely on one or both of poisoning and using the MMU to trap accesses. But the MMU approach only works fast if you only trap access to unallocated pages, not if you try to trap every access. That's where the comparison to Valgrind comes in - Valgrind checks every memory access precisely. But it's ridiculously slow. So you get immediate feedback for accesses to unallocated pages from the simpler tools, and very quickly, since it's no slower than any other memory access through the MMU, except when there's a hit. Tools like this may or may not try to be more precise by trapping accesses to partially allocated pages, but if they do, performance drops dramatically. Then they can trap writes to poisoned areas where they don't trap reads by running checks for magic values at specific times - typically at least on free() and program exit. The problem with this is that it won't pinpoint where the write happened, and it won't catch reads of unallocated memory. But this tool inlines code during compilation that checks every dereferencing of every pointer, as far as I understand, by maintaining a lookup table that says whether or not a specific byte is allocated or not. The upside is that they can be as precise as Valgrind.

yalogin 15y ago
Oh. Thanks for the clarification.