Reported also by a user on http://ask.libreoffice.org/en/question/19894/ Seems to be similar to this old bug: https://bugs.freedesktop.org/show_bug.cgi?id=40571 Although I can only reproduce it on somewhat complex files (several of them).
Created attachment 95071 [details] Spreadsheet with named ranges. Crashes when managing those. I managed to clean sensitive data from this workbook, although I deleted some sheets that had named ranges. Trying to modify named ranges (for instance the "Llave" range) crashes Calc. Trying to delete appears to work, but it crashes when saving.
No crash for me. Marking as WFM. I am running: Ubuntu 13.10 LibreOffice 4.2.2.1 Please try with 4.2.2.1 (which is currently rc so not recommended for daily use). Before installing 4.2.2.1 please purge libreoffice completely from your system. If you still experience the crash please reset your profile: https://wiki.documentfoundation.org/UserProfile If you still have problems please mark as UNCONFIRMED and tell us more about your system (distro, locale, etc . . .)
Okay I take it back - it crashed when I tried to close it after modifying the name.
Confirmed on: 4.2.2.1 rc but it looks fine in 4.3.0 build a couple days ago Still worth marking as NEW and making sure that the commit gets backported as we don't want managing ranges to cause crashes in 4.2 until 4.3 is released. If 4.2.2.x release shows it to be fixed, please come back and mark as RESOLVED-WORKSFORME so we know it's been fixed in 4.2 branch. Thanks!
I'm afraid this test document has been too messed up for us to use. This has nothing to do with named range editing. On the 2nd sheet in Column E, you have lots of formulas that are totally empty, which should never happen. How did you manage to get those in?
Once Column E is removed from the document, modifying range names doens't cause any instability. Valgrind reports no memory issues. So, the only question is how those invalid formula cells ended up in Column E (on the 2nd sheet) in the first place.
I have a similar problem, on 4.2.2.1 Ubuntu 13.10 64 bit. I have a complex workbook with many sheets and many named ranges. I have two named ranges that I cannot amend or delete without Calc crashing. I'm not running the debug version so don't have any crash report or evidence anywhere. It just stops. As a work-around I recreated a copy of the sheet to which these two names refer, created new names, and changed all references to use these new names. My data is now sound. I still couldn't amend the two old named ranges without Calc crashing. I then deleted the underlying sheet to which the problematic names refer. However, I still have the two named ranges, which now have invalid references (eg $#REF!.$A$1:$H$35) since the sheet to which they refer has been deleted. However, I still cannot delete or amend the names without LO just stopping. I cannot supply the sheet, nor a crash report even if I had a debug version, since the data is personal finance information.
It occurred to me to try the same sheet in a different version - 4.1.4.2 - under Windows 7. I deleted the two named ranges with no difficulty. There were other differences in the environment, including the fact that macros were not enabled because the file wasn't in a trusted folder, and there was no link to my LibreOffice Base/MariaDb database (from which the data comes for the sheets on a manually requested refresh to pivot tables). So I haven't got a decent proof that it's the LO version, but if people have been working on Named Ranges since that version there's a clue that something may have gone slightly awry.
This is worse than I thought. Having successfully replaced the sheet and named range that I thought was causing problems with a new sheet and named range, I cannot modify that new named range under 4.2.2.1 ubuntu 13.10 64 bit. LO just stops again, either immediately or when I save. Under Windows 7, 4.1.4.2 it works fine. To check that this is not macro related I tested the same sheet on my ubuntu system in a different directory that wasn't trusted, and did not enable macros. No change. To test things further I inserted a brand new simple named range pointing to one cell, with no references to that name from elsewhere. That worked OK. On deleting it, LO stopped again. It now seems that to make any changes to my named ranges in this complex set of sheets I have to use my Windows partition (and older LO version), something I spend a lot of time trying to avoid! I tried to reproduce the problem on a trivial ods, but have not yet succeeded. I'll keep trying.
I'm not running a debug version of LO, but I do now have an ubuntu crash report. I'd rather not publish this on a public website due to the nature of the data in the spreadsheet. However, I am willing to send it by private email to someone listed as working for LibreOffice if needs be. It isn't small (17 MB zipped). I have access to a dropbox if that would make it easier/safer. I'm not sure how easy it would be for someone to decode the contents. Probably much easier than I imagine, so I'd appreciate some advice. If a debug version is needed I'll install it and try again.
Is anyone likely to look in to this? I've been offering to try and help diagnose the problem for a few days, but so far there's no response. If no one wants further data from me I'll back out to an older version of LO. That will not, however, help to find and fix whatever is going on here, so I'd rather pursue it on this (or newer) version if I can.
(In reply to comment #6) > Once Column E is removed from the document, modifying range names doens't > cause any instability. Valgrind reports no memory issues. So, the only > question is how those invalid formula cells ended up in Column E (on the 2nd > sheet) in the first place. My sheet works fine in 4.1.4.2, so it's not a corrupt sheet in my case. I'm hoping to help someone research this further, as I've said above.
Moving back to NEW - Kohei doesn't get email from FDO so he may be unaware that more info is on the bug now
Thanks very much. Libreoffice people have usually been so quick to respond to comments that I have got too used to it and was beginning to wonder if the problem was being ignored. :-)
Created attachment 96104 [details] A spreadsheet demonstrating the crash I have finally managed to remove over 90 sheets and reduce my problem spreadsheet down to 2 sheets with no personal data, as attached. One sheet contains a pivot table to a database. If it asks for a password just leave it blank and it should proceed OK. The other sheet has some fields which reference a Named range called AcBalances. This refers to $AccountValsPvt.$A$1:$H$36 Use Insert, Names, Manage to change this to $AccountValsPvt.$A$1:$H$37, and Save. Calc crashes. There are a host of invalid range names because I have deleted the sheets referred to. I can't delete most of them - I get the same crash as before. Please note that before I started trimming the ods back to this demonstration version, all these ranges were valid (no #Ref) and I still got a crash every time I tried to amend AcBalances.
Is anyone going to test my demonstration sheet and respond? I put quite a lot of effort into producing it.
Is this bug report, which records irrecoverable, and therefore critical, Calc crashes, been discarded? I have no way round this. It's a complete blocker for me. I was thinking of creating a new report to gain someone's attention, but that seems a bit of a waste of everyone's time. I have the debug version of LO installed, and have a simple demo sheet attached. What more can I do? Help!
do not report again - that would be a waste of everyone's time and lead to someone from QA just marking as a dupe. The bug is marked as NEW, MAJOR and on MAB list - it'll get attention
Hi Tim, some useful things you can do would be: a) get a 'thread apply all backtrace' output having attached gdb to a running process for the crash, and attach it here. b) run valgrind --num-callers=50 ./soffice.bin --calc 2>&1 | tee /tmp/val-log and attach /tmp/val-log here - that -should- also point pretty directly to the memory corruption that is prolly going on there. Having that data (particularly the valgrind log - beware runs 100x slower or so) - is very useful and will usually point directly at the issue. Thanks !
Created attachment 96676 [details] valgrind log from crash I was hopping that a demo sheet would provide enough. Doesn't it crash for others if you try and modify the AcBalances named range (as per comment 15)? I'm afraid I'm just a simple user. I don't know how to "get a 'thread apply all backtrace' output having attached gdb to a running process for the crash". I have a crash dump (repeated today) from a debug version. What should I do to it? However, I have installed and run valgrind as requested, and the log is attached.
Thanks for the log - brilliant; and yes we can prolly reproduce it but development time is really limited: the more complete the bug report the easier it is to fix & this more attractive; this guy is the bug: ==8131== Invalid read of size 2 ==8131== at 0x289B00EA: ScFormulaCell::CompileNameFormula(sc::CompileFormulaContext&, bool) (formulacell.cxx:3458) ==8131== by 0x288B81F1: ScColumn::CompileNameFormula(sc::CompileFormulaContext&, bool) (column2.cxx:3213) ==8131== by 0x289F56FD: ScTable::CompileNameFormula(sc::CompileFormulaContext&, bool) (table4.cxx:2074) ==8131== by 0x2890AA62: ScDocument::CompileNameFormula(bool) (documen4.cxx:569) ==8131== by 0x28C685CD: ScDocFunc::ModifyAllRangeNames(boost::ptr_map<rtl::OUString, ScRangeName, std::less<rtl::OUString>, boost::heap_clone_allocator, std::allocator<std::pair<rtl::OUString const, void*> > > const&) (docfunc.cxx:4903) ==8131== by 0x28D1C82E: ScNameDlg::Close() (namedlg.cxx:185) ==8131== by 0x28D1C6CC: ScNameDlg::LinkStubOkBtnHdl(void*, void*) (namedlg.cxx:474) ==8131== by 0x7000A9F: Control::ImplCallEventListenersAndHandler(unsigned long, Link const&, void*) (link.hxx:123) ==8131== by 0x72892C9: Window::EndTracking(unsigned short) (window2.cxx:718) ==8131== by 0x72AAD2A: ImplHandleMouseEvent(Window*, unsigned short, unsigned char, long, long, unsigned long, unsigned short, unsigned short) (winproc.cxx:787) ==8131== by 0x72AC47A: ImplWindowFrameProc(Window*, SalFrame*, unsigned short, void const*) (winproc.cxx:2066) ==8131== by 0x1D2FB136: GtkSalFrame::signalButton(_GtkWidget*, _GdkEventButton*, void*) (salframe.hxx:243) ... ==8131== Address 0x1baca418 is 24 bytes inside a block of size 56 free'd ==8131== at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8131== by 0x289AF9E6: ScFormulaCell::Compile(sc::CompileFormulaContext&, rtl::OUString const&, bool) (formulacell.cxx:1015) ==8131== by 0x289B022C: ScFormulaCell::CompileNameFormula(sc::CompileFormulaContext&, bool) (formulacell.cxx:3461) ==8131== by 0x288B81F1: ScColumn::CompileNameFormula(sc::CompileFormulaContext&, bool) (column2.cxx:3213) ==8131== by 0x289F56FD: ScTable::CompileNameFormula(sc::CompileFormulaContext&, bool) (table4.cxx:2074) ==8131== by 0x2890AA62: ScDocument::CompileNameFormula(bool) (documen4.cxx:569) ==8131== by 0x28C685CD: ScDocFunc::ModifyAllRangeNames(boost::ptr_map<rtl::OUString, ScRangeName, std::less<rtl::OUString>, boost::heap_clone_allocator, std::allocator<std::pair<rtl::OUString const, void*> > > const&) (docfunc.cxx:4903) ==8131== by 0x28D1C82E: ScNameDlg::Close() (namedlg.cxx:185) ==8131== by 0x28D1C6CC: ScNameDlg::LinkStubOkBtnHdl(void*, void*) (namedlg.cxx:474) ==8131== by 0x7000A9F: Control::ImplCallEventListenersAndHandler(unsigned long, Link const&, void*) (link.hxx:123) ==8131== by 0x72892C9: Window::EndTracking(unsigned short) (window2.cxx:718) ==8131== by 0x72AAD2A: ImplHandleMouseEvent(Window*, unsigned short, unsigned char, long, long, unsigned long, unsigned short, unsigned short) (winproc.cxx:787) ==8131== by 0x72AC47A: ImplWindowFrameProc(Window*, SalFrame*, unsigned short, void const*) (winproc.cxx:2066) ==8131== by 0x1D2FB136: GtkSalFrame::signalButton(_GtkWidget*, _GdkEventButton*, void*) (salframe.hxx:243) ... It's possible that that is related to the switch to the new UI dialog goodness - I didn't see a ton of change in namedlg.cxx otherwise.
Ok. If you need something from gdb as well you'll have to point me at some more documentation. I have got as far as attaching it to soffice.bin, but am unclear when, what and how to get the backtrace you asked for. Not ever having tried to look at the source I'm not likely to be setting breakpoints or debugging any time soon. I did find https://wiki.documentfoundation.org/Development/How_to_debug#Debugging_with_gdb in the wiki, but am none the wiser about getting the trace you want (at least for now).
Created attachment 96806 [details] simple debug patch looks a straight forward delete on a pCode is that shared by multiple ScFormulaCells
Created attachment 96807 [details] search for "deleting" Search for "deleting" and there the pCode is deleted by object 0x343c9f0 and then we go a GetLen on it from a different object 0x342c640. In the absence of knowing what the code wants to do we could throw shared_ptrs at the problem, or as a lunatic workaround seeing as in this case I see that the second leg of the && is always false a hackaround could be to reverse the order of comparison there of -else if ( !pCode->GetLen() && !aResult.GetHybridFormula().isEmpty() ) to +else if ( !aResult.GetHybridFormula().isEmpty() && !pCode->GetLen() )
BTW, I really appreciate taking the time to reduce the test document to a minimal. The bug sucks, but this test document is great.
This one is extremely hard to debug, but I'll take the grenade for everyone. Someone must do it.
Now I see why it crashes. The right way to fix this is to re-implement CompileNameFormula in a formula-group aware fashion, similar to the fixes I've been putting for various reference update operations. I'll work on this tomorrow.
Just fixed this locally which I will push shortly. But the fix will be quite large (as I expected).
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=137c288978fb8f4aee259fabfdcb9252b1b011d3 fdo#75741: Write test for this. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=355baf573425165cbc1c789a6271eb29940e1f76 fdo#75741: Re-implement CompileNameFormula for formula groups. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
4.2 backport: https://gerrit.libreoffice.org/8889
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=615f6aa293a6da90da94e6e78828198ffbc0ca5e fdo#75741: Share the context objects to avoid poor performance. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a9b9a41c567c4e8f6c6bec0a4bb35dc581d577e&h=libreoffice-4-2 fdo#75741: Re-implement CompileNameFormula for formula groups. It will be available in LibreOffice 4.2.4. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Now in the 4.2 branch as well.
I'll try this as soon as I can find a build that I'm sure has the fix in. I assume tomorrow's daily build of 4.2.4 will have it. My main system uses the ubuntu ppa for pre-releases/releases, and I assume that will not include this for quite some time. I'll therefore need a 64 bit windows daily build version, if I can find it, to test on my windows partition. I've been finding the new website more difficult to navigate than the old one (how unusual :) )
I have tested this under windows 7 using the daily build: libo-42~2014-04-09_13.06.38_LibreOfficeDev_4.2.4.0.0_Win_x86.msi. The previous daily build dated 8th April had the old problem. The new one works on the test spreadsheet that I supplied. I therefore decided to test it on the original rather complex sheet which has 90 odd sheets and many cross-references. The first thing I noticed was that Calc did not warn me that the Base database on which several pivot tables are based is not present. The previous daily build version still does this. Using the new daily build there was a bit of a delay when I changed the range, and then without saving the sheet it caused many errors, with cells displaying Err:520 all over the place. At least some of these errors occur where a cell simply takes the value of the previous cell + 1 (eg in cell F3 formula =E3+1). So, something about the change between these two versions of calc is corrupting many other unrelated data items. I have therefore set the status to reopened - I hope that's OK.
Well, unless you can provide a new test document, I don't want this reopened, because re-opening won't help us fix the other problem you are seeing, which may or may not be related. Normally we'd like a separate bug filed for each new test document. If the problem with the originally submitted test document is gone, then we should consider this particular bug fixed. So, if you can provide a new test case that causes the new problem, please consider filing a new bug so we can start fresh. Thanks a lot.
BTW, if filing a new bug is too much of a burden, just send me a new test document, and I'll file a new bug.
'Just send me a new test document' may be very hard to do. It took me many hours to produce the previous one and I've no idea where to start with the current situation. The fix has clearly made something go wrong, so with respect I would suggest that there is a flaw in the fix and that this fault report should not be closed until a fix is available that doesn't have adverse side effects. I have previously understood that asking people to test daily builds was so that such issues can be discovered and sorted before a pre-release is issued. I will do my best to produce a test document, but I'll need time since I will have to start all over again with the main spreadsheet (which I cannot really supply since it contains all my personal financial data). Please be clear that I'm just an ordinary user, doing what I can to try and help LibreOffice be the best it can be. I don't know what else has changed in Calc between these two releases. I would also like to bring your attention to the fact that when opening my original sheet the very last version of Calc did not notice that the underlying Base database is not present. That seems a very odd change in behaviour to me. Can I therefore request that this issue be re-opened until it can be shown that the problem is caused by some other change in Calc between these two daily builds.
Again - Kohei does not receive emails from the bug tracker so it's best to contact him directly
Well, without a test document we can't really proceed. And without a test document re-opening a MAB would only cause aggravation that cannot be solved. I still insist we need a new bug filed when a new test case is available.
(In reply to comment #40) > Again - Kohei does not receive emails from the bug tracker so it's best to > contact him directly I do receive notification if I'm the assignee.
Give me a few hours will you? I only got the daily build a few short hours ago, and have other things to do as well. I will do my best to get a version out tonight - I have made a start at it and will post it here as soon as it looks clear and reliably reproducible. It isn't easy reducing 90-odd sheets down to two that display the problem without leaving my personal finances all over the web (and I'm hoping not too much remains inside the sheets - I have to trust that if there is, people won't inspect it too closely). It is also hard because I have to use my (minimal and otherwise almost unused) Windows boot on my main system since I don't have a spare system to run daily builds on. I have checked with an older version of LO that if I change the range without saving the sheet, the Err:520 problem does not arise (but as before Calc then crashes if I save the file). With the new build of the 9th the Err:520 problem occurs as soon as I change the range. It's hard for me to avoid the conclusion that something is not right with the consequences of the fix, and that this report should stay open for now. I am doing my best to demonstrate it....
Hi Tim, > Give me a few hours will you? ... It isn't easy reducing 90-odd sheets down... Thanks so much for chasing the bug down and cornering it with nice test documents; much appreciated :-) and nice fixing work Kohei !
Created attachment 97154 [details] Additional test doocument The attached sheet demonstrates that all is still not well. With the (windows) daily build of 4.2.4 on 8th April I have tested that it is as before - crashing when the range is changed and the file saved. With the daily build of 9th April, which I assume has the fix in it, Calc doesn't crash, but corrupts the sheet. Using the 9th April build, on the Accounts sheet look at the year numbers in row 3, Column D onwards. They are all based on the previous year + 1. Using Insert, Names, Manage, change the range from $AccountValsPvt.$A$1:$H$37 to $AccountValsPvt.$A$1:$H$36 On the Accounts sheet the years in row 3, Column D onwards, change to Err:520. You may have to scroll down and back up to see this. I therefore ask that this issue be re-opened. Thanks.
With apologies, it isn't quite clear to me whether with the status Resolved/Fixed, Kohei will (even though Assignee) see that I have, as requested, submitted a similar document (just containing a few more fields and formula than the previous one) demonstrating that something is still not right. I'd be grateful for confirmation from others that the problem is reproducible,and that the original fault has not yet been completely fixed.
I got it. I'm just swamped. If someone can confirm the reproducibility of his 2nd test document I'd appreciate it. Otherwise I'll try to get around to it at some point.
Reproduced, but this is no longer a crasher as originally reported, so I'll file a new bug for this.
Bug 77300 filed.
I have now verified that both this, and the subsequent related problem (#77300), have now been fixed in http://dev-builds.libreoffice.org/daily/libreoffice-4-2/Win-x86@42/2014-04-12_03.20.43/libo-42~2014-04-12_03.20.43_LibreOfficeDev_4.2.4.0.0_Win_x86.msi Thanks very much.
*** Bug 78226 has been marked as a duplicate of this bug. ***