Leaks from static variables

Hi lldb-dev,

It looks like the debugger initializes static variables in llvm (see:
SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.

Does this cause memory leaks? I'd assumed that it's necessary to call
llvm_shutdown() somewhere to avoid this kind of leak.

Is there a buildbot I can check that tests an address-sanitized version of
lldb?

thanks,
vedant

Greg Clayton will almost certainly want to weigh in here when he returns next week. Generally speaking, we’ve had a long tail of issues that only show up during teardown that we’re avoiding. Leaking resources that will be reclaimed by the OS when the process terminates is a non-issue. If there are specific scenarios where a long-lived process leaks significant content that isn’t an effective cache for subsequent use, please outline how that manifests.

Kate Stone k8stone@apple.com
 Xcode Low Level Tools

If you’re linking against liblldb you can’t rely on the os cleaning up because you could unload liblldb before shutting down the process.

Also it’s good practice to do explicit cleanup since its not always just a simple matter of releasing resources, sometimes actual shutdown code needs to be interspersed with the cleanup

Agreed that it’s a defect and should be addressed. It mostly a question of prioritization relative to other work, so knowing about a specific scenario where this is a pressing issue would be valuable.

Kate Stone k8stone@apple.com
 Xcode Low Level Tools

Hi lldb-dev,

It looks like the debugger initializes static variables in llvm (see:
SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.

Does this cause memory leaks? I'd assumed that it's necessary to call
llvm_shutdown() somewhere to avoid this kind of leak.

We can add it. Since LLDB.framework is a shared library, we should add this to the SystemInitializerFull::Terminate() function and see how things go.

Is there a buildbot I can check that tests an address-sanitized version of
lldb?

I am not sure if we have one.