Created attachment 186307 [details]
Backtrace

Thanks Aron. Reproduced with example document on Linux in 7.2 and recent master build.
Crash report:

https://crashreport.libreoffice.org/stats/crash_details/c6e84de2-8484-4a07-b1dc-2a3526c9e960

(In reply to Aron Budea from comment #0)
> Crash report:
> https://crashreport.libreoffice.org/stats/crash_details/0a8cc30e-d1ba-409b-
> b2d8-33e8b581e6c7
> (a crash report taken on Win with LO 7.5.0.3 should be here, but it isn't
> for some reason, Xisco, do you know if something is wrong with the crash
> report server?)

it just takes a while to process the report. The link works now.
FYI, infra is planning to migrate it to another bot, so it should be faster once migrated.

Created attachment 186333 [details]
bt with debug symbols

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

Just for info, at the beginning when typing the fourth ".", I got:
"\a\003   ....  \b"
     69         for (SwNodeOffset n = nEndNode; nStartNode <= n; --n)
     70         {
     71             SwNode *const pNode(rNodes[n]);
     72             if (pNode->IsTextNode())
     73             {
     74                 SwTextNode & rTextNode(*pNode->GetTextNode());
when doing in gdb:
p rTextNode.GetText()
and everything is ok but LO reenters the same location (I suppose because of autocorrect mechanism) and the string becomes:
"\a\003\a   ….  \b"
Notice both \a (which correspond to CH_TXT_ATR_FIELDSTART)

LO analyzes the string from end to start and when encounters CH_TXT_ATR_FIELDSTART:
     87                         case CH_TXT_ATR_FIELDSTART:
     88                             --nFields;
     89                             assert(0 <= nFields);
     90                             break;

whereas in the first case when it's ok, it got there:
     96                         case CH_TXT_ATR_FIELDSEP:
     97                             if (nFields == 0)
     98                             {
     99                                 assert(!ret); // one per field
    100                                 ret.emplace(rTextNode, i - 1);
    101 #ifndef DBG_UTIL
    102                                 return *ret;
    103 #endif
    104                             }

Un-CCing developer, unclear if we have time to investigate this.

Reproduced in recent trunk build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0dcaff6043e1f24ce0fa354dff80a86e40622247
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

For LO 7.2 on Linux, from comment 2, signature was "sw::CalcBreaks(std::vector<std::pair<unsigned long, int>, std::allocator<std::pair<unsigned long, int> > >&, SwPaM const&, bool)".

Different crash signatures in currently maintained branches:
- 7.6.6.3, "sw::mark::FindFieldSep(sw::mark::IFieldmark const&)": https://crashreport.libreoffice.org/stats/crash_details/81d71af2-6023-4587-8f0a-2c99e82716e8
- 24.2.3.2, pesky "<name omitted>" on Linux: https://crashreport.libreoffice.org/stats/crash_details/1f47136c-e9bc-4b6c-8fba-bd0d054aa47f
   - "SwNodeIndex::SwNodeIndex(SwNode *)" on Windows: https://crashreport.libreoffice.org/stats/crash_details/0291707b-0649-48d3-93a8-04a9475ecbb6

(In reply to Thorsten Behrens (allotropia) from comment #6)
> Un-CCing developer, unclear if we have time to investigate this.
Upping priority then.