-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calling mocked safecall method corrupts stack #49
Comments
Problem seems to be in TVirtualInterface. Submitted bug report to Embarcadero - http://qc.embarcadero.com/wc/qcmain.aspx?d=127560 |
I have an issue when using safecall on a function returning a double. I have raised a QC report for it against Delphi 11. https://quality.embarcadero.com/browse/RSP-37009 type
{$M+}
ITest_OK = interface
['{F79960C7-B82E-4186-8134-B1574F3B6D68}']
function Get_Int: Integer;
function Get_Dbl: Double;
property INT: Integer read Get_Int;
property DBL: Double read Get_Dbl;
end;
ITest_FAIL = interface
['{D92AAA78-6703-4E0E-A005-6512D5C0F6E0}']
function Get_Int: Integer; safecall;
function Get_Dbl: Double; safecall;
property INT: Integer read Get_Int;
property DBL: Double read Get_Dbl;
end;
begin
var mock := TMock< ITest_OK >.Create;
try
mock.Setup.WillReturn( 1 ).When.INT;
var instance := mock.Instance;
mock.Setup.WillReturn( 1.1 ).When.DBL;
instance := mock.Instance; // this is fine as no safecall
finally
mock.Free;
end;
var mockfail := TMock< ITest_FAIL >.Create;
try
mockfail.Setup.WillReturn( 1 ).When.INT;
var instance := mockfail.Instance; // integer is ok
mockfail.Setup.WillReturn( 1.1 ).When.DBL;
instance := mockfail.Instance; // WILL BLOW UP HERE
finally
mockfail.Free;
end;
end. |
https://quality.embarcadero.com/browse/RSP-37009 This has been declared fixed in 11.1 release. I have yet to check, but will report back |
If try to call mocked safecall method, this call corrupts stack, and after several calls it leads to unpredictable exceptions.
Code for reproducing:
This happens in XE2 & XE7 Win32
Also this seems to be related to issue #8 , however, this one seems to be much broader
The text was updated successfully, but these errors were encountered: