Next WG meeting

[mhdawson]

Who

@nodejs/post-mortem

When

Monday July 18 @ 1PM EST

Where

link for participants: https://hangouts.google.com/hangouts/_/hoaevent/AP36tYeTwlUDOCqCcMnsqsIEJNVVXwWU8gcmM7G6naw1FvKM75xdfA?eid=100598160817214911030&hl=en&authuser=0

For those who just want to watch: http://www.youtube.com/watch?v=HIh7kQUifuU

Events page: https://plus.google.com/events/c3vdk1rqvktttf8ii6gcqnm47r4

Google doc for minutes:https://docs.google.com/document/d/18KwWzGTNDL3UczAWjYEsm0zY75Z_JaaQKGdd2df-_f4/edit

Agenda

• Stand up
• Actions from last meeting
• Where to put code we are collaborating on Repositories to contribute collaboratively #30
• Javascript API to support common extensions between MDB/lldb/IDDE
• NodeReport as module bundled into Node ?
• Open issues review

[mhdawson]

@nodejs/post-mortem please see http://doodle.com/poll/z862anr4c7unti3a

[mhdawson]

@node/post-mortem - just a reminder to fill out doodle for next meeting http://doodle.com/poll/z862anr4c7unti3a

[jclulow]

Before we agree to meet, can you link to some initial documentation about each of the items of new business so that we have some context? For example: what does "Javascript API to support common extensions between MDB/lldb/IDDE" mean?

[rnchamberlain]

@jclulow @mhdawson the (tentative) proposal for a Javascript API on top of the llnode/lldb libraries is here: https://github.com/indutny/llnode/issues/14

[mhdawson]

NodeReport as module bundled into Node - relates to nodejs/node#7242, just wanted to get input from this group if once the module was available if its something that would make sense to be be bundled into the shipping binaries.

[mhdawson]

@nodejs/post-mortem added date of meeting (Tuesday July 5 1PM EST) and hangout links etc.

[rnchamberlain]

Here's an architecture picture for the Javascript API topic:

moved to separate issue #33

[rnchamberlain]

And a screenshot of how it could be used

moved to separate issue #33

[indutny]

@rnchamberlain unrelated question, but does this mean that llnode works on windows? 😄

[indutny]

@rnchamberlain nvm, overlooked /lib/x86_64-linux-gnu

[mhdawson]

We did not get enough people to the meeting so another doodle poll to try and reschedule:

http://doodle.com/poll/u72rsge569srafy8

@nodejs/post-mortem please fill new available in new doodle poll.

[misterdjules]

I'm too busy to be able to commit to a date and time, so I might join the meeting if I can, but I won't add myself to the latest doodle. In general, it seems that most of the items on the agenda for this meeting could be discussed at least initially by filing new issues on GitHub in nodejs/post-mortem, and that a call would not be necessary unless consensus would not emerge easily from these.

[davepacheco]

I'm very sorry I wasn't able to make the call this morning. I had an urgent item come up (as the meeting was starting, actually). I've updated my availability in the Doodle, though if we're able to hash the items out over GitHub that works too.

[rnchamberlain]

Quick update on the core-dump analysis/llnode topic:

1. The LLDB API enhancement from @hhellyer to provide a memory region iterator has landed:
   http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20160620/030109.html
   Once the supporting platform core-reader code goes in this will enable llnode findjsobjects without
   the current readelf workaround.
2. We'll be looking at extending that to include Windows core-dumps.
3. Raised before, we should really try to share code or libraries between mdb_v8 and llnode if possible.
   Both use the same V8 post-mortem metadata. Maybe the Javascript API is a way to do that.

[misterdjules]

@rnchamberlain

Raised before, we should really try to share code or libraries between mdb_v8 and llnode if possible. Both use the same V8 post-mortem metadata. Maybe the Javascript API is a way to do that.

Can you create a separate issue in nodejs/post-mortem that describes with as much details as possible what you have in mind?

[mhdawson]

@nodejs/post-mortem new time set as Monday July 18 at 1PM EST.

[rnchamberlain]

@misterdjules
The question of re-using mdb_v8 code in a Linux solution for core dump analysis came up again here. It has been discussed by the WG before, see: #17

So I took another look at mdb_v8 vs llnode code. Here's an example, the code to identify an adaptor frame, in mdb_v8 and llnode respectively:

if (mdb_vread(&ftype, sizeof (ftype), fptr + V8_OFF_FP_CONTEXT) != -1 &&
V8_IS_SMI(ftype) && (ftypename = enum_lookup_str(v8_frametypes, V8_SMI_VALUE(ftype),
NULL)) != NULL && strstr(ftypename, "ArgumentsAdaptor") != NULL) {
if (prop != NULL) return (0);
if (jsf->jsf_showall) {
jsframe_print_skipped(jsf);
mdb_printf("%p %a <%s>\n", fptr, raddr, ftypename);

std::string JSFrame::Inspect(bool with_args, Error& err) {
Value context = v8()->LoadValue<Value>(raw() + v8()->frame()->kContextOffset, err);
if (err.Fail()) return std::string();
Smi smi_context = Smi(context);
if (smi_context.Check() && smi_context.GetValue() == v8()->frame()->kAdaptorFrame) {
return "<adaptor>";
}

The logic and the use of the post-mortem metadata is the same, but the implementation is quite different (C vs C++, use of mdb_ vs SB APIs etc). Given that the V8 metadata and the logic needed does not actually change very often, and there are only 2 implementations, my conclusion is that it is not worth trying to unify/share this code.

The other re-use possibility I was looking at was a common Javascript API built on llnode (and on mdb_v8). Then higher-level commands (eg like 'jsclosure') could be built that would work on either mdb or lldb. The lldb SB API is well suited to this, you can build a native library that uses lldb::SBDebugger::Initialize(), CreateTargetWithFileAndArch("/usr/bin/node",..) then LoadCore(filename) to read the core dump, then support the Javascript API. However, I think the mdb_ API is designed purely for developing plugins to run within the debugger. I saw that https://www.npmjs.com/package/corevis has built on mdb_v8, but it drives the debugger from a script, in a single run.

So in summary, 2 solutions based on common v8 metadata. I don't see a way around that, given that we need the functionality that the different platform debuggers provide to read the core dumps, walk native stacks, find symbols etc. Not a disaster.

[misterdjules]

@rnchamberlain Do you mind creating separate issues for topics you want to discuss with the rest of the group? Adding questions about various topics to this issue, which is about scheduling a meeting, is confusing.

In your latest comment, I don't see any question or any mention of what precisely you'd like to get feedback on. Would you mind clarifying that (but not in this issue, in separate issues)?

[rnchamberlain]

@misterdjules OK, I have moved the main topic for discussion/feedback (the Javascript API) here: #33

[misterdjules]

@rnchamberlain Thank you!

[mhdawson]

PR for minutes #34 @nodejs/post-mortem please review.

[mhdawson]

Minutes landed closing this.