I have a single HTTP API function set up, and when I call it with a REST tester, the function is called with all the parameters as expected. However as it finished up its processing, and leaves the TROHttpApiDispatcher.InvokeServiceMethod function, it crashes with an access violation in _IntfClear. Is there any clue as to what this might be caused by?
I cannot see anything odd about anything.
can you provide a simple testcase that reproduces this issue, pls?
you can attach it here or post directly to support@.
make sure that you have tested with the latest beta
Test case provided privately, unable to repeat. So am digging in myself.
Does anyone know the Delphi stack management? I have the following code, and it is failing on the second call to IntfClear on exit (marked). Which variable should I be examining please?
procedure TROHttpApiDispatcher.InvokeServiceMethod(aTransport: IROHTTPTransport;aRequest: IROHttpRequest;
aResponse: IROHttpResponse; aRequestData, aResponseData: TStream);
var
l_JsonMessage: TROJSONMessage;
oResponseOptions: TROResponseOptions;
factory: IROClassFactory;
lmethod: TROHttpApiMethod;
l_acceptHeaderValue : String;
l_requestpath: string;
l_requestpathList: TStringList;
i: Integer;
lRoute : TROHttpApiRoute;
lres: TROJSONProperty;
lsession: TROHttpApiSession;
begin
l_JsonMessage := TROJSONMessage.Create;
uROHttpApiDispatcher.pas.150: begin
00835FC0 55 push ebp
00835FC1 8BEC mov ebp,esp
00835FC3 51 push ecx
00835FC4 B912000000 mov ecx,$00000012
00835FC9 6A00 push $00
00835FCB 6A00 push $00
00835FCD 49 dec ecx
00835FCE 75F9 jnz $00835fc9
00835FD0 874DFC xchg [ebp-$04],ecx
00835FD3 53 push ebx
00835FD4 56 push esi
00835FD5 57 push edi
00835FD6 894DF4 mov [ebp-$0c],ecx
00835FD9 8955F8 mov [ebp-$08],edx
00835FDC 8945FC mov [ebp-$04],eax
00835FDF 8B45F8 mov eax,[ebp-$08]
00835FE2 E8898DBDFF call @IntfAddRef
00835FE7 8B45F4 mov eax,[ebp-$0c]
00835FEA E8818DBDFF call @IntfAddRef
00835FEF 8B4510 mov eax,[ebp+$10]
00835FF2 E8798DBDFF call @IntfAddRef
00835FF7 33C0 xor eax,eax
00835FF9 55 push ebp
00835FFA 681F668300 push $0083661f
00835FFF 64FF30 push dword ptr fs:[eax]
00836002 648920 mov fs:[eax],esp
uROHttpApiDispatcher.pas.151: l_JsonMessage := TROJSONMessage.Create;
00836005 B201 mov dl,$01
00836007 A198047A00 mov eax,[$007a0498]
0083600C E867D7EAFF call TROMessage.Create
00836011 8945F0 mov [ebp-$10],eax
finally
l_JsonMessage.Free;
end;
end;
uROHttpApiDispatcher.pas.239: l_JsonMessage.Free;
008365AC 8B45F0 mov eax,[ebp-$10]
008365AF E8B825BDFF call TObject.Free
008365B4 C3 ret
008365B5 E99E39BDFF jmp @HandleFinally
008365BA EBF0 jmp $008365ac
uROHttpApiDispatcher.pas.241: end;
008365BC 33C0 xor eax,eax
008365BE 5A pop edx
008365BF 59 pop ecx
008365C0 59 pop ecx
008365C1 648910 mov fs:[eax],edx
008365C4 6826668300 push $00836626
008365C9 8D856CFFFFFF lea eax,[ebp-$00000094]
008365CF E82887BDFF call @IntfClear
008365D4 8D4580 lea eax,[ebp-$80]
008365D7 E85844BDFF call @UStrClr
008365DC 8D4584 lea eax,[ebp-$7c]
008365DF E81887BDFF call @IntfClear // Crash here
008365E4 8D4588 lea eax,[ebp-$78]
008365E7 BA05000000 mov edx,$00000005
008365EC E8A344BDFF call @UStrArrayClr
008365F1 8D45DC lea eax,[ebp-$24]
008365F4 BA02000000 mov edx,$00000002
008365F9 E89644BDFF call @UStrArrayClr
008365FE 8D45E8 lea eax,[ebp-$18]
00836601 E8F686BDFF call @IntfClear
00836606 8D45F4 lea eax,[ebp-$0c]
00836609 E8EE86BDFF call @IntfClear
0083660E 8D45F8 lea eax,[ebp-$08]
00836611 E8E686BDFF call @IntfClear
00836616 8D4510 lea eax,[ebp+$10]
00836619 E8DE86BDFF call @IntfClear
0083661E C3 ret
Okay, so the interface of concern is that at ebp-$7c. So I checked that the local variables are not involved, which implies it is something passed in. So I looked in the disassembly for 7c and the only line that references it is this one - anyone know what it does?
uROHttpApiDispatcher.pas.196: (l_JsonMessage as IROMessage).Initialize(aTransport,lRoute.ServiceName,lRoute.MethodName_, mtRequest);
008362C7 8B45D0 mov eax,[ebp-$30]
008362CA 8B4008 mov eax,[eax+$08]
008362CD 50 push eax
008362CE 6A00 push $00
008362D0 8D4584 lea eax,[ebp-$7c]
008362D3 8B55F0 mov edx,[ebp-$10]
008362D6 85D2 test edx,edx
008362D8 7406 jz $008362e0
008362DA 81EAE8FEFFFF sub edx,$fffffee8
008362E0 B9EC668300 mov ecx,$008366ec
008362E5 E8568ABDFF call @IntfCast
008362EA 8B4584 mov eax,[ebp-$7c]
008362ED 8B55D0 mov edx,[ebp-$30]
008362F0 8B4A10 mov ecx,[edx+$10]
008362F3 8B55F8 mov edx,[ebp-$08]
008362F6 8B18 mov ebx,[eax]
008362F8 FF530C call dword ptr [ebx+$0c]
with Fastmm, I can reproduce issue. investigating …
Thanks, logged as bugs://78959
bugs://78959 got closed with status fixed.
it can’t clean interface after this cast: (l_JsonMessage as IROMessage).
using local variable like
lMes: IROMessage;
..
Supports(l_JsonMessage, IROMessage, lmes);
...
lmes.Initialize(aTransport,lRoute.ServiceName,lRoute.MethodName_, mtRequest);
...
if not factory.Invoker.HandleMessage(factory, lmes, aTransport, oResponseOptions) then begin
...
lmes := nil;
solves this case.
Confirmed, works here. Will try in my real project, but assume good unless I say. Thank you for the great support.