3 ms·
The act of stackwalking breaks. You often end up in completely nonsensical stacks halfway through and then all is lost.
by the_mitsuhiko 4y ago
The act of stackwalking breaks. You often end up in completely nonsensical stacks halfway through and then all is lost.
- loeg 4y agoIs this just an artifact of old return addresses on the stack not being overwritten?
- jsolson 4y agoThat makes sense, as you're fucked by any false positive. If it's a graph of potential stacks, though, wouldn't you eventually find the one that unwinds, if one exists?
- loeg 4y agoGP mentioned in another comment that they don't actually follow the algorithm described by userbinator -- checking the return address for a preceding call -- which would increase the number of false positives a lot.
- haileys 4y agoThe thing that makes this tricky is that x86 is a variable length instruction set: you don't know where the preceding call instruction might begin, and you can't decode backwards. You can do it speculatively, but ambiguities are still possible.
- ghusbands 4y agoGiven that the full technique apparently works well for userbinator, we can assume that this isn't a very significant issue. The chances of a phantom call instruction will be pretty low, and there's a fairly low maximum instruction length.
- loeg 4y agoYes, but checking for valid CALL instructions is probably sufficiently accurate.