Joyee Cheung

@targos hmm, wait, remind me again why we don't use the merge button? (provided that one updates the commit message properly?)

oh, right, the merge queue feature of GitHub currently only makes sure that stuff are checked. We need some automation to edit the commit messages also - unless we ask...

@vietkute02 Can you do something like: ``` (lldb) log enable lldb process thread (lldb) target create --core ``` That should print out the stacktrace of lldb. I have bumped into...

@vietkute02 BTW [these](https://github.com/llvm-mirror/lldb/blob/82db09b4ecc2870cf5a226d3415be472eda5f831/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1554) are the comments explaining why lldb can not identify the OS from the coredumps. You can use `readelf -hn ` to see if your coredump has `EI_OSABI`...

@vietkute02 That looks like a different problem (not a segmentation fault but a hang). For that please try @rnchamberlain's solution, and see if it works with lldb 4.0.

By the way I implemented MAT's algorithm on V8 heap snapshots in JavaScript: https://github.com/joyeecheung/v8-mat The algorithm probably does not work on core dump (or heap snapshots converted from core dumps)...

Having an `v8 version` should be enough, `--version` of the `llnode` may just redirect the output to stdout somehow.

Technically we could read package.json in the configuration scripts and compile the version numbers into the plugin...otherwise if we maintain something in the source code we could forget about updating...

Maybe we should just remove that recommendation (AFAIK it still works if you specify llvm@6? But using that doesn't look like a good idea). I am using the Xcode lldb...

> I think JavaScript developers will expect getProcessObject to return Node.js' process object for the core dump Is it even possible to recreate that? process is fairly complex with lots...