After working on a .doc file and exiting writer, writer starts with the document recovery function asking you whether you want to recover the .doc file. Also, when closing only the .doc document in writer, LO also closes and then upon restart the document recovery function is displayd. I also saved a .doc file in odt format. This odt file results in the same behaviour as the .doc file. To reproduce: open a .doc file, scroll through the document and click on the text and then exit writer. Upon restart, writer should start with the document recovery function. Also, close writer by only closing the .doc file and observe LO also closing. Also, save the .doc in odt and observe the same problem. I have attached a .doc file and a odt file that was converted from .doc. Use this to double check my claim. I first observed this bug with LO 3.4.2 RC1 OOO340m1 (Build:201) for Windows Xp. I have subsequently also observed this bug in LO 3.4.1 Stable with Windows XP. I do not have any additional extensions installed other than those supplied with LO. Also, I have seen this problem in the support mailing list but could not find any bug reports on this. Yes, I realy did thoroughly searched for this bug.
Created attachment 49384 [details] .doc file
Created attachment 49385 [details] .doc file converted to odt format
The initial comment is a bit confusing. When you say "then exit writer", do you mean killing the soffice.bin process forcefully in Task Manager (or some other way)? (One process, soffice.bin, implements *all* the LibreOffice "applications" (Writer, Calc, Impress etc). They are not separate programs.) Why else would the recovery functionality be invoked next time you start LibreOffice? The recovery dialogs are displayed only if the previous use of LibreOffice ended in a crash (or manual forced termination of the soffice.bin process). Or do you see the recovery dialog even if you quit LibreOffice quite normally without any crash?
(In reply to comment #3) > The initial comment is a bit confusing. When you say "then exit writer", do you > mean killing the soffice.bin process forcefully in Task Manager (or some other > way)? > > (One process, soffice.bin, implements *all* the LibreOffice "applications" > (Writer, Calc, Impress etc). They are not separate programs.) > > Why else would the recovery functionality be invoked next time you start > LibreOffice? The recovery dialogs are displayed only if the previous use of > LibreOffice ended in a crash (or manual forced termination of the soffice.bin > process). Or do you see the recovery dialog even if you quit LibreOffice quite > normally without any crash? With "Then exit writer" I mean click on the bottom "x" in the right hand corner of Writer. Hold your mouse over that "x" to see the caption "close document". I did not close Writer in any forceable manner. This is my whole point, I get the recovery message when I close Writer normally. I have tested this on other computers and get the same result.
Okay, Im with you. In other words Writer crashes the moment when I close it after working on a .doc file or on a odt file converted from .doc and therefore I get the Document recovery message
Please note following bug entry: Bug 39647. This could be a duplicate of this bug, but it refers to Linux and .odt-files. By the way, a friend always encountered exactly the same problem with 3.4.1 on Windows 7 as you describe the problem. However, he encountered the problem with both, .doc- and .odt-files. This is indeed a very annoying bug.
[Reproducible] with "LibreOffice 3.4.1 RC3 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:203)]" Steps to reproduce: 0. Terminate LibO 1. Dobleclick "Chapter 1 draft 1.doc" in WIN Explorer to open it with LibO 2. Menu 'File -> Save As -> "Chapter 1 draft 1.odt" Document will be converted and saved without problems 3. Menu 'File -> Close' Expected: Document will be closed Actual: LibO terminates (Crashes), I see some dialog with size of the recovery dialog (seems empty) for a very short moment 4. Start LibO from WIN Starc Center Expected: LibO Start Center appears Actual: LibO recovery dialog appears The created "Chapter 1 draft 1.odt" will cause further crashes always when you close it after a modification. No problem with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" No problem with "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]", so REGRESSION Also OOo 3.4.0 edits and closes "Chapter 1 draft 1.odt" without any problems. Saving "Chapter 1 draft 1.odt" with OOo3.4.0, Master or LibO Portable does not heal the problem for LibO 3.4.2 Sounds very similar to "Bug 39647 - Writer starts with LO document recovery", I will check relations
Tested 'Chapter 1 draft 1.doc' with LibO 3.4.2 RC3 (on WinXP). The crash is caused by the footnotes 59-63 of the paragraph "The second type of prohibitions [...] sections of the Competition Act." on page 7/8. The paragraph and its footnotes cover over two pages (7/8). The crash doesn't occur when this paragraph--and primarily its footnotes--are on a single page, see the attached file 'Chapter 1 draft 1_modified.doc' [above-mentioned paragraph marked with a yellow background]. The same with 'Chapter 1 draft 1.odt'. This bug is a duplicate of 'Bug 39447 - Writer crashes at closing a document with footnotes in a single paragraph over two pages'. (See also 'Bug 39510 - writer-file causes crash since version 3.4.2 rc1 and rc2') *** This bug has been marked as a duplicate of bug 39447 ***
Created attachment 49729 [details] Modified .doc file without crash
@manj_k: Great work, thank you! I found the same symptoms in a confidential sample document for "Bug 39647 - Writer starts with LO document recovery", so I can mark that one as DUP, too.
Correction concerning Comment 7: of course it is "LibO 3.4.2 RC3"
I also saw the crash with a daily build nearby "LibreOffice 3.4.1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:101)]"
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
CLOSED