Created attachment 123626 [details] Print Screen showing assertion failure CALC Crashes when attempting to reformat a cell. I'll attach the print screen image showing the error message and the test file which should be usable to reproduce the problem.
Created attachment 123627 [details] Test case file
Re-Testing with: Version: 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: en-US (en_US) reproduces same problem
Version: 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: en-US (en_US) Win 10 pro Unchecking OpenCL under Options does not affect the test result.
(In reply to Michael Amaral from comment #0) > Created attachment 123626 [details] > Print Screen showing assertion failure > > CALC Crashes when attempting to reformat a cell. Hello, what do you mean by "reformat a cell"? Please specify. Thanks.
specifically what I meant by reformatting a cell follows: 1) select a cell in any spreadsheet by single clicking on it 2) select the "Format" pull down menu (by placing the cursor over this menu item and clicking) followed by scrolling down to select "Cells..."
Could you get a backtrace: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg When you reproduce the crash, you can hit retry in the "assertion failed" dialog to be able to debug.
Created attachment 123750 [details] backtrace
WinDB ran with Version: 5.2.0.0.alpha0+ Build ID: b89feb8018bf3610faf01e73995d576f6566e20b CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17 Locale: en-US (en_US) reproduced crash and saved backtrace file
Could not reproduce using the attached test file in Windows 7 x64 with this build (dbgutil enabled) from a few days ago: Version: 5.3.0.0.alpha0+ Build ID: c0d7dfa56c8a335bdea1be2ddce33a0f19b28bbd CPU Threads: 4; OS Version: Windows 6.1; UI Render: GL; Locale: hu-HU (hu_HU)
Michael, does this error still occur in a current debug master build?
I haven't been able to recreate this problem with the version I have been using for the past several weeks. This version is: Version: 5.2.2.2 (x64) Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US); Calc: group
I haven't tried it with the master build Aron refers to. I'll test again and submit a comment with the results.
Thank you for the update. Since it was an assertion failure, the crash should only occur in a debug build.
Hi Aron, I may not be understanding what you mean by the terms "assertion failure" and "current master debug build" in the comment you posted. If you'd like me to do more testing with a specific build, please reply with instructions on how I could download said build. I'd be happy to test it and post the results. As you can see from my comments, I'm running LO in a 64 bit PC under Windows 10. Thanks for working on this software. I've had great results with using Libreoffice, and continue to appreciate the opportunity to use it.
Áron, Michael: unfortunately there are no debug builds available (Tinderbox no. 39): http://dev-builds.libreoffice.org/daily/master/Win-x86@39/ Will have to ping kendy about that.
(In reply to Buovjaga from comment #15) > Áron, Michael: unfortunately there are no debug builds available (Tinderbox > no. 39): http://dev-builds.libreoffice.org/daily/master/Win-x86@39/ > > Will have to ping kendy about that. Update: the CPU fan on the machine had died, so kendy had to order a new one. Hopefully he will have time to install it during the weekend.
(In reply to Michael Amaral from comment #14) > I may not be understanding what you mean by the terms "assertion failure" > and "current master debug build" in the comment you posted. My bad for being unclear, from the initial description I assumed you knew what it was. I can't explain it well, maybe read [1] to get an understanding of it. The important points: - they only trigger in debug builds (so not in releases), - they signal issues with the internal state of the program (basically they're some assumption the programmer made that should be true at that point, and it isn't). Therefore to test it you will need a master build compiled for debugging, you must've used one like that before as well. As Buovjaga mentioned no daily debug builds are available for Windows at the moment, but they should be back up soon, in the place he linked. Let me know if anything is still unclear. Thanks for the feedback. [1] https://en.wikipedia.org/wiki/Assertion_(software_development)
Ok, the builds are finally up again: http://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170727
I've been using Version: 5.2.2.2 (x64) Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: group for months, and also tested other previous non-debug builds without experiencing this bug. It appears to have been corrected. I have no additional information I could contribute at this time. As far as I'm concerned, no further action need be taken on this bug and it would be appropriate to change its status to RESOLVED. I've changed the status to UNCONFIRMED as requested by QA Administrators.
Closing as RESOLVED WORKSFORME then