CN107092554A - 一种应用程序的故障代码确认方法及装置 - Google Patents

Abstract

本申请提供一种应用程序的故障代码确认方法及装置，其中，所述方法包括：将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表；获取所述应用程序的诊断内存地址；根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。本申请实施方式提供的一种应用程序的故障代码确认方法及装置，通过对解析得到的符号映射表进行聚合处理，从而提高了诊断应用程序的效率。

Description

一种应用程序的故障代码确认方法及装置

技术领域

本申请涉及数据处理技术领域，特别涉及一种应用程序的故障代码确认方法及装置。

背景技术

随着智能手机的不断发展，在智能手机上运行的应用程序也在不断增多。在推出应用程序的过程中，往往包含两个阶段：第一个是线下开发阶段，第二个是线上发布阶段。

在线下开发阶段，往往需要对应用程序进行各种调试测试，以保证应用程序在线上发布时能够正常运行。在线上发布阶段，则需要对应用程序进行版本更新和运行维护。无论是线下开发阶段还是线上发布阶段，应用程序在运行过程中往往不可避免地会出现运行出错的情况。如果应用程序在线下开发阶段时运行出错，往往比较容易处理，可以利用应用程序所处的操作系统对应的调试器进行诊断，从而解决应用程序的源代码中的缺陷。例如对于苹果iOS系统而言，当其中的应用程序在线下开发阶段时运行出错，可以通过Xcode的调试器对运行出错的代码进行诊断。但是如果应用程序在线上发布阶段时运行出错，则无法通过调试器进行调试。此时则往往需要对应用程序运行出错的内存地址进行分析，以确定应用程序的源代码中出错的目标代码段，从而可以对出错的目标代码段进行诊断。

当前对应用程序进行诊断的方法可以包括以下步骤：

A1：获取并存储应用程序对应的调试符号信息文件。所述调试符号信息文件中可以包括内存地址与类名、函数名以及行号的对应关系。对于线上发布的应用程序而言，每个发布的版本均对应着一个调试符号信息文件。

A2：当应用程序运行出错时，读取并解析该应用程序对应的调试符号信息文件，以获取内存地址与类名、函数名以及行号的符号映射表。

A3：根据获取的内存地址与类名、函数名以及行号的符号映射表，查询与应用程序的诊断内存地址相对应的类名、函数名以及行号。

在实施本申请的过程中，发明人发现现有技术至少存在如下问题：

应用程序对应的调试符号信息文件的大小往往是应用程序大小的4-8倍左右，而根据调试符号信息文件解析出的符号映射表则更大。现有技术中实现应用程序的故障代码确认方法，需要将应用程序对应的调试符号信息文件以及获取的符号映射表均加载至内存中，这无疑将消耗相当多的系统内存。由于系统内存是有限的，因此现有技术中每次往往只能对一个诊断内存地址进行分析，而无法同时对多个诊断内存地址进行处理，这将导致应用程序诊断的效率非常低。

应该注意，上面对技术背景的介绍只是为了方便对本申请的技术方案进行清楚、完整的说明，并方便本领域技术人员的理解而阐述的。不能仅仅因为这些方案在本申请的背景技术部分进行了阐述而认为上述技术方案为本领域技术人员所公知。

发明内容

本申请实施方式的目的在于提供一种应用程序的故障代码确认方法及装置，以提高诊断应用程序的效率。

为实现上述目的，本申请一方面提供了一种应用程序的故障代码确认方法，所述方法，包括：将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表；获取所述应用程序的诊断内存地址；根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

为实现上述目的，本申请另一方面提供了一种应用程序的故障代码确认装置，所述装置包括：符号映射表获取单元，用于将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；聚合处理单元，用于按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表；诊断内存地址获取单元，用于获取所述应用程序的诊断内存地址；目标代码段参数确认单元，用于根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

本申请另一方面还提供了一种应用程序的故障代码确认装置，所述装置包括：存储器，其存储应用程序对应的调试符号信息文件；处理器，其从所述存储器中获取所述应用程序对应的调试符号信息文件，并将所述调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表，并将所述聚合后的符号映射表存储于所述存储器中；获取所述应用程序的诊断内存地址；根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

由以上本申请实施方式提供的技术方案可见，本申请的有益效果在于：通过对调试符号信息文件进行解析，并且对解析得到的符号映射表进行聚合处理，从而可以压缩所述符号映射表的大小，提高了根据诊断内存地址查询目标代码段参数的效率，从而提高了应用程序诊断的效率。

参照后文的说明和附图，详细公开了本申请的特定实施方式，指明了本申请的原理可以被采用的方式。应该理解，本申请的实施方式在范围上并不因而受到限制。在所附权利要求的精神和条款的范围内，本申请的实施方式包括许多改变、修改和等同。

针对一种实施方式描述和/或示出的特征可以以相同或类似的方式在一个或更多个其它实施方式中使用，与其它实施方式中的特征相组合，或替代其它实施方式中的特征。

应该强调，术语“包括/包含”在本文使用时指特征、整件、步骤或组件的存在，但并不排除一个或更多个其它特征、整件、步骤或组件的存在或附加。

附图说明

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

图1为本申请实施方式提供的一种应用程序的故障代码确认方法流程图；

图2为本申请实施方式提供的一种应用程序的故障代码确认方法的符号映射表解析步骤；

图3为本申请实施方式提供的一种应用程序的故障代码确认方法的调试符号信息文件删除步骤；

图4为本申请实施方式提供的一种应用程序的故障代码确认方法的聚合处理步骤；

