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 ?
wabik: 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 LiO: 4.3.0.0.beta2 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 4.1.6.2. 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 3.5.4.2 opening LO-generated 100 entries odt: 2min25 - LO 3.5.4.2 opening AOO-generated 100 entries odt: 2min25 - LO 4.2.5.2 opening LO-generated 100 entries odt: 1min35 - LO 4.2.5.2 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. Lionel, 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. > > Lionel, > It is not only slow but it does not do anything ... it just stops with no > result. > 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 4.2.5.2 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) [CUT] > > Are you *sure* your LibreOffice is completely stopped, and not just slower > than your patience? Lionel, 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 4.3.0.3 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
Lionel, Can we do sth with the bug? :) I can wait 1 min to get result but it should come finally :) Brgds, wabik
(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! Brgds.
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 4.4.1.1 :( 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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 5.1.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux.
File-opening and handling is slow, because of 174 SVG images (attachment 103278 [details]) Conforming with: Version: 5.4.0.0.alpha0+ 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 Version: 6.4.0.3 Build ID: 6.4.0-2 CPU threads: 4; OS:Linux 5.5; UI render:GL; VCL: kf5;
Created attachment 157849 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
Still extremely slow at opening attachment 103278 [details] in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 31fb3045dabdb27d913712f3abcade315e3ea9bd CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded While 6.4 eventually displayed the contents (with a frozen UI, after more than a minute), 24.2 doesn't even get to displaying the contents (I stopped waiting after a few minutes).
Created attachment 192023 [details] Windows Performance Analyzer output I took an ETW trace on Windows and the attached output shows it doing ~80 secs worth of work doing a vector insert with the shapes. I would think that inserting shapes would be a quick operation, but someone with more knowledge of the code may be able to tell why it's doing so much work there. Here is the callstack: swlo.dll!std::vector<SwRootFrame * ptr64,std::allocator<SwRootFrame * ptr64> >::insert swlo.dll!SwDoc::GetUniqueShapeName swlo.dll!SwFmDrawPage::add swlo.dll!SwXShape::attach swlo.dll!SwXText::insertTextContent xolo.dll!XMLTextImportHelper::InsertTextContent xolo.dll!XMLTextShapeImportHelper::addShape xolo.dll!SdXMLShapeContext::AddShape xolo.dll!SdXMLShapeContext::AddShape xolo.dll!SdXMLCustomShapeContext::startFastElement xolo.dll!SvXMLImport::startFastElement saxlo.dll!sax_fastparser::FastAttributeList::size saxlo.dll!rtl::OUString::compareToAscii saxlo.dll!sax_fastparser::FastSaxParserImpl::parseStream saxlo.dll!sax_fastparser::FastSaxParser::parseStream xolo.dll!SvXMLImport::parseStream swlo.dll!XMLReader::Read swlo.dll!XMLReader::Read swlo.dll!XMLReader::Read swlo.dll!SwReader::Read swlo.dll!SwDocShell::Load sfxlo.dll!SfxObjectShell::LoadOwnFormat sfxlo.dll!SfxObjectShell::DoLoad sfxlo.dll!SfxBaseModel::load sfxlo.dll!rtl::ToStringHelper<rtl::StringConcat<char16_t,rtl::StringConcatMarker<char16_t>,char16_t const [40],0> >::length fwklo.dll!framework::LoadEnv::impl_loadContent fwklo.dll!framework::LoadEnv::start fwklo.dll!framework::LoadEnv::startLoading fwklo.dll!framework::LoadDispatcher::impl_dispatch fwklo.dll!framework::LoadDispatcher::dispatchWithReturnValue comphelper.dll!comphelper::SynchronousDispatch::dispatch sfxlo.dll!SfxApplication::OpenDocExec_Impl sfxlo.dll!SfxStubSfxApplicationOpenDocExec_Impl sfxlo.dll!SfxDispatcher::Call_Impl sfxlo.dll!SfxDispatcher::Execute_ sfxlo.dll!SfxDispatcher::Execute sfxlo.dll!SfxApplication::OpenDocExec_Impl sfxlo.dll!SfxStubSfxApplicationOpenDocExec_Impl sfxlo.dll!SfxDispatcher::Call_Impl sfxlo.dll!SfxDispatcher::PostMsgHandler sfxlo.dll!std::invoke<void (cdecl SfxDispatcher::*& ptr64)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> >) ptr64,SfxDispatcher * ptr64 & ptr64,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > > sfxlo.dll!std::_Invoker_ret<std::_Unforced>::_Call<void (cdecl SfxDispatcher::*& ptr64)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> >) ptr64,SfxDispatcher * ptr64 & ptr64,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > > sfxlo.dll!std::_Call_binder<std::_Unforced,0,1,void (cdecl SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> >) ptr64,std::tuple<SfxDispatcher * ptr64,std::_Ph<1> >,std::tuple<std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > && ptr64> > sfxlo.dll!std::_Binder<std::_Unforced,void (cdecl SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> >) ptr64,SfxDispatcher * ptr64,std::_Ph<1> const & ptr64>::operator()<std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > > sfxlo.dll!std::invoke<std::_Binder<std::_Unforced,void (cdecl SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> >) ptr64,SfxDispatcher * ptr64,std::_Ph<1> const & ptr64> & ptr64,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > > sfxlo.dll!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (cdecl SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> >) ptr64,SfxDispatcher * ptr64,std::_Ph<1> const & ptr64>,void,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > >::_Do_call sfxlo.dll!std::_Func_class<void,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest> > >::operator() sfxlo.dll!SfxHintPoster::DoEvent_Impl sfxlo.dll!SfxHintPoster::LinkStubDoEvent_Impl vcllo.dll!Link<void * ptr64,void>::Call vcllo.dll!ImplHandleResize vcllo.dll!ImplWindowFrameProc vcllo.dll!SalFrame::CallCallback vclplug_winlo.dll!ImplHandleSalObjSysCharMsg vclplug_winlo.dll!WinSalFrame::ResetClipRegion vclplug_winlo.dll!SalFrameWndProcW user32.dll!UserCallWinProcCheckWow user32.dll!DispatchMessageWorker vclplug_winlo.dll!WinSalInstance::ImplCreateDropTarget vclplug_winlo.dll!ImplSalYield vclplug_winlo.dll!WinSalInstance::DoYield vcllo.dll!ImplSVAppData::ImplQuitMsg vcllo.dll!Application::Yield vcllo.dll!Application::Execute sofficeapp.dll!desktop::Desktop::Main vcllo.dll!ImplSVMain vcllo.dll!SVMain sofficeapp.dll!soffice_main soffice.bin!? soffice.bin!main soffice.bin!__scrt_narrow_environment_policy::initialize_environment soffice.bin!_alloca_probe soffice.bin!_alloca_probe soffice.bin!mainCRTStartup kernel32.dll!BaseThreadInitThunk ntdll.dll!RtlUserThreadStart [Root]
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://mybusinesseo.com/ tdf#145323 reportbuilder Moving a field corrupts the field
If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://regixe.com If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.