发明内容
有鉴于此,本申请的目的在于提出一种崩溃解析方法、装置、电子设备及存储介质以解决或部分解决上述技术问题。
基于上述目的,本申请的第一方面提供了一种崩溃解析方法,包括:
接收崩溃文件;
对所述崩溃文件进行解析,得到所述崩溃文件的栈帧数据信息,其中,每个栈帧数据信息中包括至少一个栈帧;
将所述至少一个栈帧中的每个栈帧分别作为目标栈帧;
解析所述目标栈帧的属性信息,根据所述属性信息从数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,从所述目标存储空间中获取所述目标栈帧对应的符号数据;
将得到的所述至少一个栈帧对应的符号数据进行整合并输出。
在一些实施例中,在所述接收崩溃文件之前,所述方法还包括:
接收用于崩溃解析的符号表文件;
对所述符号表文件进行解析,得到多个符号数据;
将所述多个符号数据分装为至少一组,将至少一组符号数据通过中间转发器转发至所述数据库的至少一个存储空间中存储,其中,一组符号数据对应一个存储空间。
在一些实施例中,所述对所述符号表文件进行解析,得到多个符号数据,包括:
将所述符号表文件存储在临时存储器中;
确定对所述符号表文件进行解析的解析任务,根据所述解析任务生成对应的第一消息队列;
将所述第一消息队列发送至解析器中,利用所述解析器对所述临时存储器中的符号表文件进行解析,得到多个符号数据。
在一些实施例中,将所述多个符号数据分装为至少一组,将至少一组符号数据通过中间转发器转发至所述数据库的至少一个存储空间中存储,包括:
响应于确定所述符号表文件解析完成,所述中间转发器生成第二消息队列发送给所述解析器;
所述解析器将解析后的多个符号数据通过中间转发器转发至所述数据库;
利用所述数据库基于所述多个符号数据的地址信息,按照每组预定数量的地址信息进行分装,得到至少一组符号数据,将至少一组符号数据存储在数据库的至少一个存储空间中。
在一些实施例中,在利用所述数据库基于所述多个符号数据的地址信息,按照每组预定数量的地址信息进行分装之前,还包括:
确定每个符号数据的映射关系,将各个符号数据的映射关系记录到至少一种映射图中,将所述至少一种映射图存储在所述数据库中。
在一些实施例中,所述映射图包括下列至少之一:
表示功能范围关系的范围映射图;
表示地址关系的地址映射图;
表示包含功能关系的包含映射图。
在一些实施例中,在所述将至少一组符号数据通过中间转发器转发至所述数据库的至少一个存储空间中存储之后,还包括:
确定各个存储空间内的符号数据的数量,并将符号数据的数量小于第一阈值的存储空间作为稀疏存储空间;
统计所述稀疏存储空间的数量,响应于确定所述稀疏存储空间的数量大于第二阈值,对所述稀疏存储空间进行合并处理,合并到至少一个密集存储空间中,其中所述密集存储空间的存储数量小于等于所述预定数量。
在一些实施例中,所述根据所述属性信息从数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,从所述目标存储空间中获取所述目标栈帧对应的符号数据,包括:
将所述属性信息通过所述中间转发器发送至所述数据库中;
从所述数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,通过所述中间转发器从所述目标存储空间中获取所述目标栈帧对应的符号数据。
在一些实施例中,所述数据库包括下列至少之一:
用于存储所述符号数据的源信息的关系型数据库;
用于缓存符号查询指令的远程字典服务数据库;
包括所述至少一个存储空间的基础数据库。
在一些实施例中,所述解析所述目标栈帧的属性信息,包括:
根据所述目标栈帧的地址信息确定所述目标栈帧的名称;
通过所述中间转发器从所述关系型数据库中获取与所述目标栈帧的名称对应的目标源信息;
将所述目标源信息作为符号查询指令通过所述中间转发器缓存在所述远程字典服务数据库中;
基于所述目标栈帧的地址信息、所述目标栈帧的名称和所述目标源信息确定所述属性信息。
在一些实施例中,从所述数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,通过所述中间转发器从所述目标存储空间中获取所述目标栈帧对应的符号数据,包括:
通过所述中间转发器将所述属性信息发送至所述基础数据库;
利用所述基础数据库基于所述属性信息,依据与所述属性信息对应的至少一种映射图确定目标映射关系;
根据所述目标映射关系从所述基础数据库的至少一个存储空间中确定对应的目标存储空间,从所述目标存储空间中获取与所述目标映射关系对应的符号数据。
在一些实施例中,每个存储空间中的各个符号数据均以键值对的形式存储,其中,键值对包括:所述属性信息构成的键,所述符号数据构成的值。
基于同一个发明构思,本申请的第二方面提出了一种崩溃解析装置,包括:
崩溃文件接收模块,用于接收崩溃文件;
解析模块,用于对所述崩溃文件进行解析,得到所述崩溃文件的栈帧数据信息,其中,每个栈帧数据信息中包括至少一个栈帧;
符号获取模块,用于将所述至少一个栈帧中的每个栈帧分别作为目标栈帧;解析所述目标栈帧的属性信息,根据所述属性信息从数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,从所述目标存储空间中获取所述目标栈帧对应的符号数据;
输出模块,用于将得到的所述至少一个栈帧对应的符号数据进行整合并输出。
基于同一个发明构思,本申请的第三方面提出了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现第一方面所述的方法。
基于同一个发明构思,本申请的第四方面提出了一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令用于使计算机执行第一方面所述的方法。
从上面所述可以看出,本申请提供的崩溃解析方法、装置、电子设备及存储介质,预先将符号数据分装到数据库的各个存储空间中进行存储,这样接收到崩溃文件后,对崩溃文件解析得到栈帧数据信息,对栈帧数据信息中的每个栈帧从各个存储空间中查找对应的目标存储空间,再从目标存储空间中解析匹配,确定该栈帧对应的符号数据,由于每个存储空间内的符号数据的数量相对较小,使得数据读取量大大减少,并且还能加快解析匹配时间;最后,将栈帧数据信息解析匹配对应的一个或多个符号数据整合后形成解析结果输出,以供根据输出的解析结果对崩溃文件进行判定,及时制定针对崩溃情况的解决策略。这种崩溃解析方式,能够使得解析的效率得到有效的提高,减少崩溃解析时间,由于解析过程中读取量大大减少,使得读取压力得到有效降低。
具体实施方式
下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解,给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请,而并非以任何方式限制本申请的范围。相反,提供这些实施方式是为了使本申请更加透彻和完整,并且能够将本申请的范围完整地传达给本领域的技术人员。
在本申请中,需要理解的是,附图中的任何元素数量均用于示例而非限制,以及任何命名都仅用于区分,而不具有任何限制含义。
本申请提供了一种崩溃解析方案,预先将符号数据分装到数据库的各个存储空间中进行存储,这样接收到崩溃文件后,对崩溃文件解析得到栈帧数据信息,对栈帧数据信息中的每个栈帧从各个存储空间中查找对应的目标存储空间,再从目标存储空间中解析匹配,确定该栈帧对应的符号数据,由于每个存储空间内的符号数据的数量相对较小,使得数据读取量大大减少,并且还能加快解析匹配时间;最后,将栈帧数据信息解析匹配对应的一个或多个符号数据整合后形成解析结果输出,以供根据输出的解析结果对崩溃文件进行判定,及时制定针对崩溃情况的解决策略。
下面参考本申请的若干代表性实施方式,详细阐释本申请的原理和精神。
参考图1A,其为本申请实施例提供的崩溃解析方法的应用场景示意图。该应用场景包括终端设备101、服务器102和数据存储***103。其中,终端设备101、服务器102以及数据存储***103之间均可通过有线或无线的通信网络连接。终端设备101包括但不限于PC端(Personal Computer,个人计算机)、桌面计算机、移动电话、移动电脑、平板电脑、媒体播放器、智能可穿戴设备视、个人数字助理(personal digital assistant,PDA)或其它能够实现上述功能的电子设备等。服务器102和数据存储***103均可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式***,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。
服务器102用于向终端设备101的用户提供崩溃解析服务,终端设备101中安装有与服务器102通信的客户端,当终端设备101的应用程序出现崩溃的情况时,可以通过客户端向服务器102发送崩溃文件。服务器102对崩溃文件解析得到栈帧数据信息,对栈帧数据信息中的每个栈帧从各个存储空间中查找对应的目标存储空间,再从目标存储空间中解析匹配,确定该栈帧对应的符号数据;最后,将栈帧数据信息解析匹配对应的一个或多个符号数据整合后形成解析结果输出。可以将解析结果在服务器102的显示界面进行显示以供相关人员查看,进而确定崩溃原因对崩溃情况进行处理。也可以是将解析结果反馈至终端设备101或者其他的具有显示功能的电子设备上,以供查看。数据存储***103为服务器102的工作运行提供数据存储支持,例如,对崩溃文件进行临时存储,对执行崩溃解析方法的程序进行存储。
在服务器102中搭建用于崩溃解析的基础架构,具体如图1B所示,该基础架构包括:
符号表上传模块(fine_symbolicate),与终端设备的apigateway(流量转发模块)连接,终端设备的打包平台/RD能够将符号表文件打包打包成symbolicate.byted.org/android_upload,通过apigateway转发至符号表上传模块,符号表上传模块用于将符号表文件进行上传。
临时存储器(tbs),与符号表上传模块连接,符号表上传模块将符号表文件上传至tbs中进行临时存储。
解析器(dumped_sym_parser),符号表上传模块会生成一个消息队列(RocketMQ)发送给解析器,解析器对临时存储器中存储的符号表文件进行解析。
中间转发器(pc_date_proxy),与解析器连接,用于对一些指令或数据进行中间转发。
关系型数据库(MySQL),与中间转发器连接,解析器对符号表文件进行解析后,能够通过中间转发器将解析后的符号表的源文件存储在关系型数据库中。
远程字典服务数据库(redis),与中间转发器连接,用于对MySQL中所需的请求或者数据进行临时存储。
基础数据库(ABase),与中间转发器连接,用于对符号表文件解析后得到的多个符号数据进行分装,分装成多个Bucket(存储空间)进行存储。
崩溃文件解析模块(pc_stack_walk),与中间转发器连接,用于对接收的崩溃文件(RPC,Remote Procedure Call,远程过程调用请求),并对崩溃文件进行解析,根据解析结果通过中间转发器利用关系型数据库从基础数据库的相应目标存储空间中获取与崩溃文件对应的一个或多个符号数据,将符号数据整合后输出。
下面结合图1A和图1B所示的应用场景,来描述根据本申请示例性实施方式的崩溃解析方法。需要注意的是,上述应用场景仅是为了便于理解本申请的精神和原理而示出,本申请的实施方式在此方面不受任何限制。相反,本申请的实施方式可以应用于适用的任何场景。
本申请实施例提供了一种崩溃解析方法,该崩溃解析方法应用于服务器。
本实施例的崩溃解析方法,在对崩溃文件进行崩溃解析之前需要对崩溃解析所需的符号表文件进行存储,如图2A所示,存储的过程包括:
步骤2A1,接收用于崩溃解析的符号表文件。
具体实施时,终端设备上的打包平台(即安装在终端设备的客户端)将生成的符号表文件进行打包,打包之后形成打包文件(例如,symbolicate.byted.org/android_upload),通过流量转发模块(apigateway)转发至符号表上传模块(fine_symbolicate)中。
步骤2A2,对所述符号表文件进行解析,得到多个符号数据。
具体实施时,符号表文件内容较多,会包含大量的符号数据,需要将符号表文件中包含的这些符号数据解析出来,并分装成多个部分(bucket)进行存储。
在一些实施例中,步骤2A2具体过程包括:
步骤2A21,将所述符号表文件存储在临时存储器中。
具体实施时,符号表上传模块将符号表文件上传至临时存储器(tbs)中进行临时存储。方便后续进行调用解析。
步骤2A22,确定对所述符号表文件进行解析的解析任务,根据所述解析任务生成对应的第一消息队列。
具体实施时,符号表文件在临时存储器中存储完成后,符号表上传模块就会根据解析任务生成第一消息队列(RocketMQ),将第一消息队列发送给解析器。
步骤2A23,将所述第一消息队列发送至解析器中,利用所述解析器对所述临时存储器中的符号表文件进行解析,得到多个符号数据。
具体实施时,解析器接收到第一消息队列后,开始从临时存储器中调取符号表文件进行解析,将庞大的符号表文件解析成多个符号数据,解析过程中还会将符号数据对应的映射关系以及各个符号数据的源信息(例如,符号数据的来源)一起解析出来,映射关系包括下列至少之一:功能范围、地址关系以及包含功能关系等。
步骤2A3,将所述多个符号数据分装为至少一组,将至少一组符号数据通过中间转发器转发至所述数据库的至少一个存储空间中存储,其中,一组符号数据对应一个存储空间。
通过上述步骤,能够将符号数据分装成多个存储空间(bucket)进行存储,这样后续对崩溃文件解析后进行调取查找过程中,只需从对应的一个或多个存储空间中查找崩溃文件对应的符号数据即可,无需调取查找整个符号表文件,能够节省查找时间,提高崩溃解析的效率。
在一些实施例中,步骤2A3具体包括:
步骤2A31,响应于确定所述符号表文件解析完成,所述中间转发器生成第二消息队列发送给所述解析器。
具体实施时,中间转发器对符号表文件解析完成后,中间转发器能够抓取到解析完成的消息,这样中间转发器就会生成第二消息队列(RocketMQ),发送给解析器,进而使得解析器启动发送过程。
步骤2A32,所述解析器将解析后的多个符号数据通过中间转发器转发至所述数据库。
具体实施时,解析器接收到第二消息队列之后,就会将解析完成后的符号数据、源信息以及映射关系发送至中间转发器进行转发。中间转发器具有中间路由转发的功能,能够根据具体的数据信息为之匹配合适的数据库中。
在一些实施例中,所述数据库包括下列至少之一:
用于存储所述符号数据的源信息的关系型数据库(MySQL);用于缓存符号查询指令的远程字典服务数据库(redis);包括所述至少一个存储空间的基础数据库(ABase)。
当解析器发给中间转发器的是源信息,中间转发器将该源信息转发给关系型数据库;当解析器发给中间转发器的是符号数据或者映射关系,将其转发给基础数据库。
步骤2A33,确定每个符号数据的映射关系,将各个符号数据的映射关系记录到至少一种映射图中,将所述至少一种映射图存储在所述数据库中。
具体实施时,映射关系代表符号数据的一些特征,包括功能特征以及属性特征等,后续可以通过这些特征对符号数据进行查找。
在一些实施例中,所述映射图包括下列至少之一:
表示功能范围关系的范围映射图(RangeMap);表示地址关系的地址映射图(AddressMap);表示包含功能关系的包含映射图(ContainedRangeMap)。
利用各个映射图记录映射关系的程序如下:
通过上述方案,能够将符号数据的各类映射关系利用映射图的形式进行存储,这样后续进行崩溃解析时可以根据各个映射图确定相应的映射关系,进而根据映射关系查找相应的符号数据,符号数据包括方法名以及代码行的行号等信息。
步骤2A34,利用所述数据库基于所述多个符号数据的地址信息,按照每组预定数量的地址信息进行分装,得到至少一组符号数据,将至少一组符号数据存储在数据库的至少一个存储空间中。
在一些实施例中,每个存储空间中的各个符号数据均以键值对的形式存储,其中,键值对包括:符号数据的属性信息构成的键,符号数据构成的值。
属性信息包括:地址信息、名称或者源信息,这样后续可以根据崩溃信息中各个栈帧的属性信息在各个映射图中查找相应的映射关系,进而根据映射关系从相应的存储空间中调取符号数据。
在一些实施例中,该方法还包括:
步骤2A4,确定各个存储空间内的符号数据的数量,并将符号数据的数量小于第一阈值的存储空间作为稀疏存储空间。
步骤2A5,统计所述稀疏存储空间的数量,响应于确定所述稀疏存储空间的数量大于第二阈值,对所述稀疏存储空间进行合并处理,合并到至少一个密集存储空间中,其中所述密集存储空间的存储数量小于等于所述预定数量。
目前mac符号表文件有时存在极其稀疏的情况,往往在首部存在一部分符号,中间有空洞(例如空洞大小为1G或1G以上的空间),导致产生大量bucket,存储冗余变多,使得键(key)规模从几万上升到百万或千万级别,符号表文件dump入数据库产生大量堆积。
根据稀疏特性,可以采用类似多级页表的方式,进行多级划分组块(chunk),对于稀疏部分(即,稀疏存储空间)合并存储密集存储空间(例如,大bucket),极大减少了bucket数目,从百万千万级别,降低为几千几万级别,使得后续崩溃解析的时间能够从小时级别,减少到分钟级别。极大的提高了崩溃解析的效率。
崩溃解析的过程,如图2B所示,包括:
步骤2B1,接收崩溃文件。
具体实施时,终端设备上如果发生崩溃的情况,安装在终端设备的客户端就会将崩溃情况整合成崩溃文件上传到服务器上。其中,该崩溃文件为包括RPC请求的dump文件。具体利用服务器上的崩溃文件解析模块(pc_stack_walk)接收上传的崩溃文件。
步骤2B2,对所述崩溃文件进行解析,得到所述崩溃文件的栈帧数据信息,其中,每个栈帧数据信息中包括至少一个栈帧。
具体实施时,利用利用崩溃文件解析模块根据崩溃文件解析得到崩溃文件的上下文(即,至少一个栈帧),并确定各个栈帧对应的名称(例如,moudle)和地址(例如,address)。
步骤2B3,将所述至少一个栈帧中的每个栈帧分别作为目标栈帧。
具体实施时,从解析得到的第一个栈帧开始,将第一个栈帧作为目标栈帧开始进行查询。
步骤2B4,解析所述目标栈帧的属性信息,根据所述属性信息从数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,从所述目标存储空间中获取所述目标栈帧对应的符号数据。
具体实施时,利用崩溃文件解析模块对第一个栈帧(即,目标栈帧)进行解析,确定第一个栈帧对应的属性信息。由于数据库中的属性信息和符号数据是以键值对的形式存储的,因此解析出第一个栈帧的属性信息之后,就可以依据该属性信息查询第一个栈帧对应的方法名和代码行的行号等符号数据。
在一些实施例中,步骤2B4具体包括:
步骤2B41,根据所述目标栈帧的地址信息确定所述目标栈帧的名称。
具体实施时,利用崩溃文件解析模块依据第一个栈帧(即,目标栈帧)的地址,解析出该栈帧所属的名称(module)。
步骤2B42,通过所述中间转发器从所述关系型数据库中获取与所述目标栈帧的名称对应的目标源信息。
具体实施时,崩溃文件解析模块将目标栈帧的名称通过中间转发器转发至关系型数据库,从关系型数据库中查找与该名称对应的目标源信息(meta信息),得到chunk_size的大小。
步骤2B43,将所述目标源信息作为符号查询指令通过所述中间转发器缓存在所述远程字典服务数据库中。
具体实施时,利用中间转发器作为中转,将目标源信息缓存在远程字典服务数据库(redis)中,方便调用。
步骤2B44,基于所述目标栈帧的地址信息、所述目标栈帧的名称和所述目标源信息确定所述属性信息。
具体实施时,根据目标栈帧的address、chunk_size、module,可以得到该address所属chunk的abase key(即,键),其中,abase key=module_name+(address/chunk_size)
步骤2B45,将所述属性信息通过所述中间转发器发送至所述数据库中。
步骤2B46,从所述数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,通过所述中间转发器从所述目标存储空间中获取所述目标栈帧对应的符号数据。
在一些实施例中,步骤2B46具体包括:
步骤2B461,通过所述中间转发器将所述属性信息发送至所述基础数据库。
步骤2B462,利用所述基础数据库基于所述属性信息,依据与所述属性信息对应的至少一种映射图确定目标映射关系。
步骤2B463,根据所述目标映射关系从所述基础数据库的至少一个存储空间中确定对应的目标存储空间,从所述目标存储空间中获取与所述目标映射关系对应的符号数据。
具体实施时,具体实施时,将根据属性信息确定的abase key可以查询出该目标栈帧address所属chunk的几个map(即,映射图)的数据结构(RangeMap、AddressMap、ContainedRangeMap,这几个map会存储内存地址到方法信息、以及回溯栈帧方式的映射关系)。
基础数据库得到map数据结构后,可以通过映射关系查询到该目标栈帧所在的目标存储空间,从目标存储空间中查询与该属性信息确定的键(abase key)的符号数据(即,与该目标栈帧对应的方法名和行号)。并且通过包含映射图(ContainedRangeMap)可以找到下一个栈帧,按照上述步骤2B41至2B46的过程继续进行下一个栈帧的符号数据(例如,方法名和行号)的还原。
通过上述方案,按照得到的栈帧的排序依次得到各个栈帧对应的符号数据,这种通过键值对的方式进行符号数据的查找能够快速的提高查号效率。
步骤2B5,将得到的所述至少一个栈帧对应的符号数据进行整合并输出。
具体实施时,通过上述过程得到各个栈帧对应的符号数据,将这些符号数据按照解析后的栈帧的排序,对符号数据进行排序整合,得到最终的解析结果,将解析结果输出至能够进行显示的显示界面上。其中,显示界面可以是直接设置在服务器上的显示界面,也可以是其他与服务器通过有线或无线的方式连接的显示界面。这样用户就可以通过显示界面获知崩溃文件解析后的符号数据的内容,进而快速确定崩溃的原因。
通过上述实施例的方案,预先将符号数据分装到数据库的各个存储空间中进行存储,这样接收到崩溃文件后,对崩溃文件解析得到栈帧数据信息,对栈帧数据信息中的每个栈帧从各个存储空间中查找对应的目标存储空间,再从目标存储空间中解析匹配,确定该栈帧对应的符号数据,由于每个存储空间内的符号数据的数量相对较小,使得数据读取量大大减少,并且还能加快解析匹配时间;最后,将栈帧数据信息解析匹配对应的一个或多个符号数据整合后形成解析结果输出,以供根据输出的解析结果对崩溃文件进行判定,及时制定针对崩溃情况的解决策略。
这种崩溃解析方式,能够使得解析的效率得到有效的提高,减少崩溃解析时间,由于解析过程中读取量大大减少,使得读取压力得到有效降低,本申请的方案基于原始的崩溃符号解析方案,平均耗时降低了42.9倍,能够满足线上崩溃实时、大批量解析的需求。
需要说明的是,本申请实施例的方法可以由单个设备执行,例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下,由多台设备相互配合来完成。在这种分布式场景的情况下,这多台设备中的一台设备可以只执行本申请实施例的方法中的某一个或多个步骤,这多台设备相互之间会进行交互以完成所述的方法。
需要说明的是,上述对本申请的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
基于同一发明构思,与上述任意实施例的崩溃解析方法相对应的,本申请还提供了一种崩溃解析装置。
参考图3,崩溃解析装置,包括:
崩溃文件接收模块31,用于接收崩溃文件;
解析模块32,用于对所述崩溃文件进行解析,得到所述崩溃文件的栈帧数据信息,其中,每个栈帧数据信息中包括至少一个栈帧;
符号获取模块33,用于将所述至少一个栈帧中的每个栈帧分别作为目标栈帧;解析所述目标栈帧的属性信息,根据所述属性信息从数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,从所述目标存储空间中获取所述目标栈帧对应的符号数据;
输出模块34,用于将得到的所述至少一个栈帧对应的符号数据进行整合并输出。
在一些实施例中,装置还包括:
符号表接收模块,用于接收崩溃解析的符号表文件;
解析模块32,用于对所述符号表文件进行解析,得到多个符号数据;
存储模块,用于将所述多个符号数据分装为至少一组,将至少一组符号数据通过中间转发器转发至所述数据库的至少一个存储空间中存储,其中,一组符号数据对应一个存储空间。
在一些实施例中,解析模块32包括:
临时存储单元,用于将所述符号表文件存储在临时存储器中;
第一消息生成单元,用于确定对所述符号表文件进行解析的解析任务,根据所述解析任务生成对应的第一消息队列;
解析单元,用于将所述第一消息队列发送至解析器中,利用所述解析器对所述临时存储器中的符号表文件进行解析,得到多个符号数据。
在一些实施例中,存储模块包括:
第二消息生成单元,用于确定所述符号表文件解析完成,所述中间转发器生成第二消息队列发送给所述解析器;
转发单元,用于利用所述解析器将解析后的多个符号数据通过中间转发器转发至所述数据库;
存储单元,用于利用所述数据库基于所述多个符号数据的地址信息,按照每组预定数量的地址信息进行分装,得到至少一组符号数据,将至少一组符号数据存储在数据库的至少一个存储空间中。
在一些实施例中,存储模块还包括:
映射解析单元,用于确定每个符号数据的映射关系,将各个符号数据的映射关系记录到至少一种映射图中,将所述至少一种映射图存储在所述数据库中。
在一些实施例中,所述映射图包括下列至少之一:
表示功能范围关系的范围映射图;
表示地址关系的地址映射图;
表示包含功能关系的包含映射图。
在一些实施例中,所述存储模块还包括:稀疏处理单元,具体用于:
确定各个存储空间内的符号数据的数量,并将符号数据的数量小于第一阈值的存储空间作为稀疏存储空间;统计所述稀疏存储空间的数量,响应于确定所述稀疏存储空间的数量大于第二阈值,对所述稀疏存储空间进行合并处理,合并到至少一个密集存储空间中,其中所述密集存储空间的存储数量小于等于所述预定数量。
在一些实施例中,符号获取模块33包括:
属性转发单元,用于将所述属性信息通过所述中间转发器发送至所述数据库中;
查找单元,用于从所述数据库的至少一个存储空间中确定与所述属性信息对应的目标存储空间,通过所述中间转发器从所述目标存储空间中获取所述目标栈帧对应的符号数据。
在一些实施例中,所述数据库包括下列至少之一:
用于存储所述符号数据的源信息的关系型数据库;
用于缓存符号查询指令的远程字典服务数据库;
包括所述至少一个存储空间的基础数据库。
在一些实施例中,符号获取模块33包括:属性解析单元,具体用于:
根据所述目标栈帧的地址信息确定所述目标栈帧的名称;通过所述中间转发器从所述关系型数据库中获取与所述目标栈帧的名称对应的目标源信息;将所述目标源信息作为符号查询指令通过所述中间转发器缓存在所述远程字典服务数据库中;基于所述目标栈帧的地址信息、所述目标栈帧的名称和所述目标源信息确定所述属性信息。
在一些实施例中,查找单元,具体用于:
通过所述中间转发器将所述属性信息发送至所述基础数据库;利用所述基础数据库基于所述属性信息,依据与所述属性信息对应的至少一种映射图确定目标映射关系;根据所述目标映射关系从所述基础数据库的至少一个存储空间中确定对应的目标存储空间,从所述目标存储空间中获取与所述目标映射关系对应的符号数据。
在一些实施例中,每个存储空间中的各个符号数据均以键值对的形式存储,其中,键值对包括:所述属性信息构成的键,所述符号数据构成的值。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
上述实施例的装置用于实现前述任一实施例中相应的方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
基于同一发明构思,与上述任意实施例方法相对应的,本申请还提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上任意一实施例所述的方法。
图4示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图,该设备可以包括:处理器410、存储器420、输入/输出接口430、通信接口440和总线450。其中处理器410、存储器420、输入/输出接口430和通信接口440通过总线450实现彼此之间在设备内部的通信连接。
处理器410可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本说明书实施例所提供的技术方案。
存储器420可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器420可以存储操作***和其他应用程序,在通过软件或者固件来实现本说明书实施例所提供的技术方案时,相关的程序代码保存在存储器420中,并由处理器410来调用执行。
输入/输出接口430用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口440用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线450包括一通路,在设备的各个组件(例如处理器410、存储器420、输入/输出接口430和通信接口440)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器410、存储器420、输入/输出接口430、通信接口440以及总线450,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本说明书实施例方案所必需的组件,而不必包含图中所示的全部组件。
上述实施例的电子设备用于实现前述任一实施例中相应的崩溃解析方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
基于同一发明构思,与上述任意实施例方法相对应的,本申请还提供了一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令用于使所述计算机执行如上任一实施例所述的方法。
本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。
上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
所属领域的普通技术人员应当理解:以上任何实施例的讨论仅为示例性的,并非旨在暗示本申请的范围(包括权利要求)被限于这些例子;在本申请的思路下,以上实施例或者不同实施例中的技术特征之间也可以进行组合,步骤可以以任意顺序实现,并存在如上所述的本申请实施例的不同方面的许多其它变化,为了简明它们没有在细节中提供。
另外,为简化说明和讨论,并且为了不会使本申请实施例难以理解,在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外,可以以框图的形式示出装置,以便避免使本申请实施例难以理解,并且这也考虑了以下事实,即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请实施例的平台的(即,这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如,电路)以描述本申请的示例性实施例的情况下,对本领域技术人员来说显而易见的是,可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请实施例。因此,这些描述应被认为是说明性的而不是限制性的。
尽管已经结合了本申请的具体实施例对本申请进行了描述,但是根据前面的描述,这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如,其它存储器架构(例如,动态RAM(DRAM))可以使用所讨论的实施例。
本申请实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此,凡在本申请实施例的精神和原则之内,所做的任何省略、修改、等同替换、改进等,均应包含在本申请的保护范围之内。