图5为本申请实施方式提供的一种应用程序的故障代码确认方法的目标代码段参数确认步骤；

图6为本申请实施方式提供的一种应用程序的故障代码确认方法的行号确定步骤；

图7为本申请实施方式提供的一种应用程序的故障代码确认装置功能模块图。

具体实施方式

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

请参阅图1。本申请的一个实施方式提供一种应用程序的故障代码确认方法，其可以包括以下步骤。

步骤S11：将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种。

在本实施方式中，可以利用具备计算和处理能力的设备将应用程序对应的调试符号信息文件解析为符号映射表，所述具备计算和处理能力的设备可以为任何形式的计算机，例如服务器、台式电脑或者笔记本电脑。

在本实施方式中，所述应用程序可以为运行于终端设备内的软件。所述应用程序往往可以包括用户操作界面和后台代码。在应用程序运行时，可以通过所述用户操作界面接收用户输入的各项指令，然后可以将接收到的这些指令通过后台代码进行处理，以生成与这些指令相对应的结果。生成的结果可以被反馈至用户操作界面，以供用户浏览和查看。所述后台代码中往往可以包括各种各样的函数，这些函数可以通过C语言，C++语言或者Java语言等按照预设的逻辑进行编写。

在本实施方式中，对所述应用程序的故障代码进行确认的过程可以是在线下开发阶段，也可以是在线上发布阶段。其中，当应用程序处于线下开发阶段时，可以在笔记本或者计算机等具备对数据进行计算和处理功能的终端内对应用程序的后台代码进行调试。当应用程序处于线上发布阶段时，应用程序往往在用户的终端设备内运行。在用户与应用程序进行交互的过程中，应用程序往往可以产生各种各样的实时数据，所述实时数据可以由终端设备通过2G/3G/4G、Wi-Fi、蓝牙等方式发送至远程服务器，从而可以由所述远程服务器实时存储与应用程序相关的数据。这样，当应用程序在运行过程中发生故障时，往往可以产生包含故障信息的文件，该文件可以由终端设备发送至远程服务器，从而可以通过远程服务器对该包含故障信息的文件进行分析，以确定所述应用程序的故障代码。

在本实施方式中，能够运行所述应用程序的终端设备可以为智能手机、平板电脑、个人数字助理(PDA)或者智能可穿戴设备等具备数据处理功能的终端设备。所述终端设备中往往安装有操作系统，所述操作系统例如可以为苹果iOS系统、Android系统或者windows系统。在所述操作系统中通过对应用程序的后台代码进行编译，从而可以实现应用程序具备的功能。

在本实施方式中，应用程序的后台代码往往是通过人为可识别的语言进行编写的，在计算机运行应用程序的后台代码时，则需要将后台代码进行编译，以转换为计算机可识别的二进制代码。具体地，可以利用编译器对应用程序的后台代码进行编译。所述编译器可以根据操作系统的不同而发生改变。例如，对于windows系统而言，可以利用VC++编译器对应用程序进行编译；对于苹果iOS系统而言，可以利用Xcode编译器对应用程序进行编译。

在本实施方式中，在对应用程序的后台代码通过编译器进行编译后，往往会生成调试符号信息文件。所述调试符号信息文件中可以包括后台代码在运行过程中所占用的内存地址信息以及运行的目标代码段信息。具体地，后台代码在内存中运行时，每个不同的内存地址均可以对应着后台代码中不同的目标代码段。这样，内存地址与目标代码段之间便形成一种关联关系，通过指定的内存地址，便可以查询到与该指定的内存地址相关联的目标代码段。由于目标代码段的内容往往过于繁多，因此在调试符号信息文件中实际往往通过目标代码段参数来简要地表示目标代码段的内容。目标代码段中往往包括运行的函数所属的类、具体运行的函数名以及目标代码段在整个后台代码中的行号。因此，所述目标代码段参数便可以通过类名、函数名或行号中的至少一种形式，来简要地表示目标代码段的内容。

在本实施方式中，对于每个应用程序而言，当利用编译器对其进行编译时，均会生成调试符号信息文件，因此应用程序与调试符号信息文件之间可以形成对应关系。需要说明的是，随着应用程序的不断维护和更新，应用程序往往存在多个不同的版本，而对不同版本的应用程序进行编译时，均会相对应地生成一个调试符号信息文件。因此，假设某个应用程序有N个版本，那么对这N个版本分别进行编译时，则可以相对应地生成N个调试符号信息文件，而这些调试符号信息文件可以根据应用程序的版本号进行区分，也就是说，每个版本的应用程序均对应着一个调试符号信息文件。

在本实施方式中，在编译得到调试符号信息文件后，该调试符号信息文件可以存储于预设路径下，所述预设路径可以指向本地的笔记本或者计算机等具备对数据进行计算和处理功能的终端内的存储介质中，也可以指向远程服务器的磁盘中。例如，所述调试符号信息文件可以存储于远程服务器的磁盘中，其对应的路径例如可以为～/Library/Developer/Xcode/Archives/，那么通过对该路径中的文件进行访问，便可以读取应用程序对应的调试符号信息文件。由于所述调试符号信息文件中的信息往往以二进制的形式来表示，而应用程序的诊断内存地址往往以十六进制的形式来表示，那么在利用调试符号信息文件查询运行出错的目标代码段时，需要对所述调试符号信息文件进行解析，以将二进制信息转换为人为可识别的信息。

在本实施方式中，所述调试符号信息文件中的二进制信息往往使用的是DWARF(Debugging With Attributed Record Formats，以归属记录格式调试)文件结构。可以利用dwarfdump或者otool等工具对所述调试符号信息文件进行解析，从而可以将所述调试符号信息文件中通过二进制形式表示的内存地址与目标代码段参数的映射关系解析为可识别的符号映射表。解析得到的符号映射表可以包括由相关联的内存地址与目标代码段参数构成的映射数据。其中，所述内存地址可以通过十六进制来表示，其可以包括起始地址和终止地址，目标代码段参数则可以包括类名、函数名以及行号中的至少一种。在所述符号映射表中，各个映射数据可以逐行排列，每一行映射数据中均可以包括内存地址及其与所述内存地址相关联的目标代码段参数。解析后的符号映射表中某一行的映射数据可以如下所示：

7480 7494-[AppDelegate window]AppDelegate.m:48

其中，7480可以表示十六进制的起始地址，7494可以表示十六进制的终止地址，-[AppDelegate window]则可以表示目标代码段使用的函数所属的类名，AppDelegate.m则表示目标代码段具体使用的函数名，:48则表示该目标代码段在源代码中的行号。

由上可见，内存地址与目标代码段参数以映射的方式存储于符号映射表中，通过指定的内存地址，便可以查询与该指定的内存地址相关联的目标代码段参数。

步骤S13：按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表。

在本实施方式中，调试符号信息文件以及解析得到的符号映射表的大小往往与应用程序的大小成正比。例如，一个50MB的应用程序，其对应的调试符号信息文件的大小约为400MB，经过压缩后调试符号信息文件的大小也将近140MB，而解析得到的符号映射表的大小往往更大。因此，调试符号信息文件以及符号映射表将占用较多的存储空间。

在本实施方式中，为了减少符号映射表对存储空间的占用率，在解析得到所述符号映射表之后，可以按照预设聚合规则对其中的映射数据进行聚合处理，以得到聚合后的符号映射表。具体地，可以将符号映射表中具备相同特征的映射数据进行合并，从而可以将多组映射数据合并为一组，以压缩符号映射表的大小。所述具备相同特征的映射数据，可以包括目标代码段参数中的类名相同的映射数据，也可以包括目标代码段参数中函数名相同的映射数据，同样还可以包括目标代码段参数中类名和函数名均对应相同的映射数据。例如，对于目标代码段参数中类名和函数名均对应相同的映射数据，由于这些映射数据中目标代码使用的函数所属的类以及具体使用的函数均相同，因此可以将这些映射数据合并为一组映射数据。对于这些映射数据的目标代码段参数中不同的部分，可以通过预设的变换规则，将这些不同的部分变换至合并后的映射数据中。例如，当两组映射数据的目标代码段参数中类名和函数名均对应相同，而行号不相同时，可以将这两组映射数据对应的两个行号通过预设的变换规则变换至合并后的映射数据中，从而可以完成对映射数据的合并。

在本实施方式中，当对所述符号映射表中的映射数据进行聚合后，便可以得到聚合后的符号映射表。这样，聚合后的符号映射表便可以取代聚合之前的符号映射表而被保存至存储介质中，从而可以减少符号映射表对存储空间的占用率。进一步地，在本实施方式中，当聚合后的符号映射表被加载至内存中时，也可以减少符号映射表对内存的占用率，从而可以在同一时间加载多个符号映射表，以提高应用程序诊断的效率。

步骤S15：获取所述应用程序的诊断内存地址。

在本实施方式中，当应用程序在终端设备上运行出错时，往往会通过终端设备向远程服务器发送运行出错的文件。远程服务器在接收到该运行出错的文件后，可以从该出错的文件中提取出错的内存地址。所述出错的内存地址便作为应用程序的诊断内存地址，该诊断内存地址往往是通过十六进制的形式进行表示，通过查询与该诊断内存地址相关联的目标代码段参数，从而可以对运行出错的目标代码段进行修复。需要说明的是，所述应用程序的诊断内存地址也可以是调试人员直接输入远程服务器中的，这样，所述远程服务器接收到该诊断内存地址后，便可以根据预先存储的聚合后的符号映射表，对该诊断内存地址相关联的目标代码段参数进行查询。

步骤S17：根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

在本实施方式中，所述聚合后的符号映射表可以存储于远程服务器的磁盘中，当远程服务器获取到应用程序的诊断内存地址时，便可以从磁盘中将所述聚合后的符号映射表读取至内存中，以查询与所述诊断内存地址相关联的目标代码段参数。具体地，远程服务器可以将获取的诊断内存地址与所述聚合后的符号映射表中的内存地址进行对比。以确定所述诊断内存地址在符号映射表中对应的内存地址。在符号映射表中的内存地址往往是起始地址和终止地址限定的内存地址范围，那么在获取到所述诊断内存地址后，可以将该诊断内存地址与聚合后的符号映射表中的各个内存地址进行对比，判断该诊断内存地址处于哪个内存地址范围内。例如，诊断内存地址为7487，那么在经过对比之后，可以判定该诊断内存地址位于起始地址为7484，终止地址为7494的内存地址范围内。在本实施方式中，当确定出所述诊断内存地址对应的内存地址范围后，便可以将与该内存地址范围相关联的目标代码段参数确定为所述诊断内存地址对应的目标代码段参数。这样，便可以根据所述诊断内存地址，查询到运行出错的目标代码中的类名、函数名或者行号。

由上可见，在本实施方式中，通过对调试符号信息文件进行解析，并且对解析得到的符号映射表进行聚合处理，从而可以压缩所述符号映射表的大小，提高了根据诊断内存地址查询目标代码段参数的效率，从而提高了应用程序诊断的效率。

