Description: I use the sum function in Calc a LOT with no problem for many years now. Since yesterday (2nd July) a very simple sum caused multiple crashes. Today I installed the latest LibreOffice update, restarted the entire computer and the Sum function in Calc is STILL causing a crash. Existing sums are also showing up false. Here are the crash reports as sent: https://crashreport.libreoffice.org/stats/crash_details/d7a2824e-a111-4285-be19-29afbcb828e2 https://crashreport.libreoffice.org/stats/crash_details/8f980070-1fbf-4ec6-83ad-d7219d6a5d02 https://crashreport.libreoffice.org/stats/crash_details/16a37987-bd97-4e83-bd47-1438e3e886ce Steps to Reproduce: 1.Create a column of numbers 2.Sum new numbers, then cut 3.Try to add cut sum to another already existing column of numbers in same sheet Actual Results: Calc crashes and recovered version has defective existing sums in existing columns Expected Results: The new sum should be able to add safely into a blank cell in an existing column of numbers which is already summed and the new total should display accurately Reproducible: Always User Profile Reset: No Additional Info: I have used Sum, Cut, Add, in Calc for very many years on a multiple times per day basis. I have never known it fail before
Please test in safe mode, Menu/Help/Restart in Safe Mode
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
(In reply to m_a_riosv from comment #1) > Please test in safe mode, Menu/Help/Restart in Safe Mode Hello M A Riosy and thanks for this prompt reply Yes, I already did that (safe mode) before I reported the bug Requested doc follows next Best, Pa
Created attachment 195106 [details] Calc file as Requested Here FYC is the requested sample document Because it will be public but yet is just one sheet in a huge Calc file documenting all my financial, energy use and CO2 producing activities for the last 5 years it took quite some time to extract and modify for viewing this duplicate page You should be able to see v easily that the sum function is not working anywhere eg try replacing the contents of a cell in a summed column with a new (different) numerical entry and you will see that the sum doesn't change In the course of extracting this sheet from the master file I've also noticed another critical and v damaging bug which is: The (almost essential) function allowing a formula attached to a cell to be dragged down a column so that the formula also applies to sequential cells FYC I have highlighted this new error in this doc (at the foot) Hope this is what need? Here it is anyway
Two things. -Menu/Data/Calculate - Autocalculate is disabled. -Cells F36:G36 has an error formula.
Menu Data/Calculate/Recalculate Hard display several REF pbs. Could you fix them and test again?
FWIW, I am under the impression that the crash reports linked in comment 0 have nothing to do with the report about SUM() somehow failing (which cannot be proved by attachment 195106 [details], considering that AutoCalculate is OFF and cell F36 has a #REF! error). Additionally, attachment 195106 [details] seems saved with a different (newer) version than the crash links reported in comment 0. Unfortunately, we need clearer explanations of these relations and reported symptoms. Are the crashes still happening in newer versions of LO in your system? Can you correct the formulas (to avoid the #REF! errors), set AutoCalculate to ON, then execute recalculate hard and review whether the result of SUM() still fails as initially reported?
Created attachment 195175 [details] updated calc file for debugging Thanks for yr response Here FYI FYC are (I hope) full accounts of the requested 'clearer explanations of these relations and reported symptoms' : 1) The basic (original as reported) bug right enough occurred when running the previous version of Libre Office (to the most recent update). As I said previously, the sheet is part of a set of multi-annual running accounts consisting of daily measurements taken of kWh of electricity use. 2 v simple formulas then allow me to calculate daily electricity use (in kWh) and daily CO2 emissions (in Kg). For statistical purposes I also need to be able to keep a running log of daily use and daily emissions, monthly use and monthly emissions to date and projected annual total (for both kWh and CO2). I have been successfully doing this for many MANY years now using Calc and for all that time I have NEVER had a problem just dragging the 2 formulas down from the previous day's results to get today's result. It must have been so long ago that I'm afraid I can't recall whether or when I turned Autocalculate on in order to do this. What I CAN quite DEFINITELY assure you of is that I PERSONALLY have *NEVER* turned it off 2) The bug as originally reported occurred when I had just closed the monthly summed account of kWh for June. In order to then start a new account for July I did EXACTLY what I have be doing TOTALLY successfully for many years in Calc (and for many years in MS Excel before that) - which is to merely create a *new* sum in the column for kWh (F in the attached doc) consisting of the sum of the 1st and 2nd days of the new month (in order to create a valid sum) and then drag it down through several blank cells below that BUT STOPPING ABOVE the (SUMMED) RUNNING TOTAL for the year. Obviously I then get a (very temporary) false running total because July is now double counted. But for many MANY years now all I do then is cut the sum for the running total for July from the column and paste it straight back into the monthly cell for July (in the by-the-month table below all the daily running sums) 3) The FIRST CRASH report you received was *IMMEDIATELY* after I first tried to make that paste 4) At the time, I was running the previous version of LibreOffice 5) But I had performed this *very same operation* with ABSOLUTELY NO PROBLEM at all already 6 times this year using that particular version of Calc (and for many years before that using both that and previous previous versions) 6) So I recovered the doc, tried again and it crashed again 7) As you say, the initial crash reports were when I was running the previous version (on the 2nd of July): 020724 - The crash report was successfully uploaded. You can soon find the report at:https://crashreport.libreoffice.org/stats/crash_details/d7a2824e-a111-4285-be19-29afbcb828e2 020724 - The crash report was successfully uploaded. You can soon find the report at: https://crashreport.libreoffice.org/stats/crash_details/8f980070-1fbf-4ec6-83ad-d7219d6a5d02 8) Thinking it might be something to do with the fact that I hadn't yet migrated to the new version of LibreOffice, I downloaded that, restarted the computer and tried again 8) I tried again *twice*, it crashed again *twice* ALWAYS on the same paste the sum operation 9) Here is the crash report (from always the same paste-the-sum operation) once running the new version and the request from you to report the bug: https://crashreport.libreoffice.org/stats/crash_details/16a37987-bd97-4e83-bd47-1438e3e886ce Please check the report, and if no bug report is connected to the crash report yet, open a new bug report at bugs.documentfoundation.org 10) So (somewhat painfully after finding my way around your bug reporting protocols) I created the bug report 11) So that is the answers to your question: Are the crashes still happening in newer versions of LO in your system? 12) Once you had asked me for the sample doc to help you work things out I had (as I already said) to go to quite some lengths to edit and redact the operational doc in question to render it suitable for public display 13) So that (together with the timeline described above) explains the apparent (IMHO not necessarily very critical) fact that: 'Additionally, attachment 195106 [details] seems saved with a different (newer) version than the crash links reported in comment 0. 14) It was in the course of preparing that doc that I noticed that the autosum function had apparently also malfunctioned 15) That is why that is reported as a noted addendum within the doc as sent, and *not* actually as the bug in the initial report 16) Thanks to your request to: 'Can you correct the formulas (to avoid the #REF! errors), set AutoCalculate to ON, then execute recalculate hard and review whether the result of SUM() still fails as initially reported? I have now done exactly that and 17) I have discovered that the supposed '#REF' issue was/is immaterial (merely a relic of the edited doc and now replaced with a hard number in the relevant cell in this new version) 18) It now looks very much as though somehow or other (??) Autocalculate got *turned off* in the course of those crashes, since I myself MOST CERTAINLY DID NOT TURN IT OFF (Is that remotely possible ? - I can think of no other explanation) 19) So that is now back working in this new version 20) LITERALLY NONE OF THE ABOVE distracts from the fact that the original bug (as reported) is STILL very much in place 21) To replicate it: in the *new* version of the file (*attached* here) you will find that using the (now working) Autosum function I have already created for you (in the vital column F for kWh) a *new* sum for the kWh used in the current first days of July 22) Cell F239 now reports (accurately) a sum of 49 kWh for those days and is represented in the formula bar as a function =SUM(F228:F236) 23) Therefore (as already mentioned) the running annual total (in cell F242) is actually a false total, as the 49 kWh in F239 is now double counted 24) Now TO REPLICATE THE CRASH: firstly cut cell F239 (you will notice F242 now reverts to the *true* annual running total (49 less than previously) 25) Secondly TRY PASTING THE CUT CELL (sum of F228:F236) into the destination cell awaiting it: F268 (July in the monthly breakdown table - left unshaded here for easy identification) 26) Get back to me if it doesn't crash. But it certainly crashes this end 27) Here FYI FYC are tonight's crash reports attempting that same operation yet again: 080724 (3) - The crash report was successfully uploaded https://crashreport.libreoffice.org/stats/crash_details/246c1c76-8867-450a-b104-178f1d822ce6 080724 (2) - The crash report was successfully uploaded https://crashreport.libreoffice.org/stats/crash_details/0c67a315-9feb-43b5-afca-478f08d2cb5c 080724 - The crash report was successfully uploaded https://crashreport.libreoffice.org/stats/crash_details/d3e17fd8-a91e-48be-83e0-1cc417c45d93 28) SHOULD IT CRASH - I'll be amazed if it doesn't - and you then recover the doc you will then almost certainly find (at least I did earlier this evening) that the figure 49 is now *most mysteriously* somehow now to be found in the *correct destination cell* (F268 - for kWh in July) but that *equally* mysteriously in the formula bar you will now find that it is showing the FALSE SUM of =SUM(F257:F265) 29) The bug reports are all showing up as a 'Unhandled C++ Exception' 30)Hopefully all this inf. and further detail is now sufficient for you to get to zero in and get to the bottom of whatever is causing this desperate bug (?? I hope so anyway !!
I am changing the Summary field according to the relevant test and behavior, from: "Sum function in Calc not working and causing crashes" ...to: "Cell with formula, Cut+Paste, crash" STR: 1. Open attachment 195175 [details]. 2. Click on cell F239. 3. [CTRL]+[X] to cut cell F239. 4. Click on cell F268. 5. [CTRL]+[V] to paste the clipboard. Actual results: Calc Crash. Calc suggests the possibility to attempt recovery of the file. After recovery, AutoCalculate is OFF for the recovered file (but it was ON before the crash). Same crash when starting LO in Safe Mode. OpenCL: OFF. * First; Not reproduced with: ** LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 ** AOO4115m2(Build:9813) - Rev. 5f13fa0070 -> Regression. * Reproduced, but showing error message before Calc closes itself, without a recovery attempt, and with a different fatal error (IIUC, but please double check): ** Version: 7.0.4.2 (x86) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL * Crash reproduced with: ** Version: 24.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 12b0d0dd2e22a1abc955a11bfe4ae87631409622 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded ** Version: 24.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 12b0d0dd2e22a1abc955a11bfe4ae87631409622 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded Version: 7.1.2.2 (x86) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded Setting Version field to 7.1, since older version behaves differently.
It would help if someone would test on OSes other than Windows; the STR are very simple.
It happens cutting from the range F36:F240 and pasting on the range F262:F268
Thanks for clarifying. No crash in 5.2.0.4. In 5.3.0.3 and 5.4.0.2, crash with Fatal Error message: multi_type_vector::position#1491: block position not found! (logical pos=18446744073709551598, block size=17, logical size=1048576) Later, direct crash with no error message: - signature "libc.so.6" in - 6.0: https://crashreport.libreoffice.org/stats/crash_details/629f5ee3-a082-4728-a03c-3fcc78d5b7e2 - 7.0: https://crashreport.libreoffice.org/stats/crash_details/20c2c69c-9ca2-4139-a67a-7ed51053aefb - 7.1: https://crashreport.libreoffice.org/stats/crash_details/5e409624-e601-43de-93d4-9d28d842fa4a - 7.2: https://crashreport.libreoffice.org/stats/crash_details/8d5b030e-53e4-46fa-9127-fd442bab4fc9 - 7.6: https://crashreport.libreoffice.org/stats/crash_details/8692e92e-f75b-4127-8833-a700a3ba34eb - 24.2.4.2: https://crashreport.libreoffice.org/stats/crash_details/0fea636d-59e7-4ba4-96c5-aa9398831cba But as the terminal shows for 24.8 beta1, the issue hasn't changed: terminate called after throwing an instance of 'std::out_of_range' what(): multi_type_vector::position#490: block position not found! (logical pos=18446744073709551598, block size=17, logical size=1048576) Bibisected with linux-64-5.3 repo to first bad build [4467a22f4544cd2d5c637dd909f828ed3e99edb6] which is: commit dfa92e106f7eaa8c3fc6cda034001197ecc53a8f author Eike Rathke Wed Oct 19 23:04:34 2016 +0200 committer Eike Rathke Wed Oct 19 23:05:44 2016 +0200 Resolves: tdf#97968 adjust references during Cut&Paste of formula groups
seems a bit odd that a 2024-07-03 bug report about something reported to recently starting to fail then bisects to a 2016 commit but fwiw catch throw std::out_of_range gives: #0 0x00007ffff74b5201 in __cxa_throw () at /lib64/libstdc++.so.6 #1 0x00007fff9549bf6a in mdds::mtv::detail::throw_block_position_not_found (method_sig=0x7fff972a9c41 "multi_type_vector::position", line=490, pos=18446744073709551598, block_size=17, container_size=1048576) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/../util.hpp:153 #2 0x00007fff95595049 in mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::position (this=0x1b9f460, pos=18446744073709551598) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/main_def.inl:489 #3 0x00007fff961d9a80 in sc::SharedFormulaUtil::splitFormulaCellGroups (rDoc=..., rCells=..., rBounds=std::__debug::vector of length 3, capacity 4 = {...}) at /home/caolan/LibreOffice/core/sc/source/core/tool/sharedformula.cxx:129 #4 0x00007fff9557f113 in ScColumn::UpdateReference (this=0x1b9f230, rCxt=..., pUndoDoc=0x6ffe940) at /home/caolan/LibreOffice/core/sc/source/core/data/column.cxx:2392 #5 0x00007fff95c07e03 in ScTable::UpdateReference (this=0x23b88e0, rCxt=..., pUndoDoc=0x6ffe940, bIncludeDraw=false, bUpdateNoteCaptionPos=true) at /home/caolan/LibreOffice/core/sc/source/core/data/table1.cxx:1875 #6 0x00007fff9578c10a in ScDocument::UpdateReference (this=0x2380190, rCxt=..., pUndoDoc=0x6ffe940, bIncludeDraw=false, bUpdateNoteCaptionPos=true) at /home/caolan/LibreOffice/core/sc/source/core/data/documen3.cxx:1074 #7 0x00007fff95816e2f in ScDocument::CopyBlockFromClip (this=0x2380190, rCxt=..., nCol1=5, nRow1=267, nCol2=5, nRow2=267, rMark=..., nDx=0, nDy=29) at /home/caolan/LibreOffice/core/sc/source/core/data/document.cxx:2736 #8 0x00007fff958181f3 in ScDocument::CopyFromClip (this=0x2380190, rDestRange=..., rMark=..., nInsFlag=18815, pRefUndoDoc=0x6ffe940, pClipDoc=0x61d8ef0, bResetCut=true, bAsLink=false, bIncludeFiltered=true, bSkipEmptyCells=false, pDestRanges=0x7fffffff4118) at /home/caolan/LibreOffice/core/sc/source/core/data/document.cxx:2980 #9 0x00007fff96ff0aa1 in ScViewFunc::PasteFromClip (this=0x551df38, nFlags=InsertDeleteFlags::ALL, pClipDoc=0x61d8ef0, nFunction=ScPasteFunc::NONE, bSkipEmptyCells=false, bTranspose=false, bAsLink=false, eMoveMode=INS_NONE, nUndoExtraFlags=InsertDeleteFlags::NONE, bAllowDialogs=true) at sc/source/ui/view/viewfun3.cxx:1329 #10 0x00007fff96d56034 in ScClipUtil::PasteFromClipboard (rViewData=..., pTabViewShell=0x551dc10, bShowDialog=true) at sc/source/ui/view/cliputil.cxx:110 and in ScColumn::UpdateReference there is aBounds of {-18, 10, 11} so it seems to be that -18 which is causing the problem.