Sergei Gorelkin pisze: > 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.
I attached my proposition of patch here : http://bugs.freepascal.org/view.php?id=13518 and here (only windows) for external debug files (.dbg) : http://bugs.freepascal.org/view.php?id=13499 Do you have testcases for testing such invalid frames like in example above and for testing recursion ? Would be great if someone looked at proposed solution and checked under unix,win64 and other supported systems. > >> 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 That's what I did among other changes. Regards Bogusław _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus