Bug Hunting Session
Bug 93967 - LibreOffice Crash always after try to save
Summary: LibreOffice Crash always after try to save
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Windows (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.7
Keywords: haveBacktrace
Depends on:
Blocks: VclPtr
  Show dependency treegraph
 
Reported: 2015-09-06 10:38 UTC by spamkutu
Modified: 2016-10-06 12:27 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Fatal error whenever save 3rd time (94.20 KB, image/png)
2015-09-06 11:04 UTC, spamkutu
Details
I got this dump from task manager after crash (9.76 MB, application/x-rar)
2015-09-06 20:27 UTC, spamkutu
Details
I got this dump from task manager after crash part2 (9.76 MB, application/x-rar)
2015-09-06 20:29 UTC, spamkutu
Details
I got this dump from task manager after crash part3 (9.76 MB, application/x-rar)
2015-09-06 20:32 UTC, spamkutu
Details
I got this dump from task manager after crash part4 (9.76 MB, application/x-rar)
2015-09-06 20:34 UTC, spamkutu
Details
I got this dump from task manager after crash part5 (9.76 MB, application/x-rar)
2015-09-06 20:36 UTC, spamkutu
Details
I got this dump from task manager after crash part6 (9.76 MB, application/x-rar)
2015-09-06 20:38 UTC, spamkutu
Details
I got this dump from task manager after crash part7 (9.76 MB, application/x-rar)
2015-09-06 20:40 UTC, spamkutu
Details
I got this dump from task manager after crash part8 (9.76 MB, application/x-rar)
2015-09-06 20:42 UTC, spamkutu
Details
I got this dump from task manager after crash part9 (9.76 MB, application/x-rar)
2015-09-06 20:44 UTC, spamkutu
Details
I got this dump from task manager after crash part10latest (6.52 MB, application/x-rar)
2015-09-06 20:45 UTC, spamkutu
Details
this document crash always dont know reson but crash (33.83 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-09-07 11:05 UTC, spamkutu
Details
Backtrace from Windows 8.1 for crash on save with LO 5.0.3.2 (6.56 KB, text/plain)
2015-11-14 03:54 UTC, Raould
Details
Backtrace from Windows 7 for crash on save with LO 5.0.3.2 (6.56 KB, text/plain)
2015-11-14 05:01 UTC, Raould
Details
A second backtrace from Windows 7 for crash on save with LO 5.0.3.2 (6.21 KB, text/plain)
2015-11-14 06:48 UTC, Raould
Details
Backtrace from Windows 7 for crash on save with LO 5.1.0.3 (6.65 KB, text/plain)
2016-02-11 20:44 UTC, Raould
Details
Execution and backtrace after pacth add (15.09 KB, application/vnd.oasis.opendocument.text)
2016-04-25 09:51 UTC, Alexis PAQUIN
Details
Trace_WHEN_SAL_INFO_ACTIVED (17.71 KB, application/vnd.oasis.opendocument.text)
2016-04-25 11:36 UTC, Alexis PAQUIN
Details
Full BackTrace LO 5-0-5 with patch 2e1a724c2029783e84d7c508c6010afac0d6d10f (115.63 KB, text/plain)
2016-04-26 08:30 UTC, Alexis PAQUIN
Details

Note You need to log in before you can comment on or make changes to this bug.
Description spamkutu 2015-09-06 10:38:57 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Build Identifier: LibreOffice 5.0.1.2

whenever try to to save calc document its almost always crached 3rd or max4 time

i lost my last acts and reopen calc reinput information and it goes crash again 3rd or 4th save time fatalerror.

Reproducible: Always

Steps to Reproduce:
1.have 2 documents open first ms xls format second my editing calc.
2.getting data from xls to calc as once to once colon copy.
3.its not crash until i try to save calc document but it everytime crashed 2nd 3rd or 4th save time and i lost my last input.
Actual Results:  
its always crash so i could go on very little input so abuse 



[Information automatically included from LibreOffice]
Locale: tr
Module: SpreadsheetDocument
[Information guessed from browser]
OS: Windows (All)
OS is 64bit: yes
i tyed 64 bit back to 32 bit version but this bug exist 32bit too
i will go to install vers 4 i hope i can not see this bug there too.


Reset User Profile?No
Comment 1 Jean-Baptiste Faure 2015-09-06 10:53:47 UTC
Please, rename your user profile and try again.
https://wiki.documentfoundation.org/UserProfile

Best regards. JBF
Comment 2 spamkutu 2015-09-06 11:04:33 UTC
Created attachment 118460 [details]
Fatal error whenever save 3rd time
Comment 3 spamkutu 2015-09-06 11:06:28 UTC
Comment on attachment 118460 [details]
Fatal error whenever save 3rd time

tryed user profile reset its still continoue fatal error and always happen afer 3rd time to save or passed 5-6min later for the first save!!
Comment 4 spamkutu 2015-09-06 18:59:33 UTC
how may i find and add debug info its always crash whenever save 3rd or 4th.
Comment 5 spamkutu 2015-09-06 20:27:15 UTC
Created attachment 118473 [details]
I got this dump from task manager after crash

If need any other dump please tell it to me how can i achieve and so i could  post back to you if this dump not good (got from task manager after crash). Because its always happen mostly after 3. or 4.th save calc crash and i lost last sesion.
Comment 6 spamkutu 2015-09-06 20:29:45 UTC
Created attachment 118474 [details]
I got this dump from task manager after crash part2
Comment 7 spamkutu 2015-09-06 20:32:04 UTC
Created attachment 118475 [details]
I got this dump from task manager after crash part3
Comment 8 spamkutu 2015-09-06 20:34:06 UTC
Created attachment 118476 [details]
I got this dump from task manager after crash part4
Comment 9 spamkutu 2015-09-06 20:36:01 UTC
Created attachment 118477 [details]
I got this dump from task manager after crash part5
Comment 10 spamkutu 2015-09-06 20:38:04 UTC
Created attachment 118478 [details]
I got this dump from task manager after crash part6
Comment 11 spamkutu 2015-09-06 20:40:07 UTC
Created attachment 118479 [details]
I got this dump from task manager after crash part7
Comment 12 spamkutu 2015-09-06 20:42:13 UTC
Created attachment 118480 [details]
I got this dump from task manager after crash part8
Comment 13 spamkutu 2015-09-06 20:44:06 UTC
Created attachment 118481 [details]
I got this dump from task manager after crash part9
Comment 14 spamkutu 2015-09-06 20:45:46 UTC
Created attachment 118482 [details]
I got this dump from task manager after crash part10latest
Comment 15 spamkutu 2015-09-07 11:05:29 UTC
Created attachment 118491 [details]
this document crash always dont know reson but crash

not every document crach but could you please check this.
Comment 16 Jean-Baptiste Faure 2015-09-08 05:00:12 UTC
(In reply to spamkutu from comment #15)
> Created attachment 118491 [details]
> this document crash always dont know reson but crash

No crash for me with LO 5.0.3.0+ under Ubuntu 15.04 x86-64
Opens fine and navigate through the sheets without problem.
Changed random values and saved the file, did that 3 times, no crash.

You should try on another computer if you can.

Best regards. JBF
Comment 17 raal 2015-09-08 12:38:24 UTC
Cannot reproduce with  5.0.1.2
ID sestavení: 81898c9f5c0d43f3473ba111d7b351050be20261, win7
Comment 18 Buovjaga 2015-09-15 16:08:36 UTC
Did same experiments as JBF + messed around with filters. No crash.

Perhaps uninstall LibO completely before reinstalling.

Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Comment 19 Robinson Tryon (qubit) 2015-11-03 05:58:23 UTC
(In reply to spamkutu from comment #15)
> this document crash always dont know reson but crash

(In reply to Jean-Baptiste Faure from comment #16)
> 
> No crash for me with LO 5.0.3.0+ under Ubuntu 15.04 x86-64

(In reply to raal from comment #17)
> Cannot reproduce with  5.0.1.2
> ID sestavení: 81898c9f5c0d43f3473ba111d7b351050be20261, win7

Still no repro, and it's been over a month.

Spamkutu: Can you still reproduce these crashes with a current daily build of LibreOffice?
http://dev-builds.libreoffice.org/daily/

Status -> NEEDINFO
Comment 20 Raould 2015-11-10 02:55:45 UTC
I have had this problem since LO 5.0; has continued in each release since then, now in 5.0.3.2, still experiencing the problem.  I experience this problem on Windows 7, Windows 8.1 and Linux Mint 17.2.  I use 64-bit version on each OS.

I either paste data into Calc (typically a column of 6 - 30 values) or type a few values in manually (students' scores for assignments/exercises/quizzes).   After 3 - 8 saves, Calc will crash.  All data I entered since the last successful save is simply lost.

In the past (pre-LO 5.0) I would only save the file after a day's work; now I save the file after each and every update, because I never know when all my data (since the last save) will simply be lost.  

What further information can I supply to help here?  (And if logs, etc. are needed, please provide information on how to access them in Windows and Linux!)

Shall I set the status back to UNCONFIRMED?
Comment 21 Jean-Baptiste Faure 2015-11-10 08:00:02 UTC
(In reply to Raould from comment #20)
> I have had this problem since LO 5.0; has continued in each release since
> then, now in 5.0.3.2, still experiencing the problem.  I experience this
> problem on Windows 7, Windows 8.1 and Linux Mint 17.2.  I use 64-bit version
> on each OS.

At the moment, this bug report is about MS-Windows. If you have the same crash on each OS while no one can replicate it on Linux, might be the sign of a different issue. That said, please answer the following questions:

- Where the files are saved? locally or on a remote server?
- Did you try to reinitialize your user profile? If you do not know how to do that, have a look at https://wiki.documentfoundation.org/UserProfile

Best regards. JBF
Comment 22 Buovjaga 2015-11-10 08:04:17 UTC
For debugging:
https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace

Note: the Linux debugging instructions will soon receive improvements (for simplicity).
Comment 23 Raould 2015-11-11 04:53:01 UTC
Jean-Baptiste,

Thank you for the response.  The files I work with are saved locally.  The directories where I keep the files I work on daily are Dropbox directories, thus shared with other systems, but are (also) physically stored on the local system.

I have not tried to reinitialize my user profile.  I will follow the directions provided (probably on Friday, two days from now).

I did try more detailed tracking of updates and crashes yesterday; on Windows 7 I updated a file (mostly pasting numbers from Excel files, with a few manual inputs) and crashed twice - both times after 9 cycles of input, then save; some of the "input" the second time were conditional format rule changes.

I applied the same updates to a copy of the file in Linux Mint as I worked on the first file; however, on the Linux side I had to copy from one LO Calc file to another, as I don't have Excel in Linux.  I don't know if that is significant, but the Linux version did not crash.  (This is the first time I've worked on these files in Linux since upgrading to 5.0.3.2).
Comment 24 Raould 2015-11-13 05:14:48 UTC
Jean-Baptiste,

I should have read the directions for reinitializing the user profile first - the process is very simple.  I reinitialized my user profile on Windows 7 and Windows 8 yesterday, but have had the crashes on both systems since then.

Beluga,

I did not have time to look into the information on logging, but will get to that tomorrow (Friday, 13 Nov 2015).

Thank you both!
Comment 25 Raould 2015-11-13 19:03:48 UTC
In order to produce the various debugging logs in Linux, I need to install the debugging packages libreoffice-dbg.  Where would I be able to obtain that?  (It is not available for 5.0.3.2 in the LinuxMint repositories, only 4.4.3)

Thanks!
Comment 26 Raould 2015-11-14 03:54:49 UTC
Created attachment 120531 [details]
Backtrace from Windows 8.1 for crash on save with LO 5.0.3.2

Posting first backtrace file, this one from Windows 8.1.
Comment 27 Raould 2015-11-14 05:01:11 UTC
Created attachment 120532 [details]
Backtrace from Windows 7 for crash on save with LO 5.0.3.2
Comment 28 Raould 2015-11-14 06:48:44 UTC
Created attachment 120533 [details]
A second backtrace from Windows 7 for crash on save with LO 5.0.3.2
Comment 29 raal 2015-11-19 09:19:50 UTC
(In reply to spamkutu from comment #0)
> Steps to Reproduce:
> 1.have 2 documents open first ms xls format second my editing calc.
> 2.getting data from xls to calc as once to once colon copy.
> 3.its not crash until i try to save calc document but it everytime crashed
> 2nd 3rd or 4th save time and i lost my last input.
> Actual Results:  
> its always crash so i could go on very little input so abuse 
  
Hello, please could you post xls file too (point 1)? I see only .ods file in attachments.  Do you have these two files open in LO or xls file is opened in ms excel? Thanks
Comment 30 Raould 2016-02-03 06:10:58 UTC
Is there any progress on this?  This prevents LibreOffice from being a trustworthy application - one can never tell if one is going to lose their data or not.

Thanks in advance for any information!
Comment 31 Buovjaga 2016-02-03 06:46:55 UTC
Raould: from the backtraces it seems to be related to the VCL graphical toolkit.
Could you test with version 5.0.4, if you can still reproduce the crash? Or even 5.1, which should be released this week.
Comment 32 Raould 2016-02-07 03:45:24 UTC
I can confirm the problem still exists with 5.0.4!  I am still experiencing it in both Windows 7 and Windows 10 (I upgraded my 8.1 to 10 since my last note).
Comment 33 Buovjaga 2016-02-07 08:49:37 UTC
(In reply to Raould from comment #32)
> I can confirm the problem still exists with 5.0.4!  I am still experiencing
> it in both Windows 7 and Windows 10 (I upgraded my 8.1 to 10 since my last
> note).

And is OpenGL disabled, when you go to see Tools - Options - LibO - View - Use OpenGL for all rendering
Comment 34 Raould 2016-02-07 21:46:45 UTC
Beluga,

Yes, OpenGL is disabled (Use OpenGL for all rendering is NOT checked).
Comment 35 Raould 2016-02-11 04:52:51 UTC
Beluga,

I have installed LO 5.1.0.3 on Windows 7, and am still experiencing the problem.
Comment 36 Michael Meeks 2016-02-11 10:04:44 UTC
backtraces look interesting - can we get one from a dbgutil build ? I don't really trust the stack unwind without debugging symbols ? =) Thanks for reporting ! also - 5.0.x is about to drop out of support - it would be great to get a trace from a 5.1.x build with debuginfo. Thanks ! =)
Comment 37 Buovjaga 2016-02-11 10:08:14 UTC
(In reply to Michael Meeks from comment #36)
> backtraces look interesting - can we get one from a dbgutil build ? I don't
> really trust the stack unwind without debugging symbols ? =) Thanks for
> reporting ! also - 5.0.x is about to drop out of support - it would be great
> to get a trace from a 5.1.x build with debuginfo. Thanks ! =)

I am not sure, which Tinderbox for 5.1 dailies is done with debug info, but at least TB39 building 5.2 has them: http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/

The process is the same, like described in the wiki article. Just make sure your symbol path is like this:

CACHE*C:\symbols;SRV*http://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols
Comment 38 spamkutu 2016-02-11 10:21:30 UTC
As a seen the problem only occur on windows (all kind windows 7 to 10) version with LO 5 and dosen't matter 32bit or 64bit version nor dosen't related with profile reset. I have no idea if it caused by glide drive but it must change atleast windows 7 to 10 drivers are very different (windows 8-10 driver very closed but). Yes Its happen whenever try to save calc document but not always in first time at second, third, or fourth time almost absolut crash happens and with crashed recovery tool whenever start you could not have that lost data terrible. If times pass alot sometimes its happens on first save to i think may be that caused by auto save releated 1-2 time before crash happens like normal save procdures but i am not sure on this subjet.

Hopply that dosen't existed on linux version and use LO in linux emulator its slow but sure my datas protected. For all day habitual jobs i still use LO on windows but not for important task and not for often changes task which dosen't have backup sides.
Comment 39 Raould 2016-02-11 20:44:57 UTC
Created attachment 122550 [details]
Backtrace from Windows 7 for crash on save with LO 5.1.0.3
Comment 40 Raould 2016-02-11 20:46:17 UTC
Michael,

I just attached a backtrace from 5.1.0.3 on Windows 7.
Comment 41 Buovjaga 2016-02-12 06:51:14 UTC
(In reply to Raould from comment #40)
> Michael,
> 
> I just attached a backtrace from 5.1.0.3 on Windows 7.

Could you give a try to a build of 5.2 from Tinderbox no. 39?
5.1 release build does not have the debug symbols.

5.2 will install separately, so you don't have to do any special tweaks.
Comment 42 Raould 2016-02-13 19:52:58 UTC
Beluga,

I will do so - I just can't seem to find any information on how to obtain a Tinderbox build.  The information I've found so far is aimed at developers concerned creating a build.

How do I get the Tinderbox version?
Comment 43 Buovjaga 2016-02-13 20:09:57 UTC
(In reply to Raould from comment #42)
> Beluga,
> 
> I will do so - I just can't seem to find any information on how to obtain a
> Tinderbox build.  The information I've found so far is aimed at developers
> concerned creating a build.
> 
> How do I get the Tinderbox version?

I mentioned it in comment 37 :)
http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/
Comment 44 Raould 2016-02-13 21:11:58 UTC
<sigh>  You did indeed!  My apologies.

Backtrace coming up...
Comment 45 Raould 2016-02-14 23:05:04 UTC
Saving a file in the Tinderbox version of 5.2 takes VERY long.  Would this be an effect of it being a Tinderbox build, or is this likely to be a bug in LO 5.2?

(Also, the keyboard shortcut for "Paste Special" in the right-click menu for a cell has been changed in this build, from "a" to "s" - hopefully this will not happen in the Production version?  Why would someone change that after over what, over 10 years?  I end up doing it wrong every time... habits are hard to break!)

It is also taking a VERY long time for this version to crash...  usually happens after 3-7 saves; now on my 30th save and still no crash.
Comment 46 Raould 2016-02-19 21:15:55 UTC
With the 5.2 Dev version I am not getting the same crashes, but the program hangs - it sits with the toolbars grayed out (in the window I was saving), and I cannot enter data/click with mouse anywhere in that window or any other window of LO that I have open (I normally work with 2 files open).

How do I get a backtrace in this situation?
Comment 47 Raould 2016-02-22 00:48:03 UTC
The 5.2 version has hung several times now - I don't know how to save a backtrace in that case, so have had to kill it and start over.
Comment 48 Alexis PAQUIN 2016-04-08 15:09:07 UTC
On Windows 7 x86

This no crash on 4.4.7.2

This crash since the 5.0.0.0 dev version.

I try on 5.0.0.1, 5.0.5.2 and this is crash anyway.
Comment 49 Joel Madero 2016-04-08 15:15:34 UTC
@Erack - thought you might be interested at looking at the new debug backtrace.
Comment 50 Eike Rathke 2016-04-08 16:18:46 UTC
I can't make anything of it. The only thing to see is that during save some error box popped up and there under the ButtonDialog dtor when disposing stuff the process went astray.

00bde7b4 10abf5de 62ddff5e 00000000 1f3900a8 mergedlo!vcl::Window::dispose+0xb54
00bde7dc 10a2789e 62ddf092 19930522 1f38fee0 mergedlo!SystemWindow::dispose+0xbe
00bde810 10a261e8 62ddf0ba 19930522 00000000 mergedlo!ButtonDialog::dispose+0xce
00bde838 612197f2 19930522 00000000 00bde858 mergedlo!ButtonDialog::~ButtonDialog+0x48
00bdf384 10a9b1cd 00000000 02100000 00000000 MSVCR120!_NLG_Return
00bdf3bc 0fb54f72 00000000 02100000 00000000 mergedlo!ErrorBox::ErrorBox+0x5d
00bdf3f0 100a752c 00bdf440 00bdf444 00bdf458 mergedlo!VclPtr<ErrorBox>::Create<vcl::Window * &,__int64 &,rtl::OUString &>+0x62
00bdf46c 1087e745 00000000 00001101 00bdf4a8 mergedlo!aWndFunc+0x22c
00bdf4b8 1087e44d 00000c10 0000ffff 00000000 mergedlo!ErrorHandler::HandleError_Impl+0x2c5
00bdf4ec 0fd5a1e2 00000c10 0000ffff 30e4e380 mergedlo!ErrorHandler::HandleError+0x4d
00bdf870 0fd5c3ae 00000c10 00bdf898 0fc336ee mergedlo!SfxObjectShell::ExecFile_Impl+0x1482
00bdf87c 0fc336ee 15b34b48 09675698 0c57295c mergedlo!SfxStubSfxObjectShellExecFile_Impl+0xe
00bdf898 52b0efaf 09675698 00001581 00000000 mergedlo!SfxShell::ExecuteSlot+0x4e
00bdf8ac 52b05aee 09675698 00bdf908 0fc1ff5c sclo!ScTabViewShell::ExecuteSave+0x3f

A real backtrace including symbols and a detailed step by step description of how to reproduce the crash might help. As I see it Calc isn't involved other than it triggered saving the document.
Comment 51 mahfiaz 2016-04-17 06:03:15 UTC
It seems a lot like an issue not related to LibO at all.

The Dropbox was mentioned. Is it possible that Dropbox reads/writes the during the save and causes the crash? (Close or uninstall it to see if it makes the difference)

Is there an antivirus or any other background program running which could cause it?

Can you replicate the issue on a clean install of Windows, maybe in virtual machine (virtualbox)?
Comment 52 Raould 2016-04-17 19:17:39 UTC
Mahfiaz, this problem started occurring after upgrading to LO 5.0 - no other changes to my Windows set-up at the time (Dropbox, anti-virus, etc).  This occurred on two different machines, one running Windows 8.1, the other, Windows 10.

Eike, I was told by Buovjaga (see 2016-02-12 message) that 5.1 does not have the debug symbols, and asked to use a build of 5.2 from Tinderbox no. 39.  Unfortunately, that kept hanging, thus I never got a backtrace.  Is there some other way to get that?

Thanks!
Comment 53 Buovjaga 2016-04-18 05:36:13 UTC
(In reply to Raould from comment #52)
> Eike, I was told by Buovjaga (see 2016-02-12 message) that 5.1 does not have
> the debug symbols, and asked to use a build of 5.2 from Tinderbox no. 39. 
> Unfortunately, that kept hanging, thus I never got a backtrace.  Is there
> some other way to get that?

Maybe try a newer build from TB39 later. Unfortunately, TB39 seems to be having a problem and no builds are available currently :(

An other way would be for your to compile 5.2 yourself with --enable-debug, --enable-dbgutil or --enable-symbols options, but it can be a bit overwhelming, if you don't have experience with compiling software on Windows. You have to install Visual Studio and a lot of other stuff. For reference: https://wiki.documentfoundation.org/Development/lode
Comment 54 Ysabeau 2016-04-21 09:16:57 UTC
Just to say that I have this problem also with Writer doc with the 5 versions. I have a Windows 64 bits but LibO 32 bits works a bit better for me than the 64 bits version.
Take your time to fix it...
Comment 55 Buovjaga 2016-04-21 09:27:20 UTC
(In reply to Ysabeau from comment #54)
> Just to say that I have this problem also with Writer doc with the 5
> versions. I have a Windows 64 bits but LibO 32 bits works a bit better for
> me than the 64 bits version.
> Take your time to fix it...

It would help a lot, if you got a backtrace with this debug build: http://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/
You should of course first test, if the 5.2 build crashes..

Here are bt instructions once more: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
Comment 56 Commit Notification 2016-04-22 06:40:45 UTC
Arnaud Versini committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e1a724c2029783e84d7c508c6010afac0d6d10f

Try to fix tdf#93967 by using VclPtr to keep the window alive

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 57 Alexis PAQUIN 2016-04-25 09:50:15 UTC
I apply this patch on a LO 5-0-5.

And the bug still be there.

I joint the execution trace and backtrace in the document Execution_and_backtrace_crash_on_save_LO_5-0-5_20160425.odt

The class where WinDgb stop is the \vcl\source\window\window.cxx

on the line

while ( pSysWin->mpWindowImpl->mpFrameData->mpNextFrame.get() != this )
Comment 58 Alexis PAQUIN 2016-04-25 09:51:36 UTC
Created attachment 124620 [details]
Execution and backtrace after pacth add
Comment 59 Alexis PAQUIN 2016-04-25 10:39:54 UTC
An other way to solve this bug.

While a debug execution on LO 5-0-5, the crash appeard on the xml export traietement.



For the momeent, the most close method when bug appear is in \editeng\source\uno\unotext.cxx

uno::Reference< container::XEnumeration > SAL_CALL SvxUnoTextBase::createEnumeration()

the line 
SetSelection( aSelection );
Comment 60 Alexis PAQUIN 2016-04-25 11:36:20 UTC
Created attachment 124625 [details]
Trace_WHEN_SAL_INFO_ACTIVED
Comment 61 Alexis PAQUIN 2016-04-25 11:38:14 UTC
An other trace of the bug reproduction. After actived SAL_INFO debug

https://bugs.documentfoundation.org/attachment.cgi?id=124620
Comment 62 Arnaud Versini 2016-04-25 18:10:51 UTC
Alexis, please add all backtrace data in simple text files and comments in comments only. Did the commit changed the backtrace ? It seems that I fixed the too early delete but not the crash in the destructor.

Could you please send us the complete backtrace ?

I set this bug to NEW since some people on french list confirmed the issue.
Comment 63 Alexis PAQUIN 2016-04-26 08:30:05 UTC
Created attachment 124638 [details]
Full BackTrace LO 5-0-5 with patch 2e1a724c2029783e84d7c508c6010afac0d6d10f
Comment 64 Alexis PAQUIN 2016-04-26 08:46:38 UTC
I apologize for send backtrace on comment.
Comment 65 Arnaud Versini 2016-05-08 17:56:21 UTC
Hi,

The real problem is inside vcl::Window::ImplInit can't create the SalFrame, throw an exception and this exception leads to a crash. Perhaps we can remove this check, can't do anything else than crash during destructor if this exception is thrown.

The exception throwing is here : http://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx#986
Comment 66 Arnaud Versini 2016-05-16 10:14:34 UTC
I did a bibisect and this patch resolves the issue on master :
https://gerrit.libreoffice.org/#/c/20274/ .
Comment 67 Arnaud Versini 2016-05-16 10:54:35 UTC
Backport proposed on 5.1
Comment 68 Arnaud Versini 2016-05-22 09:26:17 UTC
Big thanks to Markus for this patch, Alexis could you check if https://cgit.freedesktop.org/libreoffice/core/commit/?id=fc29ace3438eea09afe3ddbb5118458cbb531b06 solves the issue on 5.0 and 5.1 ?

Thanks
Comment 69 Alexis PAQUIN 2016-05-24 10:27:23 UTC
Hi,

The patch solves the issue on LO 5-0-5.

The build of LO 5-1 with the same patch is in progress.

Best regards

Alexis
Comment 70 Alexis PAQUIN 2016-05-25 13:27:15 UTC
Hi,

The LO 5-1 build crash.

Because there isn't emum type ScHeaderFooterPart declaration.

ScHeaderFooterPart is use in class "textuno.hxx  /  fielduno.cxx   /   textuno.cxx"

Best regards.

Alexis
Comment 71 Eike Rathke 2016-05-25 15:34:47 UTC
(In reply to Alexis PAQUIN from comment #70)
> Because there isn't emum type ScHeaderFooterPart declaration.

You need to backport the patch to the structures/defines that were used in older branches, respectively resolve merge conflicts manually. But apparently you must have done that already for the 5-0 branch if that built. Likely similar changes are necessary for 5-1
Comment 72 Alexis PAQUIN 2016-05-27 12:32:00 UTC
Hey !

The patch solve the issues on 5.1 :) but with some adjustement.

The modification are on the class (textuno.hxx, textuno.cxx and fileduno.cxx).

How can we do to modify the patch, do you want the modify class files or just the modification for each ?

Best regards
Comment 73 Eike Rathke 2016-05-30 13:24:56 UTC
@Alexis:
I don't quite understand, please submit the entire patch as you modified it for the 5-1 branch to gerrit for review.
Comment 74 Arnaud Versini 2016-06-08 18:07:33 UTC
Alexis, is there any trouble during the fix ? You only need to backport the correction.
Comment 75 Alexis PAQUIN 2016-06-08 18:31:31 UTC
@Arnaud

No, nothing wrong append after the backport fix. But like i say on comment #72, to build LO 5-0 or 5-1, some other backport are needed.

Despite this, the fix is great !

I try to push / modify the patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=fc29ace3438eea09afe3ddbb5118458cbb531b06

but i didn't succes to push my modification (some trailing space errors) :(
Comment 76 Xisco Faulí 2016-09-19 15:29:41 UTC Comment hidden (obsolete)
Comment 77 Michael Meeks 2016-10-05 20:13:53 UTC
Markus' patch is in -5-2:

commit fc29ace3438eea09afe3ddbb5118458cbb531b06
Author: Markus Mohrhard <markus.mohrhard@googlemail.com>
Date:   Wed May 18 02:47:01 2016 +0200

    better fix for memory leak around calc header-footer UNO objects

5-0 is end of life; 5-1 could use a back-port; I back-ported Markus' improved fix manually and pushed to CI here for build testing:

https://gerrit.libreoffice.org/29542

Would love to close this =)
Comment 78 Michael Meeks 2016-10-06 12:23:50 UTC
Back-ported to -5-1 and closed.

Thanks !
Comment 79 Commit Notification 2016-10-06 12:27:33 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=052f98d0b1a6b0607069f0a50d4e03fcd4a1d52a&h=libreoffice-5-1

tdf#93967 - better fix for leak around calc header-footer UNO objects

It will be available in 5.1.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.