LibreOffice Base and Calc freeze after ~14 mins when exporting data of a very large (~10 MB) table from an embedded HSQLDB to a LibreOffice Calc spreadsheet. For this, I am using the procedure outlined in LibreOffice Help.
I can move the cursor after the LibreOffice freeze though.
Top shows a processor load of 102% on average. Memory usage increases slowly from ~9% to 14%.
Exporting a small (~10 kB) table works all right though.
For further analyzing this bug please let me know if I need to install the DEB program package libreoffice-dbg and repeat the export.
Or what should I do to support debugging?
What should I look for in ~/.xsession-errors?
I did report this bug in Ubuntu's Launchpad as Bug #996732 too with some more details.
I made a typo:
For (~10 MB) please read (~10O MB).
Do you have a script-generated CSV file that can be used to reproduce this ?
Having said that HSQLDB is a rather noddy database written in Java that is most likely not suitable for your use-case ;-) I'd encourage using a remote postgresql database, or somesuch.
Possibly as/when/if we get the SQLite backend implemented, life will be better for you - but that is waiting for a volunteer to help out cf. bug#38811
> Do you have a script-generated CSV file that can be used to reproduce this ?
No, I don't. In addition, I do not know how a script-generated CSV file could help to reproduce the reported bug. As I said my aim was to create a spreadsheet file. But this target failed. So I only have my embedded HSQLDB.
My efforts to extract a CSV file from that same HSQLDB table have not been successful yet.
> Having said that HSQLDB is a rather noddy database written in Java that is most
> likely not suitable for your use-case ;-)
My use case is one large table in a HSQLDB including one memo [LONGVARCHAR] field. Where do you know from that this is not a use-case for HSQLDB?
> I'd encourage using a remote postgresql database, or somesuch.
I'm going to use MySQL. But before I can do that I need to export my data. So please let me know how I can export my data from that one large embedded HSQLDB table. As I said before, the export to a CSV file was not successful either.
> Possibly as/when/if we get the SQLite backend implemented, life will be better
> for you - but that is waiting for a volunteer to help out cf. bug#38811
I cannot wait that long. I am using my HSQLDB almost every single day.
please: have a look at this bugreport. What is your opinion?
I haven't such a big database. I have tried it with
When I open the table in LO 3.3.4-Base it is shown at once. Scrolling to the end for over 30000 rows lasts 3 s.
When I register the database and then want to import the table into calc by drag and drop the prozessor is working at his maximum for a longer time - but with this table it works.
Could be that the freezing is a part of the problem which appears under https://bugs.freedesktop.org/show_bug.cgi?id=51239 .
When I try the same as described above with LO 220.127.116.11 rc LO freeezes - I have breaked the prozess after 10 minutes.
I have only tested with the internal HSQLDB. I don't think that it differs to other external DBs, because it is a problem while importing the data to Calc, not reading the data from the table, as you see in the first example with LO 3.3.4. Whith LO 18.104.22.168 rc the reading of the data is slow and the import into Calc is slow - so it won't work any more.
I have changed the status to New.
could you try replicating your previous test with current 4.1.1 release and tell us if the performance has now got any better? 1 year passed by and many LibO fixes and improvements have been added meanwhile.
(In reply to comment #7)
> could you try replicating your previous test with current 4.1.1 release and
> tell us if the performance has now got any better? 1 year passed by and many
> LibO fixes and improvements have been added meanwhile.
I have tried with LO 22.214.171.124. For the example-database of comment6 the time to paste it to calc is about 60 seconds. With LO 3.3.4 on the same machine it's 50 seconds. No big difference.
Adding self to CC if not already on
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT:
- Update the version field
- Reply via email (please reply directly on the bug tracker)
- Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Bug couldn't be confirmed by me with LO 126.96.36.199, OpenSUSE 42.1 Leap, 64bit rpm Linux. It's the same as written in comment8.
I can't create such a big database as written in the description (100MB!) (except using tables with images ...) without getting 0-pointer-exceptions of the internal HSQLDB. So I can't test the original bug.
I will set this bug to unconfirmed.
@bullgard4 : if you want us to be able to triage this bug report appropriately, we need a sample hsqldb database that is as big as the one you describe. As such a file would be too big for bugzilla to handle, you would need to provide a link to where we could download it.
Setting to needinfo. If nothing is posted, the report will eventually receive the status RESOLVED INSUFFICIENTDATA
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 INSUFFICIENTDATA
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 INSUFFICIENTDATA 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