Bug 125624 - CRASH working with file with lots of hints
Summary: CRASH working with file with lots of hints
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.4.0 target:6.3.0.1 target:6.2.5
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2019-06-01 15:40 UTC by Xisco Faulí
Modified: 2019-06-10 08:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
64 bit WinDbg stack trace of crash (15.04 KB, text/plain)
2019-06-01 16:00 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2019-06-01 15:40:02 UTC
This issue can be reproduced after https://gerrit.libreoffice.org/plugins/gitiles/core/+/9ff648c691f003a11eba9a22ac37032d72b4b642%5E%21 for bug 125372. The importing time has been drastically reduced by Noel Grandin in LibreOffice 6.3 which has uncovered another issue.

Step to reproduce:
1. Open attachment 151516 [details] from bug 125372

-> It crashes. See https://bugs.documentfoundation.org/show_bug.cgi?id=125372#c14

On linux, I get this error in console

malloc(): smallbin double linked list corrupted

Version: 6.3.0.0.beta1+
Build ID: 219e128553645911685b6061f7c5ea359a4c551c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 V Stuart Foote 2019-06-01 16:00:01 UTC
Created attachment 151834 [details]
64 bit WinDbg stack trace of crash

64 bit WinDbg stack trace against crash of TB62 build
Version: 6.3.0.0.alpha1+ (x64)
Build ID: 837c9e35ef4795cec63ac8e953e58a870e8d02bc
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-05-31_06:21:53
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 2 Noel Grandin 2019-06-01 16:12:28 UTC
Note that this still crashes on older versions (just takes a long time). 

It has something to do with the SwFntCache stuff
Comment 3 Mike Kaganski 2019-06-03 08:53:29 UTC Comment hidden (obsolete)
Comment 4 Xisco Faulí 2019-06-03 09:06:17 UTC
(In reply to Mike Kaganski from comment #3)
> My bibisect gave
> https://gerrit.libreoffice.org/plugins/gitiles/core/+/
> 32902f66e7749b2d06d13f50416be5323a0c0ea9 - which might be completely
> unrelated for multiple reasons, e.g. I couldn't try each bibisect iteration
> several times (to see how reliable the crash is); in some cases,
> auto-popping up (when finally loaded) LO intercepted my current input (so I
> could guess that inputting some characters prior to crash could affect it
> somehow, e.g. prevent it from happening, etc).

then it should be bisected again with experimental mode enabled
Comment 5 Mike Kaganski 2019-06-04 11:41:38 UTC
(In reply to Xisco Faulí from comment #4)
> then it should be bisected again with experimental mode enabled

It's somewhere in 6-2...
Comment 6 Mike Kaganski 2019-06-06 05:26:48 UTC
One needs to launch soffice with SW_REDLINEHIDE=1, to successfully bibisect prior to https://git.libreoffice.org/core/+/ae3150b1e1863e854224c2e41c7e50991f945dad
Comment 7 Mike Kaganski 2019-06-06 05:29:41 UTC
/me has some inexplicable feeling that tdf#125624 has something to do with mst___'s redline work :-D
Comment 8 Xisco Faulí 2019-06-06 07:10:52 UTC
Hi Michael,
according to the bisection, it might be related to the redlining refactor you did a few month ago...
Comment 9 Mike Kaganski 2019-06-06 09:38:07 UTC
Bisection gave https://git.libreoffice.org/core/+/4532845e22c10f252840887e55002307227b2390
Comment 10 Xisco Faulí 2019-06-06 11:14:48 UTC
(In reply to Mike Kaganski from comment #9)
> Bisection gave
> https://git.libreoffice.org/core/+/4532845e22c10f252840887e55002307227b2390

Let's change it to bisected then.
@Mike, thanks for the long bisection
Comment 11 Mike Kaganski 2019-06-07 12:22:34 UTC
https://gerrit.libreoffice.org/73654

I don't know how this might relate to my bibisection results... but some relation is undoubted: the document contains tracked changes.

As discussed in gerrit, this is only a simple change converting sal_uInt16 to sal_uInt32; then in a separate commit, this should be replaced with std::vector.
Comment 12 Commit Notification 2019-06-07 14:30:02 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/2d5821ceacf399ec9267a3704ee0b2cc8a598f04%5E%21

tdf#125624: this bugdoc overflows sal_uInt16

It will be available in 6.4.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 13 Commit Notification 2019-06-08 01:53:39 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/c744dac16ad808c73021cb2cecefe1d484934451%5E%21

tdf#125624: this bugdoc overflows sal_uInt16

It will be available in 6.3.0.1.

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 14 V Stuart Foote 2019-06-08 07:33:43 UTC
Windows 10 Home 64-bit en-US (1809) with TB39
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 9870ff897f088563426bee9567dd9cb722c2b929
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

attachment 151516 [details] now opens cleanly to full document without crash.

Also opens cleanly with default rendering.

Some very noticeable delay in page movements (the <Ctrl>+G go to page dialog) or scrolling. With corruption of rendering the page layout (seems worse when positioning any footers).

Corruption on the page is affected by zoom levels, and the view mode in use. 

Seems worse moving backwards in the file.
Comment 15 Mike Kaganski 2019-06-08 07:37:18 UTC
(In reply to V Stuart Foote from comment #14)

Let's call the crash fixed.
The file seems to be a nice stress test, exposing different edge cases and oddities - if you feel appropriate, let's have a dedicated issue about scrolling problems/layout corruption.
Comment 16 V Stuart Foote 2019-06-08 14:48:33 UTC
(In reply to Mike Kaganski from comment #15)
> (In reply to V Stuart Foote from comment #14)
> 
> Let's call the crash fixed.
> The file seems to be a nice stress test, exposing different edge cases and
> oddities - if you feel appropriate, let's have a dedicated issue about
> scrolling problems/layout corruption.

No objection.

Opened bug 125802
Comment 17 Xisco Faulí 2019-06-10 08:55:23 UTC
Verified in

Version: 6.4.0.0.alpha0+
Build ID: ec905d131374f0860bac77c52873eed984b1966f
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Mike Kaganski, thanks for fixing this issue!!
Comment 18 Commit Notification 2019-06-10 08:56:48 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/bc651b9157fa8f35e28774ffebda1bb7fadb455b%5E%21

tdf#125624: this bugdoc overflows sal_uInt16

It will be available in 6.2.5.

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.