Bug 122543 - Crash after device was put into "stand by" mode
Summary: Crash after device was put into "stand by" mode
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: iOS Editor (show other bugs)
(earliest affected)
Hardware: Other iOS
: medium normal
Assignee: Not Assigned
Whiteboard: target:6.3.0
Depends on:
Reported: 2019-01-07 18:02 UTC by Nicolas Christener
Modified: 2019-03-21 23:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:

Crash after "stand by" (6.15 MB, video/mp4)
2019-01-07 18:02 UTC, Nicolas Christener

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Christener 2019-01-07 18:02:14 UTC
When an iPad is not used for a couple of minutes iOS will put it into "stand by" mode (screen turns black, probably something like "suspend to ram" happens).

If the iOS app has an open document while the device switches into this "stand by" mode the app will crash after the devices is reactivated - this does not happen all the time but it happens approx. one in three times. 

Not sure but I think the document needs to be in "edit mode" and the user has to enter at least some characters before putting the device into "stanb by" mode to trigger the issue.

I try to attach a video that shows the issue.

Steps to Reproduce:
1. Create a document in the iOS app, write some text
2. Leave the device as is and wait until screen turns black
3. Reactive the device

Actual Results:
The iOS app often crashes

Expected Results:
The app should not crash

Reproducible: Sometimes

User Profile Reset: No

Additional Info:
Comment 1 Nicolas Christener 2019-01-07 18:02:45 UTC
Created attachment 148111 [details]
Crash after "stand by"
Comment 2 Xisco Faulí 2019-01-07 23:02:54 UTC
Moving to NEW
Comment 3 Tor Lillqvist 2019-03-20 09:14:56 UTC
At first I thought it might be hard to debug this as the device does not go into "stand by" mode when an app is being debugged in Xcode. but I could reproduce it by pressing the lock button and unlocking it. 

> libc++abi.dylib: terminating with uncaught exception of type std::length_error: vector

But sadly the thread where that abort message is generated does not have any vector operation in the call stack, huh? Investigating.
Comment 4 Tor Lillqvist 2019-03-20 11:43:58 UTC
The immediate cause of the crash is that in DocumentViewController.mm, in the block ("lambda") for the thread started by the dispatch_async() call in the userContentController:didReceiveScriptMessage: instance method, the fakeSocketAvailableDataLength() function returns -1 and that return value is passed to the constructor for std::vector<char> buf(n). The root cause is more complicated; for some reason a new Document object gets constructed even if an existing one is active.
Comment 5 Commit Notification 2019-03-20 13:23:47 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":


tdf#122543: Ignore duplicate calls to loadFromContents on same Document
Comment 6 Tor Lillqvist 2019-03-20 13:25:16 UTC
The above fix (also in the cp-6.0 branch) helps. Will be included in the next build of the app.
Comment 7 Tor Lillqvist 2019-03-20 15:56:30 UTC
I mean collabora-online-4 branch, not cp-6.0
Comment 8 Tor Lillqvist 2019-03-20 16:01:47 UTC
Nicolas, please mark as verified when you have eventually verified that the bug is gone.
Comment 9 Nicolas Christener 2019-03-21 10:23:32 UTC
Fixed in 0.1 (23)

Thanks a lot @Collabora!
Comment 10 Aron Budea 2019-03-21 23:12:55 UTC
Let's use verified status, thanks for retesting Nicolas!