CN111381992B

CN111381992B - 一种崩溃日志处理方法、装置、电子设备及存储介质

Info

Publication number: CN111381992B
Application number: CN202010153665.1A
Authority: CN
Inventors: 邓竹立; 彭飞
Original assignee: Beijing 58 Information Technology Co Ltd
Current assignee: Beijing 58 Information Technology Co Ltd
Priority date: 2020-03-06
Filing date: 2020-03-06
Publication date: 2022-07-08
Anticipated expiration: 2040-03-06
Also published as: CN111381992A

Abstract

本发明提供了一种崩溃日志处理方法、装置、电子设备及存储介质。所述方法，包括：获取崩溃日志文件对应的可执行文件中所有的类的地址；根据每个所述类的地址，获取每个所述类的每个函数的地址范围；针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃。通过对可行性文件的扫描及汇编指令的对比，查找崩溃地址所属函数地址区间，确认崩溃函数，从而将崩溃地址转成函数符号，将日志符号化。取得了在符号表缺失的情况下依旧能将崩溃日志符号化，减少程序监测的盲区，提高崩溃日志符号化的可行性和适应性的有益效果。

Description

一种崩溃日志处理方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种崩溃日志处理方法、装置、电子设备及存储介质。

背景技术

应用程序客户端崩溃是应用程序运行过程中出现的最为严重的问题，会导致服务突然中断，用户体验受损严重。因此，对于应用程序客户端崩溃的监测和分析就显得十分重要。但是，系统上报的崩溃日志是一种符号地址信息，而用户希望看到的是符号化的可视化语句，通过符号化的可视化语句，用户可以明确地知道具体是哪个函数的哪一行出了问题，且如果整个符号地址调用栈都被符号化为这样的可视化语句，那么调用栈看起来会非常的明确并且代码调用逻辑清晰，从而对定位崩溃原因和修复都有很大的帮助。

在相关技术中，一般通过符号表，将地址和函数符号进行映射。当发生崩溃时通过命令查询崩溃地址对应的符号，从而实现符号化。但是，该方法依赖符号表，如果开发者没有保留符号表，那么则无法进行日志符号化。

发明内容

本发明实施例提供一种崩溃日志处理方法、装置、电子设备及存储介质，以解决现有的崩溃日志处理方式过于依赖符号表，导致符号化过程受限的问题。

为了解决上述技术问题，本发明是这样实现的：

第一方面，本发明实施例提供了一种崩溃日志处理方法，包括：

获取崩溃日志文件对应的可执行文件中所有的类的地址；

根据每个所述类的地址，获取每个所述类的每个函数的地址范围；

针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃。

可选地，所述根据每个所述类的地址，获取每个所述类的每个函数的地址范围的步骤，包括：

针对任意一个所述类，根据所述类的地址，从所述可执行文件中获取所述类的第一结构体，所述第一结构体中包含与每个所述函数的地址范围相关的第二结构体的地址；

根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体；

根据所述第二结构体，获取所述类的函数的地址范围。

可选地，所述根据所述第二结构体，获取所述类的函数的地址范围的步骤，包括：

根据所述第二结构体，获取所述类的函数列表起始地址；

根据所述函数列表起始地址，所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。

可选地，所述根据所述函数列表起始地址，所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围的步骤，包括：

根据所述函数列表起始地址，获取所述类的函数列表；

根据所述函数列表中每个结构体的字节长度，获取所述类的每个函数的起始地址；

针对每个所述函数，从所述函数的起始地址开始读取数据，直至遇到所述函数的结束指令，以获取所述函数的结束地址；

针对每个所述函数，根据所述函数的起始地址和结束地址，确定所述函数的地址范围。

可选地，述根据所述第二结构体，获取所述类的函数列表起始地址的步骤，包括：

从所述第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。

可选地，所述根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体的步骤，包括：

从所述第一结构结构体中的第二预设位置开始，向后连续获取第二预设数量个字节，得到所述第二结构体的地址；

根据所述第二结构体的地址，获取所述第二结构体。

可选地，在所述针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃的步骤之后，还包括：

获取确认发生崩溃的函数的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。

第二方面，本发明实施例提供了一种崩溃日志处理装置，包括：

类地址获取模块，用于获取崩溃日志文件对应的可执行文件中所有的类的地址；

函数地址获取模块，用于根据每个所述类的地址，获取每个所述类的每个函数的地址范围；

符号化模块，用于针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃。

可选地，所述函数地址获取模块，包括：

第一结构体获取子模块，用于针对任意一个所述类，根据所述类的地址，从所述可执行文件中获取所述类的第一结构体，所述第一结构体中包含与每个所述函数的地址范围相关的第二结构体的地址；

第二结构体获取子模块，用于根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体；

函数地址获取子模块，用于根据所述第二结构体，获取所述类的函数的地址范围。

可选地，所述函数地址获取子模块，包括：

起始地址获取单元，用于根据所述第二结构体，获取所述类的函数列表起始地址；

函数地址获取单元，用于根据所述函数列表起始地址，所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。

可选地，所述函数地址获取单元，具体用于：

根据所述函数列表起始地址，获取所述类的函数列表；

可选地，所述起始地址获取单元，具体用于：从所述第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。

可选地，所述第二结构体获取子模块，具体用于：

根据所述第二结构体的地址，获取所述第二结构体。

可选地，所述装置还包括：

记录模块，用于获取确认发生崩溃的函数的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。

第三方面，本发明实施例另外提供了一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的崩溃日志处理方法的步骤。

第四方面，本发明实施例另外提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的崩溃日志处理方法的步骤。

在本发明实施例中，通过对可行性文件的扫描及汇编指令的对比，查找崩溃地址所属函数地址区间，确认崩溃函数，从而将崩溃地址转成函数符号，将日志符号化。从而取得了在符号表缺失的情况下依旧能将崩溃日志符号化，减少程序监测的盲区，提高崩溃日志符号化的可行性和适应性的有益效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例中的一种崩溃日志处理方法的步骤流程图；

图2是本发明实施例中的一种崩溃日志的示意图；

图3是本发明实施例中的另一种崩溃日志处理方法的步骤流程图；

图4是本发明实施例中的一种函数列表的示意图；

图5是本发明实施例中的一种崩溃日志处理过程示意图；

图6是本发明实施例中的一种崩溃日志处理装置的结构示意图；

图7是本发明实施例中的另一种崩溃日志处理装置的结构示意图；

图8是本发明实施例中的一种电子设备的硬件结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参照图1，示出了本发明实施例中一种崩溃日志处理方法的步骤流程图。

步骤110，获取崩溃日志文件对应的可执行文件中所有的类的地址；

如上述，崩溃日志文件中包含的崩溃日志的崩溃地址是一种符号地址信息，而用户希望看到的是符号化的可视化语句，通过符号化的可视化语句，用户可以明确地知道具体是哪个函数的哪一行出了问题。如图2所示为一种输入法的崩溃日志文件，其中包含多条崩溃日志。在第一条崩溃日志中通过“0x100030000+1466368”只给出了该条崩溃日志对应的崩溃在内存中的地址，也即该条崩溃日志对应的崩溃地址，但根据崩溃地址无法得知是哪个函数调用。那么为了得知是哪个函数调用导致的崩溃，则需要就是将这些内存地址转换成对应的可读性方法。当然，在本发明实施例中，也可以通过其他任何可用方式获取崩溃日志文件中每一条崩溃日志对应的崩溃地址，对此本发明实施例不加以限定。

在实际应用中，不同函数在内存中的存储形式一般也均为二进制形式，因此在本发明实施例中，为了避免崩溃日志在符号化过程中过度依赖符号表，提出一种完全不依赖符号表的崩溃日志处理方式，也即通过存储在内存中的函数指令的地址范围，查找各个崩溃地址对应的函数。

那么为了获取崩溃日志对应的程序的函数指令的地址范围，则可以获取崩溃日志文件对应的可执行文件中所有的类的地址。例如，如果崩溃日志文件是某一应用程序的崩溃日志文件，那么则可以获取相应应用程序对应的可执行文件进而扫描该可执行文件，获取其中所有类的地址。

其中，在不同的应用场景中，可执行文件的具体格式可以有所不同，具体的可以根据需求进行自定义设置获取以及扫描可执行文件的可用方式，对此本发明实施例不加以限定。例如，对于macOS、iOS等操作系统而言，可执行文件的格式可以为Mach-O文件。其中，Mach-O文件是Mach object文件格式的缩写，是一种用于记录可执行文件、对象代码、共享库、动态加载代码和内存转储的文件格式，是macOS/iOS上程序以及库的标准格式。开发人员可以根据Mach-O的文件格式对可执行文件进行解析，获取二进制文件内容。

