I'm curious what is your plan here? Note that there are several issues with this:

1. Typical Linux trace has several thousand addresses from Chrome and couple of hundreds from other libraries (which we also need to symbolize).

2. We have plans to do some post-processing in the symbolization script, e.g. assign proper categories to allocations - that won't be possible to do from the Chrome itself. So this features should be disable-able.

I think we are waiting for the TracingV2 format and changing the format of the memory dump to have all allocations. Only then the symbolization script which will assign categories will work. When we have such a format, it is also possible to symbolize inside chrome and post process just to see categories if needed. I do not get why this should be disable-able.

We need paths for proper categorization, i.e. we need to do proper symbolization using dwarf info, and not just resolve address to function name (which StackTrace does). That is going to be hard (dwarf reading stuff from breakpad might not even be compiled in by default) and slow (compared to running several addr2line instances in parallel in the script).

Overall, runtime symbolization is limited (desktop builds only), and just duplicates code that we already have in the symbolization script.

Maybe instead tracing UI should just invoke symbolization script after getting the trace file?

I believe Dmitry is a better owner of this. ;-)

Chrome switched to memlog, and erikchen@ et al. is working on that now.