Bug Hunting Session
Bug 123733 - Crash when loading the same file twice but first load was not "complete"
Summary: Crash when loading the same file twice but first load was not "complete"
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: iOS (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other iOS
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-27 09:31 UTC by Nicolas Christener
Modified: 2019-10-16 12:52 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Video showing the crash (3.38 MB, video/mp4)
2019-02-27 09:32 UTC, Nicolas Christener
Details
Presentation which can trigger the problem (4.10 MB, application/vnd.oasis.opendocument.presentation-template)
2019-02-27 09:33 UTC, Nicolas Christener
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Christener 2019-02-27 09:31:40 UTC
Description:
Opening a presentation twice leads to a crash if the first load was not 100% complete.

Steps to Reproduce:
1. Open the attached file and click the "back" button as soon as it's rendered
2. Open the same file again

Actual Results:
The app crashes

Expected Results:
The file should open as expected.


Reproducible: Always


User Profile Reset: No



Additional Info:
Please see attached video.
Comment 1 Nicolas Christener 2019-02-27 09:32:12 UTC
Created attachment 149618 [details]
Video showing the crash
Comment 2 Nicolas Christener 2019-02-27 09:33:29 UTC
Created attachment 149619 [details]
Presentation which can trigger the problem

Not all presentaitons trigger the issue, smaller ones seem to work (not sure if the size is the real problem).
Comment 3 Nicolas Christener 2019-10-02 07:35:23 UTC
The issue is still more or less present in 4.1.63 (63) and I therefore assume it is not related to #125575.

The app doesn't crash as in earlier versions, but the "document is loading" spinner won't stop and the only way to get the app back into a usable state is by killing it.

I try to be a bit more precise in explaining what the issue is:

* I never tried to reproduce in writer/calc on iOS...
* ...but it's reproducible in impress on iOS
* One needs a somewhat more complex presentation where loading takes some seconds
  -> see for example the one I attached to this bug
* Open the presentation and wait until the "go back"-icon ("<") is visible
* Click the "<" icon while the app is still "preparing" the document
* Try to open an other file (doesn't matter which one)

This is not a critical bug but some users will run into it when they open larger / more complex files.

I sometimes run into it when I realize that I opened the wrong file and then tap "<" to open the correct one while the app is still opening the current file.
Comment 4 Tor Lillqvist 2019-10-02 20:26:40 UTC
Spent most of today debugging and tracing this to little gain.
Comment 5 Tor Lillqvist 2019-10-11 09:53:30 UTC
Just adding some general notes in case I forget, if other more urgent things intervene, and/or if somebody else starts looking into this:

Although a good fix for this seems to be hard to find, it is reasonably obvious what the problem is. If one pauses the app process during the never-ending "Connecting..." spinner, one sees that there are two lokit_main threads. That is a clear sign that the plumbing of the separate threads, FakeSockets, and whatnot in the app is totally confused, and no wonder that nothing works. I tried various things including adding mutexes to make sure just one lokit_main() is running at a time, but no cigar so far.
Comment 6 Tor Lillqvist 2019-10-15 14:39:43 UTC
Finally, now I think I have found the right locking to do to keep the lifecycle of the threads and "pipes" (connected FakeSockets) in the app sane also if the user attempts to close a "heavy" document before it has loaded completely. (For instance a large presentation where it takes a long time for the slide previews to be rendered.) Will do some double-checking and then commit.
Comment 7 Commit Notification 2019-10-16 11:21:21 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/online/commit/fdb91bf15e04f182311cd263d2492aeb1c3f276f

tdf#123733: Keep the WebKit view until the lokit_main thread has finished
Comment 8 Nicolas Christener 2019-10-16 11:41:38 UTC
Fixed. I testes with 4.1.66 and I can't reproduce the issue anymore.

I think this issue can be closed.

Thanks a lot to the Collabora team and especially Tor for fixing this issue!