Closed mvastola closed 5 years ago
+1
Not sure if it's related, but I'm recieveing the following error, without a stack trace at all.
For example:
[0;31mUnhandled promise rejection TypeError: ...[0m
Great catch! Anyone interested in opening a PR?
I'm not sure adding the TypeError instead of the string would change anything. Look at part I emphasized from the documentation on Nan errors
Nan::ThrowTypeError()
Throw an TypeError object (a specialized v8::Value as above) in the current context. If a msg is provided, a new TypeError object will be created.
But searching for [0;31m
brought me to try_handle_log_message (inject.vala
and gadget.vala
)
Perhaps there is more data to print from the message?
@Nihilight That logic handles the type: "log"
messages sent when using console.log()
and friends on the agent side. Language bindings typically handle those and hide them from the user's message callback. However for frida-inject
and frida-gadget
(in standalone mode) those need their own handling. Anyway, log messages don't carry any stack-trace, and this issue is about frida-node APIs throwing.
Timed out. Will probably be addressed by an N-API rewrite at some point.
So I just learned this, but apparently, in nodejs, the code
will produce a trace as follows:
The problem being, the stack trace does not include the frame at which the error occurred (in this case, line 2). This makes it extremely difficult to debug complex apps.
Apparently, the solution is to, instead of:
.. use:
This produces the following backtrace:
.. which is infinitely more helpful.
Currently, this package uses the (v8 equivalent of the) first syntax.
Due to frida/frida#592, I currently cannot test this out, but it would seem that this is an easy fix: Given, say:
.. instead use:
Could this change be made globally in this repo?