https://bugs.documentfoundation.org/show_bug.cgi?id=165481
Patrick (volunteer) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from Patrick (volunteer) <[email protected]> --- Created attachment 201102 --> https://bugs.documentfoundation.org/attachment.cgi?id=201102&action=edit Snapshot of LibreOffice running in the macOS Intruments application's "Leaks" tool I was able to reproduce this bug in my local macOS master build while running the macOS Instruments application's "Leaks" tool. Instruments reported no memory leaks but the net memory allocations do go up by at least 100 MB and Instruments noted that a lot of that is allocated within ScColContainer::resize(). I am not familiar with the Calc code so who knows what necessary work ScColContainer::resize() does, but I did add an fprintf() (see my debug patch below) and during autosave I get the following output: Old vs new column size: 257 16384 So it looks like during autosave, LibreOffice is allocating memory for each of the empty columns in each sheet. I also get the same output when I open the document and immediately save it. Maybe a Calc developer might be able to check if this expansion of columns is necessary when saving?: diff --git a/sc/source/core/data/colcontainer.cxx b/sc/source/core/data/colcontainer.cxx index a0a9d845772f..6961403673dd 100644 --- a/sc/source/core/data/colcontainer.cxx +++ b/sc/source/core/data/colcontainer.cxx @@ -48,6 +48,7 @@ void ScColContainer::resize( ScSheetLimits const & rSheetLimits, const size_t aN { size_t aOldColSize = aCols.size(); aCols.resize( aNewColSize ); +fprintf( stderr, "Old vs new column size: %lu %lu\n", aOldColSize, aNewColSize ); for ( size_t nCol = aOldColSize; nCol < aNewColSize; ++nCol ) aCols[nCol].reset(new ScColumn(rSheetLimits)); } -- You are receiving this mail because: You are the assignee for the bug.
