►
From YouTube: Debugging Debugging by Josh Gavant, Microsoft
Description
Debugging Debugging - Josh Gavant, Microsoft
Old protocols and new protocols, Visual Studio Code and Chrome DevTools, async traces and dynamic stepping... So many new capabilities and tools have been released this year to make debugging and diagnosing Node.js apps easier, and so many more are in development in core and in vendor products. But how to start using them and what to do when things go wrong? What caveats and tips should everyone be aware of? In this session we'll "debug debugging" - turn the system inside out so you can understand how it's supposed to work from core's perspective. You'll leave better prepared to utilize the rush of new tools and better armed to address unexpected problems. You might even discover ways you can contribute to the Diagnostics WG and help us continue to improve the quality of Node.js apps!
About Josh Gavant
Node.js diagnostics and runtime.
A
How
so
debugging
debugging
I
just
wanted
to
clarify
the
title
at
the
at
the
get-go
here?
The
goal
here
is
to
help
you
understand
how
debugging
works
from
the
inside
out,
how
to
debug,
debugging
and
I
hope
you'll
come
out
of
this
better
able
to
diagnose
and
debug
your
own
programs
and
also
able
to
give
us
some
feedback
in
node
core
and
the
Diagnostics
working
group
about
the
kind
about
some
of
these
things
and
the
way
they're
being
implemented
and
how
we
can
better
serve
you.
A
So,
in
this
session,
I'm
going
to
take
a
couple
minutes
and
just
discuss
the
Diagnostics
working
group,
its
goals
and
a
couple
things
that
we've
done
this
year.
Then
I
want
to
take
you
on
a
journey
through
a
demos
of
a
couple:
evolving
interfaces,
inspector
and
tracing
controller
and
hopefully,
along
the
way,
you'll
you'll
learn
some
new
tricks,
learn
some
new
tools
and
be
able
to
write
some
of
your
own
script.
A
As
Julia
already
said,
I'm
Josh
I'm
a
technical
p.m.
working
on
open
source
of
Microsoft
for
a
while
I'm
the
coordinator
/
cat
herder
for
the
Diagnostics
working
group,
which
takes
us
to
what
exactly
is
the
Diagnostics
working
group
and
the
goal
this
is.
This
is
really
important.
It's
to
let
us
all
come
together
and
create
a
bunch
of
open
interfaces
that
developers
can
use
directly
that
can
be
built
into
open
source
projects
that
can
be
built
into
commercial
products,
stuff
that
we
can
all
party
on.
A
So
we
can
have
a
great
ecosystem
of
tools
to
better
understand
our
apps,
so
definitely
check
out
nodejs
Diagnostics.
The
issue
tracker.
There
is
where
we
have
discussions,
there's
some
documentation
in
the
main
repo.
Also
there's
some
overlap.
The
post-mortem
WG
also
has
some
diagnostic
tools.
Sleep
check
them
out
to.
A
A
couple
from
the
post-mortem
WG
node
report,
which
gives
you
a
bunch
of
information
about
the
state
of
your
process,
if
it
crashes
or
on
certain
signals,
ll
node
is
written,
it's
an
extension
to
ll
DB,
which
gives
it
better
understanding
of
v8,
JavaScript
frames
and
objects
and
then
finally,
the
tracing
controller,
which
is
just
a
PR
at
this
point.
But
it
allows
you
to
insert
trace
points
throughout
node
and
get
information
out
in
a
log.
A
One
of
the
most
exciting
parts
is
it
the
same
protocol
that
chromium
has
used
for
a
while.
Now
we
you've
been
able
to
use
node
inspector
in
the
past,
but
that
was
kind
of
a
hack
translating
from
chrome
the
chromium
protocol
to
the
old
debugger
protocol.
So
now
we
have
the
same
one
as
chromium,
step,
debugging
being
able
to
jump
into
a
running
script
and
even
modify
it
and
a
couple
new
things
that
weren't
possible
with
the
old
debug
interface
heap
analysis
and
CPU
profiling.
A
I
want
to
take
you
through
a
journey
of
using
that
interface.
Specifically,
I
want
to
start
at
the
low
level
with
WebSockets
an
HTTP
and
kind
of
show
you
how
it
works
at
the
low
level.
Show
you
a
couple
tools
that
you
can
use
that
are
built
on
top
of
it
and
then
finally,
take
you
out
to
a
high-level
tool
or
two
so
just
to
kind
of
orient
you
around
what
we're
going
to
do
here.
Here's
a
picture
of
kind
of
how
the
architecture
looks.
A
You've
got
node
over
there
on
the
right
with
v8,
a
big
part
of
that
your
user
script
will
be
running
a
v8,
then
there's
an
inspector
agent,
which
also
runs
alongside
the
main
event
loop
in
node
and
exposes
at
this
point
a
a
web
socket
interface.
On
the
other
side,
I've
made
some
concentric
circles
to
kind
of
represent
going
from
low
level
out
to
higher
level,
and
that's
actually,
the
journey
will
take
we'll
start
with
curl
we'll
go
through
some
command
line
tools
and
then
show
some
graphical
tools.
A
A
A
It
just
spins
up
a
let's:
go
down
a
little
bit
spins
up
a
basic
HTTP
server
and
sends
back
sends
back
received
requests
number
one
number
two
number
three,
as
you
go
along
so
we'll
close
that
out,
and
we
will
just
run
that
now:
node
dot,
node
scratch
index
such
a
yes
and
now
I've
got
my
HTTP
server.
Listening
on
port
8080,
actually
I
also
need
to
add
the
dash
dash,
inspect
command-line
flag.
A
Okay,
so
we've
got
that
note
process
running
it's
waiting
for
requests
if
I
curl
against
the
straight
end
point
there
I
should
get
back
response
number
one
received
I
see
on
the
console
on
the
other
side
requests
received.
Let's
show
what
the
inspector
gives
us
back.
So,
if
I
curl
against
localhost
9229,
that's
the
port
that
it's
listening
on
by
default.
You'll,
see
if
I
say
nothing
else,
I
get
back.
Websockets
request
was
expected,
doesn't
work
it's
web
sockets,
but
there
are
a
couple
metadata
endpoints.
A
Actually,
three.
I
want
to
show
you
so
one
of
them
is
list,
so
it's
always
wack
JSON
is
the
metadata
like
the
beginning
of
the
metadata.
Endpoints
will
act
ace
on
what
wek
list
will
give
you
some
important
information
amongst
that
this
ID,
which
we're
going
to
need
later
on
the
other
two
are
version
which
tells
you
some
information
about
the
version
you're
talking
to
and
protocol,
which
actually
gives
you
back
the
full
full
scheme
of
the
protocol
that
this
understands
for
inspector,
which
can
be
helpful
if
you
want
to
dynamically
use
certain
features.
A
Shoot
NDSU's,
no
I,
think
I
haven't
installed
somewhere
else
yep,
so
WS
cat
is
a
tool
which
basically
opens
up
a
WebSocket
connection
and
you
can
type
stuff
in
and
get
stuff
back,
so
we're
just
going
to
go
ahead
and
show
exactly
how
that
looks
on
the
wire
Oh
over
here.
I
meant
to
show
you
guys
some
stuff,
as
this
was
going
on.
I,
have
to
add
one
more
thing
here:
dash
y
WebSocket.
A
Oh
okay,
that's
actually
a
good
thing
that
I
missed
that
because
that's
an
important
detail,
so
you
actually
every
process
is
getting
debug
gets
its
own
uuid
its
own
identifier,
and
it
won't
allow
you
to
connect
unless
you
specify
that
in
the
string.
So
here,
for
example,
the
identifier
is
this-
you
can
get
it
out
of
the
output
from
the
when
you
run
dash
dash
inspect
so
now,
if
I
go
back
down
here
and
I
type
WS
cat
that
plus
this
uuid,
then
I
actually
connect.
So
that's
an
important
thing
to
know.
A
A
A
The
current
inspector
instance
that
you're
connected
to
so
here
I'm,
actually
just
calling
using
JSON
RPC
I
specify
that
the
method
I'm
going
to
use
a
schema,
get
domains,
and
you
actually
can
see
I
get
back
and
you
can
see
it
on
the
other
side
to
the
WebSocket
protocol
coming
in
on
the
network
and
I
get
back
the
ones
that
are
supported.
So
here's
a
debugger
supported
runtime
heap,
profiler
profiler.
A
You
can
find
out
more
about
these
domains
just
by
going
to
the
chrome,
debugger
protocol
and
I
just
search
for
that
online.
That's
the
debugger
protocol
viewer
and
you
can
get
a
list
of
the
supported
domains,
so
you'll
notice
that
here's
v8
inspector
and
those
are
the
bunch
that
I
that
I
just
thought.
A
A
A
Dot
node
node
SPECT
helpers,
and
this
is
called
index.
So
it's
a
pretty
simple
script.
It's
called
get
cpu
profile
and
you
specify
how
long
you
want
it
to
run
for
and
it
will
actually
using
this
using
the
chrome,
remote
interface
will
actually
call
profile
or
the
profiler
domain
and
able
leave
it
on
for
10
seconds
turn
it
off
and
dump
a
file
for
you,
I'm
not
going
to
actually
do
that
right
now,
but
I
can
show
you
the
output
in
chrome,
of
one
that
iran
previously.
A
So
you
could
see
there's
my
basic
listener
from
my
script
and
it
looks
a
little
small
and
they
did
a
couple
different
methods
within
that
basic
listener.
So
just
a
nice
way
to
programmatically
access
the
inspector
I
do
want
to
show
note
inspect
really
quickly
so
spin.
That
up
again
note
inspect
is
a
lot
like
if
you've
used,
node
space,
debug
and
then
a
script
is,
you
know,
it
starts
up
a
CLI
debugger
there
and
you
can
actually
attach
and
set
breakpoints
and
do
things
in
the
command
line.
A
Note
inspector
the
same
thing
for
for
the
inspector
protocol,
so
I
can
say
no
to
inspect.
You
see
a
whole
bunch
of
stuff
just
went
by
over
there
I
can
say,
set
a
breakpoint
and
index
jsf
if
teen
and
it
actually
already
hit
that
break
point,
and
it
shows
me
what
I
got
actually.
This
is
something
that
word
it's
right
now,
general
of
tremors
wrote
it
and
it's
not
yet
in
the
foundation
and
we're
discussing
how
to
bring
it
in
and
how
to
make
it
available.
So
it
definitely
would
be
interested
in
your
feedback.
A
A
A
A
Something
that
we
need
to
talk
about
actually
is.
There
is
a
you
can
record
some
dynamic,
unfixed
data,
and
maybe
we
can
use
that
to
better
log
information
about
what's
happening
in
core
I'd,
be
interested
in
people's
feedback
on
that,
and
that
then
I
put
here
the
things
that
might
come
next
and
things
that
we
need
to
think
about
and
that
we
need
feedback
from
the
community
on
what
kinds
of
things
do
you
want
us
to
trace?
Do
we
is
a
jsapi,
a
javascript
api
cuz
right
now,
it's
all
native
code.
A
So
please
give
us
feedback
on
that.
Okay,
don't
know
how
much
times
to
let
me
hurry.
Basically,
the
architecture.
Is
you
long?
You
put
a
trace
point
somewhere
in
your
code.
It
goes
down
through
the
whole
tracing
controller
hierarchy
and
writes
out
to
a
file
full
of
trace
objects.
Let's
just
go
ahead
and
do
that
really
quick.
A
So
no
9304,
I
will
say
node
dashte,
oh
I,
meant
to
show
you
actually
before
I.
Do
that
the
trace
points
that
I've
added
here
so
I've
only
added
about
20
lines
into
node
core
to
rap
to
to
track
connection
rap.
So
connection
rap
is
created
when
a
TCP
connection
is
made
from
outside.
In
two
notes:
I'm
going
to
track
when
that
connection
is
made
to
when
it's
torn
down,
which
would
give
me
a
rough
estimate
of
how
long
the
request
took
so.
A
An
interesting
thing
about
it
at
this
stage
is
that
if
you
do
a
ctrl
C
to
stop
the
process,
it
doesn't
actually
flush
the
dog
properly,
so
I
a
dad
that
wax
stop
to
make
it
stop
gently
now,
I'll
see
in
this
directory
a
node
trace,
one
dot.
Log
yeah
and
the
best
I
mean
one
way
to
parse
is
just
JSON.
So
one
way
to
parse
it
is
just
to
go
into
node
and
parse.
It
yourself,
I,
actually
wrote
a
little
script
to
like
it,
showed
you
quickly
scratch
process.
A
Let's
just
grep
out
for
node,
and
you
can
see
the
the
logs
that
I
got
four
node
album
without,
but
not
that
much
time,
but
you
can
see
I've
got
the
same
idea
for
these
two:
that's
how
in
chrome
tracing,
for
example,
it
maps
them
together
and
you
can
subtract
the
second
number
in
this
column.
These
are.
A
There's
my
log
and
you
can
actually
see
where
I've
it
actually
is
aware
that
the
this
interface
is
aware
that
the
connection
wrap
the
two
events
are
correlated
because
they
share
the
same
ID,
and
so
they
both
show
up
here
and
you
can
see
other
v8
execution
stuff
happens
on
top
of
them.
Like
an
interesting
thing
here,
you
can
see
that
the
first
request
took
a
lot
longer
than
the
other
ones,
etc,
etc.
A
Okay,
so
let
me
wrap
this
up.
Some
overtime
recap:
the
Diagnostics
working
group.
We
want
to
create
open
interfaces
that
everybody
can
party
on
projects
products.
Your
own
scripts
showed
you
a
little
bit
about
inspector,
hopefully
gave
you
an
idea
of
what
you
can
do
with
it
and
tracing
controller.
It's
at
its
early
stages,
help
us
determine
what
we
should
do
with
it,
and
hopefully
you
learned
a
little
bit
about
some
scrip
some
tools
there
to
conclude:
here's
some
resources.