We use Pascalscript extensively in our software. Even though I know it’s an unsupported product, I’ll explain the problem we run into when trying to run our software on 64 bit Window.
Basically we allow customization of our software with scripts events with specific signatures that our code calls if exists in the script. Normally it’s procedure - for example: OnGetProfile(aParameter: TOnGetProfileWraper);
But in my test project I’ve reduced it into:
procedure Test(aWrapper: TParaWrapper);
begin
aWrapper.Child.StringValue;
end;
Debugging shows that the 32 MSB is cleared on the 64 bit pointer of aWrapper.Child, and therefore leads to an AccessViolation.
I would appreciate much if someone could have a look at it. The attached project is very simple.
To be sure, I just downloaded the latest source from GitHub - remobjects/pascalscript: pascalscript master. I also made 100% sure it was that version that was used. But still the same error.
Can you retest this issue with another version of Delphi?
I can reproduce issue with Delphi 11.1 but it works with another versions of Delphi (I’ve tested with Delphi 10.3 & Delphi 10.4):
Yepp. It seems to work on 10.4.2.
I have tried our whole application previously on Delphi 10.X, but it failed. It might be that this simple test just works by luck.
We have to investigate what EMBT has changed in Delphi 11 and why old code doesn’t work anymore.
as a result, I can’t say any terms when it will be solved …
If one turn off the ASLR (address space layout randomization) the supplied test project works. But sadly our application does not, and have the same symptoms.
I’ve tried that, but still get Access Violation.
Below i a script that fails. It fails on if aParams.Product.QtyOrdered = 102 then because aParams.Product is invalid. The 32 MSB is clear til. For example when set I a breakpoint just before calling into the script, pointer(aParams.Product) returns $00007FF4F9920670. The access violation I get is on read on address $00000000F9920670.
procedure OnModifyVariants_Final(aParams:TScriptOnModifyVariantsParams);
begin
if aParams.CurrentLevel <> levOne then Exit;
if aParams.Product.QtyOrdered = 102 then
begin
aParams.AddOrUpdateVariantByVarLineNo(OStainCVar, 102, 0, False, 'Dersom 102 stk bestilles, da MÅ det være Rød :-)'); //Farge Rød Rx42 c
aParams.AddOrUpdateVariantByVarRecId(2745,0,True, 'Test innstepping av tillegg');
end
else if aParams.Product.QtyOrdered = 103 then
begin
aParams.AddOrUpdateVariantByVarLineNo(OStainCVar, 103, 0, False, 'Dersom 102 stk bestilles, da MÅ det være Blå :-)'); //Farge Blå
end;
end;
Yes. We have tried to get this to work on several pre Delphi versions during the last 4-5 years. Now we must find a solution. One options we have is to migrate to DwScript, but that will be a lot work and high risk.
The only reason the test project works when ASLR is off, is that the .Child pointer is inside 32 bit address space. On our “real” application most allocation on the heap is above the 32 bit address space limit (checked in VMMAP). I don’t know how the Windows image loader or virtual memory manager handle this, but it’s quite clear for me that Pascal script does not really support 64 bit. For small projects it works by luck as the heap allocation will be below the 32 bit address space limit.
So turning on ASLR and possible also the high-entropy option in Delphi 11, is a good way to check that it really works as 64 bit application.
