L
Lieven De Foor
Guest
Hi, We're investigating a memory leak in our application causing .NET forms to not get destructed on close. We've been able to gather a list of leaking objects using client logging with DynObjects and leakcheck.p ( Progress KB - How to detect ABL Memory Leaks with Dynamic Objects Logging ). While this shows you a list of what's leaking, it is not showing the cause of the leak i.e. the objects that are keeping the references and thus preventing garbage collection. Explicitly deleting and/or disposing the Form and ToolbarsManager + related objects (Ribbon, Tools, etc.) to get the objects released causes the destructor to run but seems to cause the session to become unstable under some circumstances. This explicit delete is also not attacking the problem at the root, but is rather symptom fighting. (in .NET you can't even do this and have to rely solely on the garbage collector to clean up objects). By using the ANTS memory profiler we also see hybrid objects staying alive on the .NET side, while their ABL counterpart is gone (i.e. destructor has run). In fact we've seen cases where the ABL side apparently has no more/few leaks, where the .NET is leaking a lot. Are there any tools/options to debug this on the ABL side as well? Should we consider zombie objects (i.e. still living on the .NET side of the bridge, but gone in the ABL side) as OpenEdge bugs or not? Any tips on how to tackle this kind of issues is appreciated!
Continue reading...
Continue reading...