Apache OpenOffice (AOO) Bugzilla – Issue 14397
OpenOffice.org freezes-up while printing
Last modified: 2019-07-23 22:05:26 UTC
My program loads a text document, prints it to a file and closes the document, over and over again, always with the same document and printer. It always finishes by freezing up OpenOffice.org, sometimes as soon as after 3 loads, sometimes it takes 75, but usually sooner than later. It always freezes on the print at the line: xPrintable->print( property_2 );, but it freezes in OpenOffice.org, not my program. When it freezes, OpenOffice.org no longer responds and I have to force it out by clicking End Now in the Windows message box which allows you to close a non responding program. The last time I ran my program, after ending OpenOffice.org, my program continued with: OpenOffice Exception on print: URP_Bridge : disposed (tid=2016) Unexpected connection closure Loaded 34 documents. Printed 33 documents. Closed 33 documents. There were errors. I which I could tell where the error is, but I can't :( The document loads, I can save it and for a while I can print it. I noticed that when the document loads the progress bar advances smoothly, but I believe that on the load that preceeds the print that fails, the progress bar zips through much more quickly and seems to repeat a few times, but the document appears normal on the screen. So I do not know if the problem is with the load which causes a problem with the print, or is it a print problem or a synchronization problem. But it always happens, always at the same place and always in OpenOffice.org. If attached the file and the program. Regards
Created attachment 6165 [details] Simple repetitive load, print and close program
Created attachment 6166 [details] Simple document that ends by freezing OpenOffice.org
@as: please investigate this problem and check wether you can reproduce the freeze in our newest beta.
I cant reproduce this freeze for our latest versions (e.g. srx644 m12). Following tests was done by me: 1) Using the original script (except changing of the document URL - not the test document itself) Parameters: Hidden = FALSE PrintWait = TRUE CloseOwnerShip = TRUE => more then 400 successfully loads without any problems 2) Use the same test but dont wait for finishing the print job Parameters: Hidden = FALSE PrintWait = FALSE CloseOwnerShip = TRUE => more then 400 successfully loads without any problems 3) Use the same test but dont wait for print jobs and take over the owner ship on closing time Parameters: Hidden = FALSE PrintWait = FALSE CloseOwnerShip = FALSE => 2..10 successfully loads + 1 CloseVetoException and showing of your debug output "There was errors" But there was no freeze inside office. 4) Load documents hidden ... Parameters: Hidden = TRUE PrintWait = FALSE CloseOwnerShip = TRUE => 100 successfully loads ... Result: works for me. Tip: May your are able to get some stack traces if you can reproduce a freeze again. Then you should provide this informations, so we can check your problem again. But please use the newest OO version so we can be shure that the problem was not already fixed by other bug reports. THX.
.
Created attachment 6355 [details] These are bitmap images of VC threads, modules, stack ... on freeze
I have just tried the load, print and close program with OOO 1.1. The program still freezes OOo, but now in a very consistent fashion, always after the 97th print ( tried 5 times ), always in OOo. I have attached the stack trace, list of loaded modules, disassembly, etc as bitmaps from MS VC 6 windows. We are trying to use OOo as part of a report generation program and often have many more than 97 reports to print, so if we consistently freeze after 97 prints we fear we will not be able to use OOo. Regards Daniel Brosseau
Rather strange thing happened. I ran the Open, Print and Close program for 95 iterations and then exited. Reported no errors. This is what I expected because it always freezes after 97 prints or on the 97th close. I then ran the program again and OOo froze after 2 prints, on the second close. So effectively it froze on the 97th close again, but this time after 2 connects to OOo. So the number of connects to OOo may be multiple but it will still freeze on the 97th close. Any ideas as to what is going on? Regards, Daniel
Joost->Daniel: Andreas mentioned a version which might be newer than your version. I would try it again using the current OOo 1.1 Beta2 which is based on a newer version of the development tree.
JA: update which I got from Daniel by mail: I did try it against OOo 1.1 Beta 2. This is why I updated the issue. There was a change in behaviour with Beta2, it now freezes consistently on the 97th iteration whereas before it would freeze, but at various iterations. The behaviour has now become more consistent. You can see from the attachment that it seems to be in Winsockets when it freezes so it might be waiting for a response that never comes or maybe the sockets are not being handled in the way Winsockets likes? But this is just a quess. JA->AS: please have a look at it again. Reassigned to you
I could reproduce the described scenario using a 6.1 Beta 2 version ... after 25 cycles. Its a race problem inside office. But such threading related problems are still well known. So we will leave this task open till we have a general solution related to multithreading problems and use this issue as test case then. There exist a workaround for this bug here: wait for the print job and deliver the owner ship on closing the document. Further it can be usefull to load all documents in hidden mode. So no paint messages or unspecified user interactions can damage your process.
I suspect this issue is somehow related to issue 18883.
utomo>AS: If you can reproduce it, do you think we better to change to New ? and setting the target ? or you still need to check with latest version? Utomo> Daniel: Please try Newer version 1.1 Rc5, as Joost suggest, If the problem still happend in 1.1 RC5 please report back Thanks
AS->Daniel: Issue 18883 isnt related to this issue. Because it describe not the time used for printing - it describes the time for marshalling remote call data and calling of the remote uno interface! AS->utomo: Yes I can reproduce it ... but as I`ve already described. Such multithreading issues cant be fixed ASAP. We have to change to many things inside our office code (which was already started) to solve it. Further this bug wont be fixed seperatly(?). It will be fixed automaticly(!), if our code can be used inside a multithreading environment in general. So this bug is more a good test scenario then a real bug, which has to be fixed. Thats the reason, why I let it stay on "UNCONFIRMED" instead of "NEW".
Thank you Andreas, comment by Kai Sommerfeld 2003-09-30 08:23 PDT on issue 18883 might be why I though issues might be linked. Regards, Daniel Brosseau
*** Issue 11819 has been marked as a duplicate of this issue. ***
I cc myself because I set another issue to "duplicate" to this one.
*** Issue 25506 has been marked as a duplicate of this issue. ***
We postpone all work on threading issues until the new threading framework will be available
to mba is there any progress for this issue. since you postpone it at Jun 18 02:44:47 -0800 2004 Thanks
Reset assignee on issues not touched by assignee in more than 1000 days.
Set as obsolete
Instead just setting to obsolete, I hope we can add notes that this is already tested and Solved
Then please retest with an actual windows OS and actual Version of OpenOffice. dessrlbe the test with each step and document the results. We can the reopen, or correctly close the issue. Thanks