Exact steps taken (no steps in between):
1. Win 7 SP1 system with LO 4.3.6 installed and working normally.
2. Installed LO 184.108.40.206 on top of it.
3. Opened Calc. Closed Calc.
4. Opened Write. Closed Write.
5. Opened Calc with a file that worked fine in LO 4.3.6.
6. Made some edits in Calc.
7. Closed Calc.
Problem Event Name: APPCRASH
Application Name: soffice.bin
Application Version: 220.127.116.11
Application Timestamp: 55406b60
Fault Module Name: vcllo.dll
Fault Module Version: 18.104.22.168
Fault Module Timestamp: 55404a02
Exception Code: c0000005
Exception Offset: 0037efd5
OS Version: 6.1.7601.2.1.0.768.3
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Sorry, cannot submit file. Maybe the above info will help.
If this is information is not useful or helpful, please delete this bug report.
Looks similar to bug 86401.
Does look similar, although that was for Writer, and this is for Calc... but perhaps it is a component in common that is crashing.
BTW, it happens every time, with the exact same error report produced.
Test system was running Win7 SP1 64-bit (modern Intel processor).
More info: I created a fresh LO profile, and found a trivial way to reproduce the bug without needing any spreadsheet file.
Note that all I have to do is copy a single cell, paste it, and then close (without saving); LO Calc will crash every time.
Here are the exact steps:
1. Load LO Calc with a fresh profile, and no spreadsheet file.
2. Type 'hello' in A1
3. Hit enter
4. Hit up arrow
5. Hit Ctrl+c
6. Hit down arrow
7. Hit Ctrl+v
8. Hit the little red close button in the upper right corner
9. Press the "Don't save" button in the message box
Crashes each and every time, with error reported above.
Yes, every time.
Tested on other systems?
Reproducible on other systems?
Yes, every time.
Hmmm... I refused to believe that such a huge bug could slip through the cracks. So I tried it on 3 systems, and each showed the same crash.
But now I've tried the same procedure on a fourth system, and it does not have the problem at all (and should have the same LO upgrade path).
So I'm trying to narrow down what is different that would cause the error in some systems, and not others. Isolating all the variables will be a time-consuming challenge.
Please look here: http://portableapps.com/node/36359
Thanks. DLL's confirmed to be as they should be. Just FYI, there are some transposed letters within filenames in the contents of that thread.
As I'm trying to determine what is causing LO to crash, I have a question: is registrymodifications.xcu just a log, or does it have other functions?
Still interested in the answer to question in comment #7 above, but for now must stop all testing.
So here's the report of what I've worked on; hopefully it will help others:
Can get LO Calc to crash when exiting on multiple Win 7 SP1 64-bit systems.
As soon as it looks like it is reproducible on every system, it will suddenly stop crashing (when starting the testing with a new profile).
This suggests one of 3 possibilities off the top of my head:
1) Self-healing: something breaks, but it fixes itself by design
2) Timing is critical: small differences in timing of operations may cause different results
3) Conflict: another process is preventing LO to work as designed
Current guess: Now, this is just a guess, but I'm thinking that an Antivirus program is sometimes interfering with LO writing its profile files, thus causing frequent profile corruption. I noticed that every system with the problem was running Avast Antivirus 2015.10.2.2218 (their current release as of this post). This could be a coincidence, I'm not sure. Often, when LO Calc was running (and after it exited), Avast was performing a large number of real-time scans of LO files.
At this time, it appears that repeating identical procedures results in different outcomes. Sometimes LO Calc works as expected, and sometimes it crashes. But once it gets into "crash mode", the crashes seem to be easily reproducible. I haven't had enough time to determine what causes LO to get into "crash mode", and I must now switch tasks. Well, actually I needed to switch tasks hours ago... :O
The following crash is reproducible on every system I tested (8 systems). All systems were Win 7 SP1 64-bit.
How to reproduce:
1. Delete LO Profile
2. Open Calc
3. Close the sidebar from the sidebar's drop-down menu
4. Close Calc
5. Open Calc (this is not a mistake - do it!)
6. Close Calc
7. Open Calc
8. Type 'hello' in A1
9. Hit enter
10. Hit up arrow
11. Hit Ctrl+c
12. Hit down arrow
13. Hit Ctrl+v
14. Hit the little red close button in the upper right corner
15. Press the "Don't save" button in the message box
Result: LO Calc Crashes (same error as reported above)
Please confirm this bug.
Created attachment 115512 [details]
I confirm this as reproduced on Windows 7 64-bit with LO 22.214.171.124. Didn't test further.
Thanks for the confirmation and backtrace, Timon. Happy to see that my time spent on testing will likely be useful to the project.
This should be fixed, of course, but the priority you changed is not in accordance with https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg.
That's not crash in use, only crash on exit which doesn't prevent work, so it's more likely to be marked as minor.
When I follow the flowchart, here's what I get:
START -> Does the bug cause crash...? -> YES -> Does this bug happen very frequently on clean install/install attempt? -> NO -> Critical -> Does bug involve major component affecting most users? -> YES (Calc) -> HIGHEST.
Currently, I have the crash set at MEDIUM/MAJOR. According to the flowchart, I didn't set it with enough importance. Although the flowchart recommends HIGHEST/CRITICAL, I think it is a little better at only HIGH/CRITICAL because it requires closing a new sidebar that is now enabled by default on a clean install. Not an uncommon task, but may not affect users who leave it on (I haven't debugged the source code to determine what is actually causing the crash, nor will I be taking on that task). I'll set it to the lower end of what the chart recommends, and if the chart needs to be changed or clarified, we can change the chart.
I should note that the simple steps I generated to reproduce the crash are not the only ways to reproduce it. I discovered the crash during evaluative testing for a client, and worked backwards to determine a simple way to reproduce it (not a trivial task). Unfortunately, LibreOffice failed the client's evaluation, and they have moved on to evaluate another office suite. This satisfies the "Does the bug reflect poorly on LibreOffice to the community" criteria specified in the flowchart.
I originally reported bug 90873 , but could not give out the ss that caused it.
I have the following to add:
The bug still exists in LO 126.96.36.199. (I first discovered it in 188.8.131.52)
I can reproduce it on Windows 8.1 using essentially the same method as comment 3 (just no new profile; I open calc directly from a shortcut on my desktop to the binary):
type "asdfg" into cell A1
down arrow to A2
up arrow to A1
down arrow to A2
click the red "X" in top right hand corner to exit
click on "Don't Save"
I am also using Avast Antivirus 2015.10.2.2218
This is starting to look suspicious
If I wait a while (5 to 10 minutes) between saving and closing the original ss
it doesn't crash. Using the above and waiting between discarding the ss and closing calc also does not crash.
It seems pretty certain this is the same bug as 90873, but this is far easier to reproduce
*** Bug 90873 has been marked as a duplicate of this bug. ***
I have a bit to add:
1) Disabling Avast makes no difference to the crashing
2) I get(superficially)the same crash on another box (old, air-gapped, XP SP2, AVG free) on both LO 184.108.40.206 and 220.127.116.11
So it does NOT depend ONLY on Avast
I'll try disabling AVG early next week, and report back
I came to a similar conclusion.
I'm not sure how many different crash cases we are dealing with, but I have concluded that the one that is simplest to reproduce (comment #9) is not related to Avast or any other antivirus.
I can now confirm that the simplest crash (copy paste from A1 to A2) occurs on XP SP2 with AVG free disabled.
Fwiw the error message is:
The instruction at "0x02bfefd5" referenced memory at "0x00000004". The memory could not be "read".
Created attachment 115975 [details]
File causes calc crash on calc exit
Previous attachment went in without my comments.
When I open file then exit calc will crash.
If changes are made to spreadsheet and not saved data is lost.
I started with a new file and added to it until it failed.
Spreadsheets with less sheets are OK.
Problem seen in many versions of calc.
*** Bug 86401 has been marked as a duplicate of this bug. ***
Wow - I was concerned about this being a VclPtr bug - but it's 4.4.x only =) Can anyone reproduce it in 5.0.x-beta ?
(In reply to Michael Meeks from comment #23)
> Wow - I was concerned about this being a VclPtr bug - but it's 4.4.x only =)
> Can anyone reproduce it in 5.0.x-beta ?
this error I have seen so far in LO 5.0 beta 1
bug 86401 - my bug, however, in the release version 4.4 this error does not occur
Created attachment 116079 [details]
00bff58c 66307e28 09fa9970 675a106f 10da6f09 vcllo!Application::GetSolarMutex+0x5
00bff594 675a106f 10da6f09 09fa9970 09fa9970 vcllo!SolarMutexGuard::SolarMutexGuard+0x8
00bff5b8 675a239b 09fa9970 00bff5d4 692753dc sblo!DocBasicItem::~DocBasicItem+0x4f
the stack Timur posts has ^^^ in it, which means its a duplicate of 90969
*** This bug has been marked as a duplicate of bug 90969 ***
The different crash on comment #20 is fixed in 5-0 and backport for review to 4-4 is at https://gerrit.libreoffice.org/16298
Is the reproducible bug in Comment #9 fixed by the patch that will be included in 5.0 and backported to 4.4.x?
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":
Related: tdf#91214 crash on exit after loading comment #20
It will be available in 4.4.5.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.