Memory Leak by showing PDF in wxWebViewIE

[Solosigi]

I use the last Version of Visual Studio 2022 C++ V17.9.5/NET Framework 4.08.09032
Windows 11

I made a simple wxWebView for showing a PDF-Document_

WebFrame::WebFrame() :
    wxFrame(NULL, wxID_ANY, "Bedienungsanleitung")
{
    rli_iso639Class iso639;
    wxString isocode;
    wxString filename = iso639.GetLanguageFileName(g_rli_puser->m_data.data.sys.language, &isocode, rli_lngfile);
    if (!(g_rli_puser->m_docdir.EndsWith("\\")) || (g_rli_puser->m_docdir.EndsWith("/")))
        g_rli_puser->m_docdir += "/";
    wxString pdf = g_rli_puser->m_docdir + _("Manual_") + isocode + _(".pdf");
    if (!wxFileExists(pdf))
        if (!wxFileExists(pdf = g_rli_puser->m_docdir + _("Manual_de.pdf")))
        {
            wxMessageBox(_("Datei nicht gefunden!"), _("Bedienungsanleitung.."), wxCANCEL | wxICON_ERROR);
            Destroy();
            m_created = false;
            return;
        }
    gui_ReadPosSize(this, WXDMENUWEBFRAME);
    m_browser = wxWebView::New();
    m_browser->Create(this, wxID_ANY, pdf, wxDefaultPosition, wxDefaultSize);
    m_created = true;
}



WebFrame::~WebFrame()
{
    if (m_created)
    {
        gui_SavePosSize(this, WXDMENUWEBFRAME);
        m_browser->Stop();
        m_browser->DestroyChildren();
        m_browser->Destroy();
    }
}

If i finish the program there is a memory leak of 36 bytes!

Very intresting:
If i take the original sample webview and i imput an URL of a PDF-file (W:/wxDMenu/wxDMenuData/Doc/Manual_de.pdf) i get als the same memory leak of 36 Bytes!

What's wrong?
TNX
Robert

[vadz]

Please try debugging the leak using the same tool you used to detect it in the first place to see where is it coming from.

Also, it's not clear which wxWebView backend you're using: is it the default (and deprecated) IE one or the Edge one (which needs to be explicitly enabled)?

[PBfordev]

I can reproduce it with GIT master and wxWebViewIE backend (Internet Explorer 9.11.19041), only when displaying a PDF.

Detected memory leaks!
Dumping objects ->
{51989} normal block at 0x000002398A1B0DA0, 48 bytes long.
 Data: < =ll            > 80 3D 6C 6C FB 7F 00 00 01 00 00 00 01 00 00 00 
Object dump complete.

Adding (and verifying afterwards the allocation order number was still the same)

    _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
    _CrtSetBreakAlloc(51989);

to WebApp::OnInit() points to creating wxActiveXEvents instance events here

wxWidgets/src/msw/ole/activex.cpp

Lines 991 to 1003 in 72d5cf6

	if ( cp )
	{
	wxActiveXEvents * const
	events = new wxActiveXEvents(this, ta2->guid);
	hret = cp->Advise(events, &adviseCookie);
	// We don't need this object any more and cp will keep a
	// reference to it if it needs it, i.e. if Advise()
	// succeeded.
	events->Release();
	CHECK_HR(hret);
	}

events is never deleted, only its interface released. Of course, simply adding delete events leads to a crash. The same code gets executed when a web page is loaded and there is no leak. So maybe the location is wrong? I have forgotten the little I ever learned about COM, but IIRC the usual pattern was the interface instance deleting itself when its reference count drops to 0: Perhaps for PDFs the interface is not released somewhere properly...

Calling wxWebViewIE::MSWSetEmulationLevel() did not help with the leak.

[Solosigi]

I have tried to exclude this block...

                if ( cp )
                {
/*
                    wxActiveXEvents * const
                        events = new wxActiveXEvents(this, ta2->guid);
                    hret = cp->Advise(events, &adviseCookie);

                    // We don't need this object any more and cp will keep a
                    // reference to it if it needs it, i.e. if Advise()
                    // succeeded.
                    events->Release();

                    CHECK_HR(hret);
*/
                }

Build new library and link my app.
And see: with PDF (i use only PDF) the was no memory leak any more...
Regards
Robert

[vadz]

Thanks for debugging this!

AFAICS it really looks like the connection point forgets to call Release() on our objects, but I don't know what to do about it. Removing this code means that no wxEVT_ACTIVEX events will be generated, which doesn't seem ideal, but, in a pinch, we probably could add some flag to disable the events generation if they're not needed anyhow and this would avoid the leak too.

I'd recommend switching to Edge backend in any case.