Created attachment 185055 [details]
The Writer document that crashes

This is a reproduction of a book of 1200 pages approx. The document is not completed due to the crashing bug. In addition to the crash, there are several issues with formatting the text where there are footnotes. I shall report those issues once the crash is fixed.

Oups! I see that I interverted "Actual Result" with "Expected result". Sorry

Thanks, Yves.

On Windows 10, I could reproduce following your steps. With crash report:

https://crashreport.libreoffice.org/stats/crash_details/3c8406fa-1845-422f-bafc-0cd4150c8a7d

Same signature as you, which also corresponds to closed bug 151433.

Version: 7.4.5.1 (x64) / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

I tested on Ubuntu 20.04 as well and didn't even need to change the font size to make it crash, it crashed shortly after opening the Styles deck in the sidebar.

Version: 7.4.5.1 / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

I got the following crash report:

https://crashreport.libreoffice.org/stats/crash_details/0a84cb90-bb30-418c-8a9e-07514d47cc5b

...which has a different crash signature ( SwFrame::GetPhyPageNum() const ) to yours ( SwFrame::FindPageFrame() )

Will report this one separately.

Also crashed in following versions:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 4b67515418ee4f10071b3f0f2275ba37f32b0ae5
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

Version: 7.1.0.3 (x64) / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

Version: 7.0.0.3 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

In 7.0, I get the signature:

"SwSaveFootnoteHeight::SwSaveFootnoteHeight(SwFootnoteBossFrame *,long)" - https://crashreport.libreoffice.org/stats/signature/SwSaveFootnoteHeight::SwSaveFootnoteHeight(SwFootnoteBossFrame%20*,long) 

In 7.1, I get the signature:

"SwSaveFootnoteHeight::SwSaveFootnoteHeight(SwFootnoteBossFrame *,__int64)" - https://crashreport.libreoffice.org/stats/signature/SwSaveFootnoteHeight::SwSaveFootnoteHeight(SwFootnoteBossFrame%20*,__int64)

So seems you are correct regarding it being footnote-related.

Could *not* crash it in 6.0:

Version: 6.0.0.3 (x64)
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: en-GB (en_GB); Calc: group

Created attachment 185061 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I got an assertion.

More of my observations:
I took a look at the Linux stack trace. This is consistent with my observations.

The book contains a lot of footnotes. Several lenghty ones. At least one spanning more that one full page. Changing the font size, in this case, forces the paragraphs to lengthen and forces the recompute of paragraphs and footnotes distributions and pages formatting. Clearly, there are some critical paragraph-to-footnote relationships that causes troubles to the page reformating algorithm.

One issue I had, which I can't give exact reproduction steps before the crash is resolved, was that after I made sure all the pages were properly formatted and saving the document. Once I reopened the document, some pages had large gaps of blank space at the bottom of the page. Those pages were invariably followed by a page with a footnote anchor in the first line. So, clearly, the footnote reformatting algorithm couldn't figure how to resolve this situation. I could resolve it manually by deleting the space between the last word and its previous word of the page with the large blank gap. This brought the rest of the text and the associated footnote to fill the gap. Then I reinserted the space between the words and all looked fine. ... Until I saved the document and reopened it again.

In case you are curious, the book was typeset in 1954 and can be found at https://archive.org/details/dli.ernet.505700/page/n5/mode/2up

Regression does appear:

Version: 6.3.7.0.0+ (x86)
Build ID: 726535ec30f12697ceccd2f0640d9371a64dc5bd
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

I'm currently looking repository 6.2

Regression introduced by:

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

commit 1caea03fcc6c24e38b2d1d9f6097ad84183ffefd	[log]
author	Michael Stahl <Michael.Stahl@cib.de>	Mon May 06 15:40:41 2019 
committer	Michael Stahl <Michael.Stahl@cib.de>	Mon May 06 17:48:54 2019 
tree 7d0a8a46d4825b6695322aab4dda756b5326fbef
parent 2ff22c0bf4c23c4bed9ccfcfa79dff848086650d 

Bisected with: win32-6.3

Adding Cc: to Michael Stahl

FWIW: this bug is closely connected with bug 153319. The bug might be fixed if and when https://gerrit.libreoffice.org/c/core/+/146534 gets committed

I opened the document, and no other change and crash

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a1acc2f46cc499631d66b1d7a923ed15ab4f28de
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

(In reply to BogdanB from comment #10)
> I opened the document, and no other change and crash
> 
> Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: a1acc2f46cc499631d66b1d7a923ed15ab4f28de
> CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3
> Locale: ro-RO (ro_RO.UTF-8); UI: en-US
> Calc: threaded

You need to change the font size of the Default paragraph style to exactly 9.8 pt. I tried with 10 pt (maybe more common case than 9.8) and no crash, but entering 9.8 makes it crash.

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 440c23ee678442fc64aa9fcca13b137738e10a04
CPU threads: 14; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: threaded

"I opened the document, and no other change and crash".
I didn't say that I can not reproduce the crash, maybe I miss punctuaction.

I meant: "I opened the document, I just kept the document opened for 5–10 seconds and LO crashed.". So, I repro.

I did the same thing now, just opening the document, and in some seconds crash with latest master.

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: b5a22fceed57f05eb43a5fb0817afbc141610c5e
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

unable to reproduce this now; tentatively assuming it was fixed by 7e9b2b71db72b8c4c9c6ca83d08d3b6b05775ac8

*** This bug has been marked as a duplicate of bug 153319 ***

Moving crash signature to the dedicated field from https://crashreport.libreoffice.org/stats/crash_details/d8608389-1417-4856-87e0-a5d3cb87ba39 and others in comments.