Apache OpenOffice (AOO) Bugzilla – Issue 7553
Performance issue opening document containing Internet reference
Last modified: 2017-05-20 10:55:30 UTC
OpenOffice.org Writer may execute an invalid operation when loading some documents containing reference to an Internet URL if the Internet connection is not available at the time(or having incorrectly set Option\Internet\Proxy settings). Windows2000 issuses a dialog saying "The instruction at '0x035c6f15' referenced memory at '0x00000000'. The memory could not be 'read'" and terminates OOo Writer. This doesn't occur to all documents containing Internet reference. And it doesn't happen every time (but frequently) opening the document that had issued this error. When testing, I found if the error occurs, Windows2000 seems always complaining the same instruction address mentioned above. One more problem is, if the Internet connection is very slow, it takes too long(minutes) to load the document before OOo recovers from "freezing" when loading.
Created attachment 2742 [details] SampleDoc.sxw is a document (in Chinese_cn) that frequently causes the fatal error.
I have successfully replicated the bug report by using the file attached. I opened the file online, it has been opened but slowly (about 3minutes, I use dial up). Then I went off line, and the file cannot be opened.
On an XP using OOo 1.1 Beta2, this document crashed Writer when an internet connection is open, but doesn't crashes Writer when an internet connection is not open.
New per comments From YingZheng@openoffice.org 2002-09-16 12:10 PDT and From maxkennedy 2003-06-25 23:35 PDT I tried to reproduce the problem with 1.1Beta2 verman version WIN98SE 1. save attached testfile 2. open file in explorer by double click with 1.1Beta2 during an open ADSL internet connection expected: file should be opened actual: more or less no load from internet, WRITER hangs, must be closed with task manager. Questions: - All systems? Rainer
Reassigned to Éric.
ES->All: yes it is platform independant ES->ABI: AFAIK this problem has been partly fixed in cws_abi3. It istill takes too much time to load such a document with about 50+ graphics.
Platform changend due to Additional Comments From Eric Savary 2003-07-28 Rainer
ABI->ES: If a file contains 50 graphics which can be loaded, the overall time is not so much determined by the loading core, but by the way all graphics are loaded and rendered together. Nothing, which I can influence (maybe someone in the application teams can). Otherwise, where do you get your numbers from? Is there any specification, against which you decide that the time is too long, or is it personal feeling only?
Rainer -> ABI Hi, die you read that that is not a general time problem but something reproducible with the testfile? It should be tested if the same file with images local on harddisk or embedded would be faster. But before I do all that work question ->ES : how sure are are you with "partly fixed in cws_abi3"? Might be more useful to test example with that version. Rainer
Sorry, I thought this was refering to another issue.
ES->BH: we must find a way to manage the time out in OOo when linked contents exist in a document, for instance: - Timeout earlier when contents are not available - Allow the user to break the retrive process but load the document
Hello Kay, could you please take over this bug. It might effect each application, not only Writer. So I reassigned this one to you. If you are not the right one, please assign it to the concerning developer. Thank you.
Set to framework as it concerns all applications.
Sorry Kai, your name ends with "i". :)
seems to be related to fileobj.cxx
MIB->ES: What are we discussing currently? a) a specific issue (crash) with a specific file, that is reproducable? b) a feature enhancement that allows OOo to specify the timeout for HTTP connerctions or something like this? c) something else?
ES->MIB: I can't reproduce the original report that tells about a *crash*. I can reproduce the extreme slow loading time (about 5 minutes) of the document when: - no proxies are set or - the connection is slow - the graphics do not exist at the given addresse. So it's a performance bug (thus I changed the title)
MIB: It is a well known issue that OOo is loading images synchronously. For my point of view, that's okay, because SO is not a web browser, but an HTML editor. Therfor it is valid to assume that the images contained in the document that should be edited are loadable. An improvement of cause would be possible. Since the issue occurs only under certain circumstances, P4/Office later seems to be more appropriate.
I agree with MIB.
file attached to http://qa.openoffice.org/issues/show_bug.cgi?id=29366 contains single linked image. if internet connection is not available 1.1.2 opens slowly, but then allows to edit docuemnt etc. 680m47 hangs when docuemnt is loaded. should i open a new issue or is this supposed to be handled by this one ?
-> richlv: yes it is handled by this one. No need to open another issue. ->MIB/AMA: the fact that OOo is not a web browser does not justify the not acceptable loading time of documents with linked content when no Internet connection is available. - save the front page of Yahoo.com localy (without graphics) - open it in OOo after having turned the proxy settings off -> it lasts 4 (four!) minutes before one can edit anything in the document or even do something with OOo. This is not acceptable. Every user (not aware about this conceptual bug) would have killed OOo after, let's say, 40sec, believing OOo is hanging and eventually causing a data loss. Microsoft Word is not either a Web browser but it loads the same document (and the document is then editable) in a couple of sseconds. Thus I raise prio to P3 (though I really think it would be worth a P2)
*** Issue 32390 has been marked as a duplicate of this issue. ***
If src680m46 was able to load a document, but src680m47 isn't then this does not match the current issue that is only about pewrformce. Please subimit a new issue to the sfx team.
I asked richlv to detail the problem in the other issue. Reassigning to you.
ES->BH: I just rewrite my statement from last year (nov. 03): we must find a way to manage the time out in OOo when linked contents exist in a document, for instance: - Timeout earlier when contents are not available - Allow the user to break the retrive process but load the document In other words: - we have to see if this can enter in a PCD for OOo 3.0 - then build an I-Team (framework) to design an acceptable behaviour
Reset to Enhancement
*** Issue 49967 has been marked as a duplicate of this issue. ***
I can still confirm this problem exists with OOo 1.9.118 on Windows and OOo 1.9.125 (Novell edition) on SUSE Linux 9.3. Honoustly I think this is a very grave bug which should be fixed for OOo 2.0. Think of the following scenario: You have a bunch of OpenDocument files on a server in your corporate network which contain references to images on a server in your network. Then the address of the referenced server changes. Of course you now have to open the documents to correct the references, but OOo simply hangs and sometimes even crashes when opening the documents. Some documents take as much as much 10 minutes to open, where the entire OOo interface is frozen for 10 minutes. Sometimes OOo just keeps hanging, at which point you just kill it after 15 minutes of being frozen. But it's not just documents with references which can trigger this behavior. If you just open a new document and go to Insert => Picture => From File... and you enter an HTTP URL to a server on an unreachable network*, OOo just hangs, and keeps hanging. (Again, I killed it after 15 minutes of hanging). 15 minutes is really too much for a single HTTP timeout, so it can't be attributed to that alone. Seriously, this is not just an enhancement request, this is a very grave bug. OOo really should fetch external references asynchronously and should not hang (forever?) when trying to fetch non-existing references. *) To test: if you're on a 192.168.0.* network, just try referencing a 192.168.1.* address, provided there's no gateway to route to 192.168.1.* addresses. This was tested on Linux, I don't know if the specifics differ between platforms.
*** Issue 62075 has been marked as a duplicate of this issue. ***
*** Issue 62764 has been marked as a duplicate of this issue. ***
IMHO it is quite important that OOo informs the user of operations when is loading external files: Having my OOo (version 2.0, w/winXP) frozed i thought it crashed and that my document was dead, and spent time manually recovering informations from "contents.xml". (by chance, doing so, i found an image's URL, and understood the problem). One could have spent many many hours doing such a recovery work, without thinking that switching off his firewall will solve the problem!!. Most users won't wait 10 minutes: More thane 2 minutes whith a frozen progression bar is understood as a crash by the user and "solved" by a Ctrl-Alt-Del! PROPOSITION: A good part of a solution would be to add a log-line (similar to netscape's) telling the user what is going on. Either or not replacing the progression bar (and having mini-progression after the message (dots...). - "opening file..." (this is so quick that will not disturb anybody) - "uncompressing file xxxxxxxx.odt" - "loading files whaterver1", - "loading files whaterver2", - "interpreting and formatting document" - "loading external image href=http://www.01net.com/img/dot.gif" - "..." When it freezes (or takes a little too long), the last log line will stay, becoming a way for the user to understand which particular action is so long to complete, and it'll give him a chance to understand without using pkzip and a text editor.. And when it doesn't freezes, the user probabely won't even see that small line saying incomprehensible things changing too quickly. (Loglines can be added to a log-file, making a debug action possible after the "crash"). Hoping it can help...
Happens to me as well. I am attaching "admin.zip", that exhibits the problem of slow loading and long delay before showing text and images. Competing word processor quickly displays the text, then in status shows "Retreiving" and progress bar.
Created attachment 40324 [details] File, that exposes problematic bahavior
I can't understand how this can be treated as an enhancement. This is clearly a defect. IIRC this is more or less a duplicate for some similar issues we have. I take it for the time being and clean up later.
Thank you Matthias to take it over. When I reset the issue type the first time from enhancement to defect, it got reset from defect to enhancement again (issue activity).
ES->MBA: please have a look at issue 28625. Maybe we can close it (28625) at duplicate of this one?
*** Issue 73012 has been marked as a duplicate of this issue. ***
*** Issue 28625 has been marked as a duplicate of this issue. ***
I've submitted issue 73788 to solve this problem in Writer for linked graphic files. This issue will be solved in cws swqbf91
Issue 74114 has been marked as duplicate of issue 28625, which was marked as duplicate of this issue. But is it really duplicate? The case of issue 74114 is a plane writer document without html, no content from the internet, no links to images from the internet. The problem never occured when opening or editing the document or copying its content to other documents. Its only during save.
It depends. :-) It is a duplicate as it has the same root cause: OOo will hang if it runs into a timeout accessing external resources. While this can be fixed for the case of linked graphics it can't be fixed in case of *necessary* access to a hyperlink while the document is saved. So if both problems can be fixed at all the fixes will surely be different. So in case a document could be provided that shows the problem described in issue 74114 I would opt for reopening it and see if we can fix it. As you are the reporter of issue 74114: can you attach a typical document to issue 74114 that shows the problem? Then we can decide how to proceed. For the time being I reopen this issue.
*** Issue 60384 has been marked as a duplicate of this issue. ***
*** Issue 74552 has been marked as a duplicate of this issue. ***
Issue #74552# was marked as duplicate. Hint for QA: If this task will be fixed it should be tested on Vista too.
*** Issue 65118 has been marked as a duplicate of this issue. ***
*** Issue 67002 has been marked as a duplicate of this issue. ***
This performance issue still exist since 2002. I hope it will be taken care soon. Thanks
If everything goes well at least the problem with linked graphics will be solved in 2.3. That should be the biggest problem. Once experience will have shown that our approachs works well the plan is to extend it to other kinds of linked content as well.
*** Issue 69752 has been marked as a duplicate of this issue. ***
I wanted to inform all people interested in this issue that in OOo2.3 the first step to solve this problem was done: Writer will not block anymore when loading linked images. I hope we can solve the remaining problems (linked images in other applications, all other links in all applications) in further releases. But each journey starts with the first step. :-)
*** Issue 83269 has been marked as a duplicate of this issue. ***
according to release status meeting -> target 3.x
*** Issue 84567 has been marked as a duplicate of this issue. ***
SBA: This Looks like a duplicate of issue 73788 ("Don't block Writer in order to load linked graphic files"). That one was fixed for OOo 2.3. When testing fix for issue 85717 ("non-blocking load of linked graphics in Writer is broken") in CWS sw24bf03, I loaded the attached sxw without performance problems. I set this one to Duplicate. (This one is older, but all changes took place under the other issue ID). *** This issue has been marked as a duplicate of 73788 ***
Issue 73788 only solve one part of the this issue - namely the performance with references/links for graphics. Thus, I undo the made change of SBA
(Please, raise priority: there are many duplicates) I can confirm that OOo 2.3 freezes whenever I drag&drop a picture from the web onto a text document. The freeze is hazardous: - I can still move the window, but now updates (strange screen drawings) - If I kill the window (Ctrl+Alt+Esc) a zombie process keeps running so unskilled users cannot start OOo any more! Background: Debian Sarge + OOo 2.3 deb packages, Proxy used (WPAC autoconf). (KDE system settings are valid). 100% reproducable. Only skilled users can handle this (save graphic locally and insert to document as file), migrators mock.
This is a different problem, please try 2.4.
As the task to make OOo responding while resolving linked content is a huge one, the work is happening in several steps. Let me try to summarize where we are and what we will achieve in the next releases. Starting with OOo 2.4 Writer no longer hangs on loading files with linked graphics. Starting with OOo 3.2 all OOo applications no longer will hang on saving files with linked content (graphics or anything else). This was fixed for issue 50983 in CWS os128. So two things are left: - don't hang on loading linked non-graphical content - don't hang on loading linked graphics in other applications than Writer The first topic is covered by issue 41368. As this issue here started to become a confusing read some time ago already ;-) and never touched anything else than graphics in close detail, I would like to keep that out of here. The second topic is in the works and I've added a dependency here that refers the issue 101430 covering that work. Once this issue is fixed we can close this issue here.
*** Issue 96389 has been marked as a duplicate of this issue. ***
set myself on CC
Comment on attachment 40324 [details] File, that exposes problematic bahavior When copy from internet to document in Open Office the program freezes up
Reset assigne to the default "issues@openoffice.apache.org".