fix fragment id capture in StackTraceDeobfuscator file name regex

[Samin061]

When a frame has no symbol map entry, which is the normal case for anonymous functions, the deobfuscator falls back to reading the code split fragment number out of the frame's file name. That name comes from the //# sourceURL=<moduleName>-<fragmentId>.js comment CrossSiteIframeLinker writes at the end of every fragment, so it is the only place the fragment number is still available on the server. The pattern used to read it back is .*(\d+)\.js, and because .* is greedy it backs off only far enough to leave a single digit for the capture group, so app-12.js reports fragment 2 and app2-104.js reports fragment 4. Under ten fragments that happens to be correct, which is presumably why it has gone unnoticed, but past that the wrong _sourceMap<N>.json is loaded and the frame gets resolved against unrelated source. Requiring a non-digit ahead of the captured run fixes the capture, and it also drops the quadratic backtracking the old pattern has on a file name that arrives from the client (a 32k name took ~700ms to reject, ~1ms after). The set of file names that match is unchanged, only the digits handed back differ, and I kept the change to the pattern so the surrounding fallback stays as it is.

[jnehlmeier]

Nice find! I am pretty sure that is the reason why a larger app I work on still produces wrong stack traces even after dodging #9931 . The app has more than 10 split points / fragments.

[Samin061]

That lines up with what I'd expect. The fallback only runs when the symbol map has no entry for the method, so it's the anonymous-function frames that get a bad fragment id, and those are exactly the ones that then resolve against whichever source map the truncated digit happens to point at. With 10+ fragments -12.js becomes fragment 2, so the frame gets mapped through an unrelated fragment's source map and comes back with a plausible-looking but completely wrong file and line. Frames that do have a symbol map entry take the id from the symbol map and are unaffected, which fits the pattern in #9931 where only some frames in a trace are nonsense.

If you want to sanity check it against your app, the fragment ids that misresolve are the ones >= 10 whose last digit is a different valid fragment; a frame in fragment 12 should show up resolved against fragment 2's source.

[jnehlmeier]

Just a small wording change. Otherwise its fine.

[Samin061]

any update?