Extracting correct stack traces on windows

29 views
Skip to first unread message

Mark Logan

unread,
Sep 24, 2015, 2:10:40 PM9/24/15
to v8-users
Is there any way to get a correctly decoded native (i.e. not js) stack trace, on Windows, from within C++ code that is called from javascript via the v8 api?

I've noticed that stack traces captured by a crash reporter like BugSplat are bogus, and that the MSVS debugger is also incapable of decoding stacks that contain v8 frames. I assume that v8 uses cdecl, not stdcall, but I don't see why that would interfere with at least decoding return addresses correctly. However, all the stack traces I see wander off into nonsensical addresses, and never arrive back at main(), or whatever the thread entry point was.

I've attached an example from the MSVS debugger at the end of the email.

Thanks,
Mark

  iojs.dll!v8::internal::FunctionCallbackArguments::Call(void (const v8::FunctionCallbackInfo<v8::Value> &) * f) Line 34 C++
  iojs.dll!v8::internal::HandleApiCallHelper<0>(v8::internal::Isolate * isolate, v8::internal::`anonymous-namespace'::BuiltinArguments<1> & args) Line 1111 C++
  iojs.dll!v8::internal::Builtin_HandleApiCall(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 1128 C++
  000002300e9060bf() Unknown
  iojs.dll!v8::internal::Builtin_HandleApiCall(int args_length, v8::internal::Object * * args_object, v8::internal::Isolate * isolate) Line 1128 C++
  000002300e9196f5() Unknown
  000000a64644ed68() Unknown
  00000319801a4019() Unknown
  000000bcd6a695d9() Unknown
  000002300e933a50() Unknown
  000003198019b831() Unknown
  000002300e906001() Unknown
  000000a64644ed20() Unknown
  000000a64644edc8() Unknown
  000002300ecaa7b5() Unknown
  000003198019b831() Unknown
  0000037fd67299b9() Unknown
  000002d3013fdec1() Unknown
  000003198019b831() Unknown
  000000bcd6a695d9() Unknown
  00000319801a43c9() Unknown
  0000037fd67286a1() Unknown
  0000031980104131() Unknown
  0000037fd66d9dd1() Unknown
  0000037fd66d7b19() Unknown
  000000a64644ee20() Unknown
  000002300eaebfa6() Unknown
  0000037fd67086e1() Unknown
  0000037fd67274d9() Unknown
  0000031980104111() Unknown
  0000031980104131() Unknown
  0000037fd66d9dd1() Unknown
  0000031980104131() Unknown
  0000037fd67274d9() Unknown
  0000037fd6708a49() Unknown
  0000037fd6708719() Unknown
  000000a64644ee68() Unknown
  000002300eabda57() Unknown
  0000037fd6706ab1() Unknown
  000003198018c559() Unknown
  0000000100000000() Unknown
  0000037fd6727281() Unknown
  0000000200000000() Unknown
  000000bcd6ae8181() Unknown
  000000bcd6a70139() Unknown
  000000a64644ef18() Unknown
  000002300e98018c() Unknown
  0000037fd6706ab1() Unknown
  00000319801043a1() Unknown
  0000037fd6708ab1() Unknown
  0000031980104131() Unknown
  000000bcd6ae8181() Unknown
  000001fe3fe73271() Unknown
  00000319801043a1() Unknown
  0000031980104131() Unknown
  00000319801043a1() Unknown
  00000319801043a1() Unknown
  0000031980104111() Unknown
  0000037fd6706da1() Unknown
  0000031980104131() Unknown
  0000031980104131() Unknown
  0000000100000000() Unknown
  0000037fd6708ab1() Unknown
  0000031980104131() Unknown
  0000037fd6727249() Unknown
  000001fe3fe73271() Unknown
  000000bcd6a70139() Unknown
  000000a64644ef50() Unknown
  000002300eadc1f0() Unknown
  000003198017ae89() Unknown
  0000037fd6706ab1() Unknown
  000001fe3fe73271() Unknown
  000000bcd6aec989() Unknown
  000000bcd6ab1639() Unknown
  000000a64644efa0() Unknown
  000002300eab4318() Unknown
  0000037fd6706ab1() Unknown
  0000037fd6706c91() Unknown
  0000031980104131() Unknown
  000000bcd6aec989() Unknown
  000000bcd6aceb51() Unknown
  0000031980104361() Unknown
  000000bcd6af2bf1() Unknown
  000000bcd6aceb51() Unknown
  000000a64644f000() Unknown
  000002300ea88119() Unknown
  0000037fd6706ab1() Unknown
  0000037fd6706c91() Unknown
  000000bcd6aec989() Unknown
  0000031980104131() Unknown
  000000bcd6af2bf1() Unknown
  0000037fd6727161() Unknown
  0000037fd6727099() Unknown
  000000bcd6aec989() Unknown
  000000bcd6a6a721() Unknown
  000000bcd6aceb51() Unknown
  000000a64644f038() Unknown
  000002300e919f23() Unknown
  00000319801a43c9() Unknown
  000000bcd6a6a721() Unknown
  000002300e919e21() Unknown
  0000000800000000() Unknown

Ben Noordhuis

unread,
Sep 25, 2015, 7:26:34 AM9/25/15
to v8-u...@googlegroups.com
The machine code that V8 generates uses a custom calling convention
that's neither cdecl nor stdcall. I'm not aware of any tooling (that
works on Windows) that knows how to decode the stack trace.

Mark Logan

unread,
Sep 25, 2015, 5:25:51 PM9/25/15
to v8-users


On Friday, September 25, 2015 at 4:26:34 AM UTC-7, Ben Noordhuis wrote:

The machine code that V8 generates uses a custom calling convention
that's neither cdecl nor stdcall.  I'm not aware of any tooling (that
works on Windows) that knows how to decode the stack trace.

Is the calling convention just similar enough to cdecl that stack traces on OS X / Linux work by chance? I've never had a problem with gdb/lldb.

Ben Noordhuis

unread,
Sep 26, 2015, 6:10:47 AM9/26/15
to v8-u...@googlegroups.com
On UNIX platforms, you can build with `make gdbjit=on` to get
human-readable stack traces in gdb and lldb (although lldb's JIT
support was a little broken last I checked.)

Without gdbjit though, if you got a stack trace that goes all the way
back to main(), you got lucky.
Reply all
Reply to author
Forward
0 new messages