这个数字是bigarr! 的大小，即NUM_SPREAD_ARGS sizeof(a)。为了查看JITed代码，我们可以设置JSC_dumpDFGDisassembly环境变量，这样jsc就可以跳转到DFG和FTL的编译代码了。
ZDIs-Mac:webkit_ga_asan zdi$ JSC_dumpDFGDisassembly=true lldb -s lldb_cmds.txt WebKitBuild/Release/jsc ~/poc3.js
这将丢弃掉大量无关的代码集，那我们应该如何确定相关代码呢？
我们知道崩溃事件发生在0x6400042d1d29处：mov qword ptr [rcx 8rsi], r8。那我们为何不尝试搜索这个地址呢？
没错，我们在DFG中找到了：
代码在使用DFG JIT的分布操作符来创建一个新数组时，调用了NewArrayWithSpread方法，整个行为发生在gen_func生成的一个函数f中，调用行为发生在一个循环中。
在对源代码进行分析后，我们发现了Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp文件中的SpeculativeJIT::compileNewArrayWithSpread函数。这是DFG代码的起始位置，启动代码意味着将JIT生成的机器代码写入内存以供以后执行。
我们可以通过查看compileNewArrayWithSpread方法来理解其中的机器代码。我们看到compileAllocateNewArrayWithSize()负责分配具有特定大小的新数组，它的第三个参数sizeGPR将作为第二个参数传递给emitAllocateButterfly()，这意味着它将为数组分配一个新的butterfly（包含JS对象值的内存空间）。如果您不熟悉JSObject的butterfly，可以点击【这里】了解更多信息。
跳转到EnITalListAtButoFuffE()，我们看到大小参数siZeGPR向左移动3位（乘以8），然后添加到常数sieof(IndexingHeader)。
方便起见，我们需要将实际的机器代码与我们在这个函数中的C 代码相匹配。m_jit字段的类型是JITCompiler。
JITCompiler负责根据数据流图生成JIT代码。它通过委托给jit来实现，后者生成一个宏汇编程序（JITCompiler通过继承关系拥有该程序）。JITCompiler保存编译期间所需信息的引用，并记录链接中使用的信息（例如，要链接的所有调用的列表）。
这意味着我们看到的调用，如m_jit.move()、m_jit.add32()等，是发出程序集的函数。通过跟踪每一个函数，我们将能够将其与C 对应的组件匹配。除了跟踪内存分配的malloc调试功能外，我们还根据自己对Intel程序集的偏好配置11db。
ZDIs-Mac:~ zdi$ cat ~/.lldbinit
settings set target.x86-disassembly-flavor intel
type format add --format hex long
type format add --format hex "unsigned long"
command script import lldb.macosx.heap
settings set target.env-vars
DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
settings set target.env-vars MallocStackLogging=1
settings set target.env-vars MallocScribble=1
由于在启用Guard Malloc的情况下正在分配大容量，我们需要设置另一个允许此类分配的环境变量。
ZDIs-Mac:webkit_ga_asan zdi$ cat lldb_cmds.txt
env DYLD_FRAMEWORK_PATH=/Users/zdi/webkit_ga_asan/WebKitBuild/Release env MALLOC_PERMIT_INSANE_REQUESTS=1
r
JSC_dumpDFGDisassembly将以AT&T格式转储程序集，因此我们运行deassembly-s 0x6400042d1c22-c 70可以获得英特尔风格的程序集，结果如下：
