1) Go through the steps described in Issue 31585, using Query_Book as the table data source to produce 118 writer documents (which incidentally contain no data other than the template information of the basic elements.odt document). Each of these mailmerged documents weighs in at 12kb. 2) Quit / close all open documents. 3) Go to File > Open, and select all 188 documents in the File Picker and click on "Open" or "OK" (depending on OS). 4) LibO will start to load the documents, getting slower, and then crash. On my machine (Mac OSX 10.6.5), the crash happens at around document 95. Alex
Sorry, in step 3, that should have read : "Select all 118 documents" Alex
Alex, any chance you could attach gdb to the running office (it's included in XCode)? I was not able to reproduce the crash, neither on Mac (10.4 here, though), nor on Linux.
@Thorsten, Hmm, I've never been very good with gdb :-/ but will try and check it out. Will have to read up on its usage documentation first... FWIW, I can also reproduce the same behaviour on OOo 3.2.1, except that I can load just over 100 documents, instead of 95 as with LibO. Alex
[Reproducible] with "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m9 (build 3.2.99.3)]" Modified OS due to my results and attached test kit. I created 120 documents all only containing 1 character "X", used OOo file dialog from Start Center, browsed for sample documents, selected all and pressed 'Open' buton. OOo started opening documents, but after app. 50 documents (I found 47 ".~lock" files in the folder LibO crashed.
Created attachment 40588 [details] Test kit, pls. see comments from Rainer Bielefeld Serious, but not a blocker, I doubt that many users will try to open such a lot of documents in time.
Hm. Tried here, with trivial self-generated sample docs - stopped at 150, because desktop became unbearably slow - this was Linux x86_64 - will retry on Mac later.
Unzipped test suite, opened all documents in one go, twiddled my thumbs for a minute or two, closed them all down. And no crash, performance seemed good too. This however is on x86_64 Linux with an obscene amount of memory
It seems that my crash was because of other reasons, today I did a second test without crash until 70 documents opened, then I terminated the test; unfortunately I have no obscene amount of memory, old PC, old HDD so that a test takes a lot of Time. So until other news OS back to MAC
I installed LibO on a second WIN XP PC, same problem, always crashes after app. 50 documents open. Same with OOo 3.1.1 and DEV300m94 for WIN XP on both PC. There is no unusual virtual swap file load. I filed <http://www.openoffice.org/issues/show_bug.cgi?id=115808> May be they will find out something?
This problem is not limited to WRITER documents, I also see it with drawings, pls. see attached test kit. Opening documents from LibO file Dialog (using LibO dialogs) crashes LibO after app. 50 open documents. Different to the crash from WRITER I see a "Documents will have to be recovered" Message during the crash. An other difference seems to be that I can recover documents and then view the documents (not 100% reproducible), for WRITER documents my LibO always crashes after the recovery. @Alex: Can you reproduce the DRAWING problem? Because of it's impact to Mail Merge Wizzard (pls. see Bug 31585), where lots of documents might be created and opened, I believe this one is a 3.3 blocker.
Created attachment 40615 [details] Another test kit
I am not able to reproduce the crash. Rainer or others, do you see the same problem with OOo? With the older stable versions or with the last 3.3rc? It might need quite some effort to optimize LO to work better with many opened documents. I guess that it crashes because of not enough memory. I am afraid that there are many locations where the memory is allocated and where we would need to improve the error handling. So, if it is an old bug, I would not consider it as a blocker. It would delay the release too much.
(In reply to comment #12) > Rainer or others, do you see the same problem with OOo? @Petr: Pls see my Comment 9
I think this problem may be related to OOo bug http://qa.openoffice.org/issues/show_bug.cgi?id=112766 - any chance the people seeing this crash / problem could try with a *fresh, extension-free install*?
(In reply to comment #12) > So, if it is an old bug, I would not consider it as a blocker. It would delay > the release too much. I think so, too. It's annoying, very important, and it would really be fine if it could be fixed, but due to our blocker definition (which follows common sense) it's not a blocker. @tbehrens: I can try to uninstall all OOo/Libo versions on my laptop, delete all user profiles and reinstall WIN LibO only English LibO. Is that what you need? and if yes, how can we get best profit from that action?
@Rainer: no need to purge everything - just a default LibO install with clean user config should suffice. When reading the comments on http://qa.openoffice.org/issues/show_bug.cgi?id=112766 I see some evidence of this being an out-of-memory condition of some sorts.
@Thorsten : I take it one can actually remove all of the installed extensions, even the bundled ones ? ;-) I could reproduce it with Rainer's test kit. I am trying to do a screencam of the Mac OS activity monitor which shows memory usage increasing with each document opened. Alex
Oh and yes, I can also confirm the same behaviour on NeoOffice, and OOo 3.2.1. Alex
As announced I tried with "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m12 (build 3.2.99.3)]" without any self installed extensions, problem also exists there. Laptop Processor: Mobile AMD Sempron 3200+ Hauptspeicher: 1GB Graphic Card: ATI Radeon Xpress 1100 Monitor : 1200x800 OS: WIN XP SP3
Tried again with "LibreOffice 3.3.0 RC2 - WIN7 Home Premium (64bit) German UI [OOO330m18 (build 3.3.0.2)]" on a PC with 4GB and AMD Phenom II X4: no crash,
Alex, could you try as well please, preferrably with 3.3 final? thanks.
Hi Thorsten, Tried both testkits with a fresh 3.3 final on Mac OSX. Another testkit : no crash, all documents opened. Test kit : all documents opened, albeit much slower than with the Draw documents. Writer documents seem to be much more memory intensive. I thought at one stage that it was going to hang and crash because there was a period of inactivity. No crash. However, massive screen repainting issues, I was left with a blank screen and the LibO main menus at the top of the screen. Before testing, I already had one Writer document open, and the focus of the app was clearly on this document. When I closed this Writer document, the focus and screen repainting kicked in for the test kit documents. So although not brilliant from a user perspective, at least it doesn't crash any more :-)) HTH, Alex
Curious about this bug, I tried both test kits. I had no problem opening either of them separately (closing the previous one before testing the next one). I then tried opening the first test kit, and after it had finished loading I tried opening the second one. This caused a crash of my system with approximately 700 processes of soffice.bin left open. I was forced to restart. System: Windows 7 SP1 x64 Core i5 CPU 4GB DDR3 Memory
"LibreOffice 3.4.3 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" opens 120 smaöö .odg documents from OOo file dialog without problems. Anyone here who still has a problem?
Seems we have got rid of that problem
Remove infoprovider from closed and resolved bugs.
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.