[SOLVED] Detect if a memory is valid

[440bx]

Thank you very much for clarifying this!

You're welcome.

[Okoba]

Does anyone knows what SysUtils set to handle such system exceptions? I tried setting ErrorProc and AssertErrorProc but the program still crashes. I want to get it just like SysUtils does it.

[marcov]

Does anyone knows what SysUtils set to handle such system exceptions? I tried setting ErrorProc and AssertErrorProc but the program still crashes. I want to get it just like SysUtils does it.

Sysutils sets a errorproc to RunErrorToExcept  that converts runtimerrors to exceptions. It also defines the exception class. You probably would have to copy all that.

But in general sysutils is a core unit, and it is not smart to avoid it.

[Okoba]

I set all of them but still program crashes silently. Yes but my use case is small program without any unit needs, and I hope to learn something too.

[440bx]

Yes but my use case is small program without any unit needs, and I hope to learn something too.

if you don't mind a Windows-only solution, you can use IsBadReadPtr or IsBadWritePtr depending on whether you need read or read-write.

Using those API's, you can find out if a pointer is bad without using sysutils.

Another way, likely more portable, would be using (Read/Write)ProcessMemory which likely have equivalents in other O/Ss.

HTH.

[Okoba]

A better way I found is VirtualQuery.

Code: Pascal  [Select][+][-]

1.  function Check(AValue: Pointer): Boolean;
2.   var
3.     MBI: TMemoryBasicInformation;
4.   begin
5.     Result := (VirtualQuery(AValue, MBI{%H-}, SizeOf(MBI)) = SizeOf(MBI))
6.       and (MBI.AllocationProtect <> 0) and (MBI.Protect <> 0)
7.       and ((MBI.Protect and PAGE_NOACCESS) <> 1)
8.       and ((MBI.Protect and PAGE_GUARD) <> 1);
9.   end;

 But using it is a little bit slow comparing to exception, and I am curious to find out how Sysutils handle system exception.
I appreciate any suggestion or code.

[440bx]

But using it is a little bit slow comparing to exception, and I am curious to find out how Sysutils handle system exception.

I haven't benchmarked the various ways of determining the invalidity of a pointer but, generally speaking, using exceptions will likely be the slowest method because in addition to requiring a ring transition, it also requires going through a list of handlers to find the one, if any, that is willing to deal with the exception.

Personally, I'd use IsBad(Read/Write)Ptr and let the O/S handle the exception internally and return a simple boolean indicating the validity of the pointer.

[Okoba]

You are right about exception being slower, but only if the pointer is invalid and error is rare. Windows API, is slow even on checking valid ones.

[PascalDragon]

Isn't the exception an internal feature of FPC? An that is why the errorProc is available to be set and set by the SysUtils?

Since the switch from SetJump/LongJmp-based exception handling to SEH-based on Windows it is no longer possible to use try-blocks without also using the SysUtils unit. It is on my ToDo list to fix this, but considering that there are few people using it that way it's not a high priority to fix.

[Okoba]

@PascalDragon can you point me to the section of SysUtils that sets handling these exceptions? Maybe I can find my way with it for the time being.

[PascalDragon]

SysUtils isn't the important part here. The important part is the raw exception handling in the System unit that calls function pointers that the SysUtils unit hooks into (or more precisely that this code doesn't call compared to the generic exception handling). You can find it in rtl/win32/seh32.inc and rtl/win64/seh64.inc and the generic one in rtl/inc/except.inc.

[Okoba]

Thank you.

I checked them and found I can have a custom exception handling like this:

Code: Pascal  [Select][+][-]

1. uses
2.   windows;
3.  
4. type
5.   CustomException = class(TObject)
6.     Code: Longint;
7.   end;
8.  
9.   CustomExceptClass = class of CustomException;
10.  
11. implementation
12.  
13. function DoExceptObjProc(code: Longint; const rec: TExceptionRecord): CustomException;
14. begin
15.   WriteLn('DoExceptObjProc');
16.   Result := CustomException.Create;
17.   Result.Code := code;
18. end;
19.  
20. function DoExceptClsProc(code: Longint): CustomExceptClass;
21. begin
22.   WriteLn('DoExceptClsProc');
23.   Result := CustomException;
24. end;
25.  
26. initialization
27.   ExceptObjProc := @DoExceptObjProc;
28.   ExceptClsProc := @DoExceptClsProc;
29. end.                                                            

A question I have is that in debug mode, Lazarus uses exception handling that leads to the message box. Where was it set?

[Okoba]

Here is a cleaner version of checking a memory is valid:

Code: Pascal  [Select][+][-]

1.   function IsValid(AValue: Pointer): Boolean;
2.   var
3.     OldExceptObjProc, OldExceptClsProc: Pointer;
4.   begin
5.     OldExceptObjProc := ExceptObjProc;
6.     OldExceptClsProc := ExceptClsProc;
7.     ExceptObjProc := @DoExceptObjProc;
8.     ExceptClsProc := @DoExceptClsProc;
9.     try
10.       try
11.         Result := PBoolean(AValue)^;
12.       except
13.         on E: CustomException do
14.         begin
15.           Writeln(E.Code);
16.           Exit(False);
17.         end;
18.       end;
19.       Result := True;
20.     finally
21.       ExceptObjProc := @OldExceptObjProc;
22.       ExceptClsProc := @OldExceptClsProc;
23.     end;
24.   end;
25.            

Is it safe swapping exception handling functions in such manner?

[Thaddy]

No.

[Okoba]

Thaddy you good man, can you elaborate?