src: print stack for error objects #233

mmarchini · 2018-09-20T13:27:06Z

Error objects have a .stack property, which is actually an accessor. The
stack is stored in a unnamed symbol property and converted to a string
when .stack is accessed in JavaScript. This patch implements the
accessor behavior to print the error stack when inspecting an Error
object.

Fixes: #218

mmarchini · 2018-09-26T14:38:21Z

Jenkins CI: https://ci.nodejs.org/view/post-mortem/job/llnode-pipeline/31/

(first try, let's see how it goes)

Error objects have a .stack property, which is actually an accessor. The stack is stored in a unnamed symbol property and converted to a string when .stack is accessed in JavaScript. This patch implements the accessor behavior to print the error stack when inspecting an Error object. Fixes: nodejs#218

mmarchini · 2018-11-09T17:13:30Z

@cjihrig thank you for your review! I addressed your comments, PTAL.

joyeecheung

Looks like the test is happy enough, so LGTM. Personally I'd prefer we use constant names instead of magic numbers, but that can be refactored later

joyeecheung · 2018-11-09T17:15:22Z

src/llv8.cc

+
+    int64_t stack_len = Smi(maybe_stack_len).GetValue();
+
+    int multiplier = 5;


Maybe it would be more maintainable if FrameArray::kElementsPerFrame is exposed in the post mortem metadata and gets loaded here..(not sure if that's on 6.x but it's still in TOT)

Yes, I have this on my TODO list and will probably get to that at some point.

joyeecheung · 2018-11-09T17:17:07Z

src/llv8.cc

+    // TODO (mmarchini): Refactor: create an StackIterator which returns
+    // StackFrame objects
+    for (int64_t i = 0; i < stack_len; i++) {
+      Value maybe_fn = arr.GetArrayElement(2 + (i * multiplier), err);


So this is actually kFirstIndex + i * kElementsPerFrame + kFunctionOffset right?

Error objects have a .stack property, which is actually an accessor. The stack is stored in a unnamed symbol property and converted to a string when .stack is accessed in JavaScript. This patch implements the accessor behavior to print the error stack when inspecting an Error object. Fixes: #218 PR-URL: #233 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>

mmarchini · 2018-11-09T17:46:24Z

Landed in bb0d400

misterdjules · 2018-11-29T17:29:51Z

@mmarchini Did this make it into a release? If not would that be possible to release a version of llnode that includes this?

mmarchini · 2018-11-29T18:30:37Z

Yes, I'll prepare a release today, which should be released in the next few days :)

(Want to make sure we have a new release before #246 lands)

misterdjules · 2018-11-29T23:41:29Z

@mmarchini I was inspecting a core dump generated from node 6.x and I was trying to get the actual stack trace for the error, and when trying to get the full stack trace with `v8 inspect -l length-of-stack-array' I constantly get a segmentation fault:

$ lldb ~/Downloads/node-v6.10.3-linux-x64/bin/node -c /path/to/core/dump
(lldb) target create "/Users/jgilli/Downloads/node-v6.10.3-linux-x64/bin/node" --core "/path/to/core/dump"
Core file '/path/to/core/dump' (x86_64) was loaded.
(lldb) plugin load /Users/jgilli/dev/llnode/llnode.dylib
(lldb) v8 bt
 * thread #1: tid = 1024, 0x0000000001334fa9 node`v8::base::OS::Abort() + 9, name = 'node', stop reason = signal SIGILL
  * frame #0: 0x0000000001334fa9 node`v8::base::OS::Abort() + 9
    frame #1: 0x0000000000d5241a node`v8::internal::Isolate::Throw(v8::internal::Object*, v8::internal::MessageLocation*) + 490
    frame #2: 0x0000000000eb4e33 node`v8::internal::Runtime_Throw(int, v8::internal::Object**, v8::internal::Isolate*) + 307
    frame #3: 0x000035e3c31092a7 <exit>
    frame #4: 0x000035e3c58ec96b throwError(this=0x2ad297b2fc41:<Object: Immediate>, 0x2ad297b2f569:<Object: TypeError>) 
[...redacted to hide private info...]
(lldb) v8 inspect 0x2ad297b2f569
0x2ad297b2f569:<Object: TypeError properties {
    .stack=0x2ad297b2f981:<Array: length=45>,
    .<non-string>=0x2ad297b2f981:<Array: length=45>,
    .message=0x2ad297b2f541:<String: "Cannot match aga...">,
    .<non-string>=0x2725531043c1:<true>}>
(lldb) v8 inspect 0x2ad297b2f981
0x2ad297b2f981:<Array: length=45 {
[...redacted to hide private info...]
}>
(lldb) v8 inspect -l 44 0x2ad297b2f981
Segmentation fault: 11
$

Am I missing something?

EDIT: I'm running llnode from latest master:

$ git rev-parse --short HEAD
bb0d400
$

mmarchini · 2018-11-29T23:53:14Z

Seems like a separate issue. v8 inspect -l 44 0x2ad297b2f981 is inspecting an Array unaware it might be a stack trace, so it's not - or at least shouldn't be - related to changes on this PR.

This is not the first segfault I see in llnode (#196), we probably have some fragile code paths somewhere. Do you mind opening a new issue for this? Also, it would be nice to get llnode's stack trace right before it segfaulted. I haven't tried it, but it seems to be possible with dtrace: https://stackoverflow.com/a/17115382/2956796.

misterdjules · 2018-11-30T00:18:58Z

@mmarchini How are users supposed to inspect the stack trace? v8 inspect address-of-stack-property doesn't seem to output the full stack.

mmarchini · 2018-11-30T00:26:10Z

v8 inspect 0x2ad297b2f569 (the Error object) should give you the stack trace.

Ohhh I see, this is a TypeError. Ok, we'll need to handle this differently in Node.js v6.x.
Will do a follow-up PR for that.

mmarchini · 2018-11-30T00:29:34Z

FWIW, it's working as expected on Node.js v10.13.0

(llnode) v8 findjsinstances -d TypeError
0x17febe244e11:<Object: TypeError properties {
    .stack=0x17feba59f0d9:<unknown>,
    .<non-string>=0x17febe244fd1:<Array: length=41>}
  error stack {
    0x17fe6794dd81:<function: (anonymous) at [eval]:1:0>
    0x17febe210d61:<function: runInThisContext at vm.js:91:19>
    0x17febe210c71:<function: runInThisContext at vm.js:299:26>
    0x17febe244791:<function: (anonymous) at [eval]-wrapper:1:10>
    0x17fe27675eb9:<function: Module._compile at (external).js:649:37>
    0x17fe6791fae9:<function: evalScript at internal/bootstrap/node.js:1:10>
    0x17fec0b985a9:<function: startup at internal/bootstrap/node.js:1:10>
    0x17fec0b987e1:<function: bootstrapNodeJSCore at internal/bootstrap/node.js:1:10>
  }>
(Showing 1 to 1 of 1 instances)

(edit: and I'm also getting segfault with v6.x)

joyeecheung · 2018-11-30T02:07:30Z

Tips: you can turn on the environment variable LLNODE_DEBUG=true to see some debug output from llnode. Also running log enable lldb api in the lldb console would tell lldb to log all the API calls which may help as well (if you don't want to debug into the plugin, that'll be debugging the debugger)

mmarchini · 2018-11-30T02:20:52Z

if you don't want to debug into the plugin, that'll be debugging the debugger

I just did it 😂

Tip: to attach a debugger to the debugger, run the debugger you'll use to attach as root.

mmarchini force-pushed the js-error-stack branch from 5ed2051 to 2db870f Compare October 5, 2018 20:04

This comment was marked as off-topic.

Sign in to view

fixup! src: print stack for error objects

9895bf3

joyeecheung approved these changes Nov 9, 2018

View reviewed changes

cjihrig approved these changes Nov 9, 2018

View reviewed changes

mmarchini closed this Nov 9, 2018

mmarchini mentioned this pull request Nov 30, 2018

Error stack inspection is broken on v6.x for most scenarios #250

Closed


		int64_t stack_len = Smi(maybe_stack_len).GetValue();

		int multiplier = 5;

Uh oh!

src: print stack for error objects #233

src: print stack for error objects #233

Uh oh!

Conversation

mmarchini commented Sep 20, 2018

Uh oh!

mmarchini commented Sep 26, 2018

Uh oh!

This comment was marked as off-topic.

Uh oh!

mmarchini commented Nov 9, 2018

Uh oh!

joyeecheung left a comment

Choose a reason for hiding this comment

Uh oh!

joyeecheung Nov 9, 2018

Choose a reason for hiding this comment

Uh oh!

mmarchini Nov 9, 2018

Choose a reason for hiding this comment

Uh oh!

joyeecheung Nov 9, 2018

Choose a reason for hiding this comment

Uh oh!

mmarchini commented Nov 9, 2018

Uh oh!

misterdjules commented Nov 29, 2018

Uh oh!

mmarchini commented Nov 29, 2018

Uh oh!

misterdjules commented Nov 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mmarchini commented Nov 29, 2018

Uh oh!

misterdjules commented Nov 30, 2018

Uh oh!

mmarchini commented Nov 30, 2018

Uh oh!

mmarchini commented Nov 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joyeecheung commented Nov 30, 2018

Uh oh!

mmarchini commented Nov 30, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

misterdjules commented Nov 29, 2018 •

edited

Loading

mmarchini commented Nov 30, 2018 •

edited

Loading