During normal operation, tried to load a file that was too big for calc. OK, ignore and move on. To test for another bug, "kill"ed office. On starting oocalc, got the Document Recovery with 10 documents. One of those docs was the one that failed to load days earlier. Got the "The data could not be loaded completely because the maximum number of rows per sheet was exceeded."
This file, having failed previously and the load cancelled, should not appear in the Document Recovery.
Edited registrymodifications.xcu to remove references to the non-existent file; suspected this may not work because there were 2 references to this missing file which appeared identical. Starting oocalc after deleting these <item> records results in LO going to 100% CPU.
Since LO doesn't like a modified registrymodifications.xcu; restored original and created an empty file. LO offers to open with an empty Text Import dialog; OK results in 100% CPU. Killed.
Try again; but hit Cancel on Text Import dialog leads to successfully opening several documents.
Exit LO without saving any documents finally cleans up the recovery process.
Obviously not a user friendly way to get out of crashing...
AFAIK loading a file does not change its internal contents, so there's no point recovering the file.
(In reply to Rafael Lima from comment #3)
> AFAIK loading a file does not change its internal contents, so there's no
> point recovering the file.
"recovering" in this context has nothing to do with contents; it's simply about restoring the session -- like a browser restoring all the open tabs. In this case, OO failed loading a file; yet put it on the recovery (restore) list. A file which fails to load is not part of a session to restore; because it failed and is not loaded when the session is saved for later restore. HTH