Page 1 of 1

Suggested Memory Error Detection ASAN.

Posted: Fri May 22, 2020 2:18 am
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

Re: Suggested Memory Error Detection ASAN.

Posted: Thu May 28, 2020 9:52 pm
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.

Re: Suggested Memory Error Detection ASAN.

Posted: Fri May 29, 2020 8:56 pm
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.

Re: Suggested Memory Error Detection ASAN.

Posted: Sat May 30, 2020 12:20 pm
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.