在一个具体的实施方式中，所述应用程序可以处于线上发布阶段，例如该应用程序可以为在苹果iOS系统中运行的手机淘宝。在用户与手机淘宝进行交互的过程中，手机淘宝往往可以产生各种各样的实时数据，这些实时数据均可以通过手机终端发送至远程服务器中，这样远程服务器便可以将手机淘宝中的实时数据进行存储和备份。在手机淘宝发布之前，可以利用苹果iOS系统提供的Xcode编译器对手机淘宝的后台代码进行编译，从而生成与该手机淘宝相对应的具备.dSYM后缀的文件，该具备.dSYM后缀的文件即可以为该手机淘宝对应的调试符号信息文件。在该调试符号信息文件中，可以通过二进制的形式保存手机淘宝的后台代码在内存中运行时内存地址与目标代码段参数之间的映射关系。该调试符号信息文件可以保存在所述远程服务器的磁盘中。进一步地，可以利用dwarfdump或者otool等工具对所述调试符号信息文件进行解析，从而可以将所述调试符号信息文件中通过二进制形式表示的内存地址与目标代码段参数的映射关系解析为可识别的符号映射表。在将所述调试符号信息文件解析为可识别的符号映射表后，为了节约远程服务器的存储空间，可以通过步骤S13中描述的方式对该符号映射表进行聚合处理，可以将符号映射表中具备相同特征的映射数据进行合并，从而可以将多组映射数据合并为一组，以压缩符号映射表的大小。在得到聚合后的符号映射表之后，便可以将该聚合后的符号映射表替代聚合前的符号映射表，存储于远程服务器的磁盘中。

当手机淘宝在运行过程中发生故障时，往往可以在手机终端上出现闪退的现象。在手机淘宝闪退的瞬间，其往往可以将运行出错的故障信息封装在故障文件中，并通过手机终端将该故障文件发送至远程服务器中。远程服务器接收到该故障文件后，便可以提取其中运行出错的内存地址，该运行出错的内存地址便可以为所述手机淘宝的诊断内存地址。通过将该诊断内存地址与远程服务器中存储的聚合后的符号映射表中的内存地址进行比对，从而可以确定与该诊断内存地址相关联的目标代码段参数，从而可以对运行出错的目标代码段进行诊断。

请参阅图2。在一个实施方式中，由于调试符号信息文件往往较大，在对调试符号信息文件进行解析的过程中，如果一次性将整个调试符号信息文件加载至内存中，则会占用相当多的内存。因此，为了减少解析过程中对内存的占用率，在本实施方式中，在将应用程序对应的调试符号信息文件解析为符号映射表的步骤中可以包括以下步骤。

步骤S21：将所述应用程序对应的调试符号信息文件划分为预设数量的文件块；

步骤S23：依次读取所述预设数量的文件块中的各个文件块，并将读取的文件块中的二进制信息解析为内存地址与目标代码段参数的映射数据；

步骤S25：将解析得到的所述映射数据存储至本地数据库中。

在本实施方式中，可以将所述调试符号信息文件进行分块解析。具体地，在本实施方式中，可以将应用程序对应的调试符号信息文件划分为预设数量的文件块。可以预先确定调试符号信息文件的大小，并根据调试符号信息文件的大小来确定划分后的每个文件块的大小。例如，所述调试符号信息文件为50M，那么可以将该调试符号信息文件划分为10个文件块，每个文件块的大小为5M。在进行解析时，可以依次读取所述预设数量的文件块中的各个文件块，并依次对各个文件块进行解析。具体地，划分后的文件块可以仍然存储于原先的预设路径下，在将调试符号信息文件划分为预设数量的文件块后，可以为每个文件块分配唯一的标识，以对这些文件块进行区分。所述标识可以为数字编码，例如共计10个文件块，那么便可以将数字编码1至10分别分配给这10个文件块。在对文件块进行读取时，便可以访问所述预设路径，并且按照文件块所分配的标识分别对其进行读取。例如，所述调试符号信息文件被划分为N个文件块，那么在对其进行解析时，可以读取所述N个文件块中标识为1的文件块。在读取了该文件块后，便可以将该文件块中的二进制信息解析为内存地址与目标代码段参数的映射数据。同样的，所述内存地址可以包括起始地址与终止地址，所述起始地址与终止地址均可以通过十六进制来表示，所述目标代码段参数则可以包括类名、函数名或者行号中的至少一种。在解析得到由相关联的内存地址与目标代码段参数构成的映射数据后，可以将该映射数据写入本地数据库中。所述本地数据库例如可以为远程服务器的磁盘。这样便完成了对一个文件块的读取和解析过程，接着便可以对下一个文件块进行读取和解析，直至处理完所述预设数量的文件块为止。

由上可见，在本实施方式中，通过对调试符号信息文件进行分块解析的方式，可以避免一次性地将整个调试符号信息文件加载至内存中，从而减少了解析过程中调试符号信息文件对内存的占用率，提高了解析调试符号信息文件的效率。

在另一个实施方式中，尽管对调试符号信息文件进行了文件块划分处理，但划分后的文件块解析得到的映射数据的数据量可能会比较大，那么将数据量较大的映射数据一次性写入本地数据库时，对远程服务器CPU的占用也会较大。因此，为了减少单次写入数据时对CPU的占用率，在本实施方式中，在将解析得到的所述映射数据存储至本地数据库中的步骤S25中，可以包括以下步骤。

