-
Notifications
You must be signed in to change notification settings - Fork 731
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS app: crash when cursor is in a writer table for ~30s #403
Comments
Investigating. |
It seems that while the cursor (caret) is inside the table, the JS (or maybe C++?) code is requesting tiles over and over again, or something like that. This then seems to overwhelm the WebContent process (possibly these tiles are leaked by the JS or C++ code?), and the WebContent process crashes. Here is a snippet of the log (with log level "debug"): 2020-10-23 11:52:57.284571 [ lokit_runloop ] DBG child_ws: recv [tilecombine nviewid=0 part=0 width=512 height=512 tileposx=0 tileposy=0 imgsize=0 tilewidth=3840 tileheight=3840 ver=4346 oldwid=0 wid=0 | Kit.cpp:1860 |
Reproducible on Linux with a "make run", too. Open a text document with a simple 3x3 table, just let it sit there, with the caret in a table cell. The /tmp/loolwsd.log will show an endless stream of stuff going on. Surely this can not be normal? |
Sample document. (The .zip contains a single .odt, because silly GitHub doesn't accept .odt files as attachments in comments...) |
More accurately, it isn't the Online code (JS or C++) that requests tiles spontaneously in a loop, but the core code that sends LOK_CALLBACK_INVALIDATE_TILES callbacks, I think. Backtraces from these: #0 SfxLokHelper::notifyInvalidation(SfxViewShell const*, rtl::OString const&) (pThisView=0x6f1ac50, rPayload="284, 284, 5589, 3001") #0 SfxLokHelper::notifyInvalidation(SfxViewShell const*, rtl::OString const&) (pThisView=0x6f1ac50, rPayload="1474, 1474, 9525, 651") #0 SfxLokHelper::notifyInvalidation(SfxViewShell const*, rtl::OString const&) (pThisView=0x6f1ac50, rPayload="38, 38, 745, 400") #0 SfxLokHelper::notifyInvalidation(SfxViewShell const*, rtl::OString const&) (pThisView=0x6f1ac50, rPayload="1474, 1474, 9525, 651") |
I tried to add a stopgap measure just for the iOS app by adding a |
This trivial patch seems to help for the "make run" case, but sadly not for the iOS app.
|
In the iOS app, after a while, even if I don't even click the blue round make-editable button, I start seeing lots of this:
The call stack, with a breakpoint in paintTileIOS in desktop/source/lib/init.cxx, is:
|
... and after some 4300 pointless tiles painted, the WebContent process crashes. |
I expect the leaflet view to borrow CPU when the document is idle to try to get tiles around the document so we're ready to scroll-down / left / right etc. which might be related (?) though 4300 tiles is rather a lot =) |
But the document is very short, everything is visible all the time. |
@nikslor , does by any chance the document you get the crash with start with the table? |
Nah, whether the table is first thing or not does not seem to affect the "make run" issue (with an unmodified cp-6.4, without the patch a few comments earlier). Also in that case, if I put the caret in a table cell, the kitbroker_003 process starts consuming CPU like crazy. |
Hmm, now again it seems that the simple patch in #403 (comment) does help, both in the iOS app and in "make run". I must have missed some step when testing it earlier on iOS. Or something. |
See #403 Change-Id: I59012565ac6376d03872fe6e4cd78a5d14be1319 Signed-off-by: Tor Lillqvist <tml@collabora.com>
See #403 Change-Id: I59012565ac6376d03872fe6e4cd78a5d14be1319 Signed-off-by: Tor Lillqvist <tml@collabora.com>
Hi Tor I tested this again in 6.4.0 (6) and I can't reproduce the issue anymore. I think your fix works and we can close this issue. Thanks a lot for taking care of this! Do you close the issue? |
OK, closing. |
See CollaboraOnline#403 Change-Id: I59012565ac6376d03872fe6e4cd78a5d14be1319 Signed-off-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 3a4169a) Signed-off-by: Tor Lillqvist <tml@collabora.com> Signed-off-by: Rash419 <rasheshpadia419@gmail.com>
See CollaboraOnline#403 Change-Id: I59012565ac6376d03872fe6e4cd78a5d14be1319 Signed-off-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 3a4169a) Signed-off-by: Tor Lillqvist <tml@collabora.com>
Describe the bug
When placing the cursor in a table in a writer document and just wait for ~30s the app will crash.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Nothing should happen.
Actual behavior
The app crashes.
Tablet
Additional context
I have a hardware keyboard (Apple Smart Keyboard) attached.
The text was updated successfully, but these errors were encountered: