Julia Language(多功能动态语言开发工具)

　　Julia Language是一款Julia语言是动态键入的，感觉就像是一种脚本语言，并且对交互使用提供了很好的支持；Julia具有丰富的描述性数据类型语言，并且类型声明可用于阐明和巩固程序，这些程序可通过LLVM编译为多个平台的高效本机代码；Julia使用多个调度作为范例，使表达许多面向对象和功能编程模式变得容易，标准库提供异步I/O，过程控制，日志记录，性能分析，程序包管理器等；它具有高级语法，使它成为任何背景或经验水平的程序员都可以使用的语言；朱莉娅语言每个人都可以免费使用，所有源代码都可以在GitHub上公开查看；它已被下载超过1000万次，并且社区已注册了2000多个软件包供社区使用，这些工具包括各种数学库，数据处理工具以及用于通用计算的软件包；除了这些，用户还可以轻松使用Python，R，C/Fortran，C++和Java中的库！

软件功能

　　数据可视化和绘图

　　数据可视化具有复杂的历史。

　　绘图软件在功能与简单性，速度与美感以及静态和动态界面之间进行权衡。

　　有些软件包可以显示，并且永远不会更改，而其他软件包则可以实时更新。

　　构建，部署或嵌入代码

　　该应用程序使您可以编写UI，静态编译代码，甚至将其部署在Web服务器上。

　　它还具有强大的类似于Shell的功能，用于管理其他进程。

　　它提供类似Lisp的宏和其他元编程功能。

　　与数据交互

　　数据生态系统使您可以快速加载多维数据集，并行执行聚合，联接和预处理操作

　　并以有效格式将其保存到磁盘。

　　您也可以使用OnlineStats.jl对流数据执行在线计算。

　　无论您是寻找方便，熟悉的DataFrame，还是使用JuliaDB的新方法，它为您提供了丰富的工具。

　　Queryverse提供查询，文件IO和可视化功能。

　　除了处理表格数据之外，JuliaGraphs包还使处理组合数据变得更加容易。

　　可扩展的机器学习

　　它提供了用于深度学习（Flux.jl和Knet.jl），机器学习和AI的强大工具。

　　Julia的数学语法使其成为表达算法的理想方式，就像它们写在论文中一样

　　构建具有自动微分，GPU加速以及可通过JuliaDB支持TB级数据的可训练模型。

软件特色

　　丰富的科学计算生态系统

　　Julia从头开始设计，非常擅长数值和科学计算。

　　可以在应用程序中编写的大量科学工具中看到这一点

　　例如最新的微分方程生态系统（DifferentialEquations.jl），优化工具（JuMP.jl和Optim.jl）

　　迭代线性求解器（ IterativeSolvers.jl），用于傅立叶变换的强大框架（AbstractFFTs.jl）

　　通用量子模拟框架（Yao.jl）等，可以推动所有模拟。

　　并行和异构计算

　　该语言专为并行性而设计，并为每个级别的并行计算提供内置基元：

　　指令级并行性，多线程和分布式计算。

　　Celeste.jl项目在NERSC的Cori超级计算机上使用650,000个内核，达到1.5 PetaFLOP / s。

　　编译器还可以为各种硬件加速器（例如GPU和Xeon Phis）生成本机代码。

　　诸如DistributedArrays.jl和Dagger.jl之类的包为并行提供了更高级别的抽象。

软件优势

　　快速

　　朱莉娅从一开始就为高性能而设计。Julia程序可通过LLVM编译为多个平台的高效本机代码。

　　动态

　　Julia是动态键入的，感觉就像是一种脚本语言，并且对交互使用具有良好的支持。

　　可重现

　　可重现的环境使您可以跨平台使用预先构建的二进制文件每次都重新创建相同的Julia环境。

　　可组合

　　Julia使用多个调度作为范例，使表达许多面向对象和功能编程模式变得容易。

　　关于多次分派的不合理有效性的演讲解释了为什么如此有效。

　　一般

　　Julia提供了异步I / O，元编程，调试，日志记录，性能分析，程序包管理器等。

　　可以在Julia中构建整个应用程序和微服务。

　　开源的

　　Julia是一个开源项目，拥有1,000多个贡献者。

　　它是根据MIT许可提供的。该源代码可以在GitHub上。

使用教程

　　使用时间旅行来远程调试故障DRAM

　　一个几个月前，在这个博客，我介绍了一个新的朱莉娅功能，让用户轻松地使用提交bug报告rr时间旅行调试器（请去阅读后如果你还没有，不然这个帖子的其余部分可能没有多大意义） 。自一个多月前正式发布Julia 1.5以来，已有十几个用户利用此功能向我们发送了详细的错误报告。到目前为止，一切都按计划进行。

