Created attachment 49939 [details] Excel file witch does not open in LibreOffice - calculation takes for ever I have a Excel file that was created by Microsoft Excel 2003 and saved in this program format. The file is opened in Excel in 2 seconds on 9 years old PC, but in LibreOffice Calc it never opens. It looks like LibreOffice is frozen at 60% of auto-calculation at opening of file. The auto-calculation takes 100% of CPU for a lot of time. I have killed the LibreOffice program after 10 minutes. I got this file from my coworker. I have first try to open file with LibreOffice 3.3.3 on Windows XP sp3. Now I have upgraded to LibreOffice 3.4.2 (latest stable at the moment) and the problem is exactly the same. The frustrating thing is that for opening this file LibreOffice does not do the job. So I am marking this bug as 'critical'. See attached file. P.S. If I could just open file without auto-calculating and see raw data and then calculate it somehow, would help little bit.
[Reproducible] with reporter's sample and "LibreOffice 3.4.2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:203)]" opening document by double click from WIN explorer. When progress bar for "Calculating" shows half way LibO stops responding. Also a problem if EXCEL version (I checked 95, 97) is selected in file type. Also a problem with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" OOo 3.1.1 and OOo 3.4 show the same problem No problem with MS EXCEL Viewer Not critical because currently only 1 document in the world seems affected, let's rethink when we fin more examples. @Kohei: Please feel free to reassign if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
please report this in launchpad, it seems to be a distro specific bug
Sorry, added this comment to the wrong bug report ;)
This is not good. I'll try to look into this for 3.5.
Four months after bug reported now I have tested with the latest stable 3.4.4 and problem remains. I have noticed that soffice.bin is at 100% of CPU and memory is just growing and growing. After 10 minutes I killed the LibreOffice. It looks like in some kind of endless loop or something.
The data label (x-label) ranges in several of the charts are specified to be the entire column A (data!A:A), which basically spans over a million rows. That ends up slowing down the chart import. If you change that range to data!A2:A32 or something like that, the file imports fine.
Kohei, thanks a lot for looking into the problem. Like I see your suggestion is a work-around, but I get such a documents on daily basis and I am not the author of spreadsheets and there are many authors that are sending me spreadsheets from Excell and I have zero influence on telling them what to do. Also whole column is selected in x-axis, because when data are added there is no need of changing the graph it changes automatically. Just wondering why Excel imports this file in 2 seconds? Blind guess, it stores something like maximum row in column where data are stored, so import just finishes without looking all the data in whole column. So in my case, having zero influence on how document is created, LibreOffice becomes useless for opening this type of documents. I was suggested by my boss to install Excel, which I would just like to avoid if possible.
Fixed on master. http://cgit.freedesktop.org/libreoffice/core/commit/?id=c81b005921b39c54b33777af126b87e9f4e92860 I believe we are still prior to branching, so I think this will make it into the next beta build.
I have downloaded LibreOffice 3.5.0 beta from: http://www.filehippo.com/download_libreoffice/ and tested it. Problem still persists. I don't know if this problem is not solved or fix not included in beta.
(In reply to comment #9) > I have downloaded LibreOffice 3.5.0 beta from: > http://www.filehippo.com/download_libreoffice/ and tested it. Problem still > persists. I don't know if this problem is not solved or fix not included in > beta. That's not a real beta (note beta *zero*). Try beta1 when it's out.