Suggested Memory Error Detection ASAN.

delphi package - automated exception handling

Suggested Memory Error Detection ASAN.

Postby mattg » Fri May 22, 2020 2:18 am

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.com/2020/02/detecting-memory-corruption-bugs-with-hwasan.html

"SWASAN" like android used to use.

Kind Regards
Matt
mattg
 
Posts: 17
Joined: Thu Apr 27, 2017 11:25 pm

Re: Suggested Memory Error Detection ASAN.

Postby madshi » Thu May 28, 2020 9:52 pm

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.
madshi
Site Admin
 
Posts: 10305
Joined: Sun Mar 21, 2004 5:25 pm

Re: Suggested Memory Error Detection ASAN.

Postby mattg » Fri May 29, 2020 8:56 pm

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.
mattg
 
Posts: 17
Joined: Thu Apr 27, 2017 11:25 pm

Re: Suggested Memory Error Detection ASAN.

Postby madshi » Sat May 30, 2020 12:20 pm

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.
madshi
Site Admin
 
Posts: 10305
Joined: Sun Mar 21, 2004 5:25 pm


Return to madExcept

Who is online

Users browsing this forum: No registered users and 15 guests

cron