Excel memory leak

Oct 5, 2012 at 10:31 PM

Hi Keith,

I'm trying to track down a memory leak that surfaced with Excel-DNA. I now believe it is a problem with Excel itself. I wonder if you could perhaps confirm that I'm not doing anything stupid.

I make this macro with your library:

static AddInX xai_macro(
    // C function name, Excel macro name
    _T("?xll_memleak"), _T("XLL.MEMLEAK")
);
int WINAPI
xll_memleak(void)
{
#pragma XLLEXPORT
    try {
        long val = 1;
        OPERX target = OPERX(0, 0, 1, 1);
        ExcelX(xlSet, target, OPERX(_T("Hello World!")));

        for(;;)
        {
            OPERX str = ExcelX(xlfConcatenate, OPERX("AAA"), OPERX(val));
            ExcelX(xlSet, target, str);

            val++;
            if (val % 1024 == 0)
            {
                if (ExcelX(xlAbort))
                return 0;
            }
        }
        // return 1;
    }
    catch (const std::exception& ex) {
        // Use the macro ALERT.FILTER to control which alerts you see.
        XLL_ERROR(ex.what()); // or XLL_WARNING or XLL_INFO

        return 0; // failure
    }

    // return 1; // success
}	

This inserts constantly changing strings onto cell A1 (until you press Esc). While running the macro (I start it with Alt+F8), I see the Excel process using more and more memory (until Excel crashes in exhaustion at around 1.5 GB).

Strangely, when I restart the macro, the memory usage is stable until the last value previously inserted is reached, and then starts growing again - as if Excel is storing all the unique strings it has ever seen. There does not seem to be a problem when pushing in doubles.

I'm using 32-bit Excel 2010 SP1 on 64-bit Windows 7.

Am I doing something silly? Is this something you know about? Can you confirm that you see the same behaviour?

Thank you for the help.

Regards,

Govert

Oct 6, 2012 at 2:40 PM

Ah - OK the behaviour is the same from VBA too.

Sub MemLeak()
    Dim val As Long
    val = 0
    While True
        [A1] = "X" & val
        val = val + 1
        If val Mod 1024 = 0 Then
            DoEvents ' Allows you to see results, and break
        End If
    Wend
End Sub

So I'm sure it's an Excel issue.

-Govert

Coordinator
Oct 6, 2012 at 4:52 PM

Hi Govert,

I haven’t been able to replicate this. I’ve tested on Windows 7 64-bit with Excel 2003 and 64-bit Excel 2010 and on Window 7 32-bit with 32-bit Excel 2010.

Best,

Keith

From: govert [email removed]
Sent: Saturday, October 06, 2012 9:40 AM
To: kal@kalx.net
Subject: Re: Excel memory leak [xll:398247]

From: govert

Ah - OK the behaviour is the same from VBA too.

Sub MemLeak()
    Dim val As Long
    val = 0
    While True
        [A1] = "X" & val
        val = val + 1
        If val Mod 1024 = 0 Then
            DoEvents ' Allows you to see results, and break
        End If
    Wend
End Sub

So I'm sure it's an Excel issue.

-Govert

Oct 6, 2012 at 11:08 PM
Edited Oct 6, 2012 at 11:09 PM

Hi Keith,

Thank you for checking - I'm surprised at what you report!

I also get the same behaviour with growing memory usage for both the VBA and the XLL on Excel 2002 SP-1 / Windows XP. I just put the VBA into a new module, then start it with Alt+F8, then watch the Memory Usage for Excel.exe in the Task Manager while the macro runs.

I'll be thinking about what might be special on my machines, and trying some others in the week. But I'm now very sure it has nothing to do with Excel-DNA, which is what I was really trying to figure out.

Thanks for the help.

Regards,

Govert

Coordinator
Oct 7, 2012 at 2:06 AM

I take your bug reports seriously Govert. Sorry about being so slow getting back, but I was running the code you sent on the configurations I reported trying to replicate what you are seeing. I don't have a 64-bit Windows 7 machine with 32-bit Office 2010. It is not possible to install both 32 and 64-bit Office on the same machine.

I am sure you are correct this is not a Excel-DNA problem. The unmanaged world is a lot messier.

Sadly, reinstalling Office and using Windows update seems to be the best hope for solving mysteries like this. The good old unix days where human beings could just RTFM and get to the bottom of things seems to be gone now.

Oct 7, 2012 at 4:50 PM

Thanks Keith - I'm at peace.

I guess Excel has an internal string cach, to manage duplicate strings effectively. Pumping in different strings makes the memory used grow slowly but consistently - I presume different versions might deal with this differently and have different optimisations. I no longer suspect a problem in my code (or yours) - otherwise the insides of Excel remain a mystery.

Cheers,

Govert