This is a follow-up to tdf#148851 which fixed one memory leak that is also present with experimental editing mode disabled, but there is another problem that only shows up with experimental mode enabled. Steps to reproduce: 1) enable the experimental editing mode in Android Viewer 2) open attachment 179845 [details] (from tdf#148851) in Android Viewer 3) switch to the first table in the spreadsheet, which has more rows than the second one 4) scroll down the document, then up again 5) repeat step 2 over and over again Actual result: At some point in time (in my case, I usually had to repeat step 2 about 2-10 times, depending on the device), the app crashes because it runs out of memory. This is with git master as of commit 6c724e18c2af227c2ad865342531ff35b0d511ac + the pending fix for tdf#148851 in place.
Result of a first analysis: This is caused by the way that Calc row and column headers (the "A", "B", "C", ... labels for columns and "1", "2", "3", ... for rows) are currently handled. Android Viewer currently gets the headers for the whole current "document size", s. `LOKitTileProvider#getCalcHeaders`. However, this has the side effect of increasing the document size, triggered by this in `ScTabView::getRowColumnHeaders`: > > // 2) if we are approaching current max tiled row, signal a size changed event > // and invalidate the involved area > lcl_ExtendTiledDimension(/* bColumn */ false, nEndRow, nVisibleRows, *this, aViewData); Properly fixing this would probably include reworking the way that Calc headers are handled in Android Viewer more fundamentally. With this workaround/hack to no longer retrieve headers for the whole doc size, I no longer see that problem (but Calc headers are missing): diff --git a/android/source/src/java/org/libreoffice/LOKitTileProvider.java b/android/source/src/java/org/libreoffice/LOKitTileProvider.java index 0c7931763571..03e6f1a7abb7 100644 --- a/android/source/src/java/org/libreoffice/LOKitTileProvider.java +++ b/android/source/src/java/org/libreoffice/LOKitTileProvider.java @@ -396,7 +396,7 @@ class LOKitTileProvider implements TileProvider { long nWidth = mDocument.getDocumentWidth(); long nHeight = mDocument.getDocumentHeight(); return mDocument.getCommandValues(".uno:ViewRowColumnHeaders?x=" + nX + "&y=" + nY - + "&width=" + nWidth + "&height=" + nHeight); + + "&width=" + 10 + "&height=" + 10); } /**
I found if call method('getCalcHeaders') frequently it will be blocked.Such as frequently pause and resume the DocumentActivity
Created attachment 180141 [details] Screenshot of Perfetto memory profile (web UI) Attached is a screenshot of the web UI showing the memory profile created with Perfetto's "heap_profile" tool, which shows that updating formulas is causing high memory usage (and the delays also). One potential solution (besides looking more closely into what exactly happens there) would probably be to only request the headers relevant for the portion of the doc that is currently shown (i.e. pass corresponding x and y values instead of the whole doc size), s.a. how gtktiledviewer does it. I probably won't find the time to look into this in the coming weeks, but *might* return to it at some point in time later. If anybody else wants to look into this, please feel free. :-)
Reproduced with current APK from F-Droid (7.6 alpha1+): scrolling up and down a for a while on the first "part" of the file suddenly closes the document. Tested on a Samsung Galaxy A20e.
*** Bug 158300 has been marked as a duplicate of this bug. ***
Dear Michael Weghorn, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug