►
Description
A
Okay,
we
are
live
so
welcome
everyone
on
the
node.js
diagnostic
working
group,
meeting,
2019
September
25.
The
today's
meeting
is
different
than
the
usual
one,
meaning
that
today
we
will
discuss
one
of
the
deep
dive
topics
around
diagnostic
use
cases,
user
journeys
and
and
tutorials,
and
we
peaked
the
crash
analysis
as
the
first
one.
So
today
we
will
talk
about
both
how
we
want
to
work
together
on
these
two
topics:
kind
of
figuring
out.
What
are
the
use
cases
what
have
available
to
us?
What
are
the
user
journeys
today?
A
So
the
today
is
the
first
one
as
I
mentioned,
which
little
bit
will
be
mixed,
both
figuring
out
how
we,
how
we
want
to
work
on
this
and
to
discuss
the
actual
deep
type
of
it,
which
is
the
closest
crash
willing.
The
document
today
meetings.
Actually
it's
cross-linked
both
in
the
original
data
security,
new
notes
document,
and
we
have
these
separate
documents
which
will
be
used
today.
So
you
can
find
the
link
in
both
the
github
issue
and
in
the
zoom
meeting.
A
Okay.
So
what
was
in
my
mind
how
we
could
facilitate
this
meeting
today
is
kind
of
start
to
come
up
with
use
cases.
What
what
we
we
know,
as
both
the
users
and
I
know,
stick
working
group
members
that
people
may
want
to
do
around
process
crash
analyzes.
Then
we
could
kind
of
discuss
how
we
are
debugging
today,
those
what
are
the
tools
and
what
are
the
gaps.
A
A
Okay
about
the
use
cases,
I
have
no
better
idea.
Then
I
start
with
one
right
now
and
I
would
like
to
hear
what
other
people
are
facing
issues
around
this
or
know
about
that
their
customer
facing
and-
and
hopefully
we
start
to
have
some
kind
of
list.
What
we
can
work
with
that.
Does
it
sound
good
to
the
people
here?
A
Yep,
okay,
so
what's
probably
really
Netflix,
Pacific
or
platform-specific?
Is
that
our
use
case
is
basically,
my
team
is
building
a
platform
where
people
running-
let's
say
arbitrary
code,
black
box
code
from
our
team
point
of
view,
because
we
are
just
providing
a
platform
and
operating.
So
when
we
start
to
see
crashes,
then
sometimes
it
can
be
really
hard
to
to
kind
of
inspect
to
process
the
post-mortem
in
a
way,
you're
kind
of
gaining
as
data
to
really
figure
that
what
happened.
A
So
sometimes
the
error
message
and
the
stack
trace,
which
was
thrown,
have
enough
information
for
that
sometimes
doesn't,
and
the
use
cases
when
it
doesn't
have
enough
information
is
usually
when
either
of
the
stack
trace
is
like
it's
happening
in
a
third
party
library
which
has
a
really
deep
stack
trace,
and
the
error
message
is
not
very
useful.
This
is
an
example
when,
for
example,
you
use
the
official
G
RPC
library.
A
So
when
you
make
an
issue
like
when
you
pass
the
negative
negative
number
to
positive
integer
strongly
tied
for
buffer,
that
it
blows
up,
the
error
message
is
not
used
for
the
stack
trace
is
not
useful
because
it's
inside
the
library,
so
it's
kind
of
a
black
box.
What
really
happened
in
the
process-
and
another
use
case
is
why
am
someone
is
catching
the
error
and
withdrawing?
A
A
B
Guess
like
if
we
look
at
the
document
that
juries
put
together
with
the
crash
use
case,
I
mean
crashes,
could
also
be
like
a
sea
level
crash
in
the
process
right,
yeah,
so
I
don't
know
if
that's
like
in
terms
of
the
the
original
documentation,
it
makes
sense
to
combine
those
like
right.
Okay,
so
like
it's
right,
because
it's
kind.
C
The
way
I
look
at
it
is
at
least
there
are
two
different
class
of
issues
which
comes
under
the
crash.
After
listening
to
the
explanation
of
Peter,
one
is
basically
low
level
crashes,
such
as
sea
crash,
etc,
which
do
not
leave
a
trace
of
a
stack
trace
for
whatever
reason,
whereas
the
the
crash
context
and
the
failure
data
is
crisp
and
precisely
available,
if
you
debug
through
a
core
dump
debugger,
that
is
the
first
class
of
issue.
The
second
class
is
basically
through
some
abstraction,
such
as
a
third-party
library,
etcetera.
B
C
Yeah
I
mean
the
only
commonality
would
be
like
there
is
somebody
such
as
a
low-level
tracing
which
intercepts
the
origination
of
the
first
error
and
generates
a
quorum
in
response
to
the
creation
of
the
first
error,
and
then
that
core
file
has
complete
information
that
you
are
looking
for
and
the
DPR
is
a
predict
and
it
shows
all
the
predict
that
is
required
for
generating
the
column.
Yeah.
C
A
So
please
we
will
jump
to
codons
and
kind
of
way
of
find
it.
It's
it
kind
of
resonates.
The
second
one.
The
error
message
is
tempered
by
the
error
ending
pipeline
which
what
I
shared
so
I.
Think
and
and
can
you
talk
a
little
bit
about
the
low-level,
see
like
use
cases?
I
know
it
can
happen,
but
to
be
honest,
I
didn't
run
too
much
into
this,
so
I
have
a
really
limited.
The
context
would
why
it
can
happen,
and,
and
how
can
happen,
could
you
maybe
share
some
examples?
Yeah.
C
So,
basically,
if
you
look
at
the
way,
node.js
is
abstracting
the
JavaScript
API.
Is
it
internally
make
use
of
v8
api's
and
almost
everywhere,
and
the
v8
API
is
be
within
the
API
or
at
the
call
site
of
the
APA.
You
have
macros
to
validate
the
sanctity
of
the
input
and
the
output.
For
example,
you
will
see
checks
and
rechecks.
These
are
basically
to
make
sure
that
you
don't
get
unexpected
results
because
of
a
user
error
or
a
completely
bogus
input
or
output.
C
Now
it's
so
possible
that
at
some
because
of
some
bug,
these
chips
are
missing
at
some
control
flow
parts
and
when
the
application
undergoes
that
control
flow
path,
the
the
side
effect
is
that
it
can
crash
in
a
highly
unexpected
manner.
We
thought
without
having
any
proper
JavaScript
call
stack.
Possibly
it
will
be
as
good
as
a
granular
C
program
that
is
correct.
I.
B
Right
and
I
guess
in
that
case,
even
if
it
does
include
the
JavaScript
stock,
you
need
to
be
set
up
to
be
able
to
get
those
core
dumps
and
introspect
them
and
get
them
off.
The
production
machine,
which
is
part
of
what
the
the
other
dog
Jewish
put
together,
covers
yeah.
The
other
thing
I'll
add
to
that.
One
is
like,
in
addition
to
something
as
the
e
crashing
anytime,
your
application
uses
native
modules.
You
know
the
native
modules
can
also
cause
you
know,
node
to
crash.
C
B
B
A
A
Input
can
be
caused
by
native
model
crashes
and
memory
leak
in
native
models,
and
we
have
another
bigger
category,
which
is
mainly
when
the
error
is
tempered
by
the
error
ending
pipeline,
which
couple
of
examples
can
be
third
party
libraries
kind
of
not
making
really
good
job
of
making
the
arrows
and
can
be.
We
are
simply
restoring
arrows
wrapping
across
or
doing
other
things
with
error
which
which
causes
the
original
error
message
and
stacktrace
kind
of
hidden
in
the.
B
A
B
We
have
isn't
the
second
one
more
like
that.
You
can
have
things
like
unhandled
exceptions
and
resolve
promises
which,
depending
on
your
options,
can
cause
you
to
exit
and
then
under
that
you
can
either
have
one
that
gives
you
a
nice
good
stack
trace
where
it's
like
obvious.
What
is
happening
or
one,
where
you've
got
that
problem
of
the
tampering.
A
C
And
I
would
like
to
clarify
on
the
first
bullet,
which
is
v8
checks
when
input
check
is
missing,
can
lead
to
a
crash.
Yes,
basically,
what
I'm
Mandy
is
the
check
missing
is
not
necessarily
the
root
cause
of
the
crash
check.
Missing
is
now
causing
the
manifestation
to
be
of
the
vanilla
crash.
If
the
check
is
present,
then
we
would
see
a
more
decent
aramis,
a
probably
optional
crash,
as
for
the
actual
root
cause
could
be
any
any
bug
in
the
virtual
machine
or
in
the
data
or
in
the
application.
C
A
E
D
What
about
like
until
I
think
no
12?
We
never
showed
properties
on
arrows,
for
example,
when
we
lock
them
that's
different
now,
so
now
we
definitely
lark
properties
all
the
time
when
they're
directly
on
the
arrow
as
an
enumerable
property,
but
we
often
create
arrows
in
various
ways
and
often
also
have
properties
on
them
that
are
non
enumerable
due
to
being
on
the
prototype.
For
example,
what
opinion
do
you
have
about
these
things?
Should
these
properties
be
visible
by
default,
it
might
be
a
bit
off.
Okay,
I'm,
not
totally
sure.
B
I
guess
cuz,
like
yeah
I,
mean
to
reach
correct
me
if
I'm
wrong,
but
even
in
the
case
where
there's
a
missing
check,
some
other
bug
must
have
allowed
that
call
to
be
made,
or
it's
a
bug
that
you
know
they.
You
know
you
shouldn't
be
able
to
pass
data.
It
would
be
a
bug
and
node
potentially
calling
zi8
in
a
way
that
wasn't
intended
right.
A
A
Some
of
Netflix
we
have
many
of
them,
because
we,
our
philosophy,
is
that
we
crash
the
process
instead
of
keeping
it
in
consistent,
States
all
right
so
but
I
know
how
example,
people
who
using
Express
GS
the
XS
Jas,
has
a
try-catch
in
the
middle
right,
so
synchronous
error
happens.
Then
the
xsj
s
basically
catches
that
and
doesn't
crash
and
the
promise
also
catches
errors.
So
my
feeling
is
that
maybe
in
the
new
type,
I
mean
more
modern
applications.
A
A
So
the
question
was
that
what's
the
percentage
Noah
days
or
and
application
crashes
from
programmatic
errors,
and
then
we
started
to
discuss
that
because
promises
catches
them
and
the
xpress
has
a
try-catch.
Maybe
it's
less
frequent
now
that
actually
applications
crash
is
because
the
automatic
errors,
but
for
and
I
was
just
asking.
What's
your
experience,
because
probably
you
got
the
most
involved
with
many
user
applications.
A
A
B
A
A
A
Okay,
so
we
have
three
tools
in
this
table:
I
mainly
again,
I
was
working.
What
was
in
my
head
at
Netflix,
we
use
condoms
heavily,
meaning
we
are
running
or
process
with
about
on-call
exception
and
we
have
a
ready
to
download
the
code
and
and
otherwise,
and
we
use
it
to
to
find
original
stacktrace
and
when
it's
usually
useful
than
ever
that
tampered
at
least
that's
the
most
common
use
case
when
we
need
to
use
it
I
know,
IBM
was
heavily
involved
with
the
diagnostic
report
and
Rubin
was
involved
with
error.
C
C
It
also
has
the
ability
to
Colin
to
collect
reports
on
demand,
basically
API
based
report
generation.
The
whole
idea
of
report
is
to
provide
a
snapshot
of
the
running
virtual
machine.
Looking
from
different
aspects,
the
JavaScript
heap
the
overall
native
memory,
the
versions
of
the
subsystems,
the
libuv
state,
the
lorda
shared
libraries
and
environment
variables,
and
things
like
that.
Basically,
looking
from
a
diagnostic
engineer's
perspective
and
see
what
are
the
most
useful
information,
he
would
be
interested
in
and
capture
all
those
things
in
once
in
the
readable
file
text
file.
C
That
was
the
philosophy
behind
Nord
report
when
it
was
the
integrator
into
the
core,
the
objective
slightly
changed.
No,
we
made
it
into
a
JSON
formatted
report
other
than
that,
fundamentally,
that
the
content
remains
unchanged.
The
the
philosophy
basically
is
the
same,
provide
as
much
as
useful
information
collected
in
one
shot
from
the
running
application.
C
A
B
You
know,
for
example,
if
you
you
know,
if
say
it
includes
information
about
you
limits,
and
you
know
those
are.
The
kinds
of
things
were
like.
So,
for
example,
if
you
had
a
you
limit
that
constrained
your
memory
to
be
too
low
and
that's
sending
a
person
crashes
or
if
you're
getting
an
unhandled
exception,
because
you
know
you
can't
create
a
sockets
open
a
file,
you
know
the
you
limits
can
help.
You
understand
at
a
quick
shot.
B
B
C
If
you
are
looking
at
the
plane
crashes
that
is
controlled
by
the
v8,
you
get
the
JavaScript
stack
trace,
whereas
the
one
which
is
controlled
by
the
diagnostic
report,
you
get
both
JavaScript
stack
as
well
as
the
native
stack,
of
course,
depending
on
the
use
case
and
the
specific
control
flow
point
at
which
the
crash
has
happened.
The
native
stack
can
be
of
great
value
or
of
no
value
right.
A
A
B
C
Yeah,
that
was
basically,
we
have
different
types
of
distributions
of
no
JS
binaries
and,
for
example,
in
certain
Linux
distributions.
They
have
the
option
to
bundle
the
open,
SSL
versus
linking
against
the
existing
optimism,
shared
libraries
in
the
system,
etc.
Now,
just
by
looking
at
the
node.js
version,
you
wouldn't
know
which
SSL
Bush
library
is
being
linked
against
the
executable.
In
this
particular
scenario,
the
application
was
questioning
one
of
the
SSL
teams.
C
Just
by
looking
at
the
listings
from
the
diagnostic
port,
it
was
very
evident
that
it
was
it
was
using
I
mean
it
was
supposed
to
use
the
inbuilt
library,
but
because
of
fair
overriding
mechanism.
It
was
connecting
to
a
wrong
library
and
that
led
to
wrong
offset
calculations
and
crash.
So
it
was
just
a
nope.
Once
we
have
the
diagnosis
poor.
B
A
A
A
B
B
And
you
can
also
meet
the
arrow
properties.
Now.
Are
you
always
using
ll
note
for
that?
Yes,
right
so
I
wonder
if
above
it
should
almost
be
core
dump,
/
error,
/,
ll,
node
yeah,
possibly
in
the
table,
because
it's
kind
of
like
it
doesn't
you
can't
use
it?
The
core
dump
is
very
hard
to
use.
Just
thought
it
sound.
Yes,.
A
D
Just
as
I
said
before
it
like
him
for
a
long
time
and
no
chance
did
not
print
arrows
fully
it
just
printed
to
the
stack
trace
and
the
stack
trace
contains
the
actual
stack
frames,
and
it
also
contains
the
error
message
and
and
arrow
name,
while
it
might
not
be
the
actual
name
of
the
error
class,
because
if
you
have
a
subclass
of
an
arrow,
then
it
normally
only
prints
the
native
class
name.
So
let's
say
you
have
error
of
class
foo
extends
type
error.
D
D
D
D
Think
it
was
not
a
conscious
choice.
I
think
it
was
just
historically
because
and
like
if
you
think
about
arrow
to
string.
It
is
exactly
what
it
was
before
and
that's
how
was
printed
since
I
think
the
beginning
of
no
J's
until
I
changed
it
and
to
also
include
no
wait,
I'm,
not
sure
about
all
properties.
It
might
have
printed
in
some
cases,
some
properties
that
normally
did
not,
and
now
it
definitely
does
sorry.
It
did
not
show
them
when
you
crashed.
That
was
it.
It
did
show
them
when
he
actively
locked
them.
Yeah.
E
D
D
B
D
We
might
show
like
it's
difficult
to
distinguish
all
these
properties,
because,
if
you
think
about
prototype
and
how
people
might
create
an
error,
there
are
really
lots
of
ways
how
people
do
that.
It's
not
only
about
es6
classes,
but
also
about
the
old
prototype
style
and
then,
if
they
call
have
like
a
kind
of
a
super
call
or
not,
and
so
how
you
could
detect.
These
properties
is
actually
by
going
down
the
prototype
and
then
checking
and
the
prototype
properties
and
then
removing.
D
A
B
B
A
B
D
It's
working,
so
you
can't
actively
say
that
we
do
not
want
to
track
no
warframes.
We
cannot
distinguish
that
before
getting
the
stack
frames.
What
we
can
do
is
to
hide
them
after
serializing
the
stack
frames
and
that's
what
we
are
currently
doing.
I
think
I
implemented
it
in
no
12
I'm,
not
sure
if
it's
before
to
the
secrets
in
verse
number
minor,
where
we
now
gray
out
the
note
core
frames,
but
it's
done
after
serializing
them.
D
So
we
already
collected
and
stack
frames
and
now
the
default
is
10
and,
let's
say
nine
of
those
are
note
forcings
and
only
a
single
one
is
a
user
frame,
but
maybe
it's
not
the
original
user
frame
and
in
the
worst
case
we
have
a
recursion
algorithm
in
node
core
and
it's
more
than
ten
stack
frames.
So
the
user
stack
frame
is
not
visible
anymore.
D
D
We
might
and
try
to
reduce
the
amount
of
recursive
algorithms
in
node
core
and
also
I
would
like
to
start
thinking
about.
How
can
we
reduce
note
course
that
frames
in
general
to
the
absolute
minimum,
maybe
even
have
an
like
discuss
with
DES,
be
a
team
if
it's
possible
to
distinguish
specific
frames
to
track,
don't
tract
any
pretty
much
and
or
or
not
to
count
them
towards
the
number
10
as
a
limit?
That
would
be
pretty
cool.
D
So
let's
say
you
have
the
10
stack
frame
limit
as
it
is
by
default
now,
but
we
could
tell
the
8
not
to
track
specific
frames
to
that
number
to
that
counter,
so
we
would
get
at
least
10
up
to
10
frames
from
the
user.
That
would
improve
a
couple
of
use
cases
because
you
also
have
modules,
so
it's
not
only
applying
to
node
core
in
this
case,
but
it
could
also
apply
to
node
modules
within
the
module
implement.
That
could
say
you,
I
don't
know,
could
try
skip
tracking
dos
or
something
like
that.
I.
B
E
B
B
B
So
I
mean
I,
I
would
say
you
know,
let's
say
that
that's
one
of
the
limitations
cuz,
you
know
it'd,
be
it'd,
be
good
to
have
a
here's.
What
we
have?
Here's,
the
here's,
the
use
case,
here's
what
we
we
have
today.
Here's
our
recommendations
for
how
you
do
how
you
you
know
you
basically
debug
and
then
here's
a
list
of
things
that
are
still
a
challenge
in
that
flow,
that
we
can
work
on
to
improve
yeah.
A
Okay,
I
think
it
would
be
too
ambitious
in
this
remaining
seven
minutes
to
really
go
into
user
journey.
So,
let's,
let's
try
to
focus
what
we
started.
The
use
case
have
been
kind
of
the
tools
what
we
have
today,
because
it
sounds
reasonable
for
the
people
sure,
okay,
so
we
design
week,
report
condoms
and
our
properties
and
what
the
arrow
properties
are
today
and
what
it
could
involve
in
the
future.
A
B
B
Well,
we
I
mean
we
have
support
that
for
that
and
note
as
well.
We
just
don't
have
a
lot
of
trace
points.
We
could
introduce
more
trace
points
like
that.
If
you
have
a
if
you
have
a
actual
sea
level
crash
that
can
help
in
terms
of
the
exceptions.
Sometimes
it's
a
bit
harder
because
you
know
you've
already
unwound
for
where
the,
where
the
actual
error
happened,
but
it
can
still
give
you
an
idea
of
like
what
were
you
doing
before
you
got.
B
C
Yeah,
the
trade-off
with
the
trace
option
is
on
one
hand,
it
is
very,
very
good
in
the
sense
it
penetrates
every
JavaScript
matter
and
with
trace
points,
every
C++
method,
as
well
with
the
most
useful
information.
But
on
the
other
hand,
it's
a
little
bit
less
consumable,
because
the
large
amount
of
data
it
produces
makes
Italy
usually
impossible
to
be
used
in
the
production
and,
more
importantly,
there
is
no
control
mechanism
for
us
to
be
able
to
say
start
tracing
only
when
this
method
is
kicked
in
or
start
tracing
after
this
many
hours.
D
B
B
C
C
B
A
A
A
We
want
to
recommend
to
the
people
to
do
and
how
to
do
it
and
and
the
more
interesting
conversation
which
we
kind
of
started
to
touch
when
we
were
talking
what
it
could
be,
the
arrow
property,
but
it
could
be.
The
trace
point
is
what
would
be
the
ideal
user
journey
and
the
ideal
tool.
I
think
that
that
could
be
really
interesting.
Conversation
that
why
we
have
three
different
tools
for
how
we
could
make
it
one
which
is
working
on
every
platform.
A
B
B
There's
gonna
be
like
what
do
you
need
to
do
in
advance
so
that
you're
ready
when
it
happens
and
and
that's
you
know,
part
of
what
jury
she's
put
together
there
and
if
we
can
actually
agree
on
that
and
land
it
that
smaller
piece
I
think
that's
good,
then
the
next
step
would
be
the
okay.
Now
your
application
is
crashing.
What
do
you
do
and
and
then
we
could
talk
through
and
I
my
mind
is
kind
of
the
layered
thing
of
like
hey.
B
B
Yeah
I
I
would
almost
say,
like
you
know,
if
that's
if
we
can
agree
that,
that's
a
reasonable
recommendation
for
setting
up
to
be
ready
for
crashes,
we
should
lie
on
that
and
then
you
know
we
could
add
another
document
underneath
crash,
which
is
like
the
readme
that
says.
Okay,
you
know
you
need
to
you
know
crashes.
Here's
some
of
the
you
know
could
have
a
some
here's,
some
of
the
use
cases
and
maybe
point
back
to
the
larger
document
that
says
you
know
you've
got
your
you've
got
this
situation
and
here's
the
summary.
Now.
B
What
do
you
do?
Well,
first
of
all
make
sure
that
you
know
your
setup
point
over
the
setup
document.
Second,
here's
their
here's,
the
sort
of
initial
steps
we
recommend
and
that
document
could
be
its
own
thing
and
then
it
could
have
within.
We
could
have
new
documents
that
go
in
there
that
are
like
how
to
use
diagnostic
report:
how
to
use
core
dumps
how
to
use
error
properties.
A
B
Right
and
and
I
think
we
should
like
personally,
if
we
can
break
it
up
a
little
bit
like
that,
if
we
can
land
little
pieces
like
even
if
we
just
land
like
if
the
using
core
dumps
ll
node,
if
the
initial
thing
we
land
is
simply
like
a
collection
of
links
to
articles
or
things
that
are
already
public,
that's
at
least
a
starting
point
right
and
we
could
lie
on
that.
Then
the
next
step
would
be
to
go
through
and
actually
extract
the
most
important
information
and
put
it
into
the
dock
itself
right.
B
A
B
B
A
A
I
have
to
go
and
we're
running
out
of
time
is
there
anything
that
we
should
us
now
or
I
would
recommend
that
in
two
weeks
let's
do
the
normal.
The
analytic
meeting
kind
of
with
a
little
conversation
how
to
proceed
on
this
one
and
then
the
next
one
could
be
again
a
deep
dive
on
either
continuing
this
one
or
attaching
other
topics
so
yeah,
big
sense.
Okay,
then,
thank
you,
everyone
and
wonderful
day.
All.