[Lazarus] function StabBackTraceStr(addr:Pointer):shortstring; - problem with subsequent back traces

[Sergei Gorelkin]

Bogusław Brandys пишет:
> There is a problem with this function. To avoid recursion there is a 
> hack there to  point BackTraceStrFunc to system implementation (which 
> only shows addresses in hex).Long back trace which mostly ends with 
> incorrect frame address as I suppose (OpenStabs is returning false for 
> nil address) - thus function pointer is not returned back to lineinfo 
> stabs processing method and next back trace contains only addresses .
> 
Right you are. However, many backtraces *start* with an invalid frame: 
e.g. when you call a virtual method of an object that is already 
destroyed, you'll likely end up at a random address.

> 
> This problem is minor if program crashes with exception and stack trace 
> but in other cases , like in bigger program (any Lazarus ones) , ONLY 
> first back trace has useful information (source,line number) attached to it.
> That eliminates any useful logging like multilog for example.
> And nobody really is able to know correct stack frames length before 
> calling any of such functions to obtain back trace (that would resolve 
> problem).
> 
> How we could fix it ? Is this recursion still a subject here ?
> 
I fixed one of the causes recently (see exeinfo.pp, rev.12802), but that 
wasn't enough. In general, code of lineinfo, lnfodwrf and exeinfo has to 
be checked very carefully to make sure it would not crash at any 
circumstances. Including possibly unknown/corrupted state of the RTL in 
case when backtrace is called due to a crash.

> I have one idea, probably not perfect.
> 
> 
> How about  a function to initialize
>   BackTraceStrFunc  : TBackTraceStrFunc;
> 
> 
> The only way now is to set :
> 
> BackTraceStrFunc := @SysBackTraceStr; (displays only hex of addresses)
> 
> Something generic is needed, able to set to StabBackTraceStr if lineinfo 
> unit (option -gl) is used and only to  SysBackTraceStr in other case.
> It might be used also to set to user defined function.
> 
> That way in any such functions in lcl 
> (DumpExceptionBackTrace,GetStackTrace) or external package (like 
> multilog), we could initialize BackTraceStrFunc to point again to 
> correct function before obtaining stack trace.
> 
For me, it looks simpler and better to restore BackTraceStrFunc 
unconditionally at the end of StabsBackTraceFunc/DwarfBackTraceFunc.
Or even better, have it set to stub only for calling GetLineInfo.

Regards,
Sergei