Description: 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:
Created attachment 148111 [details] Crash after "stand by"
Moving to NEW
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.
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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/online/+/8dce31364219ed5a41a4f8f530ab658d4aff7778%5E%21 tdf#122543: Ignore duplicate calls to loadFromContents on same Document
The above fix (also in the cp-6.0 branch) helps. Will be included in the next build of the app.
I mean collabora-online-4 branch, not cp-6.0
Nicolas, please mark as verified when you have eventually verified that the bug is gone.
Fixed in 0.1 (23) Thanks a lot @Collabora!
Let's use verified status, thanks for retesting Nicolas!