Issue 121337 - random crashes with linked files
Summary: random crashes with linked files
Status: CLOSED DUPLICATE of issue 120013
Alias: None
Product: Calc
Classification: Application
Component: ui (show other issues)
Version: 3.4.1
Hardware: Mac OS X 10.8
: P3 Critical (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact: Alex
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-11 12:40 UTC by pldg
Modified: 2017-05-20 09:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
standard crash report generated on MacOS (65.84 KB, text/plain)
2012-11-11 12:49 UTC, pldg
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description pldg 2012-11-11 12:40:12 UTC

    
Comment 1 pldg 2012-11-11 12:49:10 UTC
Created attachment 79901 [details]
standard crash report generated on MacOS
Comment 2 pldg 2012-11-11 13:18:15 UTC
I'm a professor and work with a rather complex spreadsheet with student data, each tab referencing cells from other tabs. I'm not sure whether I had another spreadsheet with 200K+ cells open at the time (really a database for me). I might also have a third one open, a small one that does lookups on the second one (database). After I'm happy with the lookups, I copy and paste the results to the first one, so those two might be just open when the crash occurs. The crash on the first one might also have happened without those two; my memory won't help here.

The first one (with no external links) is 246KB, the second one, i.e. the "simple" one that references data on the third one (a 2.3MB "database") is 1.3MB, despite having only about 160 lines by 10--15 columns, but I guess this is due to the external references.

All of a sudden OO crashes, all windows disappear. On recovery afterwards, I usually lose recent data.

If the crash is really related to the large "database" sheet (still an ods file), I might add that the second sheet, the one that references data on it, is quite unusable in UI terms. Just trying to scroll it is enough to trigger a freeze that might take up to half a minute, colored spinning wheel etc. Editing any cell with content will also trigger this long freeze. I will probably assemble a csv file with those data and grep things with the shell, since getting the data I need will certainly take much less time this way.

The files contain some sensitive data, but I may be willing to make them available to some developer that takes responsibility for keeping them private (I would send an URL through private mail, in which case please let me know that address).

I also should add that these crashes (more than one on this season) is not related to these particular set of files or OO version, since on previous semesters I had the same issue, with the by then current OO version. Last semester, for instance, I had a version of my spreadsheet that had the large set of data as a tab in it, with cells on other tabs looking up data on it. Needless to say, when I started to use it with the current student data, the file became unbearably slow, as described above, and with the frequent crashes I lost data. The quick solution was to remove the large data set from the file, as well as all reference to it, becoming the current version (3 files).
Comment 3 pldg 2013-05-20 12:26:40 UTC
Ever since I was instructed to clear preferences/profiles when crashes happened, then I've been living with that. It works but is far from acceptable, because you ened to reinsert all your preferences manually again. Not only this takes time, but also is hard to do it since who can actually remember all the few options that one requires to have a working environment? Like, not checking spelling or disabling the dreadful auto input stuff...

Having to remove my preferences folder has happened at least 3 times since I was instructed to do so. Funny I don't see that recorded on the bug track.
Comment 4 pldg 2013-05-20 12:29:04 UTC
Found it. I had filed another bug at some other point in time.

*** This issue has been marked as a duplicate of issue 120013 ***