而且，在本发明实施例中，可以通过任何可用方式获取可执行文件中所有的类的地址，对此本发明实施例不加以限定。例如，对于Mach-O文件，可以根据Mach-O文件的(__DATA,__objc_classlist)节(Section)获取所有类的地址。其中，Section是可执行文件中的二进制节，位于Segment(段)中，Segment是可执行文件中的二进制段。

另外，对于iOS上程序的Mach-O文件而言，由于常用的语言为Objective-C(简称OC)，因此也可以称此时的类为OC类，对此本发明实施例不加以限定。

步骤120，根据每个所述类的地址，获取每个所述类的每个函数的地址范围。

在获取得到每个类的地址之后，则可以根据每个类的地址读取得到相应类的全部代码，从而根据代码获取相应类中包含的每个函数指令的地址范围。

具体地，可以根据每个类的地址，逐一遍历类，获取每个类中包含的每个函数的函数指令的起始地址和结束地址，从而得到每个函数的函数指令的地址范围。而且，在本发明实施例中，可以通过任何可用方式获取函数指令的起始地址和结束地址，对此本发明实施例不加以限定。

步骤130，针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃。

在获取得到函数的地址范围之后，则可以进一步比对每条崩溃日志对应的崩溃地址与每个函数的地址范围。针对崩溃日志文件中的任意一条崩溃日志，如果该崩溃日志对应的崩溃地址位于任一函数的地址范围内，则可以确认相应函数发生崩溃。

例如，如果崩溃日志文件中某一崩溃日志对应的崩溃地址为22222222，而某一函数的地址范围为11111111至FFFFFFFF，那么该崩溃地址在该函数的地址范围内，也即在该函数的函数指令的地址范围内，则可以确认相应函数发生崩溃。

而且，为了方便相关人员准确定位发送崩溃的类，还可以获取相应函数所属的类，进而确认相应类中的相应函数发生崩溃，而且在本发明实施例中，还可以进一步记录相应函数与相应崩溃地址和/或相应崩溃日志之间的对应关系，以确定每一条崩溃地址和/或相应崩溃日志对应的崩溃函数。而且也方便在崩溃日志文件处理完成之后，统计是否崩溃日志文件中的每一条崩溃日志都已对应查找到相应的崩溃函数，以执行后续的相关操作。

参照图3，在本发明实施例中，所述步骤120进一步可以包括：

步骤121，针对任意一个所述类，根据所述类的地址，从所述可执行文件中获取所述类的第一结构体，所述第一结构体中包含与每个所述函数的地址范围相关的第二结构体的地址。

步骤122，根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体。

步骤123，根据所述第二结构体，获取所述类的函数的地址范围。

在实际应用中，为了获取函数的地址范围，可以获取与函数的地址范围相关的结构体的地址，以获取相应的结构体，进而获取函数的地址范围。而且，在实际应用中，与函数的地址范围相关的结构体的地址一般存储于另一结构体中。

因此，在本发明实施例中，为了获取每个类中包含的每个函数的地址范围，可以针对任意一个所述类，根据所述类的地址，从所述可执行文件中获取所述类的第一结构体，所述第一结构体中包含与每个所述函数的地址范围相关的第二结构体的地址，进而根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体，最终则可以根据所述第二结构体，获取所述类的函数的地址范围。

如上述iOS应用的二进制文件为Mach-O文件，OC编写的应用程序中存在(__DATA,__objc_classlist)节，该节数据存储的是所有类的地址(这里所说的地址是指距Mach-O文件起始地址的偏移地址)。而且，在Mach-O文件中，此地址指向一个class64结构体。而且，在class64结构体中指向的class64Info结构体中存储类名的字符串地址及方法(也即函数)列表地址。

因此，此时可以认为class64结构体相当于上述的第一结构体，class64Info结构体相当于上述的第二结构体。那么，在本发明实施例中，可以针对任意一个类，根据所述类的地址，从所述可执行文件中获取所述类的class64结构体作为第一结构体。进而根据所述class64结构体，获取所述类的class64Info结构体作为第二结构体。最终可以根据所述class64Info结构体中存储的类名的字符串地址及方法列表地址，获取所述类的每个函数的地址范围。

可选地，在本发明实施例中，所述步骤123进一步可以包括：

步骤1231，根据所述第二结构体，获取所述类的函数列表起始地址；

步骤1232，根据所述函数列表起始地址，所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。

方法(也即函数)列表中存储的是类的实例方法，如果想要查找类方法，那么需要先跳转到元类的第二结构体，再查找方法列表。

如上述，第二结构体与每个所述函数的地址范围相关。具体地，在实际应用中，类的第二结构体中可以包含相应类的函数列表起始地址，而且函数列表中包含的结构体类型是已知的，而且每种结构体类型的字节长度也是已知的，也即函数列表中包含每个结构体的字节长度也是已知的。因此，在本发明实施例中，可以根据所述函数列表起始地址，所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。

以作为第二结构体的class64Info为例，class64Info结构体可以如下所示：

其中，baseMethods表征所记录的地址，此地址为这个类的函数列表起始地址。由此可见，此时可以根据所述class64Info结构体，获取“baseMethods”对应的字段即为所述类的函数列表起始地址。而且，由于“baseMethods”的数据类型为“unsigned long long”，也即无符号的长整型，其长度为8字节，因此获取的函数列表起始地址的长度也为8个字节。

根据上面的寻址后，我们能够找到每个类的所有类方法和实例方法。而且，如图4所示一种方法(也即函数)在函数列表的存储示意图，可以看出，在函数列表中，前8字节为一种结构体，也即method64_list_t结构体，用于说明函数的数量，此后文件中连续存储另一种结构体，也即method64_t结构体，而且每个method64_t结构体中包含name、types、imp三个参数，其中name是指method64_t结构体对应的函数的函数名称，imp可以理解为相应method64_t结构体对应的函数的起始地址。通过method64_t结构体可以找到与之对应的每个函数的名称和函数的起始地址。

而且，由于在函数列表中在method64_list_t结构体之后连续存储method64_t结构体，而且每个method64_t结构体对应一个函数，每个method64_t结构体的字节长度(例如图4所示均为24字节)相同，且每个method64_t结构体的内部结构也相同，因此在本发明实施例中，可以根据所述函数列表的起始地址，所述类的函数列表中method64_list_t结构体的字节长度和method64_t结构体的字节长度，获取所述类的每个函数的地址范围。

而如果函数列表中包含的每个结构体的内部结构并不完全相同，那么则需要相应地根据函数列表中包含的每个结构体的字节长度，在函数类别中定位每个结构体的所在位置，进而根据相应每个结构体的内部结构，从相应结构体中获取相应结构体对应函数的地址范围。

可选地，在本发明实施例中，所述步骤1232进一步可以包括：

步骤S1，根据所述函数列表起始地址，获取所述类的函数列表。

步骤S2，根据所述函数列表中每个结构体的字节长度，获取所述类的每个函数的起始地址。

步骤S3，针对每个所述函数，从所述函数的起始地址开始读取数据，直至遇到所述函数的结束指令，以获取所述函数的结束地址；

步骤S4，针对每个所述函数，根据所述函数的起始地址和结束地址，确定所述函数的地址范围。

如上述，在本发明实施例中，可以在类的函数列表中记录类的各个函数的函数名称、函数指令的地址范围(也即函数的地址范围)等信息。因此可以先根据每个类的函数列表起始地址，获取相应每个类的函数列表。

进而则可以根据函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的起始地址。例如，如果函数列表中包含的每个结构体均对应一个函数，且在结构体中记录其对应函数的名称、函数的起始地址等信息，那么则可以根据每个结构体的字节长度，依次查找得到每个结构体在函数列表中的位置，进而从每个结构体中读取其对应的函数的名称、函数的起始地址等信息。其中，由于每个结构体的内部结构，也即结构体中包含的参数，每个参数的数据类型、各个参数的前后关系等都是已知的。而且，根据每个参数的数据类型，可以获取每个参数的字节长度。因此，结构体中包含的函数的名称、函数的起始地址等在结构体中的位置可以预先获知。

例如，method64_t结构体中包含的imp可以理解为相应method64_t结构体对应的函数的起始地址。而且在在函数列表中，前8字节为method64_list_t结构体，用于说明函数的数量，此后文件中连续存储method64_t结构体。

那么则可以从method64_list_t结构体中获取该函数列表中包含的函数的数量，而且由于函数列表中的第一个结构体为method64_list_t结构体，因此可以根据method64_list_t结构体的字节长度，从函数列表中在method64_list_t结构体之后的第一个字节开始，按照method64_t结构体的字节长度为单位，读取得到对应一个函数的method64_t结构体。例如，假设如图4所示，method64_list_t结构体的字节长度为8个字节，method64_t结构体的字节长度为24个字节，因此可以从函数列表的第9个字节开始，每次读取24个字节，从而读取得到每个method64_t结构体。进而则可以从每个method64_t结构体中获取“imp”对应的具体值，从而得到每个method64_t结构体对应函数的起始地址。

另外，在本发明实施例中，由于各个method64_t结构体的字节长度和内部结构都是一致的，因此也可以直接从函数列表中读取每个method64_t结构体中“imp”对应的具体值，从而得到每个method64_t结构体对应函数的起始地址。

例如，参照图4所述的函数列表，method64_list_t结构体的字节长度为8个字节，method64_t结构体中包含的name、types、imp三个参数的字节长度均为8个字节，因此对于第一个method64_t结构体，可以从函数列表中的第25个字节开始取8个字节，即为第一个method64_t结构体对应函数的指令的起始地址，此后可以每次间隔一个method64_t结构体的字节长度进行数据读取，且每次读取8个字节，进而得到每个method64_t结构体对应函数的起始地址，也即相应函数的函数指令的起始地址。

在获取得到每个函数的起始地址之后，由于每个函数的函数指令长度并不是一致的，因此函数的地址可能是一个地址范围，那么在获取其起始地址之后，为了获取地址范围还需要获取其指令的结束地址。具体地，针对每个函数，可以从所述函数的起始地址开始读取数据，直至遇到所述函数的结束指令，以获取所述函数的结束地址。

其中在不同的应用场景中，结束指令的形式可以有所不同，而且读取数据的单位可以有所不同，具体可以根据需求进行自定义设置，对此本发明实施例不加以限定。

例如，对于arm64的可执行文件，一条arm64的指令为4字节，当函数结束时会执行一条ret指令，当从函数起始地址开始扫描，扫描到ret指令时即可认为函数结束。ret指令为无操作码指令，其指令固定为0xC0035FD6。此时针对每个函数，可以从函数的起始地址开始，按4字节为单位读取数据，直至遇到ret指令，即读出4字节为0xC0035FD6，则认为此函数扫描结束，进而获取此时的结束地址作为相应函数的结束地址。

进而则可以根据每个函数的起始地址和结束地址，确定每个函数的地址范围。例如，假设针对某一函数，其起始地址为11111111，而结束地址为FFFFFFFF，那么该函数的地址范围即为11111111至FFFFFFFF。

可选地，在本发明实施例中，所述步骤1231进一步可以包括：从所述第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。

在实际应用中，同一种结构体内包含的参数的数据类型、各个参数的前后关系等都是可以预先设置，并且相对稳定。因此，在本发明实施例中，函数列表起始地址在第二结构体内的位置也是可以预先获知的。那么，为了快速且准确获取函数列表的起始地址，可以直接从第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。其中的第一预设位置、第一预设数量均可以根据不同的应用场景进行自定义设置，对此本发明实施例不加以限定。

而且，第一预设数量的具体取值与函数列表起始地址在第二结构体内的数据类型有关。例如，如果在第二结构体内函数列表起始地址的数据类型为“unsigned int”，也即无符号整型，其数据长度为4个字节，那么此时的第一预设数量即可以为4，而如果在第二结构体内函数列表起始地址的数据类型为“unsigned long long”，也即无符号长整型，其数据长度为8个字节，那么此时的第一预设数量即可以为8。

如上述的class64Info结构体，其中“baseMethods”指向函数列表在Mach-O文件中的起始地址，其中“unsigned int”表示的数据类型为无符号整型，数据长度为4个字节，“unsigned long long”表示的数据类型为无符号长整型，数据长度为8个字节，因此可以推知函数列表的起始地址在class64Info结构体中的第33至40字节。此时的第一预设位置即为第33个字节位置处，第一预设数量即为8。

可选地，在本发明实施例中，所述步骤122进一步可以包括：

步骤1221，从所述第一结构结构体中的第二预设位置开始，向后连续获取第二预设数量个字节，得到所述第二结构体的地址；

步骤1222，根据所述第二结构体的地址，获取所述第二结构体。

