在Node.js程序上使用DTrace时没有函数名称
我试图根据本指南在VirtualBox中的OmniOS虚拟机上使用DTrace进行Node.js程序的CPU分析，我完全按照以下步骤设置（除了使用节点0.10.26）。
不幸的是，DTrace不给我人类可读的JS函数名称，但只是原始函数地址（据我所知），看起来像这样，并不是很有帮助：
CPU ID FUNCTION:NAME 0 66407 :tick-30s node`v8::internal::String::ComputeHashField(unibrow::CharacterStream*, int, unsigned int)+0x162 node`v8::internal::Utf8SymbolKey::Hash() [clone .part.342]+0xb9 node`v8::internal::HashTable<v8::internal::SymbolTableShape, v8::internal::HashTableKey*>::FindEntry(v8::internal::Isolate*, v8::internal::HashTableKey*)+0x20 node`v8::internal::SymbolTable::LookupKey(v8::internal::HashTableKey*, v8::internal::Object**)+0x38 node`v8::internal::SymbolTable::LookupSymbol(v8::internal::Vector<char const>, v8::internal::Object**)+0x4e node`v8::internal::Heap::LookupSymbol(v8::internal::Vector<char const>)+0x34 node`v8::internal::Factory::LookupSymbol(v8::internal::Vector<char const>)+0x34 node`v8::internal::JSProxy::CallTrap(char const*, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*)+0x76 node`v8::internal::JSProxy::GetPropertyWithHandler(v8::internal::Object*, v8::internal::String*)+0x108 node`v8::internal::Object::GetProperty(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::LookupResult*, v8::internal::Handle<v8::internal::String>, PropertyAttributes*)+0x57 node`v8::internal::LoadIC::Load(v8::internal::InlineCacheState, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::String>)+0x49d node`v8::internal::LoadIC_Miss(v8::internal::Arguments, v8::internal::Isolate*)+0xbd 0xa730a376 0x8966eee0 0x8968bb7c 0xa7321899 0xa731308a 以上是运行这些命令的结果：
dtrace -n 'profile-97/pid == 12345 && arg1/{ @[jstack(150, 8000)] = count(); } tick-30s { exit(0); }' > stacks.out gc++filt < stacks.out > demangled.out
我以前没有使用过DTrace的经验，但是从目前为止收集到的信息来看，Node的ustack帮手应该把这些地址转换成可读的名字。 当使用--with-dtrace标志（我这样做）构buildNode时，应该启用这个function，但是显然它不适用于我。
实际上， 之前已经提到过 --dest-cpu=x64问题，但是接受的答案在我的情况下并没有帮助，因为我反正使用了--dest-cpu=x64 （也试过--dest-cpu=ia32只是为了确保，但这没有任何区别）。
想想看，这要感谢在FreeBSD上关于node.js + DTrace的优秀文章。 带有DTRACE_DOF_INIT_DEBUG标志的起始节点产生了一条类似于文章中提到的消息：
dtrace DOF: DTrace ioctl failed for DOF at cd5240 in /usr/local/bin/node: Arg list too long dtrace DOF: DTrace ioctl succeeded for DOF at 1397e70 in /usr/local/bin/node
尽pipe这篇文章是关于FreeBSD的，DTrace源代码的相关部分（ dtrace_dof_copyin中的dtrace.c ）几乎是相同的（请参阅FreeBSD源代码与OmniOS源代码 ）。 因此，在我看来，Node ustack帮助程序也超出了DOFs / DTrace对象的大小限制，尽pipe在OmniOS中限制设置为8 MB ，而FreeBSD则是256 KB 。
为了validation这个假设，我尝试了与Node v0.10.5完全相同的过程，而不是v0.10.26，因为那个版本显然已经为至less3个人工作过了，而且在我的情况下也是这样。 用上述标志打印开始Node：
dtrace DOF: DTrace ioctl succeeded for DOF at cd6c88 in /usr/local/bin/node dtrace DOF: DTrace ioctl succeeded for DOF at d122c8 in /usr/local/bin/node
按照预期，JS函数名称出现在DTrace输出中。
编辑 ：节点v0.10.20是它工作的最新版本。