The report with (finally) 5 pages is being generated in Writer but ...
if the report is going to have more pages (like >10), it is being generated (progress bar is working) but no content is displayed in Writer :( it stops with no error ... just blank report screen (either no data nor graphical objects)
Still some problems with reports
wabik : can you provide a test case setup for us please ?
Are you using the included ORB (bundled extension) or a separately installed extension ?
Which version of Java ?
Alex, I will try to prepare an example next week if I find some time ....
ORB already provided inside LO and version of JRE I use is 1.7.0_55 ...
wabik: ok thanks
OK ... It is not about number of pages generated!
What I tested is attached already to the bug.
The test case is (Raport 1):
1. Table with 3500 (or so) entries.
2. Generated report which consisted of only table entries --> everything ok 493 pages
Second test case (Raport 2):
1. The same table ...
2. Report prepared with some shapes --> Generated ... but at the end stops and halts with no result :( FAILED
So it is number of pages or number of shapes generated inside the report which causes error?!
Created attachment 100969 [details]
Database test with reports one good and one bad
Just to say it was
Build ID: a06aa316117a6ff0f05c697c82831c227812d810
Have tried it with the attached database. I have set Raport2 to limit 100 for a test. Works, but has the CPU (1 core) runs at 100% for a longer time. Then tried it with limit 200 and get a grey background without content, while the CPU is running at 100% - have stopped this process after some minutes.
Then I tried to save the writer-file (limit 100). It needs nearly the same time as creating the file.
It is the same behavior with LO 220.127.116.11.
I don't know if we could say this is a Base-bug. I recognize also a problem to open the saved file. Note there are nearly 6000 shapes inside such a file and the whole report is created with frames in Writer. We could really say: The limit is reached for such a construction.
Robert: OpenOffice 4.1 can handle that with no problem but I can agree it takes a long time. I did that to see the immediate result (hanging) as you said: a grey background without content.
Report 1 opens on Mac OSX 10.9.3 and LO 4242, but I see no shapes, no lines in the table (these appear to be invisible), only letters/numbers (which I assume are the field data). The report has 367 pages according to LO.
The Navigator shows no other objects in the document than 3 tables. For me this is a bug.
If I save the report as a copy (Save as copy...) and re-open the ODT document, I see the table markings, but still no shape objects.
Report 2 does not open on OSX 10.9.3 and LO 4242. It leaves the app in a strange condition, I can access the menus and other parts of the app, but the mouse cursor remains permanently on the hourglass icon, instead of the normal pointer.
Setting as new, and platform all, since OSX is also affected.
Adding Lionel to CC, but methinks this is more of a Writer shape import/draw/rendering problem than a database one
Altered title to reflect findings
Alex: You cannot see shapes in Raport 1 because there are no shapes :)
It is just to visualise the problem with the shapes :(
wabik : Attempting to open Raport 2 in LO 4132 causes LO to continuously consume memory until the application is deemed "not responding" on OSX and the spinning beachball status is attained.
Confirming on OSX.
Changing OS to ALL.
Bumping ... Anything on that bug?
For now Base reporting is useless at least for me :(
I confirm that the problem is the time that Writer takes to open the odt file; report builder takes a rather short time to generate it.
Here are my tests comparing LibreOffice with Apache OpenOffice:
- AOO 4.1.0 opening AOO-generated 100 entries odt: 1min20
- AOO 4.1.0 opening LO-generated 100 entries odt: 1min20
- LO 18.104.22.168 opening LO-generated 100 entries odt: 2min25
- LO 22.214.171.124 opening AOO-generated 100 entries odt: 2min25
- LO 126.96.36.199 opening LO-generated 100 entries odt: 1min35
- LO 188.8.131.52 opening AOO-generated 100 entries odt: 1min35
Created attachment 103082 [details]
AOO-generated 100 entries odt
Created attachment 103083 [details]
LO 3.5-generated 100 entries odt
No significant difference with LO 4.2-generaged 100 entries odt.
(In reply to comment #20)
> No significant difference with LO 4.2-generaged 100 entries odt.
It is not only slow but it does not do anything ... it just stops with no result.
Reports do not work with shapes :(
(In reply to comment #21)
> (In reply to comment #20)
> > No significant difference with LO 4.2-generaged 100 entries odt.
> It is not only slow but it does not do anything ... it just stops with no
> Reports do not work with shapes :(
The tests of other people on smaller datasets suggest that it is "just slow", albeit I admit too slow to be usable in your particular usage scenario of a myriad shapes per entry). Since 100 entries take about 1:30 minutes on my machine, by extrapolation 3200 entries would take on the order of magnitude of one hour (assuming linear algorithms, which is not obvious... I'd bet we have at least some n*log(n) algorithms, and possibly some quadratic or worse...).
I launched a test on the full dataset, for me LibreOffice 184.108.40.206 is "busy", but not locked up: I can open a "new" Raport 1, I can open a new document, I can open the table, etc. I haven't waited the full hour yet to see if something eventually comes out of it.
Are you *sure* your LibreOffice is completely stopped, and not just slower than your patience?
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> Are you *sure* your LibreOffice is completely stopped, and not just slower
> than your patience?
My patience is done ... after 6 hours of waiting Report 2 is not done and whole LO is blocked ... memory in windows process has reached 256 MB so maximum that can be set in LO Options/Memory and whole LO was blocked ... Nothing can be done except killing LO process.
I am using Windows version of LO 220.127.116.11 on Windows 7 64-bit.
Something more is broken ... As I suppose ... But maybe I am wrong ...
Can you test Report 2? :)
(In reply to comment #23)
>> Are you *sure* your LibreOffice is completely stopped, and not just slower
>> than your patience?
> after 6 hours of waiting Report 2 is not done and
> whole LO is blocked ... memory in windows process has reached 256 MB so
> maximum that can be set in LO Options/Memory and whole LO was blocked ...
If you mean the "Graphics cache" setting, I don't think this is related per se. I have 50MB there, and my LibreOffice memory usage happily goes into gigabytes.
> Can you test Report 2? :)
I've tested report 2 (on a faster machine) limited to 100, 130, 150, 170 records; it gets ever slower as I add more records, but "in the end" LibreOffice wakes up. Getting to 174 records, indeed it seems to go in an infinite loop: 100%CPU utilisation for much longer than what is needed for 174 records...
Created attachment 103277 [details]
backtrace of seeming infinite loop
Here's the backtrace after it seems to spin infinitely. It does not exit SwTabFrm::MakeAll for a long time; I assume that's where the ~infinite loop is.
Created attachment 103278 [details]
LO 4.2-generated 174 entries odt. LibreOffice seemingly in infinite loop
Can we do sth with the bug? :)
I can wait 1 min to get result but it should come finally :)
(In reply to comment #27)
> Can we do sth with the bug? :)
Sure, I'd be glad to review and commit a patch that fixes it :) Else, I hope a Writer developer will pick it up and fix it.
To Writer Developer,
Can you do anything in near future?
Thanks in advance!
Just one question .... WHEN?
Please fix it :)
Bumping the bug ... is sth going on with this bug?
Thanks for the answer!
Nothing in here ... :( Too bad, but still waiting...
wabik: please, don't ping here without bringing new information (for example, you reproduce the problem or not with last LO version), it's quite useless.
Adding self to CC if not already on
The bug is still valid for LO 18.104.22.168 :(
Too bad and have a feeling very few new things are being added from one version to another ... But having fingers crossed :)
@up ... Added to LO Base :)
** 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.5 or 5.1.0) 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-02-21
Bug still exists with LO 22.214.171.124, OpenSUSE 42.1 Leap, 64bit rpm Linux.
File-opening and handling is slow, because of 174 SVG images (attachment 103278 [details])
Build ID: d0288a482a3dc0f50f535565e4c66a95bb140942
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-26_23:25:18
Locale: nl-NL (nl_NL); Calc: CL
The bug still exists in 6.4
Build ID: 6.4.0-2
CPU threads: 4; OS:Linux 5.5; UI render:GL; VCL: kf5;
Created attachment 157849 [details]
Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.