Skip to main content

Memory Leak

  • January 27, 2015
  • 16 replies
  • 0 views
D

Hello,

I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

Thanks

    16 replies

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Sadly, we don't have a lot of good developer tools for tracking memory leaks beyond the U debugger command.

    However, we do have a way to log all memory requests, and include a dump of all unfreed memory at program end. While this won't necessarily be useful to you, it can be extremely useful to us (Micro Focus developers of the ACUCOBOL-GT product set).

    Add the following to the runtime command line (somewhere before the name of the COBOL program):

    -m 3 memdesc.txt

    When you quit the runtime, take a look at the memdesc.txt file. It will list all allocations, reallocations, and frees (including the filename and line number of the operation, and a short text description of what the memory will be used for). And at the bottom of the file, there will be a "final memory dump", which will list all memory that was not freed by the runtime before exit.

    There are two types of things to look for:

    1) A lot of memory blocks that are not freed in the final memory dump. While you won't necessarily be able to tell exactly what the memory was used for, you may get a clue which can help determine what exactly is not being freed.

    Note that there are some blocks that we know about, and just haven't had time to clean up yet. Those account for about 5K of unfreed memory at program end. These are things like NIS sign decoders, handle thread data, debugger file buffer.. You can ignore those. A good way to see what is known is to run your COBOL program twice. The first time, run in the debugger and quit before any COBOL is executed. Then compare that memdesc.txt file to an actual run of your program.

    2) Some block of memory that is being constantly reallocated to a larger and larger size. Again, you might not be able to determine why that memory is growing. But it may give a clue.

    If you do this, and you just have no idea where to start with the examination, feel free to attach the file to this post and we can take a look at it.

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Removed trace from post and added it as attachment.memtrace.zip

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    I'll elaborate a little more on our program as it may help sort this out. We launch a main application window which is then used as a menu to launch subprograms, each in their own thread, and we allow the user to switch between these windows. Messages are sent from the subprograms through thread messaging to the main application window, so we can process events such as the window activate and window close. We're currently using Codejock's Commandbars ActiveX control as a Ribbon for launching the subprograms, and we use ComponentOne's flexgrid lite as a grid in our applications. This memory leak appears to be occurring when we launch a subprogram repeatedly, which is pretty typical behavior when working with a menu driven application. The subprogram used here has 3 grids and 6 commandbars on it, and was called multiple times to illustrate the memory leak. I'm not making anything out of the attached log, if you can take a look and tell me any areas of concern, I can further investigate this issue.

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Before answering, I need to ask - by how much does memory grow according to the U debugger command? Is it the full 600K - 1MB as shown in the Windows task manager?

    According to the final memory dump you posted, there are a lot of "resizing layout data' blocks that are not freed. Normally I would consider that a memory leak, but there is a known aspect of the ACUCOBOL-GT runtime in which just declaring a layout manager handle in working storage causes the runtime to allocate space for the layout manager. Before cancelling that COBOL program, that layout manager handle needs to be destroyed.

    Also, there are a few 'Event parameter names' that are not freed. This looks like an actual memory leak. Though in the case you have provided, there was a total of 64 bytes allocated for those names. So I can't believe that they are the cause of 600K of unreleased memory.

    Finally, there is no indication of any memory blocks getting reallocated to larger and larger sizes. So I don't think that is the issue.

    I hope this helps,

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Thanks for the help so far, it is much appreciated. It appears in the -u output that the growth is much smaller, assuming this is showing in bytes, it looks to be losing about 55KB. Would it be Windows misrepresenting the memory amount, or the -u option? Not sure which number to rely on here. What would it mean by Event Parameter Name? I'm destroying all ActiveX control handles that are in use, is this maybe a call to GETEVENTPARAM that wasn't cancelled? As for the layout manager, I see a handle tied to the subprogram's window, I'll add that handle to the list of items being destroyed at the end of the program, and see if that changes the leakage.

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Have reportet somthing like the same to MF,

    incident 2809413

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    I've added code to destroy the Layout Manager handle, as well as the window on the way out of the program. I've ensured that all Calls are cancelled within the program, including all calls to C$GETEVENTPARAM, and it's still bleeding memory just as badly as before. Any other ideas?

    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Without actually posting a new memdesc.txt, can you compare a newly generated one with the one made before the layout manager destroys, and see a difference in the final memory dump? In other words, did we make any progress at all?

    The "Event parameter names" leak is actually a leak. I can see exactly where we allocate memory for some event parameters and don't free that memory. I don't believe it is from a GetEventParameter call, but I may be wrong. In any event, that is not something you can control for, though it is a small number of bytes.

    As for the rest, there are multiple ways to allocate memory. EVERY allocation that the ACUCOBOL-GT runtime does itself uses a single method. It is for that reason that we can even support the debugger U command.

    However, ActiveX controls and other DLLs have no knowledge of our memory API, and don't use it. As such, any memory allocated (and released) by such things can't be reported by the debugger. And that is why there is a discrepancy between what the debugger U command reports, and what the Task Manager reports (not to mention that the Task Manager also reports the actual stack size of the runtime, and the size of the runtime itself, and not just the heap size).

    As well, especially with ActiveX controls, Windows will sometimes not actually release memory that an ActiveX control frees, under the assumption that it will be faster to do that in the case that the ActiveX control needs to reallocate the same memory again. We have no control over what Windows does with memory internally.

    Essentially what I am saying here is that What happens in ActiveX controls stays in ActiveX controls (with apologies to the Las Vegas PR team...) And you may need to speak with the ActiveX control vendor about the possibility that you are not calling some method required to actually release all the memory that it allocates.

    But at this stage, I suggest you work with Micro Focus Customer Care to determine whether this is actually a bug in our runtime, and what you can do about it.

    In reference to JRJan's comment, memory leaks have such diverse causes that it is not very likely that your incident has the same cause as this issue. Not to minimize the impact of your issue.

    A
    • Anonymous
    • September 29, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Hi,

    I have a similar trouble. I've been inspecting the generated file with '-m 3' command line configuration, but I don't know what it means 'hotkey program name'

    Here I leave the final part or the file:

    final memory dump:
    0058DEC0, 24: config/config.c:151, `Configuration variable comment'
    005FBBC0, 20: runtime/startup.c:4321, `Current thread frame list'
    0060DA08, 582: ui/newwin.c:4466, `key maps'
    006735E0, 20: ui/win/win3ctl.c:5802, `Clip list'
    0067E5E8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    033CC9A8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    033CCB68, 16: runtime/variant.c:186, `OLE scratch buffer'
    03423F58, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0342C338, 582: ui/newwin.c:4466, `key maps'
    034364C8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436648, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436678, 7: runtime/stdlib.c:2304, `hotkey program name'
    034366A8, 7: runtime/stdlib.c:2304, `hotkey program name'
    034366D8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436708, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436768, 7: runtime/stdlib.c:2304, `hotkey program name'
    034367C8, 7: runtime/stdlib.c:2304, `hotkey program name'
    034367F8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436828, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436858, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436888, 7: runtime/stdlib.c:2304, `hotkey program name'
    034368B8, 7: runtime/stdlib.c:2304, `hotkey program name'
    034368E8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436918, 7: runtime/stdlib.c:2304, `hotkey program name'
    034369D8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03436A08, 7: runtime/stdlib.c:2304, `hotkey program name'
    03452628, 7: runtime/stdlib.c:2304, `hotkey program name'
    03452748, 7: runtime/stdlib.c:2304, `hotkey program name'
    03452808, 7: runtime/stdlib.c:2304, `hotkey program name'
    03452958, 7: runtime/stdlib.c:2304, `hotkey program name'
    034529B8, 7: runtime/stdlib.c:2304, `hotkey program name'
    034529E8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03452AD8, 7: runtime/stdlib.c:2304, `hotkey program name'
    03452B08, 7: runtime/stdlib.c:2304, `hotkey program name'
    03454308, 12: runtime/stdlib.c:2295, `hotkey stack node'
    03454378, 12: runtime/stdlib.c:2295, `hotkey stack node'
    03487A70, 64: ui/control.c:2937, `event list'
    0348F860, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348F898, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348F908, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348F978, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348F9B0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FA20, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FA58, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FB00, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FB38, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FC18, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FC50, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FC88, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FCF8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FDD8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FE10, 12: runtime/stdlib.c:2295, `hotkey stack node'
    0348FE48, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D5C0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D5F8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D630, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D668, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D6A0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D6D8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D710, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D748, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D7B8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D7F0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D828, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D898, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D8D0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D940, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D978, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D9B0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7D9E8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DA20, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DA58, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DAC8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DB00, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DBA8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DBE0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DC18, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DC50, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DC88, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DCC0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DCF8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DD68, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DDD8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DE10, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DE48, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DE80, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DEB8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DEF0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DF28, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DF60, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DF98, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7DFD0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E008, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E040, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E078, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E0B0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E0E8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E120, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E158, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E1C8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E200, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E238, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E270, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E2A8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E2E0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E318, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E388, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E3C0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E3F8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E430, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E468, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E4A0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E4D8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E510, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A7E548, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A805A8, 582: ui/newwin.c:4466, `key maps'
    05A81160, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A811F0, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81220, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81250, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81280, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81400, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81430, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81BD0, 582: ui/newwin.c:4466, `key maps'
    05A82240, 582: ui/newwin.c:4466, `key maps'
    05A824B0, 582: ui/newwin.c:4466, `key maps'
    05A82E50, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82E88, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82EC0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82EF8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82F30, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82F68, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82FA0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82FD8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83010, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83048, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83080, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A830B8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A830F0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83128, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A831D0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83208, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83240, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83278, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A832B0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83320, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83358, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83390, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A833C8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83400, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83438, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83470, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A834A8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A834E0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83518, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83F30, 582: ui/newwin.c:4466, `key maps'
    usable memory allocated: 5786 bytes
    memory description overhead: 3744 bytes


    Any assistance would be of great help

    Thanks!
    A
    • Anonymous
    • September 29, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Hi,

    I'm in a similar case, but I'm not using Active-x.

    I leave here a little part of the end of the file:

    05A805A8, 582: ui/newwin.c:4466, `key maps'
    05A81160, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A811F0, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81220, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81250, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81280, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81400, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81430, 7: runtime/stdlib.c:2304, `hotkey program name'
    05A81BD0, 582: ui/newwin.c:4466, `key maps'
    05A82240, 582: ui/newwin.c:4466, `key maps'
    05A824B0, 582: ui/newwin.c:4466, `key maps'
    05A82E50, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82E88, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82EC0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82EF8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82F30, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82F68, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82FA0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A82FD8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83010, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83048, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83080, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A830B8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A830F0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83128, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A831D0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83208, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83240, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83278, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A832B0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83320, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83358, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83390, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A833C8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83400, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83438, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83470, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A834A8, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A834E0, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83518, 12: runtime/stdlib.c:2295, `hotkey stack node'
    05A83F30, 582: ui/newwin.c:4466, `key maps'
    usable memory allocated: 5786 bytes
    memory description overhead: 3744 bytes

    Any assistance would be of great help

    Thanks
    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • September 29, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    hotkey typically is defined in your runtime configuration file. You assign a key (i.e. F4) hotkey="some-program-name" such as help program. Your config file may contain a number of hotkey programs.
    A
    • Anonymous
    • October 3, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Hi,

    I've defined just 2 hotkeys in my runtime configuration file, but is there any problem by configurating this?

    Thanks
    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • October 3, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    No, there isn't a problem defining hotkey programs. It would be best to work directoy with Customer Care. That way, they and Development could look at the memory log file and see what may be going on. Are you encountering a mav.. or have you determined some type of memory leak .. or are you wondering about when certain programs close, why memory isn't freed up???
    A
    • Anonymous
    • October 3, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Yes, certain types of programs are increasing the use of memory around 100k per call. Such calls are used very frequently, and if the user does not close the application, the memory used may reach a disproportionate amount
    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • October 3, 2017

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    If you're on Windows, Windows does not always clean up the memory when you clean up resources, as it anticipates that you may need the resource again. I don't know if these calls are in threads or not, and whether there are bitmaps, fonts, and or ActiveX in these programs that are increasing memory. Cleaning up resources as best you can when the call has ended, but that doesn't mean that Windows reduces the memory footprint.
    D

    Hello,

    I've got a memory leak issue, where launching a program will bleed between 600KB and 1MB of memory as shown in the windows task manager. We call the program in a thread and destroy all bitmaps/fonts/activex controls when we're exiting the program. When I look at the debugger's -u output, I can see that the Program memory is staying constant, the file memory is constant, but the Windows and Overhead memory buckets are constantly increasing each time I call the program. Is there any way for me to see what is in these buckets or to tell why they are increasing and not falling back when I exit the program? There are 9 ActiveX controls in total on the window, and some bitmap buttons, I'm assuming destroying them when exiting should release their memory. As this program is run in a thread that we're not waiting for, there is not a cancel that's run after the call, but we do run a Cancel All prior to calling the program, which should free up any memory used by inactive programs. Any assistance troubleshooting this would be of great help.

    Thanks

    Are you running in the debugger and using the 'u' command to examine memory usage? If not, then please do that and cycle through several iterations of calling the program, exiting the program, and checking memory with 'u' after each. If you have a test case that demonstrates memory continuing to grow with each iteration, then please raise a support incident and we'll look at it.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement