Thread overview
[Issue 19322] A lot of memory is consumed and not freed to the system when Exception is formatted with stacktrace in debug
Oct 20, 2018
Tomáš Chaloupka
Oct 21, 2018
kinke@gmx.net
Jan 13, 2019
Tomáš Chaloupka
Jan 13, 2019
kinke@gmx.net
Dec 21
Dlang Bot
October 20, 2018
https://issues.dlang.org/show_bug.cgi?id=19322

Tomáš Chaloupka <chalucha@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com

--
October 21, 2018
https://issues.dlang.org/show_bug.cgi?id=19322

kinke@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke@gmx.net ---
This is probably because at least for ELF, the .debug_line section data is mmap()ped from the executable file and not unmapped after looking up file and line infos for the frames in the backtrace.

The mmapped section data is owned by the ElfSection struct (via its its MMapRegion member) created in the return statement in Image.getDebugLineSectionData(). What's actually returned is the data array via alias this, and the ElfSection struct (and its MMapRegion member) apparently aren't destructed, which seems to be a bug in its own right.

I only know because I 'had' to replicate this leaking behavior in
https://github.com/dlang/druntime/pull/2330/files#diff-a10edf024597f176f219ea3c0cb2bdafR64,
otherwise the data array was invalid (unmapped) as soon as the data slice was
returned.

Possible fix: pass a delegate processing the section data (something like
`Image.processDebugLineSectionData(dg)`), so that the Image type can hold and
release the data itself.

--
January 13, 2019
https://issues.dlang.org/show_bug.cgi?id=19322

--- Comment #2 from Tomáš Chaloupka <chalucha@gmail.com> ---
Thanks for the lead description. It seems to be exactly it. I've tried to debug this a bit to understand this more.

And the problem is as you said with this line: https://github.com/dlang/druntime/blob/master/src/rt/backtrace/elf.d#L59

which thanks to the alias here: https://github.com/dlang/druntime/blob/master/src/rt/backtrace/elf.d#L197

returns only aliased ubyte[] here: https://github.com/dlang/druntime/blob/master/src/rt/backtrace/elf.d#L59

and that doesn't destruct MMaped file which is hold here: https://github.com/dlang/druntime/blob/master/src/rt/backtrace/elf.d#L199

which seems to be another bug (I've tried to reproduce it in a simple test
case, but failed to do so).
But even if it will be destroyed on return, than the debugLineSectionData would
point to invalid data.

--
January 13, 2019
https://issues.dlang.org/show_bug.cgi?id=19322

--- Comment #3 from kinke@gmx.net ---
I already fixed this as part of a mainly refactoring, still pending PR: https://github.com/dlang/druntime/pull/2330

--
December 21
https://issues.dlang.org/show_bug.cgi?id=19322

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #4 from Dlang Bot <dlang-bot@dlang.rocks> ---
@kinke updated dlang/druntime pull request #2330 "Refactor ELF utils from rt.backtrace.elf and rt.sections_elf_shared to core.elf" fixing this issue:

- Fix Issue 19322 (memory leak in backtrace generation with -g)

https://github.com/dlang/druntime/pull/2330

--