Bug 98868 - FILESAVE: crash if try save ODT file with track changes compared
Summary: FILESAVE: crash if try save ODT file with track changes compared
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high critical
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.4
Keywords: haveBacktrace
Depends on:
Blocks: Crash-Assert Document-Comparison
  Show dependency tree / graph
 
Reported: 2016-03-24 18:39 UTC by Roman Kuznetsov
Modified: 2020-11-02 09:17 UTC (History)
9 users (show)

See Also:
Crash report or crash signature: ["sw::ClientIteratorBase::ClientIteratorBase(SwModify const &)", "GetFrameOfModify(SwRootFrame const *,SwModify const &,SwFrameType,Point const *,SwPosition const *,bool)"]

Attachments
backtrace (41.57 KB, text/x-log)
2017-02-27 16:33 UTC, Xisco Faulí 		Details
backtrace with WinDBG from LO 6.3+ (182.88 KB, text/plain)
2019-01-07 17:50 UTC, Timur 		Details
bt with debug symbols (15.02 KB, text/plain)
2020-01-26 20:26 UTC, Julien Nabet 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2016-03-24 18:39:25 UTC 
Version: 5.1.2.1 (x64)
Build ID: 2603b69c5ec5981bb5f053f8ebfd1f3de00a4c29
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; 
Locale: ru-RU (ru_RU)

steps for repro:

1. download full getting started guide 4.2 and 5.0 from 
https://wiki.documentfoundation.org/images/0/0f/GS42-GettingStartedLO.odt
and
https://wiki.documentfoundation.org/images/f/f3/GS50-GettingStartedLO.odt
2. open GS Guide 5.0 in LO
3. select menu Edit - Track Changes - Compare Document
4. select GS Guide 4.2 and wait
5. after compare try to save file
6. LO crashes
Comment 1 tagezi 2016-03-24 19:07:58 UTC 
I confirm this

OS: Gentoo GNU/Linux 4.1.15-gentoo-r1 x86_64 Intel(R) Core(TM) i5-2450M CPU@2.50GHz
LO 5.1.1.3, building ID: Gentoo official package
Comment 2 Roman Kuznetsov 2016-03-24 19:27:36 UTC 
if try compare only one chapter from GS 4.2. and 5.0, then LO not crashes!

i try on chapter 8
Comment 3 steve 2016-03-25 09:59:53 UTC 
also confirmed w current master
Version: 5.2.0.0.alpha0+
Build ID: d9c1921c5031e5b372ee9d8db1e00fe7211cdd31
CPU Threads: 4; OS Version: Mac OS X 10.11.4; UI Render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-03-25_00:52:11
Locale: de-DE (de.UTF-8)
Comment 4 Roman Kuznetsov 2016-03-25 12:22:12 UTC Comment hidden (no-value)
Comment 6 Roman Kuznetsov 2016-09-24 15:02:38 UTC 
crash LO is not critical? how long ago is this? Or status "critical" spoils statistic?
Comment 7 Timur 2016-12-20 16:47:31 UTC 
https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg 
Critical is for core functions, major for particular docs.

We get crash report with LO 5.2 and similar result with 5.3.

We have some side regression here, LO 5.4.0.0.alpha0+ Build ID: 5903235d57acb13d9d5286d23b443a01aeab9a3c Windows 6.1 TinderBox: Win-x86@39, Branch:master, Time: 2016-12-19_00:12:28 takes loong to opet GS50-GettingStartedLO.odt
"Compare" results with dump. 
I'll report separately.
Comment 8 Buovjaga 2016-12-31 15:42:02 UTC 
(In reply to kompilainenn from comment #6)
> crash LO is not critical? how long ago is this? Or status "critical" spoils
> statistic?

No, Timur is reading the flowchart wrong. Reverting severity to critical.
Comment 9 Xisco Faulí 2017-02-27 10:07:56 UTC Comment hidden (obsolete)
Comment 10 Timur 2017-02-27 13:34:14 UTC 
Reproduced with master~2017-02-20_05.58.54_LibreOfficeDev_5.4.0.0.alpha0_Win_x86:
Version: 5.4.0.0.alpha0+
Build ID: 76f9e3b417f19c0a16477e0a0e68e2da31d1de6f
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-02-20_05:58:54
Locale: hr-BA (hr_BA); Calc: CL
 and 
LibreOffice_5.3.0.3_Win_x64:
Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: hr-BA (hr_BA); Calc: CL

But crash signature is different now, why?
http://crashreport.libreoffice.org/stats/crash_details/a797917b-5ee0-43ea-8f05-2b773334dde3

Set back as New. Although this may be Bug 98202 dupe.
Xisco, did you test both Lin and Win?
Comment 11 Timur 2017-02-27 13:45:56 UTC 
Not Bug 98202 dupe, signatures different. This might be WFM for the first signature, in that case we need to open a new one with the second one.
Comment 12 Xisco Faulí 2017-02-27 15:57:02 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2017-02-27 16:33:11 UTC 
Created attachment 131515 [details]
backtrace
Comment 14 Xisco Faulí 2017-02-27 16:37:52 UTC 
(In reply to Xisco Faulí from comment #12)
> (In reply to Timur from comment #10)
> > Reproduced with
> > master~2017-02-20_05.58.54_LibreOfficeDev_5.4.0.0.alpha0_Win_x86:
> > Version: 5.4.0.0.alpha0+
> > Build ID: 76f9e3b417f19c0a16477e0a0e68e2da31d1de6f
> > CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; 
> > TinderBox: Win-x86@39, Branch:master, Time: 2017-02-20_05:58:54
> > Locale: hr-BA (hr_BA); Calc: CL
> >  and 
> > LibreOffice_5.3.0.3_Win_x64:
> > Version: 5.3.0.3 (x64)
> > Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
> > CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; Layout Engine:
> > new; 
> > Locale: hr-BA (hr_BA); Calc: CL
> > 
> > But crash signature is different now, why?
> > http://crashreport.libreoffice.org/stats/crash_details/a797917b-5ee0-43ea-
> > 8f05-2b773334dde3
> > 
> > Set back as New. Although this may be Bug 98202 dupe.
> > Xisco, did you test both Lin and Win?
> 
> Hello Timur,
> You're completely right. It didn't crash for me because I selected 'Accept
> All' in Manage Changes dialog. However, if I select 'Close', LibreOffice
> crashes. The steps are the same as in bug 98202 but as you said, the report
> is different, so let keep both open

backtrace from bug 98202 and from this one look exactly the same though
Comment 15 Julien Nabet 2017-03-19 10:28:20 UTC 
Bt are similar + description of bug is similar=>DUP

*** This bug has been marked as a duplicate of bug 98202 ***
Comment 16 Xisco Faulí 2018-11-14 13:41:23 UTC 
I get a different crash from bug 98202 when I reproduce this crash -> http://crashreport.libreoffice.org/stats/crash_details/35cbe0bb-668b-46a4-8e0b-13a5342787ee
Comment 17 Timur 2018-11-15 07:56:40 UTC 
Let's keep split. Easy to join if resolved.
Comment 18 yellowhank 2018-11-29 09:10:43 UTC 
Bug still exists


Version: 6.3.0.0.alpha0+
Build ID: 72e204da9a062282e52d5060e7f633e3b21414ff
CPU threads: 4; OS: Mac OS X 10.10.5; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-26_01:27:57
Locale: zh-CN (zh_Hant.UTF-8); UI-Language: en-US
Calc: threaded
Comment 19 Timur 2019-01-07 17:50:28 UTC 
Created attachment 148110 [details]
backtrace with WinDBG from LO 6.3+
Comment 20 Telesto 2019-06-04 07:34:19 UTC 
FWIW: recently fixed in NeoOffice
Comment 21 Julien Nabet 2020-01-26 20:26:02 UTC 
Created attachment 157440 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I got an assertion when trying to save after having compared both files.
Perhaps it's related to the crash.
Comment 22 Julien Nabet 2020-01-26 20:34:30 UTC 
Assertion has been added with:
author	Michael Stahl <mstahl@redhat.com>	2013-06-15 21:25:27 +0200
committer	Michael Stahl <mstahl@redhat.com>	2013-06-20 00:34:38 +0200
commit 6db39dbd7378351f6476f6db25eb7110c9cfb291 (patch)
tree 0f9321d40740e87e80d8ed05a7c7f474d5310afd
parent e012f326c1c32c053304998a6826cb322f2c7728 (diff)

fdo#52028: sw: let text formatting ignore RSID in automatic styles
A suprising regression from 062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c:
The RSID text attributes that are inserted for every user-inserted text
cause the text formatting (SwAttrIter) to create a lot more text portions,
and the portion breaks make font kerning impossible.
...

(Of course I don't mean the assertion here isn't correct, it may just reveal something buggy on LO code, I've got no idea at all)
Comment 23 Roman Kuznetsov 2020-10-22 13:10:14 UTC 
I didn't get a crash in

Version: 7.1.0.0.alpha0+ (x64)
Build ID: fca525d570f4fada3db1a9bbee2e88a5a02839d9
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL

People, please retest it in latest master 7.1, thanks
Comment 24 Timur 2020-10-22 13:35:39 UTC 
Crash Windows fca525d570f4fada3db1a9bbee2e88a5a02839d9 and Linux f1d798151048dde3f48b124ef406416668d1e9c5 gtk3.
Comment 25 Buovjaga 2020-10-22 17:39:47 UTC 
Still crashing here

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: ccdb78773ac6c9d19140e8084f37cc2c7f06240e
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 18 October 2020
Comment 26 Caolán McNamara 2020-10-27 20:09:10 UTC 
I think when we compare the documents we are copying SwTOXMark from the source document to dest document but leaving the copy pointing to the SwTOXType of the source which is deleted with the compare is done
Comment 27 Commit Notification 2020-10-28 15:55:26 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/496771a6466d6a48f0bcbd8976df24308e052f38

Related: tdf#98868 split out reusable hunk as function

It will be available in 7.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 28 Commit Notification 2020-10-30 12:31:37 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/60b1f8f6ef715ee4cb282215375188c1511ad6d6

Related: tdf#98868 add SwDoc& member to SwTOXType

It will be available in 7.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2020-10-30 12:31:49 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fd9c47eda58dda5e61850e9b9f6de0f38d221b4a

tdf#98868 re-register cloned TOXMark if the dest doc is different

It will be available in 7.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 30 Caolán McNamara 2020-10-30 12:37:14 UTC 
I feel the above fixes the "real world" crash, but there is still an unrelated assert from the RSID check
Comment 31 Buovjaga 2020-10-30 13:02:23 UTC 
I verify that it does not crash anymore

Arch Linux 64-bit
Version: 7.1.0.0.alpha1+
Build ID: 1a4ae360d06ae300a8fd5482b3b3a86dc021750d
CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 30 October 2020
Comment 32 Xisco Faulí 2020-10-30 13:13:36 UTC 
For the record, I found bug 137855 while checking this issue
Comment 33 Caolán McNamara 2020-10-30 14:33:07 UTC 
Based on comment #31 I'll deem this fixed and backport a submission for 7-0. If there needs to be follow up on the IMO fairly low priority RSID assert a new bug can be used for that.
Comment 34 Xisco Faulí 2020-10-30 16:07:38 UTC 
I do confirm the issue is fixed after https://git.libreoffice.org/core/commit/fd9c47eda58dda5e61850e9b9f6de0f38d221b4a, however, I can't reproduce the original crash in libreoffice-7-0 branch

Version: 7.0.2.0.0+
Build ID: b27137a7091104cce177791478e86d127680c9af
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

so it seems the crash might have been fixed and recently introduced with https://git.libreoffice.org/core/+/69d903c59729deb9f9824929bb31e4256f09025b%5E%21

@Caolán, I'm wondering if the backport to 7.0 is needed...
Comment 35 Caolán McNamara 2020-10-30 16:29:48 UTC 
I feel we're safer with the patch in 7.0 than without. As far as I can see the problem exists there too in having a pointer to the old deleted SwDoc existing in the new document. IIRC I was able to get my 7.0 to crash sometimes with the same steps.
Comment 36 Xisco Faulí 2020-10-30 16:47:13 UTC 
(In reply to Caolán McNamara from comment #35)
> I feel we're safer with the patch in 7.0 than without. As far as I can see
> the problem exists there too in having a pointer to the old deleted SwDoc
> existing in the new document. IIRC I was able to get my 7.0 to crash
> sometimes with the same steps.

fair enough. Thanks a lot for fixing this issue!
Comment 37 Commit Notification 2020-11-02 09:17:21 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/3faa7a5efad3c0532446c2e576464570d7110179

tdf#98868 re-register cloned TOXMark if the dest doc is different

It will be available in 7.0.4.

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

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