I received the following error several times from LO Calc 5.0.2.2 (release version): LibreOffice 5.0 - Fatal Error SEH Exception: ACCESS VIOLATION Since this is a severe error, I will provide as many details as possible: 1. Occurred when using the Windows 7 jump list of the taskbar's LO Calc shortcut to open a spreadsheet. Specifically, right-clicking on the LO Calc taskbar icon, and then selecting the file from the jump list. 2. LO Calc would open, the spreadsheet would display, the error would appear, and LO Calc would hard crash. There was no way to try to save the file. 3. Tried multiple times, with the same result each time. 4. The spreadsheet was originally created in LO Calc, most likely in version 4.x. Never a problem in version 4.x with the spreadsheet. The spreadsheet is not very large (under 10,000 cells), and does not contain highly complex formulas. It does contain custom cell styles as well as conditional formatting. I cannot upload the file. After multiple abends, I experimented with colorful NSFW language. Some of the word combinations were unique, and I may have to look into publishing them. I then tried opening LO Calc without any file, and then opening the file via the Recent menu. The file loaded successfully. I then saved it with a new name. Then, I tried the jump list again to load the ORIGINAL file (the one that just repeatedly caused the hard abend), and it suddenly loaded without error. Truth is stranger than fiction. This happened on a Windows 7 SP1 64-bit system running the 32-bit version of LO Calc 5.0.2.2, installed using the Typical Install option. No other consumer applications were open during this experience.
If you can't share the original file, you could anonymize it: https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission#Sanitize_file_text Hopefully you could still reproduce the crash with the anonymized file. You might try to get a backtrace of the crash: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg Without the file we can't reproduce this. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided more information/the file.
The second to last paragraph in post #1 explains that even the original file no longer causes the crash. Hence the last sentence in that paragraph: "Truth is stranger than fiction." Consequently, the first place to look for the cause of the bug is what could have possibly changed during the events: opening file via jump list caused hard LO Calc crashes, followed immediately by loading the same file using the Recents menu (successful), followed immediately by saving the file with another name, followed immediately by performing the same action that caused the crash. No other steps were taken. Additional info: spreadsheet was stored on a local drive, and not on a network.
Ok, then we can't really confirm it. I'm going to have to set this to worksforme, but if the problem returns and you manage to replicate it and get a backtrace, you could change it back to unconfirmed.
Okay, sounds good. Well, maybe not. If a bug, even a severe crash bug like this one, cannot be reliably reproduced, is it best just not to report it? For non-reproducible bugs, it seems like it is a waste of the bug-reporter's time to compose a detailed report. I made it a priority to stop my work and file a bug report to help the LibreOffice community. I spent my time writing all the details. I provided the exact steps I took that fixed the issue. To someone more familiar with the LibreOffice code, that info may hold the key to understanding the problem. If this bug is flagged RESOLVED-WORKSFORME, we will never know, because no one will ever read it. The bug is definitely present. I don't think it's in LibreOffice's best interest to mark known bugs as RESOLVED. Marking it as UNCONFIRMED is appropriate, because it has not been confirmed by another party (well, except for everyone at the client's office who lost confidence in LibreOffice as they watched it crash repeatedly). I truly understand that it makes life much easier when a bug can be reliably reproduced, but the most challenging bugs are not like that.
Well, do you have a plan for when we can set this to WFM, then? Does 6 months without it occurring again qualify for closing? I recently completed a survey and found that we have about 80 reports in the tracker that could be resolved by this: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile User profile corruption (which is a bit vague of a term) can lead to all kinds of craziness, including crashes. Yet, the reports are not left open after it is discovered a profile reset solved it. Without a backtrace of the crash or a reliably crashing file, there is nothing a developer or a QA person can do to investigate.
Since on LibreOffice 5.0.X, Must return in previous version (For many computer of my office in 4.4.3.2). In 4.4.x no problem. No problem in OpenOffice 4.1.1. Trying to repair file > KO nothing better. Delete profile doesnt have effect.
(In reply to Jean Paul from comment #6) > Since on LibreOffice 5.0.X, Must return in previous version (For many > computer of my office in 4.4.3.2). In 4.4.x no problem. No problem in > OpenOffice 4.1.1. Trying to repair file > KO nothing better. Delete profile > doesnt have effect. Seems to be with a huge number of data. Mine have 19 tab and one picture(3kb).
There really isn't enough information here for us to do anything about the issue. If you want you can do a trace of the crash (since you've provided nothing for us to really reproduce) and attach it to this bug. I am marking this as WFM - please do not reopen it until you've provided a detailed log according to the wiki below. When you do, you can change status as UNCONFIRMED. Thanks https://wiki.documentfoundation.org/Development/How_to_debug
Just to be clear, it appears to be a waste of time for people to submit bug reports (even critical crash reports) unless the crash is easily reproducible. I will no longer be submitting such bug reports, and will instruct my clients to refrain from doing so. Unfortunately, it also means many clients will have to switch away from LibreOffice. If multiple people all experience LibreOffice crashes that cannot easily be reproduced, there will be no work to fix it, because all the bug reports will be closed and marked "WORKSFORME". This is contrary to best practices for software development and testing.
Fair enough - good luck. If you ever return just know that we expect our users who have hard to reproduce bugs to work with us (which we asked, provide a sample, and do a backtrace). We're available to help (both via email and in live chat). The fact that you've decided that you can't take the time to do these things just reflects your misunderstanding of how our project works. That being said, it seems to not work for you, so, again, good luck moving forward.
Your attitude comes across clearly. If you actually took a moment to read the bug report I filed, you would understand that providing a trace is impossible as is providing a document that will reliably reproduce the bug. I have taken my time to accurately and extensively provide every detail I could in order to help this project. Your "don't let the door hit you on the way out" attitude is appalling for a community-based open-source project like this. LibreOffice does not belong to you. You don't speak for this project, and thankfully, you never will.
(In reply to helplibreoffice from comment #11) > If you actually took a moment to read the bug report I filed, you would > understand that providing a trace is impossible as is providing a document > that will reliably reproduce the bug. > > I have taken my time to accurately and extensively provide every detail I > could in order to help this project. If we assume you had been able to get it to crash again, I don't see why getting a backtrace would have been impossible. If we assume that you will not be able to get it to crash ever again, then this report will lead nowhere and such weird crashes are best left to the crashtesting VM and fuzzers and such. You can read more about those in these links: https://mmohrhard.wordpress.com/2013/04/19/automated-import-crash-testing-in-libreoffice/ http://caolanm.blogspot.com/2015/10/finding-ui-crashes-by-fuzzing-input.html It is untenable that you ask us to behave in a certain way or you will start painting LibreOffice black. You know you can always come back to this report, add new findings and open it again, so why resort to threats?
Naturally, if the crash is reproducible, I will provide a backtrace. That's a given. Your two assumptions disregard many possibilities, including the most obvious one: that other people may experience the same issue and will add more details. One user already started doing this before the bug was erroneously relabeled as WORKSFORME. I have made no threats. Most of my clients are not willing to use software that exhibits hard crashes, that when reported, the response is the proverbial "don't let the door hit you on the way out". Furthermore, in good faith, a quality consultant cannot recommend such a product to any clients for production use. I'll take a few minutes of my time to explain best practices regarding software testing and development. I am available for trainings on this topic, although my schedule is completely booked for the immediate future. It is very common in the industry for software to have major bugs that are not easily reproduced This is nothing new. When such bugs occur, the best practice is to gather as much information regarding the circumstances of the bug. This typically includes software, hardware, and the steps the operator took when the bug occurred. My report is a good example of one that provides extensive details as to the steps that resulted in the product (LibreOffice, in this case) crashing. The best practice is also to gather as much information as possible as to the specific errors generated. Again, my report is a good example of one that provides such information. Now that you have a quality report, the last thing you want to do is shuffle it off into the "we will never look at this again" file. Best practice is to do exactly the opposite. Best practice is to request correlative data from other parties. An effective development team (which includes the QA department) will work to collect all other data that might be related to the issue. Such a team will also work to encourage users and developers alike to provide more supportive data. For example, some proactive firms will issue bulletins indicating that one customer is experiencing an issue, and request correlative data from other firms. Many serious bugs go unreported or under-reported. The onus is on the development team to gather more information about the bug, in order to fix it. The last thing a team wants to do is sweep bugs under the carpet. When that type of behavior is condoned, the quality of the product always declines. In response, the size of the user-base decreases as people find other solutions to meet their data processing needs.
You clearly don't understand the open source world - the "onus is on the developer" is about as ridiculous of a statement as can be found on our bug tracker. I'm not sure why you're still being active - the issue is closed, you're moving on, we're okay with that (again, wishing you best wishes along the way). Would you like for me to close your bugzilla account? (real question since you said you're moving away from LibreOffice and won't be using the bugzilla account any longer)
"Most of my clients are not willing to use software that exhibits hard crashes" Then your clients cannot possibly be using any software, and since you had open that bug for 'Windows' surely you statement is not true. Oh, btw, your 'clients' are not our 'clients'. We are a free software project. most of us are doing this on their free time, none of us have any obligation to care about your clients... There are services company that specialize in that, if you want a service-level agreement you should contact them. "I'll take a few minutes of my time to explain best practices regarding software testing and development." You should not have. keep your precious time and avoid wasting ours at the same time... "I am available for trainings on this topic," And yet you seems not to be very familiar with it as illustrated by you tantrum and demands. "It is very common in the industry for software to have major bugs that are not easily reproduced This is nothing new." No easily reproduced is not the same as not reproducible by any known method. "My report is a good example of one that provides extensive details as to the steps that resulted in the product (LibreOffice, in this case) crashing." your report boils down to: I managed to crash the product, I can't reproduce the crash, and I won't give you the document that trigger it.. iow, no dev can do anything about it. my favorite part is "2. LO Calc would open, the spreadsheet would display, the error would appear, and LO Calc would hard crash. There was no way to try to save the file." the error being the crash-notification dialog right ? that was not followed by Lo crashing 'hard' (as if there was such a s thing as a soft crash), that was preceded by it, which triggered the crash dialog. No way to save the file ? you said you just opened it, why would there be any reason to save anything.. beside yeah, upon a crash by definition you can't continue to use the app, to save or otherwise.... There is nothing inherently wrong with your attempt, and no-one would have pointed it out had you not insisted to be an expert on the topic and claimed to have provided: "Now that you have a quality report" If you _actually_ had any understanding is what is involved in software development you would not have hold such ludicrous assessment. "Such a team will also work to encourage users and developers alike to provide more supportive data." we did and we get: "I cannot upload the file." "I tried the jump list again to load the ORIGINAL file (the one that just repeatedly caused the hard abend), and it suddenly loaded without error." How on earth do you imagine anyone can do anything with that. "The onus is on the development team to gather more information about the bug, in order to fix it." You do not have the first clue about how free software works... the devs owe you nothing, nor does any other _volunteers_ working on the project. Most of us are usually willing to help, but banging your fist on the table with a sens of entitlement is not the best way to get people to spend their free time helping you. and btw, earlier you said: "You don't speak for this project, and thankfully, you never will." If you cared even a little about the project, you might have seen this page: https://www.documentfoundation.org/foundation/board/ pay attention to the third entry there... my advice: keep off the keyboard for a few days... collect yourself, try to reproduce the bug and come back, keeping in mind that we are not your vendor or employee.. we do that in our spare time and certainly not to be yelled at, insulted, patronized.... I, for one, do not hold grudge.. so I will assume, for now, that you just had a bad day, and needed to vent, and that normally you are not like that.
Instead of responding to Joel Madero and Norbert Thiebaud with the same atrocious nastiness and hostility that they each decided to exhibit (shame on you both), I chose to dedicate my time to peacefully testing LibreOffice to find what is actually causing it to crash so often. I successfully found the root cause of the bug that all the crashtesting VMs and fuzzers were not able to find. The root cause of the bug would cascade, causing LibreOffice Calc to generate an Access Violation. By narrowing it down to the root cause, the Access Violation can be avoided, but LibreOffice Calc will still crash each and every time. Steps to reproduce: 1. Open LibreOffice Calc v5.0.4.1 2. Enter 1 into A1 3. Enter 0 into A2 4. Select A1 5. Go to Format->Conditional Formatting->Icon Set 6. In the resultant dialog box, change the yellow arrow row to "=A2" and "Formula", and then click OK 7. Select A2 8. Go to Format->Conditional Formatting->Icon Set 9. In the resultant dialog box, change the yellow arrow row to "=A1" and "Formula", and then click OK 10. Save the spreadsheet 11. Close LibreOffice Calc 12. LIBREOFFICE CALC WILL NOW CRASH 13. Open the saved file in LibreOffice Calc 14. Close LibreOffice Calc 15. LIBREOFFICE CALC WILL NOW CRASH, JUST BY EXITING LIBREOFFICE CALC 16. Repeat steps 13-14 17. LIBREOFFICE CALC WILL CRASH EACH TIME Note that even if many edits are performed in the spreadsheet between steps 13 and 14, LibreOffice Calc will still crash. To one of my clients, it made it look like each edit was causing another crash. In fact, as steps 16-17 demonstrate, simply opening the file and then closing LibreOffice Calc will result in a crash. Based on the behavior of Joel Madero and Norbert Thiebaud, I will no longer be making my annual financial donation to The Document Foundation. After witnessing the treatment I received, I doubt any of my clients will continue to donate. Although I will no longer be contributing financially, I hope this bug report will help improve the LibreOffice project.
Created attachment 121159 [details] Backtrace of crash on Windows, LibO 5.0.3 Thanks for the instructions! Now I could reproduce the crash and I even managed to get a backtrace. Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI)
Thanks for finally reporting a decent bug. Looks like the "nastiness" (honesty?) taught you something about reporting good reports in open source world. Other open source projects will surely appreciate this as you report other bugs. Also - it appears like you're here to stay? I offered to close the account if you're not interested in LibreOffice (as was mentioned) but.....you're back? Just want to be sure as this is on my to do list (try not to keep accounts around when a user has told us they are moving away from the product).
Beluga: On pc Debian x86-64 with master sources updated today or with LO Debian package 5.0.4.2, I don't reproduce this. Would you have some time to give a try to either 5.0.4, 5.1.0.2RC2 perhaps master daily build? If just one, perhaps master one in order to know if it's solved at least with the dev most up-to-date. (http://dev-builds.libreoffice.org/daily/)
Still crashes in 5.0.4, but not in 5.1 RC2 or 5.2. Note: crash happens on closing whole LibO, not Calc. Win 7 Pro 64-bit, Version: 5.0.4.2 (x64) Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Locale: fi-FI (fi_FI) Version: 5.2.0.0.alpha0+ Build ID: 6b65a0e83c4798f117be61af91dbaebdc85e94b7 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-21_03:41:08 Locale: fi-FI (fi_FI)
(In reply to Buovjaga from comment #20) > Still crashes in 5.0.4, but not in 5.1 RC2 or 5.2. > > Note: crash happens on closing whole LibO, not Calc. > > Win 7 Pro 64-bit, Version: 5.0.4.2 (x64) > Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 > Locale: fi-FI (fi_FI) > > Version: 5.2.0.0.alpha0+ > Build ID: 6b65a0e83c4798f117be61af91dbaebdc85e94b7 > CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; > TinderBox: Win-x86@39, Branch:master, Time: 2016-01-21_03:41:08 > Locale: fi-FI (fi_FI) So I can't reproduce this on Linux and I think it is a platform dependent bug. If I understand the backtrace correctly it is in the destructor for the bitmap representing an icon. Now the interesting part is that it seems that the destructor for the windows gdi resource is destructed long after vcl has been cleared. If this bug is really limited to 5.0 and does not appear in 5.1 or master we can close this bug. I'm not going to spend a long time chasing a lifecycle issue deep down in vcl for 5.0.6. If that bug can also be reproduced in another version I will sadly need to start looking for ways to fix this problem.
Actually the fix for it is most likely 05896a16412dd48d19ffd2e360ae7da5e41c2725.
Yep, let's set to FIXED then.