　　在这篇文章中，我想讲述问题＃37524的故事，这是rr我们收到的几条痕迹中最不寻常的。如本博客文章的标题所述，最终的问题原来是错误的记忆。但是，根据大众的需求，并且为了消除有关使用黑魔法的任何谣言，我认为有必要逐步分析此问题。

　　调试rr跟踪时，通常要做的第一件事就是将其重播到崩溃点以四处查看（有时从崩溃位置的程序状态可以明显看出崩溃，有时还需要更多历史记录） 。在这种情况下，我的同事蒂姆·贝萨德（Tim Besard）进行了初步调查。下载跟踪并开始重播，他将看到以下内容。请注意，该记录的速度提高了约20倍（实时运行约两分钟），最后进行了轻松编辑以仅关注相关输出。

　　00:00

　　很明显，提交错误报告的用户正在执行某种形式的程序（可能是ML训练过程），并且经过数千次迭代，出了点问题。该问题报告了以下输出：

　　但是相反，我们收到一个内部rr错误：

　　这是蒂姆要我接任的重点，因为那真的不应该发生。现在，这里的错误消息可能看起来有些吓人，但让我们将其部分解析。实际的错误信息是：

　　这是什么意思？首先，快速回顾其rr工作原理：基本上，它记录内核（或任何其他非确定性来源）对进程内存所做的任何修改。然后，在这种修改之间，在给定输入存储状态的情况下，它依赖于处理器的确定性来产生按位相同的输出状态。在每个事件中，rr还记录完整的传入和传出寄存器状态。传入的寄存器状态不是严格要求的（因为它将根据先前的输入状态确定性地进行计算），但是对于某些分析目的以及允许重新检查是否正确进行重放来说，它可能是有用的。

　　现在，这里发生的事情是rr希望得到确定性（(det)）段（即由指令执行引起的段错误，而不是由其他进程（例如使用kill -SIGSEGV）异步发送）。但是，我们没有看到此段错误，而是在其他地方结束了：but instead at 'write'。在重放期间，rr发现自己被告知执行write系统调用，而不是看到崩溃。我们已经看到了程序的输出行为（基本上每个情节都会写一次），所以合理的猜测是在重放过程中，它成功完成了情节并到达了下一个write系统调用（这将是第一个执行点）rr主管在该位置从示踪者那里重新获得控制权）。在rr因此，我们将其称为“差异”：一种情况，其中在重放过程中采用的执行路径与在录制过程中实际发生的情况不同。差异通常是由rr错误引起的，这些错误导致无法观察到的内存修改（例如，内核内存修改行为的不完善模型），但是还有更多细微的问题也可能是造成这种情况的原因（例如CPU微体系结构错误）。因此，我转向尝试调试这种分歧。我首先寻找几种常见的分歧候选人。没有特别的优先顺序，它们是：

　　可能未经过足够测试的异常系统调用rr，因此可能导致rr内核行为的模型不完整

　　不寻常或专有的设备/设备驱动程序/内核扩展，可能会悄悄地修改用户空间内存（一个很大的禁忌，可能是安全问题，但令人惊讶的是，许多错误的驱动程序还是这样做了）。

　　之前可能没有经过测试的不寻常的CPU或微体系结构（例如，已知旧的Silvermont Atom芯片具有此类微体系结构错误）。

　　但是，通过浏览原始跟踪（使用获取的事件日志rr dump）并询问硬件细节，没有特别可疑的地方，因此我着手分析跟踪本身。在上面的清单中，我截断了段错误之前的事件，但是在这里仅供参考，因此我们可以稍微讨论一下：

　　让我们从解释一些术语开始。尽管rr确实跟踪了过去的挂钟时间（real_time上面），但“时间”的概念完全是信息性的。取而代之的，而不是将时间分成小时，秒和分钟，rr将时间划分events，tid（每个任务的内核线程ID;在IDS是重复使用一个额外的情况下serial计数器计算，但不保存）和ticks。events是导致事件外部修改过程内存（例如系统调用或信号）的事件的全局（在记录的过程树上）线性排序，而ticks每个任务（每个线程或每个线程的思考）是线性的tid）衡量前进的进度。确切的指标取决于CPU微体系结构以及可用的测量硬件。有效选择例如为Number of retired instructions或Number of retired conditional branches，但是从理论上讲，只要能够唯一地标识（可能与寄存器状态结合）执行中的特定点（例如，退休指令的数量很少，并且退休的条件分支通常有效，因为该计数与指令指针一起形成单调递增的对。

