Huge files not responding in Libre office all versions. We tested it keeps crashing. The files contains 60000 rows with normal data and texts, however the same file works perfectly in MS office its high time productivity for us. Need your help to fix it. I am attaching the file. Try to draw a graph for the column B,C and D. Even more than 2 MB files having same issue.
PC: Core 2Duo with 2 GB RAM OS- Windows XP
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.)
The actual original file size when extracted using excel is 15 MB after manually converting to Libre calc is 4 MB. Due to file sixe limitation unable to attach it. Please advice.
SriJanani: you may use dropbox or follow this link:
I have uploaded the file please check and revert.
Where the file is?
I have uploaded the file in the below link
Created attachment 107764 [details]
blocage pour finalise l enregistrement libreoffice
je ne peux terminer l installation de libre office
voir le bug suivant
AAC: please don't hijack this bugtracker, it's completely unrelated.
You can submit a new bug by using this link:
SriJanani: I could open the file with 4.3.2 LO Debian package.
Could you give a minimal step by step process to try to crash or hang?
Created attachment 107915 [details]
Graph plot screen shot
Attached the screenshot of the file not responding while we try to plot the graph for the column- B,C,D.
Try to plot the graph it hangs and not reponds. Opening is ok takes 5 mins.
I request you to try with the windows platform OS like windows 7 and windows XP.
Awaiting your response.
confirmed on Fedora 21 LO22.214.171.124
Open file (it takes 2-3 minutes) and select columns B,C & D. Insert->Object->Chart and calc locks up. I left it for 10 minutes. No response. I also copied the contents into a new document. Same problem.
Same problem in XP with LO126.96.36.199
Changing status to NEW
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Now I'll reduce the importance since having thousands of data for a chart is not a current thing for just an "Office" usage. But perhaps I'm wrong.
Now I am confused how do we come to a conclusion why its happening... It will be a big challenge if we cannot use files with large data.
Michael/Markus: Thought it could be interesting to have your opinion about this tracker.
In my opinion trying to make a chart with 60 000 rows is rather a test limit exercise than a current case but perhaps I'm wrong.
Crashing is bad; though there may be an out-of-memory condition I guess. Ultimately, big charts are rendered with the drawing-layer which is pretty fundamentally large & slow I'm afraid =) it's quite a chunk of engineering work to improve that. Possibly OpenGL rendering would improve the rendering performance at least.
I would also like to report that even the base file is created in Libre office format and worked upon. If we have multiple thousand rows and columns then we do some vlookup or filtering commands the file crashes.
This is a major concern for us since we deal with lot of hige files.
Awaiting your response for the same huge file issues. Please advice.
> This is a major concern for us since we deal with lot of hige files.
> Awaiting your response for the same huge file issues. Please advice.
I think, perhaps, your expectations are not well aligned here with what a volunteer project can deliver; there are ~6000 open bugs, of which this is just one - with prolly a lower priority than most: we know charting large data sets is not at all optimal. There is some chart performance work going on to target LibreOffice 4.4 which may (or may not) address your specific problem and may arrive in a usable state for an enterprise in around six months.
Feel free to get involved in the project to fix your issue though; I'd love to see patches to help out here; I'd recommend starting by getting a profile of the code in cachegrind, and seeing where the bottlenecks are. Patches are most welcome.
Thanks for getting back to us. We appreciate the efforts that the volunteer team is delivering, but we would be happy to contribute what ever we can do from our end.
We are a huge crowd where we can be the best testing ground for this project. Since we are not developers I would like to take your help so that we can contribute as much as we can as you mentioned below.
1) We need steps how to send you patches or test logs
2) We are not aware of profile code in cachegrind- Let us know how to do? any softwares will help?
Awaiting your response-> we will happy to help you for the development.
> we would be happy to contribute what ever we can do from our end.
Great - our biggest need is for developers to work on the project to fix bugs, performance issues etc.
> We are a huge crowd where we can be the best testing
> ground for this project.
We don't really lack testing; we have tens of millions of users who test & file bugs. Then again - if you're using the latest master builds its useful to file regressions quickly vs. that. Its also really useful to get involved with QA:
> Since we are not developers I would like to take your help so that we
> can contribute as much as we can as you mentioned below.
As I said, you need a developer to fix this; you can try to make it easier for one to care about this.
> 1) We need steps how to send you patches or test logs
Patches are unified diffs of code changes; they need to be created by a developer =)
> 2) We are not aware of profile code in cachegrind- Let us know how to do?
> any softwares will help?
If you run Linux, install a build with debuginfo - well, just google for cachegrind and how it is used; certainly you can train yourself in how to do this. Even with a cachegrind trace; I'm not hyper-optimistic you'll find anyone jumping in to fix this bug for you.
But you may be lucky.
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 INVALID
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
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!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INVALID due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker
-- The LibreOffice QA Team
This INVALID Message was generated on: 2015-05-06
I want to resurrect this issue.
I have a Calc spreadsheet with some 75000 rows, three columns, unsaved data.
I inadvertently click the Chart button on the toolbar. LibreOffice takes my data hostage and hangs. I can either wait for it to show me the dialog box where I can choose the chart type, or I can kill LibreOffice, losing my data.
* After clicking the Chart button or selecting the Insert | Object | Chart menu command, the Chart Wizard appears and is responsive immediately. The preview generation is started asynchronously or skipped altogether.
* As the user modifies settings that affect the preview, preview generation is restarted asynchronously.
* If the user clicks Finish in the Chart Wizard, preview generation is stopped and the actual chart generation starts. A Stop button is displayed; clicking it cancels chart generation.
Plotting being slow is not the principal issue here; we all can understand there are limits to computer performance. However, the user must remain in control at all times; waiting forever or killing LibreOffice along with the data is a shitty choice.
Yuri: this issue has too many comments already, so it would be best, if you copied your proposal in comment 24 to a new report.
The performance issue is a broader one, so I will close this for now. It will require a big renovation.