You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a plugin stores a parameter value from a callback for later, it should be possible to provide better diagnostics about where exactly the parameter was stored. If the callback is a 100+ line function, it can be quite difficult for a human to analyze it.
Using the debug library it should be possible to examine the function's locals and upvalues, seeing which one contains the saved instance. For example if the callback creates a new closure with the value captured into the closure, it should be possible to see that - there'll be a local value (the closure) of type function whose upvalue would be equal to the saved object.
It may be necessary to re-execute the handler in order to be able to see its internals via the debug library, possibly even installing a debug hook so that code can be executed while the function is still on the stack. Perhaps this could be made into a new detection mode that installs a hook for each callback's return and checks all its locals / upvalues.
The text was updated successfully, but these errors were encountered:
madmaxoft
changed the title
Improved "stored value" reporting
Improve "stored value" reporting
Oct 18, 2016
If a plugin stores a parameter value from a callback for later, it should be possible to provide better diagnostics about where exactly the parameter was stored. If the callback is a 100+ line function, it can be quite difficult for a human to analyze it.
Using the
debug
library it should be possible to examine the function's locals and upvalues, seeing which one contains the saved instance. For example if the callback creates a new closure with the value captured into the closure, it should be possible to see that - there'll be a local value (the closure) of type function whose upvalue would be equal to the saved object.It may be necessary to re-execute the handler in order to be able to see its internals via the
debug
library, possibly even installing a debug hook so that code can be executed while the function is still on the stack. Perhaps this could be made into a new detection mode that installs a hook for each callback's return and checks all its locals / upvalues.The text was updated successfully, but these errors were encountered: