Suggested Memory Error Detection ASAN.

delphi package - automated exception handling
Post Reply
mattg
Posts: 17
Joined: Thu Apr 27, 2017 11:25 pm

Suggested Memory Error Detection ASAN.

Post by mattg »

Hi Mathias

Would you be able to implement a software version of this (especially 64bit), it picks up the different forms of memory corruption with a single check.

https://android-developers.googleblog.c ... wasan.html

"SWASAN" like android used to use.

Kind Regards
Matt
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Suggested Memory Error Detection ASAN.

Post by madshi »

madExcept already catches most (all?) of these problems right now, if you activate the "instantly crash on buffer overrun" feature. Doing so does consume a lot of extra RAM, though. On a positive note, any time such a problem happens, you'll get an exception *instantly*, pointing at the offending code.
mattg
Posts: 17
Joined: Thu Apr 27, 2017 11:25 pm

Re: Suggested Memory Error Detection ASAN.

Post by mattg »

How do you go with testing for accessing already freed memory - this is a big issue for us we use FastMM4 currently to pick up these.
with a build you have to select under run or overrun so have to do twice as many checks while using the software to pickup this kind of error.

ASAN handles all these situations so would be a big advantage.
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Suggested Memory Error Detection ASAN.

Post by madshi »

If you activate either "crash on overrun" or "crash on underrun", the memory manager is replaced with a madExcept special memory manager which automatically raises exceptions if you access an already freed allocation or if you free an allocation twice etc. So all these potential issues should already be handled.

Yes, it's true that you have to decide whether to check for buffer overruns or underruns, you can' test for both at the same time. However, buffer underruns are quite rare, compared to buffer overruns.

Overall, I don't see the big benefit of switching to ASAN compared to what I already have. I'm not even sure if ASAN raises exceptions in the moment when the buffer overrun occurs? The documentation isn't very clear on that. It's quite possible that it only detects buffer overruns after the fact (e.g. in the moment when you free the buffer). If that's the case, it would actually be a noticeably inferior solution compared to what madExcept does.

To sum up: Porting over an Android solution to Windows would probably very time consuming, and considering that there are only small improvements to be had (and potentially it could even be a worse solution!), it doesn't really seem to be worth the effort, from what I can see right now.
Post Reply