To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=115969
Issue #|115969
Summary|OO crashes when opening ODF-files
Component|framework
Version|OOo 2.3.1
Platform|PC
URL|
OS/Version|Windows XP
Status|UNCONFIRMED
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P3
Subcomponent|code
Assigned to|tm
Reported by|ubenedix
------- Additional comments from ubene...@openoffice.org Tue Dec 7 14:42:17
+0000 2010 -------
Environment:
- Clients (all clients) Windows XP SP2, Java RE 6_22, OOo 3.2.1
- Server: The linux kernelversion were samba is running at:
Linux version 2.6.18-92.1.10.el5
The operating system were samba is running at:
Scientific linux (similar Red Hat 4.1.2-42)
The samba version after update on server at 02.12.2010:
Name : samba
Arch : i386
Version : 3.0.33
Release : 3.29.el5_5.1
.#~ not vetoed in filenames!
We have got a really strange behaviour here.
Phenomena:
- A file "A" was created on a samba resource by ClientA.
(this time a odt, but we have seen this also with ods).
- Next day, the file "A" does not open, but crashes OOo on ClientA.
- Sometimes in the status line appears "loading...". Sometimes it recovers
("Unexpected
crash..) and offers the file-repair-dialog, but with no file name in the list.
Sometimes it must be terminated via task manager.
- The origin of the problem remains unclear. But up to now, it happened more
than one time, i.e. repeatedly. This time, a bunch of files was affected.
Accessing (open-save) a file (created by ClientA) on a samba resource from a
different ClientC maybe involved. But the problem cannot be reproduced this
way.
And now some strange side-effects:
- File "A" crashes on ClientA...
- ...and crashes on ClientC... !!
- ...but opens on ClientB!!!
- All local copies of File "A" on ClientA crash OOO on ClientA.
- Change the file name of the copies: crash on ClientA!.
- Change the system date/time information of the copies: crash on ClientA!
- But all copies of File "A" open on ClientB.
- On the machine of ClientA, with a parallel installed Ubuntu 10.04, OOO 3.2.0,
original File "A" accessed on the samba resource opens, the local copy on
ClientA also opens (i.e. all files, that crashed on this machine, open now)
- Opening and re-saving (save-as) in any environment that allowed opening
(client B, Ubuntu on machine of Client A, or some computer XY that does not
belong to the network) yields a file that now opens again on Client A and
ClientC. (and this is the workaround.)
This is really spooky.
- File "A" is /not/ corrupted: it opens on ClientB, with UBUNBU on ClientB...
(That is why it does not make sense to attach one of the crashing files)
- ClientA (and ClientC) rejects it - and all his copies!
- It's like File "A" carries a "Dark Mark" (for some equally dark reason),
inherited by all its copies, but only recognized as by ClientA -- ClientB does
not know about this mark.
But who keeps track of this "Dark Mark" on ClientA? OOo? Windows?
- That the problem lies within "Windows accessing Samba" seems to be very
improbable: The local copies should open then.
Some conclusions from testing:
- It has nothing to do with NTFS alternative streams (File "A" crashes with and
after deleting such a stream).
- It has nothing to do with our virus scanner and firewall (Sophos)
Workaround:
Open the file on a Client that allows it to be opened (e.g. with OOo running on
a Ubuntu on the same machine, or at home...), save it via save-as.
Some more considerations:
- Probably it has to do with OOo Version 3 - did never happen with Version 2.
- Even if OOO may not be "guilty" - it is a very annoying and time costing
behaviour. If OOo at least could catch the error condition and recover with a
clear message instead of reasserting an "unexpected crash..."!
- Maybe it could be useful to analyse what OOo does, when it opens a file. Are
there any checks of integrity, done by OOo? Why do byte-identical files open on
ClientB, crash on ClientA - is there a check that depends on more then analysing
the file itself, i.e. on external conditions? Or does Windows do such things, in
certain cases hindering the opening of certain files depending on such checks?
- If save-as works as a work-around: What does it, so that ClientA now accepts
the resulting file? Both share identical contents, but obviously after save-as
they are not longer identical. Indeed: there are SMALL differences. E.g. the
ZIP-Header is different (date, checksum). Who checks this and how on opening?
My English is very rusty, so the following also may be useful:
Deutsch / Beschreibung:
Bei Doppelklick auf ODF Datei Icon:
- korrespondierende Lock-Datei im Verzeichnis wird angelegt.
- Programmrahmen erscheint, unten Meldung, dass Datei geöffnet wird - Fenster
bleibt leer
- kommt Dialogfenster mit Meldung: OO ist unvermutet abgestürzt;
Dokumentenwiederherstellung wird angeboten (Liste der Dokumente aber leer),
Programm ist
aber tot ("keine Rückmeldung"), muss abgeschossen werden.
- Manchmal (nicht reproduzierbar) auch kompletter Absturz, von dem sich OO nicht
erholt.
- In einigen Fällen (bei Komplettabsturz? Auch nicht sicher reproduzierbar)
akkumulieren sich dabei aber Instanzen von soffice.bin (task-manager).
- in jedem Fall verbleibt die angelegte lock-datei. (wird immer brav per Hand
gelöscht...)
Problem tritt sporadisch auf und ist bisher nicht sicher reproduzierbar, d.h. es
kann nicht angegeben werden, wie man es zuverlässig herbeiführt.
Phänomen ist zum erstenmal mit Version 3 aufgetreten.
Möglicherweise sind Dokumente, die auf Samba Shares bereitgestellt sind und von
verschiedenen Clients aus geöffnet (gespeichert?) werden, der Ausgangspunkt.
Verdacht daher: Dateien bringen OO dann zum Absturz, nachdem sie von anderem
Client aus (geöffnet?) bearbeitet werden. Aber dies kann nicht systematisch
herbeigeführt werden!
Es gibt außerdem sehr merkwürdige Seiteneffekte, die (umbenannte) lokale Kopien
der Dateien betreffen. Führt die Datei bei Zugriff im Netzwerk zum Absturz,
lässt sich auch jede lokale Kopie nicht öffnen (!!!). Dabei vergeht eben so
lange Zeit bis zur Meldung über den Absturz wie beim Versuch, die Ursprungsdatei
im Netzwerk zu öffnen.
Eindruck, dass im Fall "lokale Kopie kracht" eher die Variante auftritt, wo sich
der Wiederherstellungsdialog noch ausführen lässt und das Programm sich erholt.
Frage: Wo und wie besteht eigentlich eine "Verbindung" zwischen der Datei im
Netzwerk und der lokalen, umbenannten Dateikopie? Was assoziiert für OO die
Kopie mit der Quelldatei?
Welche Prüfung (im Netzwerk?) wird hier durchgeführt, scheitert und wird von OO
nicht abgefangen?
Zugleich ist bewiesen, dass die Dateien selbst nicht defekt sind:
- sie können von anderen Clients im Netzwerk (auch bei Anmeldung mit gleichem
Anmeldenamen!) geöffnet werden. (Das schließt Samba als Problem ziemlich aus.)
- sie können auf Rechnern, die nicht Teil des Netzwerks sind, geöffnet werden.
(Per Mail
oder per Stick vom Büro nach Hause: dort kein Problem!)
Die odt und ods sind also nicht das Problem! Unter UBUNTU kann man sie auf auf
dem gleichen Rechner öffnen!
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org
For additional commands, e-mail: issues-h...@framework.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
