If the RTL is compiled with optimization then same functions may not have a stackframe. Of course that is intended. But...

Within the list of those is at least one (probably both of the following:

Procedure fpc_assert(Const
Msg,FName:Shortstring;LineNo:Longint;ErrorAddr:Pointer); [Public,Alias :
'FPC_ASSERT']; compilerproc;
begin
   if pointer(AssertErrorProc)nil then
     AssertErrorProc(Msg,FName,LineNo,ErrorAddr)
...
Procedure AssertErrorHandler (Const Msg,FN : ShortString;LineNo:longint;
TheAddr : pointer);
...
     S:=Msg;
   Raise EAssertionFailed.Createfmt(SAssertError,[S,Fn,LineNo]) at
get_caller_addr(theAddr), get_caller_frame(theAddr);

This leads to get_caller_addr/get_caller_frame getting the address and frame of the wrong function.
Instead of the function containing the assert, they will get the caller of that function.

This is unconvincing if debugging.

I was wondering what the options are? Not even sre if that really is due to the missing frame

the code calling ASSERT

006F30AB 55 push %ebp // ErrorAddr: 006F30AC b969030000 mov $0x369,%ecx 006F30B1 baf8478000 mov $0x8047f8,%edx 006F30B6 b8c8498000 mov $0x8049c8,%eax 006F30BB e800acd1ff call 0x40dcc0 <fpc_assert>

ErrorAddr is the frame of the function calling assert?

Then why get_caller_addr/get_caller_frame ?