CN105843741B - 应用程序的信息处理方法和装置 - Google Patents
应用程序的信息处理方法和装置 Download PDFInfo
- Publication number
- CN105843741B CN105843741B CN201610177236.1A CN201610177236A CN105843741B CN 105843741 B CN105843741 B CN 105843741B CN 201610177236 A CN201610177236 A CN 201610177236A CN 105843741 B CN105843741 B CN 105843741B
- Authority
- CN
- China
- Prior art keywords
- thread
- function call
- task
- information
- call stack
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
Abstract
本发明公开了一种应用程序的信息处理方法和装置。其中,该方法包括:根据本发明实施例的一个方面,提供了一种应用程序的信息处理方法,该信息处理方法包括:检测当前运行的应用程序是否出现异常;在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;将已开始执行的任务的信息发送至应用程序的服务器。本发明解决了在程序发生crash时,无法准确定位crash原因的技术问题。
Description
技术领域
本发明涉及计算机领域,具体而言,涉及一种应用程序的信息处理方法和装置。
背景技术
现有的安卓Andoid开发IDE(即android studio)在断点调试时,可以查看当前的函数调用栈;产品外发版本发生crash(即,程序崩溃)时,现有的程序崩溃上报平台也可以上报程序发生崩溃时的函数调用栈,程序开发根据上报的调用栈内容可以定位程序发生崩溃的原因,并基于该定位的原因做修正。
图1示出了现有技术中的多线程环境的数据结构,如图1所示,现有技术方案中,一个进程中可以包括多个线程,如图1示出的线程A和线程B,线程A中包括任务队列,线程B中也包括一个任务队列,如果在应用程序执行任务的过程中,线程A中抛一个异步任务T1到线程B中执行,则该异步任务T1会先添加到线程B的任务队列中,线程B会按顺序从队列中去获取任务,并一一执行。采用该方案,如果在线程B中执行任务时发生crash,则程序只能获取到在线程B中的函数调用堆栈,并将该线程B中的函数调用堆栈上报至crash上报平台。
由上可知,不管是现有的IDE或者现有的crash上报平台,在程序执行任务过程中发生crash时都只能获取当前线程的调用栈。如果外发版本crash在一个子线程,则获取该子线程的函数调用栈,而无法追溯之前线程的调用栈。由于触发一个操作的起因很多,若程序执行该操作时发生crash,只能获取当前线程的函数调用栈,无法还原用户的使用场景,无法获知触发该操作的起因,因此也无法定位发生crash的真正原因。
针对上述在程序发生crash时,无法准确定位crash原因的问题,目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种应用程序的信息处理方法和装置,以至少解决在程序发生crash时,无法准确定位crash原因的技术问题。
根据本发明实施例的一个方面,提供了一种应用程序的信息处理方法,该信息处理方法包括:检测当前运行的应用程序是否出现异常;在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;将已开始执行的任务的信息发送至应用程序的服务器。
根据本发明实施例的另一方面,还提供了一种应用程序的信息处理装置,该信息处理装置包括:检测单元,用于检测当前运行的应用程序是否出现异常;第一获取单元,用于在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;发送单元,用于将已开始执行的任务的信息发送至应用程序的服务器。
在本发明实施例中,若当前运行的应用程序发生异常,则获取已开始执行的任务的信息,并将获取的已开始执行的任务的信息发送至应用程序的服务器,从而可以在程序发生crash时,获取已开始执行的所有程序任务的函数调用信息,以获取完整的各个线程的堆栈信息,服务器在获取完整的堆栈信息之后,可以还原程序发生crash的场景,从而可以准确定位程序发生crash的原因,解决了现有技术中在程序发生crash时,无法准确定位crash原因的问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据现有技术的一种多线程环境的数据结构的示意图;
图2是根据本发明实施例的一种可选的网络环境的示意图;
图3是根据本发明实施例的一种可选的应用程序的信息处理方法的流程图;
图4是根据本发明实施例的一种多线程环境的数据结构的示意图;
图5是根据本发明实施例的另一种可选的应用程序的信息处理方法的流程图;
图6是根据本发明实施例的再一种可选的应用程序的信息处理方法的流程图;
图7是根据现有技术中的crash上报内容的示意图;
图8是根据本发明实施例的crash上报内容的示意图;
图9是根据本发明实施例的应用程序的信息处理装置的示意图;
图10是根据本发明实施例的计算机终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先,对本申请涉及的术语解释如下:
函数调用堆栈(call stack):在计算机领域,函数调用堆栈是一个存储方法列表的数据结构,其中按调用顺序保存了所有在运行期间被调用的方法。在程序crash时,或者在调试程序时,可以获取当前的函数调用堆栈。
线程本地存储(TLS):在进程中,所有线程是共享地址空间的,对于一个全局变量或者是静态变量,所有线程访问的都是同一份,如果某个线程对其进行了修改,就会影响到其他所有的线程,针对这种情况,计算机操作系统提供了线程本地存储功能(TLS),其作用是将数据和特定的线程联系起来,各个线程访问和修改自己的数据不互相影响。
Crash,在计算机系统压力或性能测试过程中,有时出现因某种原因宕机,或主机、程序停止工作、停止响应、进程中断等情况,如程序崩溃等。
实施例1
根据本发明实施例,提供了一种无线网络信息的处理方法的实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
可选地,在本实施例中,上述无线网络信息的处理方法以应用于如图2所示的网络环境中。该网络环境包括终端201和服务器203(该服务器可以为网络连接应用的服务器或云平台),其中,终端可以与服务器通过网络建立连接,终端和服务器上均可以设置处理器。
上述网络包括但不限于:广域网、城域网或局域网。优选地,上述的网络为局域网;上述终端可以包括个人计算机,可选地,该终端为移动终端(如手机、平板电脑等)。
图3是根据本发明实施例的应用程序的信息处理方法的流程图,如图3所示,该方法包括如下步骤:
步骤S301:检测当前运行的应用程序是否出现异常;
步骤S303:在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;
步骤S305:将已开始执行的任务的信息发送至应用程序的服务器。
采用本发明的上述实施例,若当前运行的应用程序发生异常,则获取已开始执行的任务的信息,并将获取的已开始执行的任务的信息发送至应用程序的服务器,从而可以在程序发生crash时,获取已开始执行的所有程序任务的函数调用信息,以获取完整的各个线程的堆栈信息,服务器在获取完整的堆栈信息之后,可以还原程序发生crash的场景,从而可以准确定位程序发生crash的原因,解决了现有技术中在程序发生crash时,无法准确定位crash原因的问题。
上述实施例的步骤S301中,安装有应用程序的终端的处理器在启动该应用程序之后,该终端的处理器中的执行器执行该应用程序的任务,以运行该应用程序的功能,具体地,处理器在执行应用程序的任务的过程中,可以实时检测该应用程序是否发生异常,即,检测该应用程序是否发生crash,如,检测应用程序是否停止工作、停止响应、进程中断等。
若检测出该应用程序发生crash,处理器获取已开始执行的所有任务的函数调用信息,该函数调用信息可以定位异常发生的位置和原因,将该函数调用信息上报到应用程序的服务器(如crash平台),开发者在获取到该函数调用信息之后,可以通过还原后的信息分析crash的原因。
可选地,该终端可以为安装有安卓操作系统的终端,当检测到程序在执行某个任务出现crash时,可以按照以下步骤还原出完整的调用堆栈:先通过安卓平台(即Android平台)提供的Throwable类对象,获取出上述的函数调用信息,将获取到的函数调用信息上报到crash平台,这样开发就可以通过还原后的完整的信息来分析crash原因了。
Throwable类是java语音中所有错误或异常的超类,该类中的信息通常用于指示发生了异常情况,可选地,该Throwable类的实例是在异常情况的上下文中新近创建的,该Throwable类对象中包含了异常的相关信息,如堆栈跟踪数据。
上述实施例中,对异常进行定位具体是指,在发生异常时,获取的已开始执行的任务的信息中可以看到程序的堆栈信息,在该堆栈信息中可以看到在哪个类、哪个函数中出的错,若无法确定在哪个类、哪个函数出的错,可以重新执行一次上述的已开始执行的任务中触发异常的任务入口,以定位出发生异常的任务入口、异常发生的原因等。在定位该异常之后,可以基于定位的该异常的原因、位置等信息,对应用程序的源代码进行修正,以修复该异常。
根据本发明的上述实施例,获取应用程序在运行的过程中已开始执行的任务的信息可以包括:获取用于执行已开始执行的任务的所有线程的函数调用信息,其中,已开始执行的任务的信息包括函数调用信息。
在上述实施例中,上述的已开始执行的任务可以包括同步任务,也可以包括异步任务。在已开始执行的任务包括同步任务的情况下,除发生异常时执行的任务外,其余的已开始执行的同步任务均已完成;在已开始执行的任务包括异步任务的情况下,已经开始执行的异步任务均可能未完成,换句话说,均可能处于当前执行的状态。
上述实施例中的所有线程包括所有执行过或正在执行所述已开始执行的任务的线程,如,该线程包括发生异常的线程和向该发生异常的线程发起异步任务的线程。
函数调用信息中记录了函数调用的顺序,每调用一次函数对应执行一个任务。
通过上述实施例,能够还原多线程环境下异步函数调用堆栈,当外发产品crash时能够获取到还原后的各个线程的完整的堆栈信息,从而帮助定位crash的原因。
下面以异步任务为例,对上述实施例进行解释说明。可以使用异步任务执行模块执行上述的已开始执行的任务,具体地,产品程序底层提供统一的异步任务执行模块XTask,所有的异步任务都通过Xtask提供的post接口来发起,在发起异步任务时,一并将该线程中所有的函数调用堆栈信息发送至执行异步任务的线程,当任务真正执行时,将暂存的堆栈信息列表写入到当前线程中,当任务执行时发生crash,XTask模块就可以从当前线程中获取出之前的所有堆栈信息列表(即上述实施例中的函数调用信息),并做上报。
具体地,获取用于执行已开始执行的任务的所有线程的函数调用信息可以包括:获取出现异常的第一线程的第一函数调用堆栈信息;从第一线程的线程本地存储单元中,获取预先保存的第二线程的第二函数调用堆栈信息,其中,第二线程为向第一线程发起异步任务的线程,函数调用信息包括第一函数调用堆栈信息和第二函数调用堆栈信息,所有线程包括第一线程和第二线程。
其中,出现异常的第一线程即为发生异常的任务所在的线程。
在上述实施例中,在应用程序开始运行之后,检测当前运行的应用程序是否出现异常,在检测到应用程序出现异常的情况下,通过终端的操作系统提供的异常类对象,获取出现异常的第一线程的第一函数调用堆栈信息,并从第一线程的线程本地存储单元中,取出预先保存的之前的所有线程的第二函数调用堆栈信息,将该第一函数调用堆栈信息和第二函数调用堆栈信息组合起来,上报到crash平台(即上述实施例中的服务器),服务器侧可以通过该组合的函数调用信息分析异常发生的原因,以定位该异常。
在本发明的上述实施例中,采用了不同于图1所示的数据结构,如图4所示,在多线程异步函数调用堆栈的场景中,每个线程都设置有一个任务队列和线程本地存储单元TLS,其中的任务队列用于保存该线程待执行的任务,在线程本地存储单元TLS中存储之前所有的调用堆栈信息列表。
下面以异步任务为例,详述本发明上述实施例:
通过异步任务执行模块XTask提供的post接口来发起,XTask模块在发起异步任务之前,将获取出之前所有的调用堆栈信息列表,将其暂存到异步任务对象中,当任务真正执行时,将暂存的堆栈信息列表写入到当前线程的TLS中,当任务执行时发生crash,XTask模块就可以从TLS中获取出之前的所有堆栈信息列表(即上述实施例中的函数调用信息),并上报该堆栈信息列表,从而可以确定该堆栈信息列表定位异常原因。
可选地,已开始执行的任务包括:在发生异常前开始执行并且执行完成的任务和在发生异常前开始执行但尚未执行完成的任务(即正在执行的任务)。
对于同步任务来讲,一个任务完成才执行下一个任务,因此,若已开始执行的任务为同步任务,则该已开始执行的任务包括已经执行完成的任务和当前执行的发生异常的任务。
对于异步任务来讲,不会等一个任务完成才执行下一个任务,因此,若已开始执行的任务为异步任务,则该已开始执行的任务包括已经执行完成的任务、未执行完成的任务和发生异常的当前执行的任务。
需要进一步说明的是,在应用程序运行的过程中,方法还可以包括:在第二线程向第一线程发起异步任务之前,获取第二线程的第二函数调用堆栈信息;在第一线程执行异步任务之前,将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中,其中,已开始执行的任务包括异步任务。
通过上述方案,可以按照顺序保存下所有线程的堆栈信息,当程序在执行某个任务出现crash时,可以按照上述实施例中获取函数调用信息的方案还原出完整的调用堆栈。
具体地,在第二线程抛出异步任务之前,获取第二函数调用堆栈信息,并将该第二函数调用堆栈信息传递给第一线程,第一线程将该第二函数调用堆栈信息保存在第一线程的线程本地存储单元中。
可选地,在检测出应用程序出现异常时,则可以获取第一线程的第一函数调用堆栈信息,并从第一线程的线程本地存储单元中,获取预先保存的第二线程的第二函数调用堆栈信息,利用第一函数调用堆栈信息和第二函数调用堆栈信息的组合信息定位异常。
具体地,获取第二线程的第二函数调用堆栈信息可以包括:获取第二线程的当前函数调用堆栈信息;从第二线程的线程本地存储单元中,读取预先保存的前序线程的函数调用堆栈信息;将当前函数调用堆栈信息和前序线程的函数调用堆栈信息作为第二函数调用堆栈信息,其中,前序线程为在第二线程执行已开始执行的任务之前执行已开始执行的任务的线程。
在该实施例中,将在第二线程执行任务之前的线程称之为第二线程的前序线程,前序线程向第二线程发起异步任务时,将前序线程中当前的函数调用堆栈信息和在线程本地存储单元中保存的函数调用堆栈信息发送至第二线程;第二线程在发起异步任务之前,获取第二线程的当前函数调用堆栈信息,并从第二线程的线程本地存储单元中预存的前序线程发送的函数调用堆栈信息(即在该异步任务之前执行的所有任务的函数调用堆栈信息),将该当前函数调用堆栈信息和前序线程的函数调用堆栈信息发送至第一线程,以便于在应用程序发送crash时,调用该函数调用信息。
在上述实施例中,第二线程即为第一线程的前序线程,第一线程即为第二线程的后序线程。
依次类推,每个线程发起异步任务之前,均获取该线程中的所有的函数调用信息,并将获取的所有的函数调用信息发送至后序线程,以便后序线程在执行任务的过程中发生crash时,调用任务信息,以还原任务场景,定位异常。
上述实施例中,将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中可以包括:将第二函数调用堆栈信息存储在异步任务的对象中;将异步任务的对象发送至第一线程的任务队列;在执行异步任务之前,从异步任务的对象中读取第二函数调用堆栈信息,并将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中。
具体地,在将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中之后,方法还可以包括:执行异步任务,在执行完成异步任务之后,清空第一线程的线程本地存储单元。
如图4所示,应用进程中每个线程都会有一个任务队列和一个线程本地存储单元TLS,该TLS用于存储函数调用信息。如图1所示,现有技术中的应用进程中每个线程仅有一个任务队列,如果在线程A中抛一个异步任务T1到线程B中执行,则T1会先添加到线程B的任务队列中。线程B会按顺序从队列中去获取任务,并一一执行。如果在线程B中执行任务发生crash,则只能获取到在线程B中的函数调用堆栈,不能知道在线程A中的函数调用堆栈。
而如图4所示的实施例中,为每个线程增加了TLS数据结构,该数据结构用来存储之前所有线程的函数调用堆栈。
下面结合图4和图5,以在线程A中抛出一个异步任务到线程B执行为例,详细描述整个函数调用堆栈信息的存储过程:
步骤S501:确定线程A中的待执行任务为异步任务T1。
步骤S502:获取在该异步任务T1之前已开始执行的所有任务的信息。
具体地,在线程A抛出该异步任务T1之前,会先通过操作系统提供的异常类对象获取到当前线程A的函数调用堆栈S1(即上述实施例中的当前函数调用堆栈信息),接着从当前线程A的TLS中取出存储的前序线程的所有的函数调用堆栈信息S2,将当前函数调用堆栈信息S1和前序程序的所有函数调用堆栈信息S2的内容组合起来得到堆栈信息S(即上述实施例中的第二函数调用堆栈信息),暂存在异步任务T1的对象中。
安装有该应用程序的终端可以使用安卓操作系统、IOS操作系统、windows操作系统等,本发明对此不做限定,对应安卓操作系统来讲,安卓操作系统提供的异常类对象为:Throwable对象;
步骤S503:通过系统的接口,将异步任务T1的对象发送到线程B的任务队列。
步骤S504:在线程B中获取异步任务T1的对象。
步骤S505:从异步任务T1的对象中取出堆栈信息S。
具体地,在异步任务T1真正执行之前,先取出存储的堆栈信息S的内容,并将其存储到线程B的TLS中。
步骤S506:执行异步任务T1。
步骤S507:在执行完成异步任务T1后将TLS清空。
上述实施例中的线程A与第二线程相对应,线程B与第一线程相对应。
通过以上步骤,就可以按顺序保存下所有线程的堆栈信息,当程序在执行某个任务出现crash时,可以按照如图6所示的步骤还原出完整的调用堆栈:
步骤S601:获取当前线程的第一函数调用堆栈信息。
具体地,可以先通过Android平台提供的Throwable对象,获取出当前的函数调用堆栈信息,此处的当前线程对应上述实施例中的第一线程。
步骤S603:从当前线程的TLS中获取出保存的之前的所有线程的函数调用堆栈信息。此实施例中的之前的所有线程的函数调用堆栈信息对应上述的第二函数调用堆栈信息。
步骤S605:将第一函数调用堆栈信息和第二函数调用堆栈信息上报至crash平台。
具体地,可以将以上两种信息组合起来,上报到crash平台,这样开发就可以通过还原后的完整的信息来分析crash原因了。
图7是采用现有技术中的方案上报的函数调用信息,图8是采用本发明的方案上报的函数调用信息。
如图7所示,采用现有技术中的方案,若在某个线程crash了,上报内容中只能看到少量的堆栈信息,如,在图7中示出的“ODDataReportMgr.reportData(ReportRequest)line:112”,从该结果中可以看出哪一个任务执行异常,也可以得知该任务的位置,但是由于触发该任务的场景很多,具体导致该任务执行异常的发生原因则无法确定。
如图8所示,采用本发明的上述方案,上报的内容中可以看到完整的程序执行的函数调用堆栈信息,如可以看到发生异常任务的来源,也即图中示出的某个异常的“Entry”,可以从该信息中准确确定该发生异常的任务的来源是哪里,从而可以缩小异常发生原因的排查范围,从而可以基于该范围采用重新执行该任务、或者重现场景的方式,检查代码逻辑,修正任务处理逻辑。
在上述实施例中,通过TLS,Throwable还原出多线程环境下完整的异步函数调用堆栈信息;并且在产品外发版本crash时,将还原后的堆栈信息上报crash平台,可以准确完整还原任务操作场景,以快速、准确定位异常。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
根据本发明实施例,还提供了一种用于实施上述应用程序的信息处理装置,如图9所示,该装置包括:
检测单元91,用于检测当前运行的应用程序是否出现异常;
第一获取单元93,用于在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;
发送单元95,用于将已开始执行的任务的信息发送至应用程序的服务器。
采用本发明的上述实施例,若当前运行的应用程序发生异常,则获取已开始执行的任务的信息,并将获取的已开始执行的任务的信息发送至应用程序的服务器,从而可以在程序发生crash时,获取已开始执行的所有程序任务的函数调用信息,以获取完整的各个线程的堆栈信息,服务器在获取完整的堆栈信息之后,可以还原程序发生crash的场景,从而可以准确定位程序发生crash的原因,解决了现有技术中在程序发生crash时,无法准确定位crash原因的问题。
上述实施例中,安装有应用程序的终端的处理器在启动该应用程序之后,该终端的处理器中的执行器执行该应用程序的任务,以运行该应用程序的功能,具体地,处理器在执行应用程序的任务的过程中,可以实时检测该应用程序是否发生异常,即,检测该应用程序是否发生crash,如,检测应用程序是否停止工作、停止响应、进程中断等。
若检测出该应用程序发生crash,处理器获取已开始执行的所有任务的函数调用信息,该函数调用信息可以定位异常发生的位置和原因,将该函数调用信息上报到应用程序的服务器(如crash平台),开发者在获取到该函数调用信息之后,可以通过还原后的信息分析crash的原因。
可选地,该终端可以为安装有安卓操作系统的终端,当检测到程序在执行某个任务出现crash时,可以按照以下步骤还原出完整的调用堆栈:先通过安卓平台(即Android平台)提供的Throwable类对象,获取出上述的函数调用信息,将获取到的函数调用信息上报到crash平台,这样开发就可以通过还原后的完整的信息来分析crash原因了。
Throwable类是java语音中所有错误或异常的超类,该类中的信息通常用于指示发生了异常情况,可选地,该Throwable类的实例是在异常情况的上下文中新近创建的,该Throwable类对象中包含了异常的相关信息,如堆栈跟踪数据。
上述实施例中,对异常进行定位具体是指,在发生异常时,获取的已开始执行的任务的信息中可以看到程序的堆栈信息,在该堆栈信息中可以看到在哪个类、哪个函数中出的错,若无法确定在哪个类、哪个函数出的错,可以重新执行一次上述的已开始执行的任务中触发异常的任务入口,以定位出发生异常的任务入口、异常发生的原因等。在定位该异常之后,可以基于定位的该异常的原因、位置等信息,对应用程序的源代码进行修正,以修复该异常。
进一步地,获取单元包括:第一获取子单元,用于获取用于执行已开始执行的任务的所有线程的函数调用信息,其中,已开始执行的任务的信息包括函数调用信息。
上述实施例中的所有线程包括所有执行过或正在执行所述已开始执行的任务的线程,如,该线程包括发生异常的线程和向该发生异常的线程发起异步任务的线程。
函数调用信息中记录了函数调用的顺序,每调用一次函数对应执行一个任务。
通过上述实施例,能够还原多线程环境下异步函数调用堆栈,当外发产品crash时能够获取到还原后的各个线程的完整的堆栈信息,从而帮助定位crash的原因。
具体地,获取子单元可以包括:第一获取模块,用于获取出现异常的第一线程的第一函数调用堆栈信息;第二获取模块,用于从第一线程的线程本地存储单元中,获取预先保存的第二线程的第二函数调用堆栈信息,其中,第二线程为向第一线程发起异步任务的线程,函数调用信息包括第一函数调用堆栈信息和第二函数调用堆栈信息,所有线程包括第一线程和第二线程。
其中,出现异常的第一线程即为发生异常的任务所在的线程。
在上述实施例中,在应用程序开始运行之后,检测当前运行的应用程序是否出现异常,在检测到应用程序出现异常的情况下,通过终端的操作系统提供的异常类对象,获取出现异常的第一线程的第一函数调用堆栈信息,并从第一线程的线程本地存储单元中,取出预先保存的之前的所有线程的第二函数调用堆栈信息,将该第一函数调用堆栈信息和第二函数调用堆栈信息组合起来,上报到crash平台(即上述实施例中的服务器),服务器侧可以通过该组合的函数调用信息分析异常发生的原因,以定位该异常。
根据本发明的上述实施例,已开始执行的任务包括:在发生异常前开始执行并且执行完成的任务和在发生异常前开始执行但尚未执行完成的任务。
需要说明的是,装置还可以包括:第二获取单元,用于在应用程序运行的过程中,在第二线程向第一线程发起异步任务之前,获取第二线程的第二函数调用堆栈信息;第一保存单元,用于在第一线程执行异步任务之前,将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中,其中,已开始执行的任务包括异步任务。
通过上述方案,可以按照顺序保存下所有线程的堆栈信息,当程序在执行某个任务出现crash时,可以按照上述实施例中获取函数调用信息的方案还原出完整的调用堆栈。
在上述实施例中,第二获取单元可以包括:第二获取子单元,用于获取第二线程的当前函数调用堆栈信息;读取子单元,用于从第二线程的线程本地存储单元中,读取预先保存的前序线程的函数调用堆栈信息;确定子单元,用于将当前函数调用堆栈信息和前序线程的函数调用堆栈信息作为第二函数调用堆栈信息,其中,前序线程为在第二线程执行已开始执行的任务之前执行已开始执行的任务的线程。
可选地,在检测出应用程序出现异常时,则可以获取第一线程的第一函数调用堆栈信息,并从第一线程的线程本地存储单元中,获取预先保存的第二线程的第二函数调用堆栈信息,利用第一函数调用堆栈信息和第二函数调用堆栈信息的组合信息定位异常。
在一个可选的实施例中,保存单元可以包括:存储子单元,用于将第二函数调用堆栈信息存储在异步任务的对象中;发送子单元,用于将异步任务的对象发送至第一线程的任务队列;读取保存子单元,用于在执行异步任务之前,从异步任务的对象中读取第二函数调用堆栈信息,并将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中。
具体地,装置还可以包括:处理单元,用于在将第二函数调用堆栈信息保存在第一线程的线程本地存储单元中之后,执行异步任务,在执行完成异步任务之后,清空第一线程的线程本地存储单元。
通过上述实施例,通过异步任务执行模块XTask提供的post接口来发起异步任务,XTask模块在发起异步任务之前,将获取出之前所有的调用堆栈信息列表,将其暂存到异步任务对象中,当任务真正执行时,将暂存的堆栈信息列表写入到当前线程的TLS中,当任务执行时发生crash,XTask模块就可以从TLS中获取出之前的所有堆栈信息列表,并做上报。通过上述方案可以还原多线程环境下异步函数调用堆栈,当外发产品crash时能够获取到还原后的各个线程的完整的堆栈信息,从而帮助定位crash的原因。
本实施例中所提供的各个模块与方法实施例对应步骤所提供的使用方法相同、应用场景也可以相同。当然,需要注意的是,上述模块涉及的方案可以不限于上述实施例中的内容和场景,且上述模块可以运行在计算机终端或移动终端,可以通过软件或硬件实现。
实施例3
根据本发明实施例,还提供了一种用于实施上述应用程序的信息处理方法的服务器,如图10所示,该服务器包括:
如图10所示,该服务器或终端包括:一个或多个(图中仅示出一个)处理器1001、存储器1003、以及传输装置1005(如上述实施例中的发送装置),如图10所示,该终端还可以包括输入输出设备1007。
其中,存储器1003可用于存储软件程序以及模块,如本发明实施例中的应用程序的信息处理方法和装置对应的程序指令/模块,处理器1001通过运行存储在存储器1003内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的应用程序的信息处理方法。存储器1003可包括高速随机存储器,还可以包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器1003可进一步包括相对于处理器1001远程设置的存储器,这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置1005用于经由一个网络接收或者发送数据,还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中,传输装置1005包括一个网络适配器(Network Interface Controller,NIC),其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中,传输装置1005为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
其中,具体地,存储器1003用于存储应用程序。
处理器1001可以通过传输装置1005调用存储器1003存储的应用程序,以执行下述步骤:
步骤S2:检测当前运行的应用程序是否出现异常;
步骤S4:在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;
步骤S6:将已开始执行的任务的信息发送至应用程序的服务器。
采用本发明的上述实施例,若当前运行的应用程序发生异常,则获取已开始执行的任务的信息,并将获取的已开始执行的任务的信息发送至应用程序的服务器,从而可以在程序发生crash时,获取已开始执行的所有程序任务的函数调用信息,以获取完整的各个线程的堆栈信息,服务器在获取完整的堆栈信息之后,可以还原程序发生crash的场景,从而可以准确定位程序发生crash的原因,解决了现有技术中在程序发生crash时,无法准确定位crash原因的问题。
可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
需要进一步说明的是,寄存区域为系统的内存和系统处理器中的寄存器。
本领域普通技术人员可以理解,图10所示的结构仅为示意,终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices,MID)、PAD等终端设备。图10其并不对上述电子装置的结构造成限定。例如,终端还可包括比图10中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图10所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
实施例4
本发明的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于执行应用程序的信息处理方法的程序代码。
可选地,在本实施例中,上述存储介质可以位于如图2所示的网络中的多个网络设备中的至少一个网络设备。
可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:
步骤S1:检测当前运行的应用程序是否出现异常;
步骤S3:在检测到应用程序出现异常的情况下,获取应用程序在运行的过程中已开始执行的任务的信息,其中,已开始执行的任务的信息用于对异常进行定位;
步骤S5:将已开始执行的任务的信息发送至应用程序的服务器。
采用本发明的上述实施例,若当前运行的应用程序发生异常,则获取已开始执行的任务的信息,并将获取的已开始执行的任务的信息发送至应用程序的服务器,从而可以在程序发生crash时,获取已开始执行的所有程序任务的函数调用信息,以获取完整的各个线程的堆栈信息,服务器在获取完整的堆栈信息之后,可以还原程序发生crash的场景,从而可以准确定位程序发生crash的原因,解决了现有技术中在程序发生crash时,无法准确定位crash原因的问题。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。
在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (14)
1.一种应用程序的信息处理方法,其特征在于,包括:
检测当前运行的应用程序是否出现异常;
在检测到所述应用程序出现异常的情况下,获取所述应用程序在运行的过程中已开始执行的任务的信息,其中,所述已开始执行的任务的信息用于对所述异常进行定位;所述已开始执行的任务的信息包括第一线程的第一函数调用堆栈信息和预先保存的第二线程的第二函数调用堆栈信息;其中,所述第一线程为发生所述异常的任务所在的线程,所述第二线程为向所述第一线程发起异步任务的线程;
将所述已开始执行的任务的信息发送至所述应用程序的服务器。
2.根据权利要求1所述的方法,其特征在于,获取用于执行所述已开始执行的任务的所有线程的函数调用信息包括:
获取第一线程的第一函数调用堆栈信息;
从所述第一线程的线程本地存储单元中,获取预先保存的第二线程的第二函数调用堆栈信息。
3.根据权利要求1所述的方法,其特征在于,所述已开始执行的任务包括:在发生所述异常前开始执行并且执行完成的任务和在发生所述异常前开始执行但尚未执行完成的任务。
4.根据权利要求1所述的方法,其特征在于,在所述应用程序运行的过程中,所述方法还包括:
在第二线程向第一线程发起异步任务之前,获取所述第二线程的第二函数调用堆栈信息;
在所述第一线程执行所述异步任务之前,将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中,
其中,所述已开始执行的任务包括所述异步任务。
5.根据权利要求4所述的处理方法,其特征在于,获取所述第二线程的第二函数调用堆栈信息包括:
获取所述第二线程的当前函数调用堆栈信息;
从所述第二线程的线程本地存储单元中,读取预先保存的前序线程的函数调用堆栈信息;
将所述当前函数调用堆栈信息和所述前序线程的函数调用堆栈信息作为所述第二函数调用堆栈信息,
其中,所述前序线程为在所述第二线程执行所述已开始执行的任务之前执行所述已开始执行的任务的线程。
6.根据权利要求4所述的方法,其特征在于,将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中包括:
将所述第二函数调用堆栈信息存储在所述异步任务的对象中;
将所述异步任务的对象发送至所述第一线程的任务队列;
在执行所述异步任务之前,从所述异步任务的对象中读取所述第二函数调用堆栈信息,并将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中。
7.根据权利要求6所述的方法,其特征在于,在将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中之后,所述方法还包括:
执行所述异步任务,在执行完成所述异步任务之后,清空所述第一线程的线程本地存储单元。
8.一种应用程序的信息处理装置,其特征在于,包括:
检测单元,用于检测当前运行的应用程序是否出现异常;
第一获取单元,用于在检测到所述应用程序出现异常的情况下,获取所述应用程序在运行的过程中已开始执行的任务的信息,其中,所述已开始执行的任务的信息用于对所述异常进行定位;所述已开始执行的任务的信息包括第一线程的第一函数调用堆栈信息和预先保存的第二线程的第二函数调用堆栈信息;其中,所述第一线程为发生所述异常的任务所在的线程,所述第二线程为向所述第一线程发起异步任务的线程;
发送单元,用于将所述已开始执行的任务的信息发送至所述应用程序的服务器。
9.根据权利要求8所述的装置,其特征在于,所述第一获取单元包括:
第一获取模块,用于获取第一线程的第一函数调用堆栈信息;
第二获取模块,用于从所述第一线程的线程本地存储单元中,获取预先保存的第二线程的第二函数调用堆栈信息。
10.根据权利要求8所述的装置,其特征在于,所述已开始执行的任务包括:在发生所述异常前开始执行并且执行完成的任务和在发生所述异常前开始执行但尚未执行完成的任务。
11.根据权利要求8所述的装置,其特征在于,所述装置还包括:
第二获取单元,用于在所述应用程序运行的过程中,在第二线程向第一线程发起异步任务之前,获取所述第二线程的第二函数调用堆栈信息;
第一保存单元,用于在所述第一线程执行所述异步任务之前,将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中,
其中,所述已开始执行的任务包括所述异步任务。
12.根据权利要求11所述的处理装置,其特征在于,所述第二获取单元包括:
第二获取子单元,用于获取所述第二线程的当前函数调用堆栈信息;
读取子单元,用于从所述第二线程的线程本地存储单元中,读取预先保存的前序线程的函数调用堆栈信息;
确定子单元,用于将所述当前函数调用堆栈信息和所述前序线程的函数调用堆栈信息作为所述第二函数调用堆栈信息,
其中,所述前序线程为在所述第二线程执行所述已开始执行的任务之前执行所述已开始执行的任务的线程。
13.根据权利要求11所述的装置,其特征在于,所述第一保存单元包括:
存储子单元,用于将所述第二函数调用堆栈信息存储在所述异步任务的对象中;
发送子单元,用于将所述异步任务的对象发送至所述第一线程的任务队列;
读取保存子单元,用于在执行所述异步任务之前,从所述异步任务的对象中读取所述第二函数调用堆栈信息,并将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中。
14.根据权利要求13所述的装置,其特征在于,所述装置还包括:
处理单元,用于在将所述第二函数调用堆栈信息保存在所述第一线程的线程本地存储单元中之后,执行所述异步任务,在执行完成所述异步任务之后,清空所述第一线程的线程本地存储单元。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610177236.1A CN105843741B (zh) | 2016-03-24 | 2016-03-24 | 应用程序的信息处理方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610177236.1A CN105843741B (zh) | 2016-03-24 | 2016-03-24 | 应用程序的信息处理方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105843741A CN105843741A (zh) | 2016-08-10 |
CN105843741B true CN105843741B (zh) | 2020-04-28 |
Family
ID=56583675
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610177236.1A Active CN105843741B (zh) | 2016-03-24 | 2016-03-24 | 应用程序的信息处理方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105843741B (zh) |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107391360A (zh) * | 2016-11-16 | 2017-11-24 | 广州爱九游信息技术有限公司 | 应用程序异常信息处理方法、装置、服务器及用户终端 |
CN108073495B (zh) * | 2016-11-18 | 2020-04-21 | 腾讯科技(深圳)有限公司 | 应用程序崩溃原因的定位方法及装置 |
CN106681811B (zh) * | 2016-12-08 | 2021-09-14 | 腾讯科技(深圳)有限公司 | 基于线程池的多线程调度方法及装置 |
CN108804299B (zh) * | 2017-04-26 | 2023-04-07 | 腾讯科技(深圳)有限公司 | 应用程序异常处理方法及装置 |
CN107479981B (zh) * | 2017-06-30 | 2020-02-07 | 武汉斗鱼网络科技有限公司 | 一种基于异步调用实现同步调用的处理方法及装置 |
CN109656773B (zh) * | 2017-10-12 | 2023-03-10 | 卓望数码技术(深圳)有限公司 | 一种基于ios系统应用异常崩溃的处理框架 |
CN110389888A (zh) * | 2018-04-19 | 2019-10-29 | 北京京东尚科信息技术有限公司 | 程序检测方法和系统 |
CN108595331B (zh) * | 2018-04-24 | 2021-11-02 | 杭州网易智企科技有限公司 | 异步接口的测试方法、介质、装置和计算设备 |
CN109002694B (zh) * | 2018-06-08 | 2021-01-26 | 广东小天才科技有限公司 | 一种应用代码混淆后定位问题点的方法及装置 |
CN109284217B (zh) * | 2018-09-28 | 2023-01-10 | 平安科技(深圳)有限公司 | 应用程序异常处理方法、装置、电子设备及存储介质 |
CN109542689A (zh) * | 2018-11-30 | 2019-03-29 | 努比亚技术有限公司 | 应用程序处理方法、终端以及计算机可读存储介质 |
CN109739676B (zh) * | 2018-12-27 | 2022-06-24 | 努比亚技术有限公司 | 一种运行监测方法、移动终端及计算机可读存储介质 |
CN109871290B (zh) * | 2019-03-07 | 2021-02-05 | 腾讯科技(深圳)有限公司 | 应用于Java的调用堆栈追踪方法、装置和存储介质 |
CN110413432B (zh) * | 2019-07-02 | 2023-09-01 | Oppo广东移动通信有限公司 | 一种信息处理方法、电子设备及存储介质 |
CN110727592A (zh) * | 2019-10-11 | 2020-01-24 | 网易(杭州)网络有限公司 | 应用程序测试方法、介质、装置和计算设备 |
CN111782508A (zh) * | 2020-06-12 | 2020-10-16 | 北京达佳互联信息技术有限公司 | 自动测试方法、装置、电子设备和存储介质 |
CN112783652B (zh) * | 2021-01-25 | 2024-03-12 | 珠海亿智电子科技有限公司 | 当前任务的运行状态获取方法、装置、设备及存储介质 |
CN113282436A (zh) * | 2021-05-21 | 2021-08-20 | 北京达佳互联信息技术有限公司 | 事件处理方法、装置、设备以及存储介质 |
CN113778570B (zh) * | 2021-09-10 | 2023-06-06 | 四川新网银行股份有限公司 | 一种基于AOP+ThreadLocal技术的分布式系统断点重试方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7958512B2 (en) * | 2005-10-31 | 2011-06-07 | Microsoft Corporation | Instrumentation to find the thread or process responsible for an application failure |
CN101114253A (zh) * | 2006-07-26 | 2008-01-30 | 腾讯科技(深圳)有限公司 | 一种程序崩溃信息上报的方法及系统 |
CN104516732A (zh) * | 2013-09-29 | 2015-04-15 | 北京新媒传信科技有限公司 | 一种应用程序崩溃报告方法和系统 |
CN104572046B (zh) * | 2013-10-16 | 2019-01-11 | 腾讯科技(深圳)有限公司 | 一种堆栈还原方法和计算机系统 |
-
2016
- 2016-03-24 CN CN201610177236.1A patent/CN105843741B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN105843741A (zh) | 2016-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105843741B (zh) | 应用程序的信息处理方法和装置 | |
US20210182136A1 (en) | Fault Processing Method, Related Apparatus, and Computer | |
CN106844136B (zh) | 一种程序崩溃信息的收集方法及系统 | |
US20170102888A1 (en) | Backup storage of vital debug information | |
US9355003B2 (en) | Capturing trace information using annotated trace output | |
CN108170552B (zh) | 一种抓取Dump文件的方法、装置和设备 | |
CN109144873B (zh) | 一种linux内核处理方法及装置 | |
CN109558313B (zh) | 构建异常测试场景的方法及装置 | |
CN111211929A (zh) | 故障定位方法、故障定位装置、控制设备及智能设备 | |
CN109324959B (zh) | 一种自动转移数据的方法、服务器及计算机可读存储介质 | |
CN113742237A (zh) | 程序调试方法、装置、设备以及存储介质 | |
CN106997313B (zh) | 一种应用程序的信号处理方法、系统及终端设备 | |
US11093361B2 (en) | Bus monitoring system, method and apparatus | |
US11055416B2 (en) | Detecting vulnerabilities in applications during execution | |
CN108241543B (zh) | 业务操作断点执行的方法、业务服务器及系统 | |
US20220229718A1 (en) | Automated crash recovery | |
US8171345B2 (en) | Disablement of an exception generating operation of a client system | |
CN110688173A (zh) | 一种跨平台界面框架中组件的定位方法、装置及电子设备 | |
WO2012164418A1 (en) | Facilitating processing in a communications environment using stop signaling | |
CN114090434B (zh) | 一种代码调试方法、装置、计算机设备和存储介质 | |
CN113535580B (zh) | 一种cts测试方法、装置及测试设备 | |
CN112740187A (zh) | 调试程序的方法和系统 | |
CN107766251B (zh) | 加载image的检测方法、系统、设备及可读存储介质 | |
US20180336086A1 (en) | System state information monitoring | |
CN113986622A (zh) | Sdk异常的自检方法、装置、介质和计算设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |