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
Currently, there seems to be an opportunity to get on-the-fly stream of messages
temporarily hitting blackbox, enabler being on-disk materialized files.
This would also give an opportunity for a deepest look into the run possible,
beside mere debugging/stracing/probing, which is rather cumbersome for
not so isolated observations.
The text was updated successfully, but these errors were encountered:
blackbox has a limited capacity whereas stream is possibly
"endless'
may not solve infloop/deadlock problems when signal handling
will never be served
Compared to big-gun solutions like attaching debugger, this would
save one from active attendance on debugging session, stopping
the process (making the timeouts kick in), expertise required from
the user. This indeed assumes the trace messages are spread
reasonably in the code.
jnpkrn
changed the title
Investigate and possibly implement real-time tracing: qb-blackbox { --attach <PID> | --command <cmd> }
Investigate and possibly implement real-time tracing: qb-blackbox { --pid <PID> | --command <cmd> }
Feb 2, 2018
Currently, there seems to be an opportunity to get on-the-fly stream of messages
temporarily hitting blackbox, enabler being on-disk materialized files.
This would also give an opportunity for a deepest look into the run possible,
beside mere debugging/stracing/probing, which is rather cumbersome for
not so isolated observations.
The text was updated successfully, but these errors were encountered: