CN110442519B - 一种崩溃文件处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明适用于云技术领域，提供一种崩溃文件处理方法、装置、电子设备及存储介质，其中，崩溃文件处理方法包括：接收用户端上传的崩溃文件，所述崩溃文件包括定位信息；根据所述定位信息判断所述崩溃文件的所属类型，所述崩溃文件的所属类型包括已知类型以及未知类型；若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注，并加入已知类型所属的样本数据库，所述样本数据库包括样本崩溃文件；统计在预设时间内接收的崩溃文件，并将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析。便于开发人员进行分析，能够提高开发人员对崩溃文件的分析效率。

Description

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

技术领域

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

背景技术

随着互联网的发展，越来越多的网络应用被开发出来并应用在终端上，当应用在终端上运行时，难免会出现应用崩溃的问题，这时，需要将崩溃文件上传到开发人员手上，开发人员要分析客户的崩溃文件，定位出现问题的原因，常规的操作是手动将文件载入windbg(Windbg是在windows平台下，一款强大的用户态和内核态调试工具)，同时需要开发人员指定该版本对应的相关pdb(Program Database File,程序数据库文件)文件以及源代码路径，这样windbg在分析过程中才能更直观地展示崩溃堆栈相关的函数代码，因为开发人员需要先人为分析出导致崩溃的代码，再到代码中定位该代码的位置，每次分析都需要开发者指定该版本对应的相关pdb文件以及源代码路径，如果有新版本推出，还得手动同步pdb文件和函数代码到本地，所以在崩溃文件的代码内容较多时，开发人员无法快速定位出代码的位置，从而使定位导致崩溃的代码的定位效率较低，从而导致对崩溃文件的分析效率低。

发明内容

本发明实施例提供一种崩溃文件处理方法、装置、电子设备及存储介质，旨在解决现有技术中对崩溃文件分析效率低的问题。

本发明实施例是这样实现的，第一方面，本发明提供了一种崩溃文件处理方法，所述方法包括以下步骤：

接收用户端上传的崩溃文件，所述崩溃文件包括定位信息；

根据所述定位信息判断所述崩溃文件的所属类型，所述崩溃文件的所属类型包括已知类型以及未知类型；

若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注，并加入已知类型所属的样本数据库，所述样本数据库包括样本崩溃文件；

统计在预设时间内接收的崩溃文件，并将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析。

更进一步地，所述根据所述定位信息判断所述崩溃文件的所属类型的步骤包括：

根据所述定位信息获取所述崩溃文件的进程名及版本号；

根据所述崩溃文件的进程名及版本号获取所述崩溃文件对应的pdb程序数据库文件及源代码路径，使用cdb分布式数据库进行分析，结合源代码定位崩溃堆栈到具体的开发代码调用函数；

根据所述开发代码调用函数，判断所述崩溃文件的所属类型。

更进一步地，所述定位崩溃堆栈到具体的开发代码调用函数的步骤包括：

在所述cdb分布式数据库中，根据所述崩溃文件对应的pdb程序数据库文件及源代码路径跳过堆栈中系统函数调用的相关帧；

逐层回溯直至定位到开发代码的函数调用帧，得到所述开发代码调用函数。

更进一步地，所述样本崩溃文件包括样本调用函数，所述根据所述开发代码调用函数，判断所述崩溃文件的所属类型的步骤包括：

将定位到的所述开发代码调用函数与所述样本数据库中的样本调用函数进行匹配，并判断匹配结果是否成功；

若匹配结果为成功，则判断所述开发代码调用函数的所属类型为已知类型；

若匹配结果为失败，则判断所述开发代码调用函数的所属类型为未知类型；

根据所述开发代码调用函数的所属类型判断所述崩溃文件的所属类型。

更进一步地，所述已知类型包括已修复及跟进中，所述方法还包括：

若所述崩溃文件的所属类型为已知类型，则判断所述崩溃文件为已修复或跟进中，并标注为所述已知类型的崩溃文件为已修复或跟进中；

所述若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注的步骤具体包括：

若所述崩溃文件的所属类型为未知类型，则标注所述未知类型的崩溃文件为跟进中。

更进一步地，在所述将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析的步骤之前，所述方法还包括：

将崩溃文件形成windbg快照并与对应崩溃文件形成链接关系，所述windbg快照包括windbg接口函数以及所述对应崩溃文件的定位信息。

更进一步地，所述已知类型包括已修复及跟进中，在所述将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析之后，所述方法还包括：

接收所述开发端返回的针对崩溃文件的分析结果，所述分析结果包括更改已知类型或保持已知类型；

若分析结果为更改已知类型，则更新所述样本数据库中对应样本崩溃文件的已知类型为已修复；

若分析结果为保持已知类型，则保持所述样本数据库中对应样本崩溃文件的已知类型不变。

更进一步地，所述开发端的数量为至少两个，在所述将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析之后，所述方法还包括：

接收各个开发端针对所述崩溃文件的分析内容；

响应于其中一个开发端发送的查看请求，发送其他一个或多个开发端的分析内容到发送查看请求的所述开发端上。

第二方面，提供一种崩溃文件处理装置，所述装置包括：

第一接收模块，用于接收用户端上传的崩溃文件，所述崩溃文件包括定位信息；

判断模块，用于根据所述定位信息判断所述崩溃文件的所属类型，所述崩溃文件的所属类型包括已知类型以及未知类型；

第一处理模块，用于若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注，并加入已知类型所属的样本数据库，所述样本数据库包括样本崩溃文件；

发送模块，用于统计在预设时间内接收的崩溃文件，并将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析。

更进一步地，所述判断模块包括：

第一获取单元，用于根据所述定位信息获取所述崩溃文件的进程名及版本号；

定位单元，用于根据所述崩溃文件的进程名及版本号获取所述崩溃文件对应的pdb程序数据库文件及源代码路径，使用cdb分布式数据库进行分析，结合源代码定位崩溃堆栈到具体的开发代码调用函数；

判断单元，用于根据所述开发代码调用函数，判断所述崩溃文件的所属类型。

更进一步地，所述定位单元包括：

跳过子单元，用于在所述cdb分布式数据库中，根据所述崩溃文件对应的pdb程序数据库文件及源代码路径跳过堆栈中系统函数调用的相关帧；

定位子单元，用于逐层回溯直至定位到开发代码的函数调用帧，得到所述开发代码调用函数。

更进一步地，所述样本崩溃文件包括样本调用函数，所述判断单元包括：

匹配子单元，用于将定位到的所述开发代码调用函数与所述样本数据库中的样本调用函数进行匹配，并判断匹配结果是否成功；

第一判断子单元，用于若匹配结果为成功，则判断所述开发代码调用函数的所属类型为已知类型；

第二判断子单元，用于若匹配结果为失败，则判断所述开发代码调用函数的所属类型为未知类型；

第三判断子单元，用于根据所述开发代码调用函数的所属类型判断所述崩溃文件的所属类型。

更进一步地，所述已知类型包括已修复及跟进中，所述装置还包括：第二处理模块，其中：

所述第二处理模块，用于若所述崩溃文件的所属类型为已知类型，则判断所述崩溃文件为已修复或跟进中，并标注为所述已知类型的崩溃文件为已修复或跟进中；

所述第一处理模块，还用于若所述崩溃文件的所属类型为未知类型，则标注所述未知类型的崩溃文件为跟进中。

更进一步地，所述装置还包括：

快照模块，用于将崩溃文件形成windbg快照并与对应崩溃文件形成链接关系，所述windbg快照包括windbg接口函数以及所述对应崩溃文件的定位信息。

更进一步地，所述已知类型包括已修复及跟进中，所述装置还包括：

第二接收模块，用于接收所述开发端返回的针对崩溃文件的分析结果，所述分析结果包括更改已知类型或保持已知类型；

更新模块，用于若分析结果为更改已知类型，则更新所述样本数据库中对应样本崩溃文件的已知类型为已修复；

保持模块，用于若分析结果为保持已知类型，则保持所述样本数据库中对应样本崩溃文件的已知类型不变。

更进一步地，所述已知类型包括已修复及跟进中，所述装置还包括：

第三接收模块，用于接收各个开发端针对所述崩溃文件的分析内容；

第二处理模块，用于响应于其中一个开发端发送的查看请求，发送其他一个或多个开发端的分析内容到发送查看请求的所述开发端上。

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

第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如本发明实施例中任一项所述的崩溃文件处理方法中的步骤。

本发明实施例中，由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率。

附图说明

图1为本发明实施例的一种可选系统架构示意图；

图2为本发明实施例的一种崩溃文件处理方法的流程示意图；

图3为实施例一中步骤S102的具体流程示意图；

图4为实施例二中步骤S202的具体流程示意图；

图5为实施例二中步骤S203的具体流程示意图；

图6为本发明实施例的另一种崩溃文件处理方法的流程示意图；

图7为本发明实施例的另一种崩溃文件处理方法的流程示意图；

图8为本发明实施例的另一种崩溃文件处理方法的流程示意图；

图9为本发明实施例的另一种崩溃文件处理方法的流程示意图；

图10为本发明实施例的一种崩溃文件处理装置的结构示意图；

图11为判断模块802的具体结构示意图；

图12为定位单元8022的具体结构示意图；

图13为判断单元8023的具体结构示意图；

图14为本发明实施例的另一种崩溃文件处理装置的结构示意图；

图15为本发明实施例的另一种崩溃文件处理装置的结构示意图；

图16为本发明实施例的另一种崩溃文件处理装置的结构示意图；

图17为本发明实施例的另一种崩溃文件处理装置的结构示意图；

图18为本发明实施例电子设备基本结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现有的崩溃文件分析中，开发人员要分析客户的崩溃文件，定位出现问题的原因，常规的操作是手动将文件载入windbg，同时需要开发人员指定该版本对应的相关pdb文件以及源代码路径，这样windbg在分析过程中才能更直观地展示崩溃堆栈相关的函数代码，因为需要开发人员人为操作对导致崩溃的代码进行定位，从而使定位导致崩溃的代码的定位效率较低，从而导致对崩溃文件的分析效率低。本发明采用在用户端采集崩溃文件上传，崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。

本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

如图1所示，图1为本发明实施例提供的一种可选系统架构，旨在支撑本发明各实施例中崩溃文件处理方法的运行，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。上述的用户包括使用终端设备101、102、103中应用的用户，也包括使用终端设备101、102、103进行应用开发的开发人员。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture ExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving PictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的主机服务器或云服务器，例如可以是对终端设备101、102、103上显示的页面提供IP地址的服务器。

需要说明的是，本申请实施例所提供的崩溃文件处理方法可以由服务器/终端设备执行，相应地，崩溃文件处理装置可以设置于服务器/终端设备中。

实施例一

请参见图2，图2为本发明实施例的一种崩溃文件处理方法的流程示意图，如图2所示，该方法包括以下步骤：

S101、接收用户端上传的崩溃文件，崩溃文件包括定位信息。

S102、根据定位信息判断崩溃文件的所属类型，崩溃文件的所属类型包括已知类型以及未知类型。

S103、若崩溃文件的所属类型为未知类型，则对崩溃文件进行标注，并加入已知类型所属的样本数据库，样本数据库包括样本崩溃文件。

S104、统计在预设时间内接收的崩溃文件，并将在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析。

上述的用户端中设置有崩溃捕捉模块以及崩溃文件上传模块，当用户端的应用或进程发生崩溃时，捕捉该崩溃的信息，形成崩溃文件，崩溃的信息包括文件名，可以在文件名的格式中增加各种有助于开发定位问题的信息，如进程名、用户id、版本号、mac地址、崩溃时间等，具体文件名格式可以是例如EC10367_1012_ADDR0x0F6e41_MAC7872428760_ID1543432_20190604_104829_RAND19371.dmp等。即是崩溃文件的文件名包括有定位信息。当然，在一种可能的实施方式中，定位信息也可以是以关联文件的形式与崩溃文件进行关联，形成需要上传的崩溃文件，比如，在关联文件中记载定位信息如EC10367_1012_ADDR0x0F6e41_MAC7872428760_ID1543432_20190604_104829_RAND19371等，本发明实施优选在崩溃文件的文件名格式中增加定位信息的方式。本发明实施例中，执行接收用户端上传的崩溃文件的主体可以是服务器，比如本地服务器或云服务器，本实施例中优选为云服务器，上述的云服务器也可以称为云端，本实施例可以是在云端对崩溃文件进行处理，上述的云服务器可以自动同步客户端新版本对应的pdb及源代码路径，并在样本数据库中进行存储。

上述的崩溃文件的所属类型包括已知类型以及未知类型，上述的已知类型可以理解为之前出现过相同的崩溃类型，上述的未知类型可以理解为之前没有出现过该崩溃类型。上述根据定位信息判断崩溃文件的所属类型可以是通过在样本数据库中进行匹配比对，若存在相同的样本崩溃文件，则说明该崩溃文件所属类型为已知类型，若不存在相同的样本崩溃文件，则说明该崩溃文件所属类型为未知类型。具体的，可以通过崩溃文件的文件名中的定位信息，如EC10367_1012_ADDR0x0F6e41_MAC7872428760_ID1543432_20190604_104829_RAND19371，提取其中的进程名、版本号、mac地址等与样本崩溃文件进行对比，判断进程名、版本号、mac地址等是否相同，根据判断结果来判断崩溃类型的所属类型。在一种可能的实施例中，崩溃文件为未知类型，若崩溃文件的所属类型为未知类型，则对崩溃文件进行标注，并加入已知类型所属的样本数据库，使该崩溃文件所属类型改为已知类型，并形成样本崩溃文件，以使该崩溃文件能对后面出现的崩溃文件进行比对。在另一种可能的实施例中，为使样本数据库的数据量不会太大，不重复匹配比对，若崩溃文件为已知类型，则不会将该已知类型的再次存储到样本数据库，这样就不会存在重复的样本崩溃文件。

上述的预设时间可以是每日、每周、每月等周期性的时间，也可以是开发人员自己设定的，比如，开发人员设定为每隔四天获取一次，或者是开发人员直接通过输入时间段，从而获取该时间段的崩溃文件。上述的统计包括数量统计、时间统计、用户统计等统计维度，数量统计例如统计每日总共接收多少个崩溃文件，同一所属类型的崩溃文件的数量，相同崩溃位置对应的文件数量等，时间统计例如各个崩溃文件的时间段，用户统计例如哪些用户的崩溃文件的崩溃数量及崩溃时间等。具体的统计维度可以根据开发人员的选择或设置进行。在一种可能的实施例中，在发送崩溃文件到开发端之前，可以对崩溃文件进行去重，将相同崩溃位置对应的崩溃文件只取其中一进行发送，这样可减少大量的数据IO，提高崩溃文件的传输到开发端的速度。上述的统计结果可以是图表形式的统计结果，统计结果可以以崩溃文件各个定位信息为维度进行表示，比如、可以按进程名、版本号等分别归类到统计结果中做为定位信息维度。上述将崩溃文件以及统计结果发送到开发端的方式可以是邮件、WEB网页、开发端程序等形式，也可以提供一个平台展示崩溃样本数据供开发人员浏览参考，开发人员通过开发者账号进行登陆浏览。统计结果的维度可以包括但不限于进程名、版本、用户id，崩溃文件名、定位到的开发代码调用函数、堆栈信息、操作系统版本、修复状态(已修复、跟进中两种状态)、mac地址。开发人员可以通过修复状态以及开发代码调用函数先大致扫一遍崩溃的分布情况以及频繁爆发状况，先有个整体上的把握。然后可以通过堆栈信息深入了解崩溃是如何发生的，不再需要手动拖入windbg等待分析完毕才能查看堆栈信息这样耗时耗力的工作。在一种可能的实施例中，发送到开发端的崩溃文件可以是样本数据库中的样本崩溃文件，由于未知类型的崩溃文件会更改为已知类型的崩溃文件从而加入样本数据库中成为样本崩溃文件，所以不会存在漏发的情况，云服务器可以不用对相同的崩溃文件进行存储，还可以减轻云服务器的存储压力。

在本实施例中，由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率。

实施例二

在实施例一的基础上，请参见图3，图3为实施例二的方法流程示意图，步骤S102的具体实现步骤包括：

S201、根据定位信息获取崩溃文件的进程名及版本号。

S202、根据崩溃文件的进程名及版本号获取崩溃文件对应的pdb程序数据库文件及源代码路径，使用cdb分布式数据库进行分析，结合源代码定位崩溃堆栈到具体的开发代码调用函数。

S203、根据开发代码调用函数，判断崩溃文件的所属类型。

其中，上述的定位信息可以是进程名、用户id、版本号、mac地址、崩溃时间等，上述的定位信息可以是崩溃文件的文件名，比如崩溃文件的文件名EC10367_1012_ADDR0x0F6e41_MAC7872428760_ID1543432_20190604_104829_RAND19371.dmp，其中，上述的进程名为EC，版本号为10367_1012，IP地址名为ADDR0x0F6e41，mac地址为MAC7872428760，用户id为ID1543432，崩溃时间为20190604_104829，随机函数为RAND19371。根据崩溃文件的进程名及版本号获取崩溃文件对应的pdb程序数据库文件及源代码路径，上述的pdb程序数据库文件与源代码路径为预先存储到云服务器的，当客户端版本更新，上述的pdb程序数据库文件与源代码也会同步上传到云服务器中，只需要提供进程名及版本号即可查询得到。

上述的定位开发代码调用函数具体可以是将崩溃文件代码在cdb分布式数据库中进行回溯，从而得到对应的崩溃堆栈，再进行细分回溯，得到崩溃堆栈中的开发代码调用函数。上述根据开发代码调用函数，判断崩溃文件的所属类型，具体的，可以将开发代码调用函数与样本数据库中的样本崩溃文件的样本调用函数进行比对，若崩溃文件的开发代码调用函数与样本崩溃文件的样本调用函数相同，则判断崩溃文件的开发代码调用函数所属类型为已知类型，进而判断崩溃文件所属类型为已知类型，若崩溃文件的开发代码调用函数与样本崩溃文件的样本调用函数不相同，则判断崩溃文件的开发代码调用函数所属类型为未知类型，进而判断崩溃文件所属类型为未知类型。

在本实施例中，通过定位信息定位到崩溃文件的开发代码调用函数，通过判断开发代码调用函数的所属类型来判断崩溃文件的所属类型，可以使判断结果更精准。由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率。

实施例三

在实施例一或实施例二的基础上，请参见图4，图4为实施例三的方法流程示意图，步骤S202的具体实现步骤包括：

S301、在cdb分布式数据库中，根据崩溃文件对应的pdb程序数据库文件及源代码路径跳过堆栈中系统函数调用的相关帧。

S302、逐层回溯直至定位到开发代码的函数调用帧，得到开发代码调用函数。

其中，跳过堆栈中系统函数调用的相关帧可以是根据崩溃文件对应的pdb程序数据库文件及源代码路径，提取崩溃文件的代码中的系统函数与崩溃文件对应的源代码的系统函数出来，可以将系统函数形成训练集，通过样本训练，学习到系统函数的识别，从而跳过系统函数的相关帧，避免系统函数参与崩溃文件的开发代码调用函数的回溯，增加回溯量和回溯时间。在cdb分布式数据库中，将崩溃文件的代码回溯到具体的函数调用帧，通过函数调用帧确定崩溃文件的开发代码调用函数。

在本实施例中，通过定位到具体的函数调用帧确定崩溃文件的开发代码调用函数，可以提高崩溃文件的开发代码调用函数的定位精准性。通过定位信息定位到崩溃文件的开发代码调用函数，通过判断开发代码调用函数的所属类型来判断崩溃文件的所属类型，可以使判断结果更精准。由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率。

实施例四

在以上任一实施例的基础上，样本崩溃文件包括样本调用函数，请参见图5，图5为实施例四的方法流程示意图，如图5所示，步骤S203的具体实现包括：

S401、将定位到的开发代码调用函数与样本数据库中的样本调用函数进行匹配，并判断匹配结果是否成功。

S402、若匹配结果为成功，则判断开发代码调用函数的所属类型为已知类型。

S403、若匹配结果为失败，则判断开发代码调用函数的所属类型为未知类型。

S404、根据所述开发代码调用函数的所属类型判断所述崩溃文件的所属类型。

其中，上述的样本崩溃文件中的代码包括样本调用函数，在获取到崩溃文件的开发代码调用函数后，可以与样本数据库中的样本调用函数进行比对，具体的，可以将样本数据库中样本崩溃文件的样本调用函数提取出来，用以和崩溃文件中的开发代码调用函数进行遍历比对，若存在崩溃文件的开发代码调用函数与样本调用函数相同的情况，则说明崩溃文件中的开发代码调用函数为已知类型，若不存在崩溃文件的开发代码调用函数与样本调用函数相同的情况，则说明崩溃文件中的开发代码调用函数为未知类型，从而可以判断崩溃文件的所属类型。

在本实施例中，通过判断开发代码调用函数的所属类型来判断崩溃文件的所属类型，可以使判断结果更精准。由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率。

实施例五

以上任一实施例的基础上，已知类型包括已修复及跟进中两种状态，请参见图6，图6为实施例五的方法流程示意图，如图6所示，本发明实施例中崩溃文件处理方法还包括：

S501、若崩溃文件的所属类型为已知类型，则判断崩溃文件为已修复或跟进中，并标注为已知类型的崩溃文件为已修复或跟进中。

S502、若崩溃文件的所属类型为未知类型，则标注未知类型的崩溃文件为跟进中。

其中，上述的已修复可以理解为该崩溃问题在之前已经被解决，可以使用之前的解决方法来进行解决，上述的跟进中可以理解为该崩溃问题还没有得到解决或正在解决中。通过对崩溃文件进行标注，可以使开发人员直观的了解崩溃文件的状态，不用打开崩溃文件进行人工检查就知道该崩溃文件是已修复还是跟进中，从而对已修复的崩溃问题进行跳过，去分析跟进中的崩溃问题，提高了分析效率。

在一种可能的实施方式中，对于未知类型的崩溃文件，还可以标注为待跟进，同时加入到样本数据库中。上述的待跟进可以理解为还没有开发人员进行跟进，这样可以便于开发人员根据状态进行跟进。

在本实施例中，由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率，对崩溃文件进行标注，将崩溃文件标注为已修复或跟进中，可以进一步提高开发人员对崩溃文件的分析效率。

实施例六

在以上任一实施例的基础上，请参见图7，图7为实施例六的方法流程示意图，如图7所示，在步骤S104之前，本发明实施例中的崩溃文件处理方法还包括：

S601、将崩溃文件形成windbg快照并与对应崩溃文件形成链接关系，windbg快照包括windbg接口函数以及对应崩溃文件的定位信息。

其中，上述的windbg快照可以使开发人员可以直接点击某个崩溃文件直接呼起windbg进行崩溃快照分析。上述的windbg快照可以是崩溃文件代码中的开发代码调用函数的快照，这样，可以使呼起的windbg分析后直接自动定位到开发代码调用函数，开发人员无需要再在windbg查看崩溃文件的其余代码部分，进一步的提高了开发人员的分析效率。

在本实施例中，由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率，开发人员在分析过程中，可以直接呼起windbg进行崩溃快照分析，进一步提高开发人员对崩溃文件的分析效率。

实施例七

在以上任一实施例的基础上，请参见图8，图8为实施例六的方法流程示意图，如图8所示，在步骤S104之后，本发明实施例中的崩溃文件处理方法还包括：

S701、接收开发端返回的针对崩溃文件的分析结果，分析结果包括更改已知类型或保持已知类型。

S702、若分析结果为更改已知类型，则更新样本数据库中对应样本崩溃文件的已知类型为已修复。

S703、若分析结果为保持已知类型，则保持样本数据库中对应样本崩溃文件的已知类型不变。

其中，上述开发端返回的针对崩溃文件的分析结果是由开发人员进行分析，并通过开发端上传的。分析结果包括更改已知类型，进一步的，已知类型包括已修复、跟进中，比如，一个跟进中的崩溃文件被开发人员解决，则开发人员会将该崩溃文件的标注由跟进中更改为已修复，并通过开发端上传到云服务器中，同时，云服务器接收到该崩溃文件后，更改该崩溃文件的已知类型，由跟进中修改为已修复，在下次用户端再上传与该崩溃文件相同的崩溃问题时，则会标注为已修复，开发人员就不用再进行一次相同的分析，提高了分析人员的分析效率。上述的保持已知类型，指的是跟进中的崩溃文件还没有得到解决，则开发人员不更改该崩溃文件的标注，上传到云服务器上的后，也不会进行标注的更改，保持该崩溃文件为跟进中。在一种可能的实施例中，开发人员可以开发端上进行筛选，筛选出已修复或跟进中的崩溃文件。

在本实施例中，由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率，开发人员在分析过程中，可以对已经解决的崩溃问题进行状态更改，使下次出现相同崩溃问题时，开发人员可以知道该崩溃问题已被解决，不用再重复分析，进一步的提高开发人员的工作效率。

实施例八

在以上任一实施例的基础上，请参见图9，图9为实施例六的方法流程示意图，如图9所示，在步骤S104之后，本发明实施例中的崩溃文件处理方法还包括：

S801、接收各个开发端针对崩溃文件的分析内容。

S802、响应于其中一个开发端发送的查看请求，发送其他一个或多个开发端的分析内容到发送查看请求的开发端上。

其中，上述的分析内容可以是开发端实时发送的，比如，检测到开发人员对分析内容有改动，则将改动后的分析内容实时发送到云服务器中。也可以是定时发送的，比如开发端每天定时将分析内容发送到云服务器中。还可以是开发人员主动发送的，比如开发人员在分析过程中，点击保存或上传分析内容，则会将分析内容发送到云服务器中。对于上传到云服务器中的分析内容，其他开发人员可以通过开发端进行访问，这样，在其他开发人员跟进的基础上，开发人员可以沿着其他开发人员的思路，协同完成对崩溃文件的修复工作。

在本实施例中，由于用户端的崩溃文件中包括有定位信息，可以根据定位信息快速定位到崩溃文件的代码位置，从而判断崩溃文件的所属类型为出现过的已知类型或未出现过的未知类型，并在统计后发送到开发端上进行分析，无需开发人员对导致的代码再进行定位，经过统计后的崩溃文件更加的直观，便于开发人员进行分析，提高了开发人员对崩溃文件的分析效率，开发人员在分析过程中，可以对通过云服务器了解其他开发人员的分析进度和情况，在其他开发人员跟进的基础上，协同完成对崩溃文件的修复工作。

需要说明的是，以上实施例中所提供的崩溃文件处理方法可以用于崩溃文件处理设备，比如具有崩溃文件处理功能的服务器、终端等。

实施例九

请参见图10，图10为本发明实施例的一种崩溃文件处理装置的结构示意图，如图10所示，装置800包括：

第一接收模块801，用于接收用户端上传的崩溃文件，崩溃文件包括定位信息；

判断模块802，用于根据定位信息判断崩溃文件的所属类型，崩溃文件的所属类型包括已知类型以及未知类型；

第一处理模块803，用于若崩溃文件的所属类型为未知类型，则对崩溃文件进行标注，并加入已知类型所属的样本数据库，样本数据库包括样本崩溃文件；

发送模块804，用于统计在预设时间内接收的崩溃文件，并将在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析。

更进一步地，如图11所示，判断模块802包括：

第一获取单元8021，用于根据定位信息获取崩溃文件的进程名及版本号；

定位单元8022，用于根据崩溃文件的进程名及版本号获取崩溃文件对应的pdb程序数据库文件及源代码路径，使用cdb分布式数据库进行分析，结合源代码定位崩溃堆栈到具体的开发代码调用函数；

判断单元8023，用于根据开发代码调用函数，判断崩溃文件的所属类型。

更进一步地，如图12所示，定位单元8022包括：

跳过子单元80221，用于在cdb分布式数据库中，根据崩溃文件对应的pdb程序数据库文件及源代码路径跳过堆栈中系统函数调用的相关帧；

定位子单元80222，用于逐层回溯直至定位到开发代码的函数调用帧，得到开发代码调用函数。

更进一步地，如图13所示，样本崩溃文件包括样本调用函数，判断单元8023包括：

匹配子单元80231，用于将定位到的开发代码调用函数与样本数据库中的样本调用函数进行匹配，并判断匹配结果是否成功；

第一判断子单元80232，用于若匹配结果为成功，则判断开发代码调用函数的所属类型为已知类型；

第二判断子单元80233，用于若匹配结果为失败，则判断开发代码调用函数的所属类型为未知类型；

第三判断子单元80234，用于根据开发代码调用函数的所属类型判断崩溃文件的所属类型。

更进一步地，如图14所示，已知类型包括已修复及跟进中，崩溃文件处理装置还包括：第二处理模块805，其中：

第二处理模块805，用于若崩溃文件的所属类型为已知类型，则判断崩溃文件为已修复或跟进中，并标注为已知类型的崩溃文件为已修复或跟进中；

第一处理模块803，还用于若崩溃文件的所属类型为未知类型，则标注未知类型的崩溃文件为跟进中。

更进一步地，如图15所示，崩溃文件处理装置还包括：

快照模块806，用于将崩溃文件形成windbg快照并与对应崩溃文件形成链接关系，windbg快照包括windbg接口函数以及对应崩溃文件的定位信息。

更进一步地，如图16所示，已知类型包括已修复及跟进中，崩溃文件处理装置还包括：

第二接收模块807，用于接收开发端返回的针对崩溃文件的分析结果，分析结果包括更改已知类型或保持已知类型；

更新模块808，用于若分析结果为更改已知类型，则更新样本数据库中对应样本崩溃文件的已知类型为已修复；

保持模块809，用于若分析结果为保持已知类型，则保持样本数据库中对应样本崩溃文件的已知类型不变。

更进一步地，如图17所示，崩溃文件处理装置还包括：

第三接收模块810，用于接收各个开发端针对所述崩溃文件的分析内容；

第三处理模块811，用于响应于其中一个开发端发送的查看请求，发送其他一个或多个开发端的分析内容到发送查看请求的所述开发端上。

本申请实施例提供的崩溃文件处理装置能够实现图2至图9的方法实施例中的各个实施方式，以及相应有益效果，为避免重复，这里不再赘述。

实施例十

为解决上述技术问题，本申请实施例还提供一种电子设备，用于崩溃文件处理。具体请参阅图18，图18为本实施例电子设备基本结构框图，如图18所示。

所述电子设备14包括通过系统总线相互通信连接存储器1401、处理器1402、网络接口1403。需要指出的是，图中仅示出了具有组件1401-1403的电子设备14，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的电子设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述电子设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述电子设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器1401至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器1401可以是所述电子设备14的内部存储单元，例如该电子设备14的硬盘或内存。在另一些实施例中，所述存储器1401也可以是所述电子设备14的外部存储设备，例如该电子设备14上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器1401还可以既包括所述电子设备14的内部存储单元也包括其外部存储设备。本实施例中，所述存储器1401通常用于存储安装于所述电子设备14的操作系统和各类应用软件，例如崩溃文件处理方法的程序代码等。此外，所述存储器1401还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器1402在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1402通常用于控制所述电子设备14的总体操作。本实施例中，所述处理器1402用于运行所述存储器1401中存储的程序代码或者处理数据，例如运行上述崩溃文件处理方法的程序代码。

所述网络接口1403可包括无线网络接口或有线网络接口，该网络接口1403通常用于在所述电子设备14与其他电子设备之间建立通信连接。

实施例十一

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，上述计算机可读存储介质存储有崩溃文件处理方法程序，上述崩溃文件处理方法程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的崩溃文件处理方法的步骤。

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

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种崩溃文件处理方法，其特征在于，所述方法包括以下步骤：

接收用户端上传的崩溃文件，所述崩溃文件的文件名包括定位信息；

根据所述定位信息判断所述崩溃文件的所属类型，所述崩溃文件的所属类型包括已知类型以及未知类型；

若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注，并加入已知类型所属的样本数据库，所述样本数据库包括样本崩溃文件；

统计在预设时间内接收的崩溃文件，并将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析；

所述根据所述定位信息判断所述崩溃文件的所属类型的步骤包括：

根据所述定位信息获取所述崩溃文件的进程名及版本号；

根据所述崩溃文件的进程名及版本号获取所述崩溃文件对应的pdb程序数据库文件及源代码路径，使用cdb分布式数据库进行分析，结合源代码定位崩溃堆栈到具体的开发代码调用函数；

根据所述开发代码调用函数，判断所述崩溃文件的所属类型；

所述定位崩溃堆栈到具体的开发代码调用函数的步骤包括：

在所述cdb分布式数据库中，根据所述崩溃文件对应的pdb程序数据库文件及源代码路径跳过堆栈中系统函数调用的相关帧；

逐层回溯直至定位到开发代码的函数调用帧，得到所述开发代码调用函数；

所述跳过堆栈中系统函数调用的相关帧是根据所述崩溃文件对应的pdb程序数据库文件及源代码路径，提取所述崩溃文件的代码中的系统函数与崩溃文件对应的源代码的系统函数，将所述系统函数形成训练集，通过样本训练，学习到所述系统函数的识别，从而跳过所述系统函数的相关帧，避免所述系统函数参与所述崩溃文件的开发代码调用函数的回溯；

所述已知类型包括已修复及跟进中，所述方法还包括：

若所述崩溃文件的所属类型为已知类型，则判断所述崩溃文件为已修复或跟进中，并标注为所述已知类型的崩溃文件为已修复或跟进中；

所述若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注的步骤具体包括：

若所述崩溃文件的所属类型为未知类型，则标注所述未知类型的崩溃文件为跟进中。

2.如权利要求1所述的崩溃文件处理方法，其特征在于，所述样本崩溃文件包括样本调用函数，所述根据所述开发代码调用函数，判断所述崩溃文件的所属类型的步骤包括：

将定位到的所述开发代码调用函数与所述样本数据库中的样本调用函数进行匹配，并判断匹配结果是否成功；

若匹配结果为成功，则判断所述开发代码调用函数的所属类型为已知类型；

若匹配结果为失败，则判断所述开发代码调用函数的所属类型为未知类型；

根据所述开发代码调用函数的所属类型判断所述崩溃文件的所属类型。

3.如权利要求1至2中任一所述的崩溃文件处理方法，其特征在于，在所述将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析的步骤之前，所述方法还包括：

将崩溃文件形成windbg快照并与对应崩溃文件形成链接关系，所述windbg快照包括windbg接口函数以及所述对应崩溃文件的定位信息。

4.如权利要求1至2中任一所述的崩溃文件处理方法，其特征在于，所述已知类型包括已修复及跟进中，在所述将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析之后，所述方法还包括：

接收所述开发端返回的针对崩溃文件的分析结果，所述分析结果包括更改已知类型或保持已知类型；

若分析结果为更改已知类型，则更新所述样本数据库中对应样本崩溃文件的已知类型为已修复；

若分析结果为保持已知类型，则保持所述样本数据库中对应样本崩溃文件的已知类型不变。

5.如权利要求1至2中任一所述的崩溃文件处理方法，其特征在于，所述开发端的数量为至少两个，在所述将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析之后，所述方法还包括：

接收各个开发端针对所述崩溃文件的分析内容；

响应于其中一个开发端发送的查看请求，发送其他一个或多个开发端的分析内容到发送查看请求的所述开发端上。

6.一种崩溃文件处理装置，其特征在于，所述装置包括：

第一接收模块，用于接收用户端上传的崩溃文件，所述崩溃文件的文件名包括定位信息；

判断模块，用于根据所述定位信息判断所述崩溃文件的所属类型，所述崩溃文件的所属类型包括已知类型以及未知类型；

第一处理模块，用于若所述崩溃文件的所属类型为未知类型，则对所述崩溃文件进行标注，并加入已知类型所属的样本数据库，所述样本数据库包括样本崩溃文件；

发送模块，用于统计在预设时间内接收的崩溃文件，并将所述在预设时间内接收的崩溃文件以及统计结果发送到至少一个开发端上进行分析；

所述判断模块包括：

第一获取单元，用于根据所述定位信息获取所述崩溃文件的进程名及版本号；

定位单元，用于根据所述崩溃文件的进程名及版本号获取所述崩溃文件对应的pdb程序数据库文件及源代码路径，使用cdb分布式数据库进行分析，结合源代码定位崩溃堆栈到具体的开发代码调用函数；

判断单元，用于根据所述开发代码调用函数，判断所述崩溃文件的所属类型；

所述定位单元包括：

跳过子单元，用于在所述cdb分布式数据库中，根据所述崩溃文件对应的pdb程序数据库文件及源代码路径跳过堆栈中系统函数调用的相关帧；

定位子单元，用于逐层回溯直至定位到开发代码的函数调用帧，得到所述开发代码调用函数；

所述跳过子单元还用于根据所述崩溃文件对应的pdb程序数据库文件及源代码路径，提取所述崩溃文件的代码中的系统函数与崩溃文件对应的源代码的系统函数，将所述系统函数形成训练集，通过样本训练，学习到所述系统函数的识别，从而跳过所述系统函数的相关帧，避免所述系统函数参与所述崩溃文件的开发代码调用函数的回溯；

所述已知类型包括已修复及跟进中，所述装置还包括：第二处理模块，其中：

所述第二处理模块，用于若所述崩溃文件的所属类型为已知类型，则判断所述崩溃文件为已修复或跟进中，并标注为所述已知类型的崩溃文件为已修复或跟进中；

所述第一处理模块，还用于若所述崩溃文件的所属类型为未知类型，则标注所述未知类型的崩溃文件为跟进中。

7.如权利要求6所述的崩溃文件处理装置，其特征在于，所述样本崩溃文件包括样本调用函数，所述判断单元包括：

匹配子单元，用于将定位到的所述开发代码调用函数与所述样本数据库中的样本调用函数进行匹配，并判断匹配结果是否成功；

第一判断子单元，用于若匹配结果为成功，则判断所述开发代码调用函数的所属类型为已知类型；

第二判断子单元，用于若匹配结果为失败，则判断所述开发代码调用函数的所属类型为未知类型；

第三判断子单元，用于根据所述开发代码调用函数的所属类型判断所述崩溃文件的所属类型。

8.如权利要求6至7中任一所述的崩溃文件处理装置，其特征在于，所述装置还包括：

快照模块，用于将崩溃文件形成windbg快照并与对应崩溃文件形成链接关系，所述windbg快照包括windbg接口函数以及所述对应崩溃文件的定位信息。

9.如权利要求6至7中任一所述的崩溃文件处理装置，其特征在于，所述已知类型包括已修复及跟进中，所述装置还包括：

第二接收模块，用于接收所述开发端返回的针对崩溃文件的分析结果，所述分析结果包括更改已知类型或保持已知类型；

更新模块，用于若分析结果为更改已知类型，则更新所述样本数据库中对应样本崩溃文件的已知类型为已修复；

保持模块，用于若分析结果为保持已知类型，则保持所述样本数据库中对应样本崩溃文件的已知类型不变。

10.如权利要求6至7中任一所述的崩溃文件处理装置，其特征在于，所述装置还包括：

第三接收模块，用于接收各个开发端针对所述崩溃文件的分析内容；

第二处理模块，用于响应于其中一个开发端发送的查看请求，发送其他一个或多个开发端的分析内容到发送查看请求的所述开发端上。

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

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

Images