Any build flag to maintain regular v8 stack trace?

[Jane Chen]

Embedding v8.  Currently on 4.6.88, and in the process of upgrading to 5.3.lkgr.

When I do a pstack of my program embedding v8, some of the v8 frames show up as ???.  I wonder whether there's a build flag I could use to enable the full stack trace of v8 frames. 

Please advise. 

Thanks.

[Ben Noordhuis]

If your pstack is a wrapper around gdb, compile V8 with
v8_enable_gdbjit set to 1 (`make native gdbjit=on`) and it should be
able to decode JS stack frames.

[Jane Chen]

Thanks Ben for the tip.

I tried building with:

make -j24 x64.debug werror=no GYPFLAGS="-Dv8_use_external_startup_data=0 -Dcomponent=shared_library -Dv8_enable_gdbjit=1"

In my gdb-backed debugger, I still got:

28 xdmp::constructType() /space/projects/head/xdmp/src/JSEngine.cpp:2875 0x00000000038c92f3   
27 v8::internal::FunctionCallbackArguments::Call() /space/projects/v8-git/v8/src/api-arguments.cc:19 0x00007ffff549cef9   
26 v8::internal::(anonymous namespace)::HandleApiCallHelper<false>() /space/projects/v8-git/v8/src/builtins.cc:5311 0x00007ffff5521150   
25 v8::internal::Builtin_Impl_HandleApiCall() /space/projects/v8-git/v8/src/builtins.cc:5341 0x00007ffff5569d92   
24 v8::internal::Builtin_HandleApiCall() /space/projects/v8-git/v8/src/builtins.cc:5329 0x00007ffff5524c1d   
23 <symbol is not available> 0x000007bc4d206147   
22 <symbol is not available> 0x000007bc4d206081   
21 <symbol is not available> 0x00007ffad9a72d90   
20 <symbol is not available> 0x0000000300000000   
19 <symbol is not available> 0x00007ffad9a72df8   
18 <symbol is not available> 0x000007bc4d269ead   
17 <symbol is not available> 0x00003481b3104399   
16 <symbol is not available> 0x000019063552bb29   
15 <symbol is not available> 0x00003481b31cdd49   
14 <symbol is not available> 0x00003308b9f1c831   
13 <symbol is not available> 0x000019063552bb29   
12 <symbol is not available> 0x00003481b3104399   
11 <symbol is not available> 0x0000190635529f49   
10 <symbol is not available> 0x0000190635504201   
9 <symbol is not available> 0x00007ffad9a72e28   
8 <symbol is not available> 0x000007bc4d242403   
7 <symbol is not available> 0x00003308b9f11869   
6 <symbol is not available> 0x0000190635529f49   
5 <symbol is not available> 0x000007bc4d242321   
4 <symbol is not available> 0x0000000c00000000   
3 <symbol is not available> 0x00007ffad9a72e90   
2 <symbol is not available> 0x000007bc4d225a6f   
1 <symbol is not available> 0x0000000000000000   

What could I be missing?

[Ben Noordhuis]

Mea culpa, Jane, I forgot to mention that you need to pass --gdbjit
(and optionally --gdbjit_full) to V8.

[Jane Chen]

Thanks, Ben!

I added that flag to my v8 init code.  Now I get:

12 xdmp::JSEngine::evalBuiltin() /space/projects/head/xdmp/src/JSEngine.cpp:11794 0x000000000391466e   
11 xdmp::JSEngine::evalBuiltin() /space/projects/head/xdmp/src/JSEngine.cpp:11766 0x00000000039141ec   
10 v8::internal::FunctionCallbackArguments::Call() /space/projects/v8-git/v8/src/api-arguments.cc:19 0x00007ffff549cef9   
9 v8::internal::(anonymous namespace)::HandleApiCallHelper<false>() /space/projects/v8-git/v8/src/builtins.cc:5311 0x00007ffff5521150   
8 v8::internal::Builtin_Impl_HandleApiCall() /space/projects/v8-git/v8/src/builtins.cc:5341 0x00007ffff5569d92   
7 v8::internal::Builtin_HandleApiCall() /space/projects/v8-git/v8/src/builtins.cc:5329 0x00007ffff5524c1d   
6 <symbol is not available> 0x0000332193c06147   
5 <symbol is not available> 0x0000332193c06081   
4 <symbol is not available> 0x00007ffad924d2a0   
3 <symbol is not available> 0x0000000300000000   
2 <symbol is not available> 0x00007ffad924d308   
1 LazyCompile:~isPrime :1()  0x0000332193c6b884   

I suppose that's as good as it gets, right?  Any performance penalties to leave it on always?

[Ben Noordhuis]

On Sat, Sep 24, 2016 at 2:40 AM, Jane Chen <jxch...@gmail.com> wrote:
> Thanks, Ben!
>
> I added that flag to my v8 init code. Now I get:
>
> 12 xdmp::JSEngine::evalBuiltin()
> /space/projects/head/xdmp/src/JSEngine.cpp:11794 0x000000000391466e
> 11 xdmp::JSEngine::evalBuiltin()
> /space/projects/head/xdmp/src/JSEngine.cpp:11766 0x00000000039141ec
> 10 v8::internal::FunctionCallbackArguments::Call()
> /space/projects/v8-git/v8/src/api-arguments.cc:19 0x00007ffff549cef9
> 9 v8::internal::(anonymous namespace)::HandleApiCallHelper<false>()
> /space/projects/v8-git/v8/src/builtins.cc:5311 0x00007ffff5521150
> 8 v8::internal::Builtin_Impl_HandleApiCall()
> /space/projects/v8-git/v8/src/builtins.cc:5341 0x00007ffff5569d92
> 7 v8::internal::Builtin_HandleApiCall()
> /space/projects/v8-git/v8/src/builtins.cc:5329 0x00007ffff5524c1d
> 6 <symbol is not available> 0x0000332193c06147
> 5 <symbol is not available> 0x0000332193c06081
> 4 <symbol is not available> 0x00007ffad924d2a0
> 3 <symbol is not available> 0x0000000300000000
> 2 <symbol is not available> 0x00007ffad924d308
> 1 LazyCompile:~isPrime :1() 0x0000332193c6b884
>
> I suppose that's as good as it gets, right? Any performance penalties to
> leave it on always?

I suppose so; does --gdb_jit_full make a difference? As to performance:

1. --gdb_jit implies --nocompact_code_space so the code space (where
generated machine code is stored) may get fragmented over time. I
have never observed that to be a problem in practice, though, even in
long-running programs.

2. There is some bookkeeping involved but it's not huge. Your
application may run a few percent slower, depending on what it does.

[Jane Chen]

It does.  --gdbjit_full gives me the complete stack.  Thanks again!