相应地，参考上述内容，第二结构体的地址在第一结构体内的位置也是可以预先获知的。那么，为了快速且准确获取第二结构体的地址，可以直接从第一结构体中的第二预设位置开始，向后连续获取第二预设数量个字节作为第二结构体的地址。其中的第二预设位置、第二预设数量均可以根据不同的应用场景进行自定义设置，对此本发明实施例不加以限定。

而且，第二预设数量的具体取值与第二结构体的地址在第一结构体内的数据类型有关。

例如，以上述的作为第一结构体的class64结构体为例，如下所示为一种class64结构体的形式：

其中，class64结构体起始8字节用于记录类的isa指针，指向类的元类。末尾8字节用于记录data，指向类的class64Info结构体，也即第二结构体。class64Info存储类名的字符串地址及方法列表地址。

因此，在本发明实施例中，为了快速且准确获取class64Info结构体，可以直接获取class64结构体中成员data(无符号的长整型，8字节)所指向的地址，data所指向的地址为class64Info结构体的地址，也即获取class64结构体中的最后8个字节，从而得到class64Info结构体的地址，进而则可以根根据class64Info结构体的地址，获取相应的class64Info结构体。

如图5所示为本发明实施例中一种macOS/iOS系统中崩溃日志处理方法的流程示意图。

首先根据作为可执行文件的Mach-O文件的(__DATA,__objc_classlist)节获取所有类(ClassA、ClassB、ClassC)的地址，针对每个类，根据类的地址从Mach-O文件中读取其class64结构体，根据class64结构体data成员记录的地址获取class64Info结构体。最后再根据class64Info结构体的baseMethods成员获取到函数列表(MethodInfo列表)(类方法需要读取元类数据，读取方法相同)。获取到函数列表的起始地址后，即可从文件中读取每个函数的函数地址和函数名称(MethodName)。获取到的函数地址即为函数距离Mach-O文件的偏移地址，如函数地址为0xAAAA，则说明在Mach-O文件，从0xAAAA字节开始是某函数的地址，在该起始地址之后一部分的连续字节为该函数的函数指令。

假设函数起始地址为0xAAAA，函数结束地址为0xBBBB，那么当崩溃堆栈显示偏移地址为0xAABB时，则说明崩溃指令位于该函数之类范围内，也就是说此函数发生崩溃。

参照图3，在本发明实施例中，所述方法还包括：

步骤140，获取确认发生崩溃的函数的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。

另外，在本发明实施例中，在确定崩溃函数之后，为了方便后续针对崩溃函数进行检测修复等操作，则可以进一步获取确认发生崩溃的函数的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中，而且在目标文件中还可以记录函数名称与类名称之间的对应关系，同时还可以记录函数名称与崩溃日志中崩溃地址的对应关系。

其中目标文件的位置和名称等都可以根据需求进行自定义设置，对此本发明实施例不加以限定。

而且，在崩溃日志处理完成之后，或者是崩溃日志的处理过程中，还可以将目标文件输出到屏幕进行显示，和/或将目标文件输出至指定目录下等，以方便后续操作，具体的可以根据需求进行自定义设置，对此本发明实施例不加以限定。

在本发明实施例中，还可以针对任意一个所述类，根据所述类的地址，从所述可执行文件中获取所述类的第一结构体，所述第一结构体中包含与每个所述函数的地址范围相关的第二结构体的地址；根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体；根据所述第二结构体，获取所述类的函数的地址范围。并且，根据所述第二结构体，获取所述类的函数列表起始地址；根据所述函数列表起始地址，所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。以及，从所述第一结构结构体中的第二预设位置开始，向后连续获取第二预设数量个字节，得到所述第二结构体的地址；根据所述第二结构体的地址，获取所述第二结构体。从而可以进一步提高每个函数地址范围的获取效率，以及获取得到的函数地址范围的准确性，进而提高符号化结果的准确性。

而且，在本发明实施例中，还可以根据所述函数列表起始地址，获取所述类的函数列表；根据所述函数列表中每个结构体的字节长度，获取所述类的每个函数的起始地址；针对每个所述函数，从所述函数的起始地址开始读取数据，直至遇到所述函数的结束指令，以获取所述函数的结束地址；针对每个所述函数，根据所述函数的起始地址和结束地址，确定所述函数的地址范围。以及，从所述第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。同样地，可以提高获取得到的函数地址范围的准确性，进而提高符号化结果的准确性。

另外，在本发明实施例中，还可以获取确认发生崩溃的函数的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。以方便相关人员获取符号化后的结果以执行后续相关操作。

参照图6，示出了本发明实施例中一种崩溃日志处理装置的结构示意图。

本发明实施例的崩溃日志处理装置包括：类地址获取模块210、函数地址获取模块220和符号化模块230。

下面分别详细介绍各模块的功能以及各模块之间的交互关系。

类地址获取模块210，用于获取崩溃日志文件对应的可执行文件中所有的类的地址；

函数地址获取模块220，用于根据每个所述类的地址，获取每个所述类的每个函数的地址范围；

符号化模块230，用于针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃。

参照图7，在本发明实施例中，所述函数地址获取模块220，进一步可以包括：

第一结构体获取子模块221，用于针对任意一个所述类，根据所述类的地址，从所述可执行文件中获取所述类的第一结构体，所述第一结构体中包含与每个所述函数的地址范围相关的第二结构体的地址；

第二结构体获取子模块222，用于根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体；

函数地址获取子模块223，用于根据所述第二结构体，获取所述类的函数的地址范围。

可选地，在本发明实施例中，所述函数地址获取子模块223，进一步可以包括：

可选地，在本发明实施例中，所述函数地址获取单元，具体用于：

根据所述函数列表起始地址，获取所述类的函数列表；

可选地，在本发明实施例中，所述起始地址获取单元，具体用于：从所述第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。

可选地，在本发明实施例中，所述第二结构体获取子模块，具体用于：

根据所述第二结构体的地址，获取所述第二结构体。

参照图7，在本发明实施例中，所述装置还可以包括：

记录模块240，用于获取确认发生崩溃的函数的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。

本发明实施例提供的崩溃日志处理装置能够实现图1至图2的方法实施例中实现的各个过程，为避免重复，这里不再赘述。

优选的，本发明实施例还提供了一种电子设备，包括：处理器，存储器，存储在存储器上并可在处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述崩溃日志处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述崩溃日志处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(RandomAccess Memory，简称RAM)、磁碟或者光盘等。

图8为实现本发明各个实施例的一种电子设备的硬件结构示意图。

该电子设备500包括但不限于：射频单元501、网络模块502、音频输出单元503、输入单元504、传感器505、显示单元506、用户输入单元507、接口单元508、存储器509、处理器510、以及电源511等部件。本领域技术人员可以理解，图8中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。在本发明实施例中，电子设备包括但不限于手机、平板电脑、笔记本电脑、掌上电脑、车载终端、可穿戴设备、以及计步器等。

应理解的是，本发明实施例中，射频单元501可用于收发信息或通话过程中，信号的接收和发送，具体的，将来自基站的下行数据接收后，给处理器510处理；另外，将上行的数据发送给基站。通常，射频单元501包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频单元501还可以通过无线通信系统与网络和其他设备通信。

电子设备通过网络模块502为用户提供了无线的宽带互联网访问，如帮助用户收发电子邮件、浏览网页和访问流式媒体等。

音频输出单元503可以将射频单元501或网络模块502接收的或者在存储器509中存储的音频数据转换成音频信号并且输出为声音。而且，音频输出单元503还可以提供与电子设备500执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出单元503包括扬声器、蜂鸣器以及受话器等。

输入单元504用于接收音频或视频信号。输入单元504可以包括图形处理器(Graphics Processing Unit，GPU)5041和麦克风5042，图形处理器5041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元506上。经图形处理器5041处理后的图像帧可以存储在存储器509(或其它存储介质)中或者经由射频单元501或网络模块502进行发送。麦克风5042可以接收声音，并且能够将这样的声音处理为音频数据。处理后的音频数据可以在电话通话模式的情况下转换为可经由射频单元501发送到移动通信基站的格式输出。

电子设备500还包括至少一种传感器505，比如光传感器、运动传感器以及其他传感器。具体地，光传感器包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板5061的亮度，接近传感器可在电子设备500移动到耳边时，关闭显示面板5061和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别电子设备姿态(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；传感器505还可以包括指纹传感器、压力传感器、虹膜传感器、分子传感器、陀螺仪、气压计、湿度计、温度计、红外线传感器等，在此不再赘述。

显示单元506用于显示由用户输入的信息或提供给用户的信息。显示单元506可包括显示面板5061，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板5061。

用户输入单元507可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。具体地，用户输入单元507包括触控面板5071以及其他输入设备5072。触控面板5071，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板5071上或在触控面板5071附近的操作)。触控面板5071可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器510，接收处理器510发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板5071。除了触控面板5071，用户输入单元507还可以包括其他输入设备5072。具体地，其他输入设备5072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

进一步的，触控面板5071可覆盖在显示面板5061上，当触控面板5071检测到在其上或附近的触摸操作后，传送给处理器510以确定触摸事件的类型，随后处理器510根据触摸事件的类型在显示面板5061上提供相应的视觉输出。虽然在图8中，触控面板5071与显示面板5061是作为两个独立的部件来实现电子设备的输入和输出功能，但是在某些实施例中，可以将触控面板5071与显示面板5061集成而实现电子设备的输入和输出功能，具体此处不做限定。

接口单元508为外部装置与电子设备500连接的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。接口单元508可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到电子设备500内的一个或多个元件或者可以用于在电子设备500和外部装置之间传输数据。

存储器509可用于存储软件程序以及各种数据。存储器509可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器509可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器510是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器509内的软件程序和/或模块，以及调用存储在存储器509内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。处理器510可包括一个或多个处理单元；优选的，处理器510可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器510中。

电子设备500还可以包括给各个部件供电的电源511(比如电池)，优选的，电源511可以通过电源管理系统与处理器510逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

另外，电子设备500包括一些未示出的功能模块，在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。

本领域普通技术人员可以意识到，结合本发明实施例中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims

1.一种崩溃日志处理方法，其特征在于，包括：

获取崩溃日志文件对应的可执行文件中所有的类的地址；

针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃；

其中，所述方法还包括：

获取崩溃的函数所属的类，以确定发生崩溃的类；

所述函数的地址范围包括：从起始地址到结束地址；

所述根据每个所述类的地址，获取每个所述类的每个函数的地址范围，包括：

根据所述第二结构体，获取所述类的函数的地址范围。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第二结构体，获取所述类的函数的地址范围的步骤，包括：

根据所述第二结构体，获取所述类的函数列表起始地址；

根据所述函数列表起始地址，以及所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。

3.根据权利要求2所述的方法，其特征在于，所述根据所述函数列表起始地址，以及所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围的步骤，包括：

根据所述函数列表起始地址，获取所述类的函数列表；

4.根据权利要求2所述的方法，其特征在于，所述根据所述第二结构体，获取所述类的函数列表起始地址的步骤，包括：

5.根据权利要求1所述的方法，其特征在于，所述根据所述第一结构体中包含的第二结构体的地址，获取所述类的第二结构体的步骤，包括：

从所述第一结构体中的第二预设位置开始，向后连续获取第二预设数量个字节，得到所述第二结构体的地址；

根据所述第二结构体的地址，获取所述第二结构体。

6.根据权利要求1-5中任一项所述的方法，其特征在于，在所述针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃的步骤之后，还包括：

获取确认发生崩溃的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。

7.一种崩溃日志处理装置，其特征在于，包括：

符号化模块，用于针对所述崩溃日志文件中的任意一条崩溃日志，响应于所述崩溃日志对应的崩溃地址位于任一函数的地址范围内，确认所述函数发生崩溃；

其中，所述装置还用于：获取崩溃的函数所属的类，以确定发生崩溃的类；

所述函数的地址范围包括：从起始地址到结束地址；

所述函数地址获取模块，包括：

8.根据权利要求7所述的装置，其特征在于，所述函数地址获取子模块，包括：

函数地址获取单元，用于根据所述函数列表起始地址，以及所述类的函数列表中包含的每个结构体的字节长度，获取所述类的每个函数的地址范围。

9.根据权利要求8所述的装置，其特征在于，所述函数地址获取单元，具体用于：

根据所述函数列表起始地址，获取所述类的函数列表；

10.根据权利要求8所述的装置，其特征在于，所述起始地址获取单元，具体用于：从所述第二结构体中的第一预设位置开始，向后连续获取第一预设数量个字节作为所述类的函数列表起始地址。

11.根据权利要求7所述的装置，其特征在于，所述第二结构体获取子模块，具体用于：

根据所述第二结构体的地址，获取所述第二结构体。

12.根据权利要求7-11中任一项所述的装置，其特征在于，还包括：

记录模块，用于获取确认发生崩溃的函数名称，以及所述函数所属类的类名称，并将所述函数名称和所述类名称记录至目标文件中。

13.一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的崩溃日志处理方法的步骤。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的崩溃日志处理方法的步骤。