Apache OpenOffice (AOO) Bugzilla – Issue 81033
Loop after pasting an image inside a table cell
Last modified: 2013-08-07 14:42:49 UTC
OOo 2.3 dev 680-m2 crashed after trying to paste an image inside a Writer document. The document recovery crashes without recovering anything with both OOo 2.3 dev as well as OOo 2.2.1 stable. I am NOT able to open that document anymore, as OOo continuously crashes. Please note, this is a low complexity document: merely a 6 page document with a 2 column layout and a table containing some images. Actions performed: - created 2 columns-layout - created a 2 column-table inside the 2 column-page - added images inside the second table-column [first column contains just some names] - images were wrapped as character - when I tried to paste another image in one of the cells, OOo crashed - 'Recover document' crashed - NO crash-report was generated Now I am NOT able to open or to recover this document, which is just shitty. The document has 4.1 MB, so I can NOT attach it here, BUT drop me a message and I will send it per e-mail. I hope somebody will be able to recover it. Thanks.
OOo Writer still crashes after deleting ALL images from the .odt-file (from the 'pictures'-subdir). As this stripped 'odt'-file has just 10 kB, I will attach this one here. I would be nevertheless glad to send the whole file per e-mail.
Created attachment 47788 [details] ODT-File with ALL images stripped away still crashes Writer
SBA: Confirmed. Attached file loops in OOo 2.0 (SO8) as well as in current dev build SRC680_m226. SBA->FME: As discussed, since we are well passed "code freeze" for OOo 2.3 and this is NOT a newly introduced problem, I set the target to OOo 2.4. Please proceed.
Cloned the task for document recovery: see issue 81066 (http://www.openoffice.org/issues/show_bug.cgi?id=81066). Please note that, as the initial document could NOT be saved during the crash, it should be still functional. However, the document recovery started after the crash and tried to recover this document. Unfortunately, this crashed OOo again, but, this time, the document got *corrupted*, too. [The only logical explanation is that the document recovery modified the initial document leading to the continuous crashes.] Any attempt to open this recovered document would crash OOo now. This is a serious bug, because the 'document recovery' has the potential to render fully functional documents into an unusable mess. As a side note: How could I recover the document? Any suggestions are welcome. [Because OOo obviously enters a loop, I believe that it would be possible to *manually* alter the odt-file in order to break this loop. This changes would probably be minimal.]
The attached document does not crash OOo, it sends it into an endless formatting loop. This is an important difference (not for the user but for the developers ;-)). It would be good to have the document *before* the image was inserted so that we could reproduce the crash that started the problems.
MRU->OD: the attached document will lead to a loop in OOo. It contains many objects in different table cells. Please have a look wether you are in need of a non-looping document version or if you are able to debug it "as is".
> It would be good to have the document *before* the image was inserted > so that we could reproduce the crash that started the problems. I would love to have that version, too, but as issue 81066 (see http://www.openoffice.org/issues/show_bug.cgi?id=81066) details, I do not have the original anymore. Though, I may help and describe how the original looked like: - is it possible to break the loop and view how this document currently looks like? - most pictures were width: 4.5 cm * variable height -- exception: 'Geranium'-picture (which was a lower dimension) - I have also the document version with the pictures (but it is 4.1 MB) - IF I remember correctly, I tried to paste a picture in the cell for 'Geranium', which had a width of 4.5 cm (I do not remember anymore IF I tried to paste before or after the existing picture) - you can look for the text 'Geranium' in the odt-file, to see where this cell is located
Loop does not occur anymore due to the implementation of some general loop controls in the Writer layout engine, see issue 81146.
fme->mru: Ready for QA.
Verified in CWS loopcontrol.
Indeed, verified in OOo-dev m231 Document opens OK. Everything looks great. The sun is shining again. ;-)
Yeah, also checked this with m232 build, fix perfectly integrated in dev build.