* GetBytecode defaults to callstack top as before, with the small change
that a missing callstack top (empty callstack) results in an error instead
of a dummy fake response.
* GetBytecode also accepts a callstack index (-1...-N) and an object/heap
target pointer.
* Fix minor bugs in duk_debug_read_tval() call sites: they assumed that a
duk_tval was pushed even when the read failed and nothing was pushed.
The fix is to stop processing an inbound message if duk_debug_read_tval()
fails and avoid making assumptions about value stack shape.
Add more flexibility to the debugger JSON mapping so that you can giver a
numbered command/notify using the 'request' or 'notify' key directlty,
without having to provide e.g. { "request": true, "command": 123 }. Instead
you can just use { "request" : 123 }.
* Add 'at foo' to indicate function name
* Put file/line into parentheses for better readability
* Use [anon] for anymous functions, which is better than an empty string but
distinguishable from a function actually named 'anon'
* Rename tailcalled flag to tailcall
* Switch from tab indent to 4 space indent
Website debugger section updates:
* Bullet list for debugger features, including AppRequest and
AppNotify
* Emphasize mixing and matching debug clients and targets
* Add documentation for duk_debugger_attach_custom() and
duk_debugger_notify()
* Change tag from 'debug' to 'debugger'
* Minor additions to other debugger API calls
* Add AppRequest example with "CommandLine" custom command which provides
the C argv[].
* Add AppNotify example with "DebuggerHandleFile" custom notify when running
code from files.
* Mention application-defined commands in the introductory overview.
* Add a new section discussing the feature and its usage at length as
well as a recommended convention for messages.
* Document the contract for the request callback and what rules it must
follow. Include a sample request callback implementation.
* Remove future work items covered by this feature.
When Duktape receives an AppRequest, it pushes all the dvalues in the
message to the value stack and calls the request callback. That callback
can process the message and optionally push its own values to the stack,
which will be sent back to the client as a reply.
It is also possible for the target to send application-specific notifys
to the client by calling duk_debugger_notify(). These will be received
by the client as an AppNotify message.
NULL all debugger transport I/O callbacks (i.e. callbacks other than
detaching_cb) whenever the transport indicates an error has occurred.
By the API contract we're not allowed to call any of them after transport
read/write error so it's safest to NULL them all on a transport error.
This is not strictly necessary because only the write_cb is used by
detach1() currently before NULLing the callbacks anyway. However, NULLing
them early on transport error ensures there's no potential to call them
incorrectly even when the code is reorganized later.
Fix a bug in `duk_debug_write_byte()` where a transport write callback
error (indicating a transport detached/broken condition) did not NULL
the transport `dbg_write_cb` as intended.
As a result, the detach1() handler (which runs immediately afterwards)
would try to write a "Detaching" notify and invoke the transport write
callback after it already returned an error. This is a violation of the
debug transport contract.
Fixed by making duk_debug_write_byte() simply call duk_debug_write_bytes()
which has correct handling for the write_cb NULLing. This reduces call sites
at the cost of being a little less optimal. However, the same approach is
already used for read helpers so this change makes the handling symmetric.
Fix two separate bugs:
* Potential to re-enter the debugger recursively when a detach happened
inside the debugger message loop.
* Potential for detach initiated from outside the debugger message loop to
be never finalized.
The re-entry bug was caused by `dbg_processing` being set to 0 in detach1()
while in the debugger message loop. This caused the potential for the
debugger code to be re-entered recursively before the detach was finalized
using detach2(), which could have various harmful side effects. The fix is
to keep `dbg_processing` set to 1 at all times when still in the debugger
message loop.
The detach finalization bug was triggered by a debug transport callback
called outside the debugger message loop indicating the transport connection
had broken (this would concretely happen e.g. for a periodic Status notify).
This caused detach1() to run which, among other things, sets dbg_read_cb to
NULL and dbg_detaching to 1.
The intent is then for detach2() to finalize the detach (this is separated
from detach1() to allow reattach-during-detached-callback to be handled
correctly). However, when dbg_read_cb was set to NULL outside the debugger
message loop, the message loop would never be entered again -- and only the
message loop has handling for finalizing a detach using detach2().
The fix for this is to allow the executor to enter the debugger message loop
when a detach is pending (dbg_read_cb == NULL and dbg_detaching == 1) so that
the detach can be correctly finalized.
The message loop detach2() handling now also supports the corner case where
user code reattaches in the detached callback but a detach is immediately
triggered while still inside the detached callback. This may happen because
`duk_debugger_attach()` writes the debugger protocol handshake line inline
inside the API call using the transport write callback, and that callback
may fail and indicate a transport error.
The fix is to then issue another detached callback etc, until we are either
cleanly detached or cleanly attached and can proceed.
Finally, the control flow was changed so that the `dbg_processing` flag is
set and cleared inside the debugger message loop now rather than in several
separate call sites outside of it. This should be less error prone.
Both bugs fixed in this commit were introduced in Duktape 1.4.0 as part of
adding the Detaching notify and splitting detach handling into detach1()
and detach2(). As such, the fixes don't need to be backported to Duktape
1.3.x etc.
* Set SIGPIPE handler to SIG_IGN when signal setup is enabled. This avoids
hard exits due to SIGPIPE when debugger transport connections break.
* Add --reattach option to allow the auto-reattach test to be done without
modifying duk_cmdline.c.
Sami Vaarala
Bruce Pascoe