按照预先设置的单次存储的限定数据量，将解析得到所述映射数据存储至本地数据库中。

在本实施方式中，可以预先设置单次存储的限定数据量，那么在将解析得到的所述映射数据存储至本地数据库中时，可以按照所述限定数据量来对映射数据进行存储。在实际应用过程中，所述单次存储的限定数据量可以通过映射数据的行数来表示，例如所述限定数据量可以设置为10万行。那么当解析得到的映射数据没有达到10万行时，便可以直接将解析得到的映射数据一次性写入磁盘中；而当解析得到的映射数据达到10万行时，便可以一次性写入10万行映射数据，多余的映射数据可以在下一次再写入磁盘中。这样便可以减少单次写入数据时对CPU的占用率，同时也可以减小单次写入数据时磁盘承受的负载。

请参阅图3。在另一实施方式中，在对调试符号信息文件进行解析，并且对解析出的符号映射表进行聚合后可以利用所述聚合后的符号映射表对诊断内存地址进行定位，而无需再对调试符号信息文件进行处理。那么在将解析得到的所述映射数据存储至本地数据库中的步骤之后，可以包括以下步骤。

步骤S29：从存储所述调试符号信息文件的介质中将所述调试符号信息文件删除。

在本实施方式中，在对调试符号信息文件进行解析得到符号映射表后，为了节省远程服务器的存储空间，便可以从存储所述调试符号信息文件的介质中将所述调试符号信息文件删除。对于同一个应用程序而言，其往往存在多个版本，而每个版本均对应一个调试符号信息文件，这些调试符号信息文件所占的存储空间往往是巨大的。在本实施方式中，在将解析得到的映射数据存储至本地数据库之后，可以将应用程序的每个版本对应的调试符号信息文件删除，从而可以节省远程服务器的存储空间。

请参阅图4。在另一个实施方式中，由于解析调试符号信息文件得到的符号映射表中的映射数据往往是杂乱无章的，这种杂乱无章的符号映射表通常不利于后续查询过程的有效进行。因此，在本实施方式中按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表的步骤中可以包括以下步骤。

步骤S31：将所述符号映射表中的映射数据按照内存地址中起始地址的大小进行排序，得到排序后的符号映射表；

步骤S33：当所述排序后的符号映射表中相邻两组映射数据的类名及函数名对应一致时，按照预设聚合规则将所述相邻两组映射数据进行聚合，得到聚合后的映射数据。

在本实施方式中，可以将所述符号映射表中的映射数据按照内存地址中起始地址的大小进行排序，从而得到排序后的符号映射表。表1为排序后的符号映射示意表。

表1排序后的符号映射示意表

起始地址	终止地址	类名	函数名	行号
					7480	7494	-[AppDelegate window]	AppDelegate.m	:48
7494	74b0	-[AppDelegate window]	AppDelegate.m	:49

如表1所示，符号映射表中的映射数据均按照起始地址的大小从小到大进行了排序。需要说明的是，在实际应用场景中，也可以按照起始地址的大小从大到小进行排序，本申请对排序的方式并不做限定。

从表1中可以看出，第一组映射数据中的类名和函数名与第二组映射数据中的类名和函数名分别对应一致，也就是说，从起始地址7480开始，一直到终止地址74b0，目标代码段对应的类名均为-[AppDelegate window]，并且使用的函数也均为AppDelegate.m，唯一的区别仅在于行号的不同。在这种情况下，可以对这相邻的两组映射数据进行聚合处理，使其合并为一组映射数据，从而达到压缩符号映射表的目的。

在一个具体的实施方式中，所述预设聚合规则可以包括以下内容。

1)将相邻两组映射数据中较小的起始地址确定为聚合后的映射数据的起始地址。

以表1中的两组映射数据为例，第一组映射数据的起始地址为7480，第二组映射数据的起始地址为7494，因此可以将7480确定为聚合后的映射数据的起始地址。

2)将所述相邻两组映射数据中较大的终止地址确定为所述聚合后的映射数据的终止地址。

由表1可见，第一组映射数据的终止地址为7494，第二组映射数据的终止地址为74b0，因此可以将74b0确定为聚合后的映射数据的终止地址。

3)将所述相邻两组映射数据中的类名和函数名确定为所述聚合后的映射数据的类名和函数名。

由于第一组映射数据与第二组映射数据中的类名和函数名均对应一致，因此聚合后的映射数据中的类名和函数名均不变，聚合后的映射数据中的类名可以为-[AppDelegate window]，函数名可以为AppDelegate.m。

4)分别获取所述相邻两组映射数据中由起始地址与行号构成的第一键值对和第二键值对，并将所述第一键值对与所述第二键值对按照预设数据交换格式转换为所述聚合后的映射数据的行号。

在第一组映射数据中，起始地址7480对应的行号为48，而在第二组映射数据中，起始地址7494对应的行号为49，那么在聚合后的映射数据中，应当保留聚合前的两组映射数据中起始地址与行号之间的对应关系。具体地，本申请实施方式可以将第一组映射数据中的起始地址与行号按照键值对(key-value)的方式进行存储，其中，起始地址可以作为key，与该起始地址对应的行号可以作为value。同样的，第二组映射数据中的起始地址与行号也可以通过相同的方式进行存储，从而可以分别得到第一键值对和第二键值对。

在获取到相邻两组映射数据的第一键值对和第二键值对之后，便可以按照预设数据交换格式转换为所述聚合后的映射数据的行号。在本申请实施方式中，所述数据交换格式例如可以为JSON串(JavaScript Object Notation)，所述JSON串可以通过名称-值的方式来定义。例如，表1中第一键值对为"7480":":48"，第二键值对为"7494":":49"，那么按照JSON串的方式转换后的行号可以表示为{"7494":":49","7480":":48"}。这样，聚合后的映射数据可以如表2所示：

表2聚合后的映射数据

需要说明的是，上述是以类名和函数名对应一致的相邻两组映射数据为例，解释本申请实施方式中的预设聚合规则，但这并不意味着本申请实施方式的聚合规则仅适用于两组映射数据。对于N组(N大于或者等于3)映射数据，只要这N组映射数据在位置上连续，并且每组映射数据中的类名和函数名均对应一致，那么便同样可以按照本申请实施方式中的聚合规则进行聚合。聚合后的符号映射表可以取代聚合之前的符号映射表，存储于所述本地数据库中。这样，通过对符号映射表进行排序和聚合处理，不仅将符号映射表的大小进行压缩，同时还能保证聚合后的符号映射表中的映射数据按照一定的顺序进行排序，从而提高了根据诊断内存地址进行查询的效率，节省了查询目标代码段参数的时间。

可以理解，本申请实施方式仅以举例的方式列举了所述预设聚合规则。所属领域技术人员在本申请的技术精髓启示下，可以通过数学建模、或流程、算法等改进，对所述预设聚合规则进行修改。但只要其实现的功能和效果，与本申请相同或相似，均应涵盖于本申请保护范围内。

请参阅图5。在另一个实施方式中，由于在对符号映射表进行聚合处理后，映射数据中目标代码段参数中的部分参数(例如行号)往往是与起始地址建立键值对进行存储的，这样，为了便于查询与诊断内存地址相对应的完整的目标代码段参数，在根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数的步骤中可以包括以下步骤。

步骤S71：将所述应用程序的诊断内存地址与所述聚合后的符号映射表中的内存地址进行对比，获取与所述诊断内存地址相匹配的起始地址；

步骤S73：根据所述聚合后的符号映射表，查询与获取的所述起始地址相关联的目标代码段参数，并将查询得到的所述目标代码段参数确定为与所述诊断内存地址相对应的目标代码段参数。

在本实施方式中，可以将所述应用程序的诊断内存地址与所述聚合后的符号映射表中的内存地址进行对比，以获取与所述诊断内存地址相匹配的起始地址。这样，在确定了与所述诊断内存地址相匹配的起始地址之后，便可以根据所述聚合后的符号映射表，查询与确定的所述起始地址相关联的目标代码段参数，并将查询得到的所述目标代码段参数确定为与所述诊断内存地址相对应的目标代码段参数。例如，诊断内存地址为7487，那么在经过对比之后，可以判定该诊断内存地址位于起始地址为7484，终止地址为7494的内存地址范围内。在确定出所述诊断内存地址对应的内存地址范围后，便可以将该内存地址范围的起始地址确定为与所述诊断内存地址相匹配的起始地址。这样，根据确定的所述起始地址，不仅可以查询到目标代码段参数中的类名和函数名，同时还可以根据起始地址与行号之间建立的键值对，查询到与该起始地址对应的行号，以保证根据诊断内存地址查询得到的目标代码段参数的完整性。

请参阅图6。在另一实施方式中，在查询到的目标代码段参数中，类名和函数名就可以为诊断内存地址对应的类名和函数名，然而查询到的目标代码段参数中的行号由于之前经过了聚合处理，可能并不是该诊断内存地址对应的行号。举例来进行说明，表1中的两组映射数据在聚合之后，形成了如表2所示的映射数据，那么如果诊断内存地址为7481，那么该诊断内存地址就位于如表2所示映射数据中，由此可以确定该诊断内存地址相匹配的起始地址为7480，根据7480这个起始地址便可以查询到与之相关联的类名为-[AppDelegate window]，函数名为AppDelegate.m，然而行号为{"7494":":49","7480":":48"}。由此可见，查询得到的行号中通过JSON串的形式实际包含了两个行号，因此，在这种情况下，在确认与所述应用程序的诊断内存地址相关联的目标代码段参数之后，还可以包括以下步骤。

步骤S19：当查询的所述目标代码段参数中的行号满足预设条件时，将查询的所述行号拆解为预设数量的映射组合，所述映射组合中包括起始地址与行号的映射关系。

在本实施方式中，当查询的所述目标代码段参数中的行号满足预设条件时，可以将查询的所述行号拆解为预设数量的映射组合，所述映射组合中包括起始地址与行号的映射关系。具体地，所述目标代码段参数中的行号满足预设条件可以为上述的查询到的行号为JSON串的情况。在这种情况下，可以将该JSON串中包含的起始地址与行号的映射组合进行拆解。例如对于{"7494":":49","7480":":48"}这个JSON串，可以将其拆解为"7494":":49"以及"7480":":48"这两个映射组合。具体的拆解过程可以通过调用Java库中的JSONObject库来实现，也可以通过对JSON串进行符号识别来实现。所述进行符号识别的过程例如可以为对JSON串的内容按照顺序进行扫描，当扫描至逗号时，便可以进行一次拆解，从而可以将JSON串拆解为多个映射组合。

步骤S111：将所述诊断内存地址与拆解得到的所述映射组合中的起始地址进行对比，获取与所述诊断内存地址相匹配的起始地址；

步骤S113：根据拆解的所述映射组合，查询与获取的所述起始地址相对应的行号，并将查询的所述行号确定为所述诊断内存地址对应的行号。

在本实施方式中，在拆解得到预设数量的映射组合后，便可以将所述诊断内存地址与拆解得到的所述映射组合中的内存地址进行对比，从而获取与所述诊断内存地址相匹配的起始地址。具体地，由于此时拆解得到的映射组合中仅包含起始地址，因此可以将所述诊断内存地址与拆解得到的起始地址进行对比。例如此时可以将诊断内存地址7481与起始地址7494以及起始地址7480进行对比，可以发现内存地址7481位于起始地址7480以及起始地址7494之间，从而可以判断与内存地址7481相匹配的起始地址为7480，从而将7480确定为所述诊断内存地址对应的起始地址。在获取到诊断内存地址对应的起始地址后，便可以根据拆解的所述映射组合，查询与确定的所述起始地址相对应的行号，并将查询的所述行号确定为所述诊断内存地址对应的行号。例如，诊断内存地址7481相匹配的起始地址为7480，根据"7480":":48"这个映射组合，可以确定诊断内存地址7481对应的行号为:48。这样，诊断内存地址7481对应的类名为-[AppDelegate window]，函数名为AppDelegate.m，行号为:48，从而可以对发生错误的目标代码段进行修复。

需要说明的是，对于某些诊断内存地址，其查询到的目标代码段参数中的行号由于没有进行聚合处理，因此查询到的行号便不是JSON串，而是实际出错的代码行号，此时便无需对行号进行上述的拆解过程。

请参阅图7。本申请实施方式还提供一种应用程序的故障代码确认装置。如图7所示，所述装置可以包括以下功能模块。

符号映射表获取单元100，用于将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；

聚合处理单元200，用于按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表；

诊断内存地址获取单元300，用于获取所述应用程序的诊断内存地址；

目标代码段参数确认单元400，用于根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

在本申请一优选实施方式中，所述符号映射表获取单元100具体包括文件块划分模块101，用于将所述应用程序对应的调试符号信息文件划分为预设数量的文件块；读取解析模块102，用于依次读取所述预设数量的文件块中的各个文件块，并将读取的文件块中的二进制信息解析为内存地址与目标代码段参数的映射数据；存储模块103，用于将解析得到的所述映射数据存储至本地数据库中。

其中，所述存储模块具体包括限定存储模块，用于按照预先设置的单次存储的限定行数，将解析得到的所述映射数据存储至本地数据库中。

在本申请另一优选实施方式中，在所述存储模块之后，所述装置还可以包括删除模块，用于从存储所述调试符号信息文件的介质中将所述调试符号信息文件删除。

在本申请另一优选实施方式中，所述内存地址包括起始地址和终止地址；

相应的，所述聚合处理单元200具体包括排序模块201，用于将所述符号映射表中的映射数据按照内存地址中起始地址的大小进行排序，得到排序后的符号映射表；映射数据聚合模块202，用于当所述排序后的符号映射表中相邻两组映射数据的类名及函数名对应一致时，将所述相邻两组映射数据进行聚合，得到聚合后的映射数据。

其中，所述映射数据聚合模块具体包括起始地址确定模块，用于将所述相邻两组映射数据中较小的起始地址确定为聚合后的映射数据的起始地址；终止地址确定模块，用于将所述相邻两组映射数据中较大的终止地址确定为所述聚合后的映射数据的终止地址；类名和函数名确定模块，用于将所述相邻两组映射数据中的类名和函数名确定为所述聚合后的映射数据的类名和函数名；行号转换模块，用于分别获取所述相邻两组映射数据中由起始地址与行号构成的第一键值对和第二键值对，并将所述第一键值对与所述第二键值对按照预设数据交换格式转换为所述聚合后的映射数据的行号。

在本申请另一优选实施方式中，所述目标代码段参数确认单元400具体包括起始地址匹配模块401，用于将所述应用程序的诊断内存地址与所述聚合后的符号映射表中的内存地址进行对比，获取与所述诊断内存地址相匹配的起始地址；目标代码段参数确定模块402，用于根据所述聚合后的符号映射表，查询与获取的所述起始地址相关联的目标代码段参数，并将查询得到的所述目标代码段参数确定为与所述诊断内存地址相对应的目标代码段参数。

在本申请另一优选实施方式中，在所述目标代码段参数确认单元300之后，所述装置还包括映射组合拆解单元，用于当查询的所述目标代码段参数中的行号满足预设条件时，将查询的所述行号拆解为预设数量的映射组合，所述映射组合中包括起始地址与行号的映射关系；地址对比单元，用于将所述诊断内存地址与拆解得到的所述映射组合中的内存地址进行对比，获取与所述诊断内存地址相匹配的起始地址；行号确定单元，用于根据拆解的所述映射组合，查询与获取的所述起始地址相对应的行号，并将查询的所述行号确定为所述诊断内存地址对应的行号。

需要说明的是，上述各个功能模块的具体实现过程均与上述方法步骤中的描述一致，这里便不再赘述。

本申请实施方式还提供一种应用程序的故障代码确认装置。所述装置可以包括：

存储器，其存储应用程序对应的调试符号信息文件；

处理器，其从所述存储器中获取所述应用程序对应的调试符号信息文件，并将所述调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表，并将所述聚合后的符号映射表存储于所述存储器中；获取所述应用程序的诊断内存地址；根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

本申请实施方式提供的一种应用程序的故障代码确认方法及装置，通过对调试符号信息文件进行解析，并且对解析得到的符号映射表进行聚合处理，从而可以压缩所述符号映射表的大小，提高了根据诊断内存地址查询目标代码段参数的效率，从而提高了应用程序诊断的效率。

在本说明书中，诸如第一和第二这样的形容词仅可以用于将一个元素或动作与另一元素或动作进行区分，而不必要求或暗示任何实际的这种关系或顺序。在环境允许的情况下，参照元素或部件或步骤(等)不应解释为局限于仅元素、部件、或步骤中的一个，而可以是元素、部件、或步骤中的一个或多个等。

上面对本申请的各种实施方式的描述以描述的目的提供给本领域技术人员。其不旨在是穷举的、或者不旨在将本发明限制于单个公开的实施方式。如上所述，本申请的各种替代和变化对于上述技术所属领域技术人员而言将是显而易见的。因此，虽然已经具体讨论了一些另选的实施方式，但是其它实施方式将是显而易见的，或者本领域技术人员相对容易得出。本申请旨在包括在此已经讨论过的本发明的所有替代、修改、和变化，以及落在上述申请的精神和范围内的其它实施方式。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

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

本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。尤其，对于系统和装置实施方式而言，由于其基本相似于方法实施方式，所以描述的比较简单，相关之处参见方法实施方式的部分说明即可。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施方式描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (10)

1.一种应用程序的故障代码确认方法，其特征在于，包括：

将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；

按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表；

获取所述应用程序的诊断内存地址；

根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

2.根据权利要求1所述的应用程序的故障代码确认方法，其特征在于，将应用程序对应的调试符号信息文件解析为符号映射表具体包括：

将所述应用程序对应的调试符号信息文件划分为预设数量的文件块；

依次读取所述预设数量的文件块中的各个文件块，并将读取的文件块中的二进制信息解析为内存地址与目标代码段参数的映射数据；

将解析得到的所述映射数据存储至本地数据库中。

3.根据权利要求2所述的应用程序的故障代码确认方法，其特征在于，所述将解析得到的所述映射数据存储至本地数据库中具体包括：

按照预先设置的单次存储的限定数据量，将解析得到所述映射数据存储至本地数据库中。

4.根据权利要求2所述的应用程序的故障代码确认方法，其特征在于，在将解析得到的所述映射数据存储至本地数据库中之后，所述方法还包括：

从存储所述调试符号信息文件的介质中将所述调试符号信息文件删除。

5.根据权利要求1所述的应用程序的故障代码确认方法，其特征在于，所述内存地址包括起始地址和终止地址；

相应的，所述按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表具体包括：

将所述符号映射表中的映射数据按照内存地址中起始地址的大小进行排序，得到排序后的符号映射表；

当所述排序后的符号映射表中相邻两组映射数据的类名及函数名对应一致时，按照预设聚合规则将所述相邻两组映射数据进行聚合，得到聚合后的映射数据。

6.根据权利要求5所述的应用程序的故障代码确认方法，其特征在于，所述按照预设聚合规则将所述相邻两组映射数据进行聚合，得到聚合后的映射数据具体包括：

将所述相邻两组映射数据中较小的起始地址确定为聚合后的映射数据的起始地址；

将所述相邻两组映射数据中较大的终止地址确定为所述聚合后的映射数据的终止地址；

将所述相邻两组映射数据中的类名和函数名确定为所述聚合后的映射数据的类名和函数名；

分别获取所述相邻两组映射数据中由起始地址与行号构成的第一键值对和第二键值对，并将所述第一键值对与所述第二键值对按照预设数据交换格式转换为所述聚合后的映射数据的行号。

7.根据权利要求1所述的应用程序的故障代码确认方法，其特征在于，根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数具体包括：

将所述应用程序的诊断内存地址与所述聚合后的符号映射表中的内存地址进行对比，获取与所述诊断内存地址相匹配的起始地址；

根据所述聚合后的符号映射表，查询与获取的所述起始地址相关联的目标代码段参数，并将查询得到的所述目标代码段参数确定为与所述诊断内存地址相对应的目标代码段参数。

8.根据权利要求1所述的应用程序的故障代码确认方法，其特征在于，在确认与所述应用程序的诊断内存地址相关联的目标代码段参数之后，所述方法还包括：

当查询的所述目标代码段参数中的行号满足预设条件时，将查询的所述行号拆解为预设数量的映射组合，所述映射组合中包括起始地址与行号的映射关系；

将所述诊断内存地址与拆解得到的所述映射组合中的起始地址进行对比，获取与所述诊断内存地址相匹配的起始地址；

根据拆解的所述映射组合，查询与获取的所述起始地址相对应的行号，并将查询的所述行号确定为所述诊断内存地址对应的行号。

9.一种应用程序的故障代码确认装置，其特征在于，包括：

符号映射表获取单元，用于将应用程序对应的调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；

聚合处理单元，用于按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表；

诊断内存地址获取单元，用于获取所述应用程序的诊断内存地址；

目标代码段参数确认单元，用于根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。

10.一种应用程序的故障代码确认装置，其特征在于，包括：

存储器，其存储应用程序对应的调试符号信息文件；

处理器，其从所述存储器中获取所述应用程序对应的调试符号信息文件，并将所述调试符号信息文件解析为符号映射表，所述符号映射表包括由相关联的内存地址与目标代码段参数构成的映射数据，所述目标代码段参数包括类名、函数名或行号中的至少一种；按照预设聚合规则对解析得到的所述符号映射表中的映射数据进行聚合处理，得到聚合后的符号映射表，并将所述聚合后的符号映射表存储于所述存储器中；获取所述应用程序的诊断内存地址；根据所述聚合后的符号映射表，确认与所述应用程序的诊断内存地址相关联的目标代码段参数。