VCL WebGMaps: Memory leaks on close of application

VCL TMS VCL WebGMaps
1
Adding MadExcept to my application shows two memory leaks on closing my application.
It seems that WebGMaps does not free two thread handles on destroy, probably for the OLE objects of the Internet Explorer used by WebGMaps:

allocation number: 4886
program up time: 769 ms
type: Thread Handle
handle: $c70
access rights: $1fffff
threadId: $2a00
processId: $2d40
process exe: D:\dev\Delphi\_test\TMSVCLWebGMapsStyled\Project1.exe

main thread ($1480):
671a9e2a madExcept32.dll madExceptDbg    4045 CreateThreadCallback
004b0dc3 Project1.exe    madExcept            HookedCreateThread
75937d5f msvcrt.dll                           _beginthreadex
76be67ea USER32.dll                           CallWindowProcW
0072cc54 Project1.exe    Vcl.OleCtrls     889 TOleControl.DefaultHandler
005cd712 Project1.exe    Vcl.Controls    7387 TControl.WndProc
005d2313 Project1.exe    Vcl.Controls   10245 TWinControl.WndProc
0072e87d Project1.exe    Vcl.OleCtrls    2482 TOleControl.WndProc
004f5d98 Project1.exe    System.Classes 17528 StdWndProc

allocation number: 4882
program up time: 769 ms
type: Thread Handle
handle: $c60
access rights: $1fffff
threadId: $2fe8
processId: $2d40
process exe: D:\dev\Delphi\_test\TMSVCLWebGMapsStyled\Project1.exe

main thread ($1480):
671a9e2a madExcept32.dll madExceptDbg    4045 CreateThreadCallback
004b0dc3 Project1.exe    madExcept            HookedCreateThread
75937d5f msvcrt.dll                           _beginthreadex
76be67ea USER32.dll                           CallWindowProcW
0072cc54 Project1.exe    Vcl.OleCtrls     889 TOleControl.DefaultHandler
005cd712 Project1.exe    Vcl.Controls    7387 TControl.WndProc
005d2313 Project1.exe    Vcl.Controls   10245 TWinControl.WndProc
0072e87d Project1.exe    Vcl.OleCtrls    2482 TOleControl.WndProc
004f5d98 Project1.exe    System.Classes 17528 StdWndProc

I can supply a simple demo project to expose this if needed, but madExcept is needed for that.
2

If WebGMap is not launched (either by AutoLaunch:=True or Launch()), the memory leaks don't appear as expected.

3

Hi,


We are not aware of any memory leaks in TWebGMaps.
Can you please provide the following information so I can further investigate this?
- The version of Delphi you are using
- The version of Windows you are using
- Does the issue also occur in the demo applications?
- Does the issue also occur in a new application that only contains a TWebGMaps component?
4
- Delphi 10.3 Rio
- Windows 10, RS5
- Yepp:

allocation number: 16155
program up time: 659 ms
type: Thread Handle
handle: $c68
access rights: $1fffff
threadId: $1590
processId: $1b68
process exe: C:\Users\Stefan\Delphi\_test\TMSVCLWebGMaps\WebGMapsMainDemo\TWebGMapsDemo.exe

main thread ($840):
671a9e2a madExcept32.dll   madExceptDbg 4045 CreateThreadCallback
004add37 TWebGMapsDemo.exe madExcept         HookedCreateThread
75ca7d5f msvcrt.dll                          _beginthreadex
75d3670e USER32.dll                          SendMessageW

allocation number: 16151
program up time: 650 ms
type: Thread Handle
handle: $c4c
access rights: $1fffff
threadId: $5c0
processId: $1b68
process exe: C:\Users\Stefan\Delphi\_test\TMSVCLWebGMaps\WebGMapsMainDemo\TWebGMapsDemo.exe

main thread ($840):
671a9e2a madExcept32.dll   madExceptDbg 4045 CreateThreadCallback
004add37 TWebGMapsDemo.exe madExcept         HookedCreateThread
75ca7d5f msvcrt.dll                          _beginthreadex
75d3670e USER32.dll                          SendMessageW

- As said above, yes. In an app with just WebGMaps on it.
5

We cannot see an issue with Delphi's built-in detection tool (ReportMemoryLeaksOnShutDown) and we can also not see an issue with the reporting tool Eurekalog that we use internally here.
Are you sure this is not a false positive from madExcept? Did you test madExcept with an application that uses a TWebBrowser that navigates to maps.google.com for example?

6
OK, that happens with a simple app with TWebBrowser navigating to maps.google.com as well.

There are a couple of open and unanswered questions on stackoverflow regarding this:
https://stackoverflow.com/questions/10224801/delphi-twebbrowser-memory-leak
https://stackoverflow.com/questions/9518594/javascript-in-delphi-twebbrowser-closing-threads/

It seems that javascript threads are not killed correctly and still running after destroying the TWebBrowser instance. I tried navigating to "about:blank", but to no avail.

Strange, that Eurekalog doesn't find this...