UserInterfaceListener:
- Add request hook for writing a core file. Implement in TeamDebugger.
Jobs/WriteCoreFileJob:
- Add new job to actually dispatch the core file request via the debugger
interface.
Team{::Listener}
- Add listener event + hook for notifications when a core file gets written.
Implement in CLI.
CliContext:
- Add event flag for core file changed.
CommandLineUserInterface:
- Add 'write-core' command. This optionally takes a path to write the core to,
otherwise one is automatically generated by, similarly to debug reports. As
such, one can now generate cores for things like app_server and registrar
crashes if desired, in addition to reports.
- Add dedicated ReportDebugger application class for the case where we're
asked to do nothing more than save a report. Also add a corresponding
UserInterface subclass whose sole purpose is to take those necessary
actions and then exit.
- When the debugger is invoked via the --save-report option, we now start
via the aforementioned report/interface rather than piggybacking on the
CLI.
- Clean up CommandLineUserInterface/CliContext to remove handling for the
report saving option.
Should hopefully resolve#12155.
UserInterface:
- Add new hook function used to notify the UI that some form of
background work is taking place for informational purposes,
i.e. no interaction required. Implement accordingly in
GraphicalUserInterface.
CliContext/CommandLineUserInterface:
- Process the debug report event asynchronously. The missing lock that
was fixed in commit 5ac34e5a78 highlighted
a problem in how the CLI was handling the case where it was intended to
exit immediately after saving a report, since it issued the quit request
directly from the report event handler. This resulted in locking issues,
as the team debugger would then attempt to tear itself down, during which
it needs to acquire the team lock. However, that was already being held
by the thread in which the CLI was initiating the quit, resulting in a
deadlock.
Add hook to UserInterface to query if Debugger is currently being run
interactively or not. Add corresponding implementations in
{CommandLine,Graphical}UserInterface.
In some circumstances, it may be necessary to ask the user to locate a file
from the lower layers. Adds the corresponding hook to UserInterface, and a
stub implementation for CommandLineUserInterface.
Adds full implementation for GraphicalUserInterface.
- For the functionality added to address #10283, we need to wait until we
receive the Team listener's thread state change notification before submitting
the report generation request, else the thread might not actually be stopped
yet when the generator walks the thread list. Should fix some lingering issues
with stack traces sometimes not being returned when using this mode of
operation.
- When constructing the CLI interface, also pass along the target thread ID
if one was specified.
- If our only reason for starting is to save a report, and we've been given
a specific thread to target, rather than just a team, ensure that the target
thread is in a stopped state prior to saving the report.
- Added 'frame' command for setting/printing the context's current stack
frame within the active stack trace.
- Added 'variables' command for printing the list of variables visible
within the current frame.
- CommandLineUserInterface is now a team listener. Consequently, when asked
to generate a debug report on startup without running the input loop,
it now waits for receipt of the debug report event to terminate.
- Style fixes.
- When invoked, starts up the CLI such that it bypasses waiting for
input and instead save a crash report of the running team, then exits.
Mainly intended to be used by debug_server.
* "thread": prints/sets the current thread.
* "continue", "stop": continue/stop the current thread.
* "sc"/"bt": Print a stack trace for the current thread. Very basic yet.
* Introduce the notion of a current thread. That's the one certain
commands will target (by default).
* Add more event handling in CliContext. There's now a queue of pending
events which are printed in the input loop at convenient times to
inform the user about what happened (new/deleted/stopped threads,
etc.).
* Move the libedit interface there and provide nicer to use methods.
* Also start adding utility methods for the input loop. It is going to
manage all interactions of the input loop with outside events.
* Fix the "quit" command. The user is now prompted what to do with the
debugged team and the input loop thread avoids reentering the input
loop.
* UserInterface::SynchronouslyAskUser() is now allowed to return -1 to
indicate that the user cannot be asked at this point for whatever
reason. The caller needs to handle that case.
* UserInterfaceListener::UserInterfaceQuitRequested(): Add new parameter
"quitOption" to specify what is supposed to happen. The previous
behavior (ask user) is only one of the options. The others are to kill
the debugged team or to resume it.
There's an input loop thread which reads and parses command lines and
the infrastructure for registering and executing commands. Currently
only "help" and "quit" commands are implemented.
Rene Gollent