Deduplication of code objects can lead to incorrect/misleading stack frame identification

[dnfield]

For example, SomeRenderObject.semanticBounds may get deduplicated to RenderClipOval._defaultBounds, because the impelmentations are both Offset.zero & size, leading to a stack trace that looks like this:

at RenderBox.size(box.dart:2023)
at RenderClipOval._defaultClip(proxy_box.dart:1731)
at RenderVisibilityDetectorBase._scheduleUpdate.<anonymous closure>(render_visibility_detector.dart:143)
at RenderVisibilityDetectorBase._processCallbacks(render_visibility_detector.dart:62)
at _TaskEntry.run(binding.dart:91)

The at RenderClipOval._defaultClip(proxy_box.dart:1731) should actually read RenderVisibilityDetectorBase.bounds (which is implemented via semanticBounds and so got deduplicated).

This is counter-intuitive and led me to believe that the stack trace was busted somehow. If we can't avoid this, perhaps we could at least indicate in the symbolication all of the candidates for a particular symbol.

/cc @a-siva @mraleph (who helped figure this out on an internal issue).

xref b/244342335

[mraleph]

We have discussed this before, but unfortunately native debugging format does not provide any reasonable means for this, so short of emitting funky names which represent all merged functions we can't really represent this.

We can do something specific for our custom symbolisation tooling - but that's too narrow to be useful.

The alternative is to disable code merging for code that contains potentially throwing instructions altogether. We can try that and see the impact on code size.

/cc @mkustermann @sstrickl

[xster]

Do you mean actually disabling inlining in production in some cases? Checking the cost sg but it seems heavy handed. Any thoughts on what the cons would be for actually doing the former? And in the above example, just letting the second row be called RenderClipOval._defaultClip or RenderVisibilityDetector.bounds(proxy_box.dart:1731)?

[rmacnak-google]

Note the engine's C code has same issue because of its use of -Wl,--icf=all / /Oicf.

[dnfield]

We can do something specific for our custom symbolisation tooling - but that's too narrow to be useful.

What if we had the following tooling:

• When generating symbol information, the tooling tells you all of the symbols that got deduplicated
• Deduplicated symbols get some special name treatment, e.g. instead of RenderClipOval._defaultClip(proxy_box.dart:1713) it would say ** Deduplicated symbol foo(deduplicated_symbols.txt:13)
• The deduplicated symbols file would have something like

foobar: RenderClipOval._defaultClip(proxy_box.dart:1713), RenderVisibilityDetector.bounds(render_visibility_detector.dart:43),....`

etc.?