GDI Metafile graphics get a Read Error and disappear after upgrading to Karmic

Bug #460618 reported by Johan Ehnberg
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openoffice.org (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

Binary package hint: openoffice.org

After opening a document created and edited in Intrepid and Jaunty (OOo 3.0 latest save) all my graphics that I had imported as GDI metafiles are gone with a "Read Error" displayed after working with the document for a while. I still haven't found any clear trigger for this bug, in fact I believe it is some background process in OOo: I tried opening a document, leaving it in the background showing the graphics and when I opened the window again after about ten minutes (background backup save?), it had already happened. When saving after the error and opening again, the objects have been removed completely.

This happens on my amd64 Karmic beta desktop and my i386 Karmic beta laptop.

I can provide a document per email for testing purposes only.

Sounds like this this:
http://www.openoffice.org/issues/show_bug.cgi?id=23154

Currently I don't know how to best proceed in order to pin down the bug, but I am doing tests (different copies of the document, stripping it down to the graphics only, running without .openoffice* in home dir etc.). I will report if I find anything but pointers on testing are welcome.

ProblemType: Bug
Architecture: amd64
Date: Sun Oct 25 20:45:01 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: fglrx
Package: openoffice.org-core 1:3.1.1-5ubuntu1
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: openoffice.org
Uname: Linux 2.6.31-14-generic x86_64

Revision history for this message
Johan Ehnberg (johan-ehnberg) wrote :
Revision history for this message
Johan Ehnberg (johan-ehnberg) wrote :

- It is triggered by AutoRecovery information saving
- It seems to only happens once after opening openoffice (closing all instances and quickstart starts over)
- It seems to require a large (mine is 8 MiB) document that takes a long time to save or perhaps something specific in it - a stripped down (22 KiB) variant with only one object works fine
- It does not change by deleting the ~/.openoffice* profile

Revision history for this message
Chris Cheney (ccheney) wrote :

Can you test this with the official version at http://openoffice.org/ and if you also see the problem there then file this upstream bug at http://qa.openoffice.org/issue_handling/pre_submission.html and add the bug number back to this report?

Changed in openoffice.org (Ubuntu):
status: New → Incomplete
Revision history for this message
Johan Ehnberg (johan-ehnberg) wrote :

I tested the official version (3.1.1, amd64 debs) but was unable to reproduce the bug.

While installing and removing packages, I noticed that I was able to to get one successful save when the Ubuntu version's -gnome and -gtk packages were not installed. However, the bug reappeared at the next attempt. This gave me the feeling that the time/number of cycles/available processing power it takes to save AutoRecovery information is somehow central to this. Without -gnome and -gtk it happens quicker. I also tried to stress my system (urandom > null on each CPU core) while running the official version which made AutoRecovery take longer than with the Ubuntu version but was unable to make it fail.

- It seems to be Ubuntu-specific
- It seems to be related to time/number of cycles/available processing power of AutoRecovery

Changed in openoffice.org (Ubuntu):
status: Incomplete → New
Revision history for this message
Chris Cheney (ccheney) wrote :

Can you please attach an example document showing this issue?

Changed in openoffice.org (Ubuntu):
status: New → Incomplete
Revision history for this message
Johan Ehnberg (johan-ehnberg) wrote :

I tried to create a test document that could be attached here but was unsuccessful. Even with more text, graphics and the GDI metafiles, the document's AutoRecovery works fine. This indicates something is wrong with just the original, or that I'm still missing something in the test document. The original document (which I cannot attach here) still shows this issue. I can send the document directly to a developer if necessary. Alternatively, I could do some debugging myself with some instructions.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

I got this error just once on 3.2 (still Ubuntu build). Currently have several users who get this often and am trying to reproduce but the files seem to be working on my machine fine... Any more hints to how to reproduce?

Since there are two of us now, just wondering about your setup.. We have custom templates installed with a custom font. We have openjdk java installed.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Attached an strace, it extracts to 500 MB. (it's only 250 k to download though). The bug maybe somewhere inside but I need more experience reading straces. I cannot yet attach the file in question. I found several interesting lines, using unique to help sort through the data

   2014 instances of "3403 read(30, "\1\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0oolog\0\0\0\0\0\0\0\0\0\0\0", 1024) = 32"
followed by:
      3403 brk(0x1ef8000) = 0x1ef8000
      3403 brk(0x1f19000) = 0x1f19000
      3403 read(7, 0xfff344, 4096) = -1 EAGAIN (Resource temporarily unavailable)

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Whatever causes this is also still applied to Ubuntu's 3.2. With up-stream's 3.2 there is no issue.

Revision history for this message
Johan Ehnberg (johan-ehnberg) wrote :

My setup is Ubuntu 9.10 with sun-java6 and at the time I was able to produce this with and without any custom settings.

Today, I was unable to reproduce the bug. I am no longer actively working on the document in question, so I will not bump into it spontaneously. However, I'd be happy to help if I can.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.