Skip to content
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

Memory leak in mormot.rest.client TRestClientUri.InternalNotificationMethodExecute #137

Closed
GoranDespalatovic opened this issue Jan 17, 2023 · 1 comment

Comments

@GoranDespalatovic
Copy link

When using ServiceNotificationMethodViaMessages I've got memory leak with instance ofTRestClientUriServiceNotification hanging.

In procedure TRestClientUri.InternalNotificationMethodExecute
sub-procedure procedure Call(methodIndex: integer; const par: RawUtf8; res: TJsonWriter);
execmsg variable is not freed, so I think it should be :

...
      execmsg := TRestClientUriServiceNotification.Create(
        callback.Factory, method, []);
      try                                                         // gigo
        execmsg.fOwner := self;
        execmsg.fInstance := callback.Instance;
        execmsg.fPar := par;
        with fServiceNotificationMethodViaMessages do
          ok := PostMessage(Wnd, Msg, Wnd, PtrInt(execmsg));
        if ok then
          exit;
      finally                                                     // gigo
        execmsg.Free;                                             // gigo
      end;                                                        // gigo
...
@synopse
Copy link
Owner

synopse commented Jan 17, 2023

I don't think so: execmsg is passed as a pointer to POstMessage() and is to be released by the message handler itself in TRestClientUri.ServiceNotificationMethodExecute.
Your modification will create a dangling pointer, and is likely to randomly GPF: you free the instance, but the message handler will use it. It won't work in the message handler, especially because fPar is ''.

synopse pushed a commit that referenced this issue Jan 17, 2023
… when message was not sent

- may be related to #137
synopse pushed a commit that referenced this issue Jan 17, 2023
- #137 is still to be investigated
@synopse synopse closed this as not planned Won't fix, can't repro, duplicate, stale Jan 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants