The problem also happens with this document if updating the TOC is the first action to be done after LO Writer has been started to work on that particular document.

Before updating the TOC was started, the CPU activity of LO Writer was around 1%. After updating the TOC was started, the CPU activity was around 12 ... 13%, RAM usage was 517,4 MiB according to taskmanager.

If I minimize LO Writer and then unminimize it again, the LO Writer Window shows parts of my desktop or the content of another window which take the same space on the screen.

When I move the window, a “comet tail” appears inside it with content from the right or left edge - depending on how I move the window.

I tried the same file with 

Version: 25.2.0.1 (X86_64) / LibreOffice Community
Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9
CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

and I encountered the same hang up.

By using version 25.2.0.1 I was able to recover the document by 

1. selecting everything below the TOC and copying it to the clipboard
2. opening a new document
3. pasting from the clipboard into the new document.

Then I also copied and pasted the document's title to the new document.

Up to this step I had a document without a TOC. Just to be sure, I saved it in that state.

Then had a new TOC be generated. It was done in a few seconds (13 pages).

The hang-problem did not show up during original generation, but on updating an existing TOC.

This was done with version 25.2.0.1 within a few seconds.

Then I saved the document and re-opened it with Version: 25.8.0.0.alpha0+ and I updated the TOC (but without doing any change to the document itself). The TOC was updated within 12 seconds.

I think, somehow some problem must have slipped into the document file. The new file only has 478 pages (including TOC) instead of 586 before (including TOC).

I'll have to check, which pages/chapters got lost.

Please attach a minimal file where this problem persists without any personal info possibly with the steps to reproduce

Looking closer at the reconstructed document:

The default font had become Liberation Serif 12 pf. Originally I had Liberation Sans 10,5 pt.

After changing the font in the default paragraph style back to Liberation Sans 10,5 pt, the number of pages shrunk to 462.

I also used the version control to compare the saved version before my recovery operations with the recovered one: This only found my added note on the recovered document as something new in it. It did not find any other changed part in the document.

(In reply to opp from comment #3)
> Please attach a minimal file where this problem persists without any
> personal info possibly with the steps to reproduce

Probably I won't be able to create such a sample file:

I took a copy of my file (with the TOC bug).

I threw away the last half of its content.

Then I saved it and opened it again in a new session. I was able to update the TOC there. 

Assuming that the bug were in the first half of the file, I started again with a copy of the TOC bug one and this time I threw away exactly the other half. Again I was able to update the TOC in this one. 

So my Idea by cutting the faulty file in halves until I have a manageable small one with the bug, did not work.

I'll keep an open eye on such things. But since I have just downloaded the development version of today, I'll install that one.