Forum Discussion

jon_1's avatar
Occasional Contributor
14 years ago

Memory Leak in VB6 Application

I am running the Allocation Profiler on a VB6 App.

This profiler indicates several objects created and not released properly???

I have looked at the first object in list and looked at the details.

The stack trace gives source of error from class/function/line.

Several of these lines are only related to error handling/messages.

My trace through what the profiler indicates does NOT give source of what object was created.

And not released or the source of memory block allocated and not deallocated correctly.

Is there any more help?

And how reliable is this tool?

I ran TaskManager on this same App and it did NOT indicate any memory leak.

Thank you very much.

1 Reply

  • Hello Jon,

    I think the problem you have faced is caused by the fact that the source files were modified after the modules were compiled and the debug information was generated.

    Please recompile your application, make sure that AQtime has reloaded the modules and read the new debug information successfully, then profile your application again. Let me know if AQtime does not display correct source code lines after that.

    I ran TaskManager on this same App and it did NOT indicate any memory leak.

    Let me quote the Allocation Profiler - Overview Help topic regarding this matter:
    The amount of allocated memory displayed for your application by AQtime may differ from the amount of memory shown in the Task Manager. This happens because AQtime displays the memory that is currently allocated by the application’s memory manager for all live objects being profiled (the Allocation profiler traces only those objects whose classes are included in profiling areas). In the Task Manager window, you see the memory size that is allocated by the operating system’s memory manager for the application. Some part of this memory may not be used at the moment, but it is still allocated by the application’s memory manager (for instance, for future use). In certain cases, deallocated memory blocks may not be returned to the operating system’s memory manager, so the operating system “thinks” that these blocks are still being allocated by the application. There are also other possible reasons. So, the difference you see is caused by the peculiarities of memory management in the operating system and in the application.