Testing memory for read access

[ramguru]

I've just figured out that if you use IsBadReadPtr for testing pointer returned with MapViewOfFile, you will be very surprised what you get...
All file is loaded into memory, so lets say you opened CD image in hex editor, you expect that filemapping is quick and easy, but you're wrong it's slow and memory consuming.
Anyone knows what's unique way to test ptr, if component has no idea where it (pointer) comes from ?

[sinsi]

Write and install an exception handler?

[zooba]

if component has no idea where it (pointer) comes from ?

The best thing to do in this situation (according to Raymond Chen, can't find a direct link) is just crash.

If you don't know where the pointer has come from you can't possibly have any idea whether it is valid or not. If your library/function crashes, the person passing in the pointer will know there's something wrong and they can check their parameters. Since they own the pointer, making sure it's valid is their responsibility.

Having said that, in general an intelligent interpretation of a null pointer is often valid. For example, passing a null pointer to PrintLine doesn't crash, it just prints the newline character. (Of course, you have to specify that a null pointer is a valid value, which makes it irrelevant in a test for an invalid pointer...)

Cheers,

Zooba :U

[MichaelW]

The direct link is here. I was there a few days ago while I was trying to figure out how best to check the validity of a heap pointer.

[ramguru]

Thanks for the link to great article (good thinking: doing nothing is the best you can do)  :U I'll watch his blog from now on...

[u]

wow... this explains some really impossible bugs I've encountered - all places where I use either IsBadXXXPtr at normal places, or exception-handling around dll-loading.

[u]

Hmm, let's actually test if guarded pages are called in custom SEH handlers.
starting with stack-pages,

Code Select Expand


main proc
.prepFatal ;// try{
mov eax,[esp-16000]
.doFatal ;// }catch{
print "fatal"
.endFatal ;// }

print eax
ret
main endp

if you remove the try-catch, same happens: our SEH handler isn't called. Let's then change the value to -17000. The program crashes without the SEH handler (it being procommented), and the SEH handler is called if enabled. So, [esp-16000] belongs to the guarding stack-page, and my SEH handler wasn't called. This on Win2kSP4.

[u]

Next test, with a large file

Code Select Expand


main proc
local f1,hmap,ptr1
mov f1,fopen("e:\OneGigabyteLargeFile.bin","rb")
;print f1
invoke CreateFileMapping,f1,0,PAGE_READONLY,0,0,0
mov hmap,eax
;print hmap

msgbox "waiting" ; I check with ProcessExplorer, and see 254 page-faults so far

invoke MapViewOfFile,hmap,FILE_MAP_READ,0,0,0
mov ptr1,eax
;print ptr1

msgbox "waiting" ; 257 page-faults so far
.prepFatal
mov eax,ptr1
mov eax,[eax+1000000]
.doFatal
;print "FATAL"
msgbox "fatal" ; this (our SEH handler) is NOT called!
.endFatal
msgbox "done" ; 258 page-faults so far. The maths is correct :)
;print "done"
ret
main endp


[evlncrn8]

another alternative i guess could be to use virtualquery maybe...

[ramguru]

tehee   :tdown  :thumbu :lol  :lol  :lol  :lol  http://blog.yuvisense.net/2007/02/15/statbot-visits-the-old-new-thing/ so who is who :) ?

[ramguru]

However, here is he http://channel9.msdn.com/Showpost.aspx?postid=116704  :dance: