Not showing details of JS frames on node v16.14.0

[randy5235]

Hey all, it looks like something has broken ( I am assuming a v8 update perhaps?) in node v16.14.0

Running on Monterey v12.2.1

Using node v12 or node v14, I can attach to a process and get JS frame details and v8 nodeinfo

On v16 (same code.. (test code does nothing but creates a large number of objects and arrays in memory) I can attach and it will break, but v8 bt returns the same thing as regular bt and v8 nodeinfo says No Process to attach to

Happy to provide any more info.

[RumenStoev]

I have the same problem! I installed Node v14.19.1 and Node v16 I can't read v8 JS frames. (Ubuntu 20.04.3 LTS)

After I come back to Node v12.22.11 I can ,but when I write the command v8 inspect --print-source terminal show me that:

(llnode) v8 inspect --print-source 0x000014537e9a4181
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr: __pos (which is 7575) > this->size() (which is 10)
Stack dump:
0.      Program arguments: /usr/bin/lldb --one-line plugin load '/home/oem/Node/llnode/llnode.so' --one-line settings set prompt '(llnode) ' -c ../core 
1.      HandleCommand(command = "v8 inspect --print-source 0x000014537e9a4181")
 #0 0x00007fe5003a74ff llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x9814ff)
 #1 0x00007fe5003a57b0 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x97f7b0)
 #2 0x00007fe5003a7ac5 (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x981ac5)
 #3 0x00007fe5079fa3c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x143c0)
 #4 0x00007fe4ff52903b raise /build/glibc-sMfBJT/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x00007fe4ff508859 abort /build/glibc-sMfBJT/glibc-2.31/stdlib/abort.c:81:7
 #6 0x00007fe4ff8e2911 (/lib/x86_64-linux-gnu/libstdc++.so.6+0x9e911)
 #7 0x00007fe4ff8ee38c (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaa38c)
 #8 0x00007fe4ff8ee3f7 (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaa3f7)
 #9 0x00007fe4ff8ee6a9 (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaa6a9)
#10 0x00007fe4ff8e53ab (/lib/x86_64-linux-gnu/libstdc++.so.6+0xa13ab)
#11 0x00007fe4ff989f48 (/lib/x86_64-linux-gnu/libstdc++.so.6+0x145f48)
#12 0x00007fe4fee10562 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const /usr/include/c++/9/bits/basic_string.h:226:26
#13 0x00007fe4fee10562 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/9/bits/basic_string.h:559:2
#14 0x00007fe4fee10562 llnode::v8::JSFunction::GetSource[abi:cxx11](llnode::Error&) /home/oem/Node/llnode/build/../src/llv8.cc:367:10
#15 0x00007fe4fee3b769 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > llnode::Printer::Stringify<llnode::v8::JSFunction, llnode::v8::JSFunction>(llnode::v8::JSFunction, llnode::Error&) /home/oem/Node/llnode/build/../src/printer.cc:120:7
#16 0x00007fe4fee37bfc std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > llnode::Printer::Stringify<llnode::v8::HeapObject, llnode::v8::HeapObject>(llnode::v8::HeapObject, llnode::Error&) /home/oem/Node/llnode/build/../src/printer.cc:726:27
#17 0x00007fe4fee3805c std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > llnode::Printer::Stringify<llnode::v8::Value, llnode::v8::Value>(llnode::v8::Value, llnode::Error&) /home/oem/Node/llnode/build/../src/printer.cc:784:28
#18 0x00007fe4fee045a1 llnode::PrintCmd::DoExecute(lldb::SBDebugger, char**, lldb::SBCommandReturnObject&) (.part.0) /home/oem/Node/llnode/build/../src/llnode.cc:208:3
#19 0x00007fe506d70c54 (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x20ec54)
#20 0x00007fe5070d4027 (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x572027)
#21 0x00007fe5070cb91b (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x56991b)
#22 0x00007fe5070cec70 (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x56cc70)
#23 0x00007fe50702f956 (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x4cd956)
#24 0x00007fe50701483f (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x4b283f)
#25 0x00007fe5070cf846 (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x56d846)
#26 0x00007fe506da0b14 lldb::SBDebugger::RunCommandInterpreter(bool, bool) (/lib/x86_64-linux-gnu/liblldb-10.so.1+0x23eb14)
#27 0x00000000004068cd (/usr/bin/lldb+0x4068cd)
#28 0x0000000000407e2a (/usr/bin/lldb+0x407e2a)
#29 0x00007fe4ff50a0b3 __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:342:3
#30 0x0000000000403dfe (/usr/bin/lldb+0x403dfe)

Someone can help me with that?
Up to which version llnode works normal?

Thank's

[kriddile]

Same problem.

[steinwang13]

Same here.
Ubuntu 18.04
node 10.24.1
lldb 8.0.0
Could this be another compatibility issue due to different versions of the tools? Also, will difference between node versions where llnode is installed and where the core dump is generated cause the issue?

[lsycxyj]

Is this repo still active? It's been 2 years since last release.

[kvakil]

It looks like the current backtrace support is broken because it assumes
ScopeInfo can be treated as a FixedArray (for example here),
which was broken by 2733037. It was probably busted prior to that too.

This patch gets you a little better output (it fixes the function
names), but the other things still need to be patched:

diff --git a/src/llv8-inl.h b/src/llv8-inl.h
index f32fdf0..1bbecf2 100644
--- a/src/llv8-inl.h
+++ b/src/llv8-inl.h
@@ -1128,20 +1128,12 @@ inline String ScopeInfo::ContextLocalName(int index, Error& err) {
 }
 
 inline HeapObject ScopeInfo::MaybeFunctionName(Error& err) {
-  int proper_index = ContextLocalIndex(err);
-  if (err.Fail()) return HeapObject();
-
-  Smi context_local_count = ContextLocalCount(err);
-  if (err.Fail()) return HeapObject();
-  proper_index += context_local_count.GetValue() * 2;
-
   // NOTE(mmarchini): FunctionName can be stored either in the first, second or
   // third slot after ContextLocalCount. Since there are missing postmortem
   // metadata to determine in which slot its being stored for the present
   // ScopeInfo, we try to find it heuristically.
-  int tries = 3;
   HeapObject likely_function_name;
-  while (tries > 0 && proper_index < Length(err).GetValue()) {
+  for (int proper_index = -2; proper_index < 10; proper_index++) {
     err = Error();
 
     HeapObject maybe_function_name =
diff --git a/src/llv8.cc b/src/llv8.cc
index c3a331a..ecc78b5 100644
--- a/src/llv8.cc
+++ b/src/llv8.cc
@@ -300,10 +300,11 @@ std::string JSFunction::GetDebugLine(std::string args, Error& err) {
 
   res += " at ";
 
-  res += Info(err).GetPostfix(err);
-  if (err.Fail()) return std::string();
-
   return res;
+  // res += Info(err).GetPostfix(err);
+  // if (err.Fail()) return std::string();
+
+  // return res;
 }

The current definition of ScopeInfo is here in Torque.

[No9]

OK Thanks to everyone contributing to this issue.
I'm closing this as we have landed the changes to support 16 and 18 in v4.0.0 and we have an unmaintained build v3.3.0 to support earlier versions of node but with later versions of LLDB.
If there are any further questions please open another issue.