At some time "inherited Destroy" steps into the RTL (part of fpc). This usually has no debug info. You need to compile your own fpc with debug info, if you really need to debug there. (fpupdeluxe can help).
The same applies to fpc_ansistr_*, part of the rtl.
But I doubt that stepping in there will get you closer to your problem.
Crashes in fpc_ansistr_* are 99.999% due to memory corruption, or accessing already free'd objects (including double free).
I suspect, that you may be destroying (or otherwise access) an object, that was already destroyed before. The memory of this object is then filled with whatever random data got there in the meantime, and that can cause any sort of bad effect.
In general, finding such bugs is extremely hard.
If you are an linux, the ultimate tool is "valgrind". But using it requires some background knowlegde.
The first steps that you should do, if you have not yet:
compile with
-gh -gt
You may want to set the the environment HEAPTRC=keepreleased in Run > Run Parmeter.
When you are in destroy, check the various fields of "self". If they have strange values (55555555 or AAAAAAAA or BAADF00D) then your object was destroyed before. (Even if the values are not the listed ones, check if they make sense)
In that case, you must find where the destroy had happened.