Reproduced in

Version: 6.3.0.0.alpha0+
Build ID: 8f7c35072a6bbb33f6582c8c9a37a275c8d3cb14
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

Reproduced back to 

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Created attachment 148547 [details]
gdb backtrace

Hi Caolán, this is an import crash never caught by the crash testing scripts. I thought you might be interested in this one...

Still reproducible in

Version: 6.4.0.0.alpha0+
Build ID: 0d36b32755ac662299e6a8165e9fa57311b74a2f
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

Still reproducible in

Versión: 6.3.4.2 (x86)
Id. de compilación: 60da17e045e08f1793c57c00ba83cdfce946d0aa
Subprocs. CPU: 2; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

but I get a different crash signature < http://crashreport.libreoffice.org/stats/crash_details/07a12c91-53cc-4bcd-a7b4-dd8b400a6494 >

The crash got fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=1052acae9a599c54e518c8fc17d6a994d8778757, however, it still hangs at import time...

(In reply to Xisco Faulí from comment #7)
Although that seems unlikely, I duplicate your bisect results. Reverting (and that is a bit complicated because it got changed into try2) didn't bring the crash back. Neither did reverting https://git.libreoffice.org/core/commit/81588ff2f0eb55576a5288778be2dfb5b4bc5e81

Hi Justin,
this is weird, it crashes for me again in

Version: 7.0.0.0.alpha0+
Build ID: 35fc5ef0a759884b24ed8b83cd05702a0fab64cc
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

deleting the user profile beforehand: 'rm -rf instdir/user/ && instdir/program/soffice /home/xisco/Downloads/0b12ccf28e8ee87a15ceb3a6d24aff72.doc'

(In reply to Xisco Faulí from comment #9)
> Hi Justin,
> this is weird, it crashes for me again in
> 
> Version: 7.0.0.0.alpha0+
> Build ID: 35fc5ef0a759884b24ed8b83cd05702a0fab64cc
> CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
> Locale: en-US (en_US.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> deleting the user profile beforehand: 'rm -rf instdir/user/ &&
> instdir/program/soffice
> /home/xisco/Downloads/0b12ccf28e8ee87a15ceb3a6d24aff72.doc'

The crash was reintroduced after https://cgit.freedesktop.org/libreoffice/core/commit/?id=642cdf2d8341f0b202f01718ccb63ac1b976e18e, so I believe the hang started to happen after 24caeee8236576abd92086974c1dbbf15b81a4c5

@Jan-marek, I thought you might be interested in this issue...

Created attachment 159556 [details]
First valgrind block accessing freed memory

(In reply to Xisco Faulí from comment #7)
> The crash got fixed by
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=1052acae9a599c54e518c8fc17d6a994d8778757, however, it still hangs at
> import time...

So I had a look at this. If I revert the whole five patches it crashes:

Initial positioning text wrap:
 * commit dc3e213dcd81be3eee8d139ea5ad55606a44eeff
 * commit f497d1dc27b4fee3db1e2228647a00971922eb5f
 * commit 1052acae9a599c54e518c8fc17d6a994d8778757

Footnote refactoring:
 * commit 642cdf2d8341f0b202f01718ccb63ac1b976e18e
 * commit 24caeee8236576abd92086974c1dbbf15b81a4c5

If I keep that revert and just apply the two broken patches:

 * commit 1052acae9a599c54e518c8fc17d6a994d8778757
 * commit 24caeee8236576abd92086974c1dbbf15b81a4c5

it hangs, but that's the same hang as bug 131530, which I fixed with

 * commit 642cdf2d8341f0b202f01718ccb63ac1b976e18e

which was a Copy'n'Paste bug in my refactoring commit to begin with.

So while comment 7 is correct from the "user perspective", it's simply not true that the crash was ever "fixed" from the code perspective.

And the valgrind log is the same with or without the whole patchset. See the attachment 159556 [details].

Just an info for someone trying to fix this, as I just have a symbol build and the optimization makes this hard to debug further.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/732d6b4209f24622972116505ad6b500e3ecc293

crashtesting: assert the condition making tdf122894-1.doc crash

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.

Still crashing at import time in

Version: 7.1.0.0.alpha1+
Build ID: 35f7d9a18fa7f559a1427e1b8a0f094f864f945a
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Caolán, recently you fixed an assert caused by tdf122894-1.doc, any chance you could take a look at the crash itself ?

This doc appears in the crashtesting report, my assert just clarify what thing is deleted that causes the eventual crash so its known broken at the assert point. So the document is known to me, I just haven't had a good result wrt this layout crash yet.

this seems a little similar to bug 101821 FWIW

Created attachment 167129 [details]
Reduced document with just the affected page and surroundings

Maybe it isn't needed to reformat the column when formatting a footnote with an object inside a column?
With `if ( pColFrameOfAnchor )` replaced by `if ( pColFrameOfAnchor && !_rAnchorTextFrame.IsInFootnote() )` in FormatAnchorFrameAndItsPrevs the document seems to display correctly (Page 116 (101)).

I've also attached a reduced document in case that helps.

That's somewhat encouraging to isolate a smaller reproducer and a workaround. Is it impossible to create working columns in a footnote anyway?

I used the crashtesting infrastructure so hunt for other examples of this type and it seems to be the only one I can find, and I can't see a way to create a document like this from our own UI (unless I miss something) so lets go with Arne's suggestion of comment #18

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

tdf#122894 skipping anchor in column in footnote

It will be available in 7.2.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.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/7d7eb9895e18a48660965a87c9e2136f028e7022

tdf#122894 skipping anchor in column in footnote

It will be available in 7.1.3.

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.