Created attachment 140443 [details] The xlsx what causes crash. Nothing special in it. If I try to open, Calc crashes.
Unconfirmed on windows 7 x64 with Version: 6.0.2.1 (x64) Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU threads: 3; OS: Windows 6.1; UI render: default
Error Reporting tool cannot start. In the Windows Event log, I found these two events: - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Level>2</Level> <Task>100</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2018-03-07T16:08:29.398173500Z" /> <EventRecordID>4079</EventRecordID> <Channel>Application</Channel> <Computer>iTee</Computer> <Security /> </System> - <EventData> <Data>soffice.bin</Data> <Data>6.0.2.1</Data> <Data>5a8f468e</Data> <Data>ntdll.dll</Data> <Data>10.0.16299.248</Data> <Data>effc9126</Data> <Data>c0000374</Data> <Data>00000000000f87bb</Data> <Data>1a94</Data> <Data>01d3b62e6b1f763b</Data> <Data>C:\Program Files\LibreOffice\program\soffice.bin</Data> <Data>C:\WINDOWS\SYSTEM32\ntdll.dll</Data> <Data>30c415ea-f78a-40e7-a942-3f673215b558</Data> <Data /> <Data /> </EventData> </Event> - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Windows Error Reporting" /> <EventID Qualifiers="0">1001</EventID> <Level>4</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2018-03-07T16:08:35.649815500Z" /> <EventRecordID>4080</EventRecordID> <Channel>Application</Channel> <Computer>iTee</Computer> <Security /> </System> - <EventData> <Data>2023558806219840934</Data> <Data>4</Data> <Data>APPCRASH</Data> <Data>Nem érhető el</Data> <Data>0</Data> <Data>soffice.bin</Data> <Data>6.0.2.1</Data> <Data>5a8f468e</Data> <Data>StackHash_ba26</Data> <Data>10.0.16299.248</Data> <Data>effc9126</Data> <Data>c0000374</Data> <Data>PCH_10_FROM_ntdll+0x00000000000A09D4</Data> <Data /> <Data /> <Data>\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER16E3.tmp.mdmp \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2387.tmp.WERInternalMetadata.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2395.tmp.csv \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER23B5.tmp.txt</Data> <Data>C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_soffice.bin_13affe8ab22098a127f55698e510591b35199e7_87475a9c_1e1929ee</Data> <Data /> <Data>0</Data> <Data>30c415ea-f78a-40e7-a942-3f673215b558</Data> <Data>268435456</Data> <Data>8e4ea747b6aec964dc15200352d8dda6</Data> </EventData> </Event>
Created attachment 140446 [details] Minidump created by Windows Error Reporting tool
I can open file with Version: 6.1.0.0.alpha0+ Build ID: 77db2da61658906c354084b13a95f1102949fbd0 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; Message: Warning loading document zárás.xlsx: The data could not be loaded completely because the maximum number of columns per sheet was exceeded.
Ok, but it is a simple document in Excel. Only a few lines, and rows. The only thing that the height of the lines has been changed to fit a a/4 page. I copy-paste in Excel to a new file, and the Calc cannot open the new file too.
No crash in Versió: 6.0.2.1 ID de la construcció: 1:6.0.2~rc1-0ubuntu0.16.04.1~lo1 Fils de CPU: 4; SO: Linux 4.13; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group nor in Versión: 6.0.1.1 Id. de compilación: 60bfb1526849283ce2491346ed2aa51c465abfe6 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group
To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I got this problem immediately I installed the Libre Office to the given Win10 machine. This was the first (and only) Excel file I should use on that machine. - Restarted in safe mode, open the file, have the same. - Restarted in safe mode, selected factory reset with the two checkboxes: still CRASH. But on the given machine, I have more files, I cannot open. I added one more as attachement.
Created attachment 140475 [details] Another file causes CRASH on the machine (Win10 HUN)
I uninstalled the x64 version, and installed the x86. It can open both excel files. If you need more information, I may help, but I don't want to reinstall the x64 edition, if that edition cannot work well. You can see the memory dump attached, and Weindows Error reporting sent the diag data to to the servers. Thanks for the investigations.
I updated the title to contain "64bit Calc on Windows 10". I confirm with 64-bit master like that in Win 10 and not in Win 7. Meister, please always test with both 32-bit and 64-bit daily master from https://dev-builds.libreoffice.org/daily/master/. @42 is usually updated. They are separate from your working installation.
Looks like a regression to me. Wasn't there in 5.4.
Unconfirmed on windows 10 x64, with Version: 6.0.3.2 (x64) Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU threads: 2; OS: Windows 10.0; UI render: default No crash. The message "The data could not be loaded completely because the maximum number of columns per sheet was exceeded." is there on v6.0.3.2, but not on v6.0.2.1.
*** Bug 116939 has been marked as a duplicate of this bug. ***
The warning message was introduced in https://cgit.freedesktop.org/libreoffice/core/commit/?id=66564dac88ffcc781b4fade7ca0f4f72af6b8bca but I don't think this is the cause of the problem. Adding Eike to keep him in the loop as well...
No crash, only warning (for the first file). Version: 6.1.0.0.alpha0+ (x64) Build ID: c8c74a0b4ca6f3a3619f423b6548c80c52392ae0 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-15_00:12:41 Locale: fi-FI (fi_FI); Calc: group
(In reply to Xisco Faulí from comment #15) > The warning message was introduced in > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=66564dac88ffcc781b4fade7ca0f4f72af6b8bca but I don't think this is the > cause of the problem. That column overflow detection was not present in 6.0.2 but was added only for 6.0.3
Just stating: The .xlsx contains <dimension ref="A1:D37"/> in which area the actual data resides, but also <cols> <col min="1" max="1" width="29.125" style="1" customWidth="1"/> <col min="2" max="2" width="25.125" style="13" customWidth="1"/> <col min="3" max="3" width="32.75" style="5" bestFit="1" customWidth="1"/> <col min="4" max="4" width="31.75" style="2"/> <col min="5" max="16384" width="31.75" style="3"/> </cols> i.e. the grey area right to the data area is covered by min="5" max="16384", probably due to which the overflow dialog is shown. It looks like we should explicitly ignore those column definitions in overflow detection unless cell content data is placed there as well. This "more columns declared than available" may or may not be related to the crash reported here (which I can not reproduce with any version on Linux), just to mention.
Is there a way to make Excel produce a file that Calc likes? I have also an XLSX file Calc complains about, and I am not able to fix it in Excel in a way that Calc won't complain. Only a couple of columns are actually used.
Also, if that warning pops up every time when opening any XLSX file, you will never notive, if there is really a file where you might actually lose data.
My file also contains a table with a column with max="16384". I would rather not change the XML file manually or overwrite the original file with Calc (that would kind of mess up my Pivot tables a little).
It seems that in my case Excel always creates a column entry with max="16384" after the last column that has a custom width.
Taking.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=16265dcdb21d7cf69c65c2a84f1d21a5d8574dd4 Related: tdf#116274 ignore the one excess cols definition's last column It will be available in 6.1.0. 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.
Pending review https://gerrit.libreoffice.org/53377 for 6-0 https://gerrit.libreoffice.org/53378 for 6-0-4
With that change the overflow warning is not triggered for this specific case of excess columns definition. As I can't reproduce any "crash" or "can't open" I'm putting this back to the pool.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-0-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4b80ac6c578bf94b88bfa0f2fec8c638f3531e14&h=libreoffice-6-0-4 Related: tdf#116274 ignore the one excess cols definition's last column It will be available in 6.0.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.
*** Bug 117210 has been marked as a duplicate of this bug. ***
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eeb8ce7d4e008fdc99032e21be655e522bd55c77&h=libreoffice-6-0 Related: tdf#116274 ignore the one excess cols definition's last column It will be available in 6.0.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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dear Meister, Could you please try to reproduce it with tomorrow's daily build from http://dev-builds.libreoffice.org/daily/master/ ?
Confirming that the fix works at least for my own documents. Tested with libo-60~2018-04-25_02.52.30_LibreOfficeDev_6.0.5.0.0_Win_x86.msi
I also confirm that xlsx opens in Windows 10 with 64-bit Calc.
I reported a similar problem and have not installed the latest patch (use 6.03). Could any of you please also test if you can open these files without this error? Download two files from links 1) https://www.dropbox.com/s/2h8c7cf0fjlx6zr/Trafikkd%C3%B8d%20i%20Norge%2C%201947-2016%2C%20etc.xlsx?dl=0 2) https://www.dropbox.com/s/jekxf6jgfafzp7q/Asylstr%C3%B8m%2C%202015.xlsx?dl=0 Thanx for help and speedy bugfix Ref Bug 116939 - Problem opening excelfile in latest release - due to overflow Cheers Sverre
With attachment 141596 [details] from DUPLICATE Bug 117210: there was no warning in Win 7 with LO 32-bit and there was warning with 64-bit now there's NO warning with LO master both 32-bit and 64-bit So I'd say it's FIXED. With files from MARKED DUPLICATE Bug 116939 I have the opposite situation now: there was no warning in Win 7 with LO 32-bit and there was warning with 64-bit now there's warning with LO master BOTH 32-bit and 64-bit Since there was change with fix, I guess that should be dealt with here.
Note: all attachments from those 3 bugs show multiple errors when open with Open XML Productivity Tool. Maybe the reason is: (In reply to sverre48 from comment #4) > It seems to be related to the most recent release, 6.03 - as the same files > have been mutually exchanged between Libreoffice Calc and MS Office 2010
I can't reproduce it in Version: 6.1.0.0.alpha1 (x64) Build ID: cb47f0d320994e001bc38dc2ee9b7d957b15e6ab CPU Threads: 4; SO: Windows 10.0; UI Renderer: GL; Configuració local: ca-ES-valencia (ca_ES); Calc: group
*** Bug 117278 has been marked as a duplicate of this bug. ***
(In reply to Timur from comment #34) > With files from MARKED DUPLICATE Bug 116939 I have the opposite situation I reopened that because it's yet another quirk.
Eike, should this one be marked as Fixed? Looks so to me. Please do.
The original report was about a crash I (and others) could never reproduce, so from my side let's call it fixed. Also a "cannot open workbook" summary isn't quite correct because there was just a warning displayed and the document opened fine.
I am not able to find a list of bugs, fixes and improvements/changes in release 6.05 (whats new cf 6.04). I reckon this bug is fixed for both documents but would like to se a collection of all bugs fixed. I suggest such a list should be easier to locate (not just for major releases) from: https://www.libreoffice.org/download/download/?type=win-x86_64&version=6.0.5&lang=en-US Please include a guide - so I am able to find this say when 6.1 is officially released. I have reported a few unresolved problems and would be great and useful to show this from the release page (or link from there, List of bugs fixed and other changes/improvements incl. Identity of recorded issue) PS Yes I have asked about this before - but have the same recurring problem as last time...
(In reply to sverre48 from comment #41) > I am not able to find a list of bugs, fixes and improvements/changes in > release 6.05 (whats new cf 6.04). I reckon this bug is fixed for both > documents but would like to se a collection of all bugs fixed. > > I suggest such a list should be easier to locate (not just for major > releases) from: > https://www.libreoffice.org/download/download/?type=win-x86_64&version=6.0. > 5&lang=en-US > > Please include a guide - so I am able to find this say when 6.1 is > officially released. I have reported a few unresolved problems and would be > great and useful to show this from the release page (or link from there, > List of bugs fixed and other changes/improvements incl. Identity of recorded > issue) > > PS Yes I have asked about this before - but have the same recurring problem > as last time... https://www.libreoffice.org/download/release-notes Note that our wiki is currently down.
(In reply to sverre48 from comment #41) > I am not able to find a list of bugs, fixes and improvements/changes in > release 6.05 (whats new cf 6.04). I reckon this bug is fixed for both > documents but would like to se a collection of all bugs fixed. See Whiteboard targets, this was fixed for 6.0.4 already (and also applied to the branch for 6.0.5) hence will not get an extra mention in the "bugs fixed" listing for 6.0.5 (which for 6.0.4 btw are https://wiki.documentfoundation.org/Releases/6.0.5/RC1 and https://wiki.documentfoundation.org/Releases/6.0.5/RC2).
This should be reopened as the problem persists/rediscovered. I edited an xlsx file using MS office and uploaded it to dropbox. However, when I open the file in Libreoffice, i get this same error message/warning. Please use testdata provided below Cheers Sverre File/document libreoffice 6.1 open file problem with compatibility, MS Office (.xlsx) https://www.dropbox.com/s/tncfecovr8y1cs8/Meningsm%C3%A5linger-2017.xlsx?dl=0 Screenshot https://www.dropbox.com/s/wdompgcr2gv4afw/Open%20file%20warning.png?dl=0
(In reply to sverre48 from comment #44) > This should be reopened as the problem persists/rediscovered. I edited an > xlsx file using MS office and uploaded it to dropbox. However, when I open > the file in Libreoffice, i get this same error message/warning. > > Please use testdata provided below > > Cheers Sverre > File/document libreoffice 6.1 open file problem with compatibility, MS > Office (.xlsx) > https://www.dropbox.com/s/tncfecovr8y1cs8/Meningsm%C3%A5linger-2017.xlsx?dl=0 > > Screenshot > https://www.dropbox.com/s/wdompgcr2gv4afw/Open%20file%20warning.png?dl=0 So what? The document opens fine for me despite the message. See comment 40.
Sheet 'Sverige-2018' is stored with <dimension ref="A1:AMN153"/> which is 4 columns more than 1024 (column AMJ). For rows 145 to 153 the span includes column 1028 (AMN) as in <row r="145" spans="1:19 1028:1028" x14ac:dyDescent="0.2"> Note that there is stray formatting (gray cell background and maybe others) sprinkled across the sheet, maybe that's related, specifically for a custom format like in <row r="148" spans="1:19 1028:1028" s="2" customFormat="1" x14ac:dyDescent="0.2"> Anyhow, the file says there are more columns than 1024 involved, so the warning is correct.
I have created a new blank sheet and copied the data from the sheet that caused the Libreoffice warning. I haven't tested it using latest Libreoffice released https://www.dropbox.com/s/62i3ithgob8uvz6/Meningsm%C3%A5linger-2017%20-%20recreated%20sheet.xlsx?dl=0 Maybe you could try and see if okay? And I appreciate such help and advice (work around). For me it is almost impossible to pin point what the problem is and where. So hoo ray - to your debug support. Cheers (but still hope compatibility problem is resolved)
(In reply to sverre48 from comment #47) > I have created a new blank sheet and copied the data from the sheet that > caused the Libreoffice warning. I haven't tested it using latest Libreoffice > released > https://www.dropbox.com/s/62i3ithgob8uvz6/Meningsm%C3%A5linger-2017%20- > %20recreated%20sheet.xlsx?dl=0 > > Maybe you could try and see if okay? > > And I appreciate such help and advice (work around). For me it is almost > impossible to pin point what the problem is and where. So hoo ray - to your > debug support. > > Cheers > > (but still hope compatibility problem is resolved) I tested your file, I saved it and open it. No crash. No problem. Open normal. Version: 6.1.1.2 (x64) Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ro-RO (ro_RO); Calc: group threaded and also Version: 6.2.0.0.alpha0+ (x64) Build ID: 18c5089df091bddeb8c2dc339776671964389040 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-12_23:24:12 Locale: ro-RO (ro_RO); Calc: threaded
I tested now your files from comment 45 and 47. On linux. At the first document the error message apears, but with file from comment 47 it's ok. Version: 6.2.0.0.alpha0+ Build ID: e005ab5d40d358adb75a64e140d46f4bf605647d CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-15_02:08:38 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
I have this reccurring Libreoffice compatibility problem in yet another file and do not have a clue where the "problem" - i.e. Libreoffice flaw complains about since excel 201l works as expected https://www.dropbox.com/s/0twullyje8mpa71/Per%20Hansson%2C%20Harry%20Potter%2C%20Jo%20Nesb%C3%B8%2C%20Jon%20Michelet%2C%20etc%2C%2014-1.xlsx?dl=0 Pls download and open with most recent libreoffice (6.1.4). I am using 64-bit and run Windows 10. Pretty annoying... and time waster
Tested on 6.3 Version: 6.3.0.0.alpha0+ (x64) Build ID: 62ce65fe042543e7aeaf83bf66f8c2357ff902c6 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-17_02:33:10 Locale: ro-RO (ro_RO); UI-Language: en-US Calc: threaded Error: Warning loading document Per Hansson, Harry Potter, Jo Nesbø, Jon Michelet, etc, 14-1.xlsx: The data could not be loaded completely because the maximum number of columns per sheet was exceeded. But then the file open like a normal file.
(In reply to BogdanB from comment #51) > Warning loading document Per Hansson, Harry Potter, Jo Nesbø, Jon Michelet, > etc, 14-1.xlsx: > The data could not be loaded completely because the maximum number of > columns per sheet was exceeded. > > > But then the file open like a normal file. Yep, again working as expected.
And about file form comment 47 evertyhing works well on 6.3 Version: 6.3.0.0.alpha0+ (x64) Build ID: 62ce65fe042543e7aeaf83bf66f8c2357ff902c6 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-17_02:33:10 Locale: ro-RO (ro_RO); UI-Language: en-US Calc: threaded
This response is _not_ a problem solver - by no means. And I regard it as rude to change the state pof this obvipous product flaW. First detect what causes the flaw, then resolve a solution, i.e. product fix, _then_ I restest/accept the fix, and first then, the problem changes state
There are already the explanations here, specifically in Comment 46. It's not correct to give some Dropbox link (we normally attach) with a large number of sheets (we normally require minimal example) without considering yourself and pointing what's different to what was already explained about 1024 columns. You have content up to column AMK34 in sheet Gunnar Ligården, Oslo. Didn't check further. But you could have fount it yourself. So I close again.
That document explicitly states <dimension ref="A1:AMK34"/> for xl/worksheets/sheet12.xml and <dimension ref="A1:AMK59"/> for xl/worksheets/sheet13.xml. The column then is used in several rows with a custom format spans="1:20 1025:1025". It is even used by cell elements like in <c r="AMK13"/>, though those cells are specified as empty. Nevertheless the XML data says there *are* cells. So what do you expect Calc to do? Ignore what the document says?
This is certainly a unresolved problem that should be resolved by making Libreoffice calc fully compatible with MS office w.r.t. handling valid .xlsx formats. I've experienced it with a wide set of files - and every time I have to roll back to som back up - by no means a satisfactory resolution to a libreoffice calc problem. As this example reveals, I have a no of sheets and impossible to find where the problem resides unless the product is able to the least tell the user where the problem sheet resides and pinpoint e.g. too wide dimensions. This dimension issue is something that seems to happen on the fly and is difficult to detect and resolve. Is there a function to reduce the size - by removing all blank cells. I am not able to find that in MS excel 2010 and when I get open file warnings in libreoffice calc, I cannot trust that information is lost - no matter what you say. It is a libreoffice problem - nothing else - and troublesome. Hence a way to resolve it could be issue a warning like Dimensions of named sheet contains too many columns Do you want to reduce the size by removing blank columns outside data area. But I still think Libreioffice calc should have the same limits as the industry standard, .xlsx Thx again for pinpointing the problem sheet, Eike Rathke. You seem to be among the ones who give helpful responses. Timurs comment is ridicoulus. What the heck is the problem with using dropbox. Without dropbox, I would have lost a lot of work due to this kind of libreoffice lack of compatibility issues with MS office. A critical part of document sharing. Cheers and pls find a solution - to resolve this. It has been known for a long time and causes big strain for the user community.
I completely agree. It is not up to the end user to track down an issue and try to circumvent it, hoping that no data is lost on the way. If an end user does not feel they can trust the product, they will not use it--I am saying that still being a great fan of LO. It is certainly causing pain to make LO fully compatible, but I also think it is the only option, if you want users to trust LO or this feature in particular.
(In reply to sverre48 from comment #57) > As this example reveals, I have a no of sheets and impossible to find where > the problem resides unless the product is able to the least tell the user > where the problem sheet resides and pinpoint e.g. too wide dimensions. This > dimension issue is something that seems to happen on the fly and is > difficult to detect and resolve. Is there a function to reduce the size - > by removing all blank cells. I am not able to find that in MS excel 2010 and > when I get open file warnings in libreoffice calc, I cannot trust that > information is lost - no matter what you say. It is a libreoffice problem - > nothing else - and troublesome. Hence a way to resolve it could be issue a > warning like > Dimensions of > named sheet contains too many columns > > Do you want to reduce the size by removing blank columns outside data area. > But I still think Libreioffice calc should have the same limits as the > industry standard, .xlsx Whatever the solution may be, it is a discussion for another report. This report stays closed. You have unnecessarily changed the status four times. Please don't do it again or I will have to ban you.
Ok, sverre48 is banned until bug 50916 is fixed and we can be certain there will be no incentive to fiddle with the status of this report.