　　好了，所以查看事件日志，我们基本上可以看到已经知道的内容：它执行了一系列写系统调用（以打印剧集号），大量的计算（价值1,430亿个条件分支），最终应该崩溃了。我们还知道，在事件51909（假定的段错误之前的最后一次写入）中，重播中的内容仍处于正常状态。我们不能说存储器的内容是否已经发散，但我们至少知道寄存器的状态和执行的指令数与记录过程中发生的位运算完全相同。

　　研究差异的一种好方法是在怀疑差异发生之前先在内存中四处摸索，然后看看什么样的内存修改可以造成差异。通常，我只是通过转到上一个事件来执行此操作，但是在我们的示例中，最后两个事件之间有1500万条条件分支，这之间的距离相当长。取而代之的是，我了一条快速命令，使我们可以直接查找特定的滴答数。在这种情况下，我任意选择143998750000，在录制过程中发生段错误之前大约10000个滴答。让我们去那儿：

　　跟踪告诉我们，它期望段错误会在address发生rip:0x7f049e2ba8e3，所以让我们看一下：

　　好的，这是的负担r10。幸运的r10是，记录在跟踪中：r10:0x1007f0490b784d0。经验丰富的调试器会很快将此指针识别为太宽。特别是，通常，对于用户空间指针，高字节为0x00，但此处为0x01（gdb删除前导零）。有时，未使用的指针位用于提供额外的信息，但至少julia本身仅将未使用的低位用于此目的，而不使用高位。也就是说，此跟踪包括大量外部本机库（包括完整的python环境），因此某些外部库肯定会使用此类指针标记技术。让我们做更多的调查。我尝试做的第一件事是查看手动清除了高位的指针，以查看它是否是有效的Julia对象，还是只是某种垃圾而以某种方式最终从中加载：

　　好的，所以这实际上是指向julia对象（类型Array{Any, 1}）的指针，该对象具有神秘设置的高位。垃圾数据看起来像有效指针不一定是意外的。垃圾数据通常来自未初始化的内存重用，并且如果这样的指针先前位于该内存位置，则肯定可以获取有效指针的一部分。为了进一步缩小范围，让我们收集更多信息。我们距离发生分段错误的地点还有10,000个滴答声，但让我们看看该过程中当前正在发生什么：

　　好的，因此我们目前正在尝试分配一个42600元素元组，所有元素都是2元素数组（类型Array{Any, 1}）。由于10000小于42600，这很可能是我们在记录期间崩溃的操作（还要记住崩溃位置是jl_apply_tuple，这是新元组类型分配的一部分）。但是，我们还没有完全解释问题。如果我们在崩溃位置设置一个断点：

　　我们只是再次产生了分歧，所以它从未真正达到这个执行点，而是更早地分歧了（但只是在那儿崩溃了）。我们能找出发生了什么吗？回顾该程序集，我们看到该程序r10是从中加载的rax，我们还具有：rax:0x436487c0。当前发生了什么（记住崩溃之前我们还有10000滴答声）？

　　这恰好是我们在崩溃期间看到的指针，但是未设置高位。我们可能要问接下来的事情是什么（记录）的变化就发生在这个记忆：

　　我们从类型缓存中看到一些访问，然后是发散。在另一个方向呢？

　　请注意，差异使rr流程崩溃了，因此我们必须首先回到相同的执行点-幸运的是，由于这是一个录音，所以一切都稳定了，所以我们可以seek-ticks回到原来的位置。

　　作为参考，这是我们当前在Julia 1.5分支中使用的相关功能：

　　该代码非常简单：它只是遍历到的传入参数tuple，并获取每个参数的类型（这样它就可以创建与该参数匹配的适当的元组类型）。

　　显然，我们只是计算了传入数组之一的类型，并将其设置为svec。

　　我们可以找出我们刚刚计算出的数组的类型：

　　我们还可以观察该数组的类型指针，以查看是否有任何意外的情况与之混淆：

　　回顾一下：我们发现了一个可疑的指针0x1007f0490b784d0，注意到它是从中加载的0x436487c0，然后我们发现以前是通过从某个数组对象中加载类型指针来设置的。

　　然后，我们发现该数组对象的地址为0x7f0478f5aa10，这意味着它的类型指针位于0x7f0478f5aa08（其值最终将传播到崩溃站点）。

　　我们进一步看到，至少在重放中，at的值0x7f0478f5aa08正确指向了该Array{Any, 1}类型，而没有任何可疑的高位翻转。