用于程序调试的方法和装置与流程

本公开涉及计算机领域，具体地，涉及一种用于程序调试的方法和装置。

背景技术：

在大规模、复杂的软件开发周期中，为了保障软件系统的可靠性、灵活性和健壮性，软件程序的调试器在其中发挥了不可替代的作用。调试器是能够监测程序执行状态的工具，它能够定位程序中的错误设计，并分析软件的工作原理。

在程序调试中，可以在用户终端之外的其他节点中远程执行调试任务。程序调试技术可能会对调试程序所在的进程产生影响，比如进程阻塞时，如果同一进程中的其他线程上正在执行其他任务时，也会被迫中断。通常会将调试任务运行于非生产环境中的节点上。

技术实现要素：

本公开的目的是提供一种可靠性较高的、用于程序调试的方法和装置。

为了实现上述目的，本公开提供一种用于程序调试的方法，应用于服务器。所述方法包括：分别接收多个用户终端发送的、与所述多个用户终端一一对应的多个调试请求，每个调试请求分别用于请求对对应的用户终端中的程序进行调试；响应于多个调试请求，分别生成与所述多个调试请求一一对应的多个调试线程；分别通过每个调试线程，对对应的用户终端中的程序进行调试。

可选地，任意两个调试线程中的调试器实例不同，任意两个调试线程中的运行环境不同。

可选地，所述分别通过每个调试线程，对对应的用户终端中的程序进行调试的步骤包括：分别通过每个调试线程，对对应的用户终端中的程序进行断点调试。

可选地，所述分别通过每个调试线程，对对应的用户终端中的程序进行断点调试的步骤包括：当调试进入断点状态时，接收用户终端发送的查询请求，所述查询请求用于请求查询变量值；响应于所述查询请求，查询变量的当前值；向所述用户终端发送所述变量的当前值。

可选地，所述方法还包括：在对一用户终端的程序调试完成时，终止对应的调试线程。

本公开还提供一种用于程序调试的装置，应用于服务器。所述装置包括：接收模块，用于分别接收多个用户终端发送的、与所述多个用户终端一一对应的多个调试请求，每个调试请求分别用于请求对对应的用户终端中的程序进行调试；生成模块，用于响应于多个调试请求，分别生成与所述多个调试请求一一对应的多个调试线程；调试模块，用于分别通过每个调试线程，对对应的用户终端中的程序进行调试。

通过上述技术方案，响应于每个用户终端的调试请求，为每个用户终端建立专用的调试线程。这样，当一个用户终端的调试由于一些原因暂停时，其他线程中执行的任务并不会受到影响，因此，调试任务对服务器中的其他任务的干扰性较小，使服务器运行更加稳定。

本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：

图1是一示例性实施例提供的用于程序调试的方法的场景图；

图2是一示例性实施例提供的用于程序调试的方法的流程图；

图3是另一示例性实施例提供的用于程序调试的方法的流程图；

图4是一示例性实施例提供的断点调试步骤的流程图；

图5是又一示例性实施例提供的用于程序调试的方法的流程图；

图6是一示例性实施例提供的用于程序调试的装置的框图。

具体实施方式

以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。

如上所述，在传统的程序调试中，服务器为每个调试任务分配一个进程，该进程中包含一个调试器的运行实例。当调试程序遇断点挂起时，此进程会被阻塞。这样，在该进程被调试器用户终端唤醒之前，其他所有执行于此进程上的用户操作均被中断。

考虑到以上缺陷，发明人想到，可以在服务器端为每个用户终端建立专用的调试线程，以解决在程序调试过程中调试程序挂起时，影响其他任务的问题。这样，使得服务器运行的可靠性更高。

图1是一示例性实施例提供的用于程序调试的方法的场景图。如图1所示，程序调试可以在一个服务器和多个用户终端1，2，…，n之间进行。

图2是一示例性实施例提供的用于程序调试的方法的流程图。所述方法应用于服务器，如图2所示，所述方法包括以下步骤。

在步骤s11中，分别接收多个用户终端发送的、与所述多个用户终端一一对应的多个调试请求，每个调试请求分别用于请求对对应的用户终端中的程序进行调试。

在步骤s12中，响应于多个调试请求，分别生成与所述多个调试请求一一对应的多个调试线程。

在步骤s13中，分别通过每个调试线程，对对应的用户终端中的程序进行调试。

其中，多个用户终端可以同时或不同时地发送调试请求。服务器在接收到一用户终端的调试请求时，创建专用于该用户终端的调试线程。

举例来说，在第一用户终端就其内部的一程序向服务器发送调试请求时，服务器可以响应于该请求，创建专用于该第一用户终端的第一调试线程，即该第一调试线程与第一用户终端相对应。之后，可以通过第一调试线程对第一用户终端中的程序进行远程调试。

对第一用户终端中的程序调试期间，当第二用户终端就其内部的一程序向服务器发送调试请求时，服务器可以响应于该请求，创建专用于第二用户终端的第二调试线程。之后，通过第二调试线程对第二用户终端中的程序进行远程调试。

具体地，可以在调试线程中初始化一个调试会话，该初始化可以实现于用户终端的集成开发环境(integrateddevelopmentenvironment，ide)内部或外部。可以在调试会话内运行一个协作的、无阻塞非侵入式调试器实例。

调试请求可以包括一个待执行的调试操作(代码)。服务器和用户终端之间可以(例如，采用长轮询技术)建立双向的通信管道(即建立数据传输协议，确定统一的序列化及编码格式)，通过该通信管道进行远程调试。

本公开的实施例中，上述调试会话是基于线程的。线程级别的调试技术可以保证当某些事件引起调试线程暂停时，其他线程上执行的任务不会受到影响。

在上述实施例中，由于用户代码被运行于远端服务器的调试线程中，调试器和用户终端可以随时获取调试过程中的所有数据，并可以控制程序的执行，因此，这种服务器端的调试需要用户终端的高操作权限来保证系统和数据的安全性。也就是，为了保证用户数据的安全性，不具有相应权限的用户终端无法实现上述分布式的调试。为了实现资源的隔离，不同的用户终端在启用调试服务时，可以使用不同的堆栈空间及运行环境。

由此，在本公开的另一实施例中，任意两个调试线程中的调试器实例不同，任意两个调试线程中的运行环境不同。例如，服务器为每个调试线程提供与其对应的调试器实例相匹配、协作的运行环境。这样，由于不同调试线程使用不同的调试器实例、运行环境以及堆栈空间，各个用户终端的调试任务在服务器端实现了资源隔离，因此，提出调试请求的用户终端并不需要具有高操作权限。

图3是另一示例性实施例提供的用于程序调试的方法的流程图。如图3所示，在图2的基础上，分别通过每个调试线程，对对应的用户终端中的程序进行调试的步骤(步骤s13)可以包括步骤s131。

在步骤s131中，分别通过每个调试线程，对对应的用户终端中的程序进行断点调试。

也就是，可以通过断点调试的方法对各个用户终端进行程序的调试。具体地，在预先使用脚本解释器逐行解释脚本语句时，可向每行脚本插入断点。当调试过程中遇到断点时，解释脚本的线程会被停止，而其他正在执行的线程可以正常执行。该实施例中，采用了断点调试的方法，增强了用户与服务器调试进程之间的交互性，利于及时发现问题。

在断点调试时，用户还可以在断点状态下，远程通过服务器查询变量值。图4是一示例性实施例提供的断点调试步骤的流程图。如图4所示，分别通过每个调试线程，对对应的用户终端中的程序进行断点调试的步骤(步骤s131)可以包括以下步骤。

在步骤s1311中，当调试进入断点状态时，接收用户终端发送的查询请求，所述查询请求用于请求查询变量值。

在步骤s1312中，响应于所述查询请求，查询变量的当前值。

在步骤s1313中，向所述用户终端发送所述变量的当前值。

以用户终端通过ide实现调试的方式为例。具体地，可以在用户终端启动一个ide，ide可显示待调试的用户源码，并提供可选的调试操作。用户可以通过ide在待调试源码中设置断点。用户终端可以将包含有断点信息的调试请求发送至服务器。当启动调试服务后，服务器创建调试线程，用户终端和服务器之间建立通信管道。

服务器在执行每条语句前，可以检查其内部状态来判断下一条待执行语句是否包含断点，并执行相应操作。当进入断点状态时，服务器可以生成一调试消息，该调试消息可以包括当前正在调试的代码文件以及当前所遇断点语句的位置信息等。服务器将该断点消息发送至对应的用户终端。用户终端中例如可以将当前执行行进行加亮显示。

该实施例中，可以在调试进入断点状态时，执行查询变量值的调试操作，增强了用户操作的灵活性。

另外，可以根据回调函数，对与各个调试器实例对应的用户终端中的程序进行调试。也就是，可以预先通过插装代码向用户终端的程序中插入回调方法。这样，服务器在遇到断点前可以通过回调函数实现代码调试。

图5是又一示例性实施例提供的用于程序调试的方法的流程图。如图5所示，在图2的基础上，所述方法还可以包括步骤s14。

在步骤s14中，在对一用户终端的程序调试完成时，终止对应的调试线程。

也就是，当一用户终端的调试任务完成以后，可以关闭服务器和该用户终端的调试会话和通信管道，以免不必要的资源占用。

通过上述技术方案，响应于每个用户终端的调试请求，为每个用户终端建立专用的调试线程。这样，当一个用户终端的调试由于一些原因暂停时，其他线程中执行的任务并不会受到影响，因此，调试任务对服务器中的其他任务的干扰性较小，使服务器运行更加稳定。

本公开还提供一种用于程序调试的装置，应用于服务器。图6是一示例性实施例提供的用于程序调试的装置的框图。如图6所示，所述用于程序调试的装置10可以包括接收模块11、生成模块12和调试模块13。

接收模块11用于分别接收多个用户终端发送的、与所述多个用户终端一一对应的多个调试请求，每个调试请求分别用于请求对对应的用户终端中的程序进行调试。

生成模块12用于响应于多个调试请求，分别生成与多个调试请求一一对应的多个调试线程。

调试模块13用于分别通过每个调试线程，对对应的用户终端中的程序进行调试。

可选地，任意两个调试线程中的调试器实例不同，任意两个调试线程中的运行环境不同。

可选地，所述调试模块13可以包括断点调试子模块。

断点调试子模块用于分别通过每个调试线程，对对应的用户终端中的程序进行断点调试。

可选地，所述断点调试子模块可以包括查询请求接收子模块、查询子模块和发送子模块。

查询请求接收子模块用于当调试进入断点状态时，接收用户终端发送的查询请求，所述查询请求用于请求查询变量值。

查询子模块用于响应于所述查询请求，查询变量的当前值。

发送子模块用于向所述用户终端发送所述变量的当前值。

可选地，所述装置还包括终止模块。

终止模块用于在对一用户终端的程序调试完成时，终止对应的调试线程的运行。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

通过上述技术方案，响应于每个用户终端的调试请求，为每个用户终端建立专用的调试线程。这样，当一个用户终端的调试由于一些原因暂停时，其他线程中执行的任务并不会受到影响，因此，调试任务对服务器中的其他任务的干扰性较小，使服务器运行更加稳定。

也就是，本公开提供了一种云服务器，该云服务器能够响应于多个用户终端的调试请求，启动线程级别的调试器实例，分别对多个用户终端中的程序进行调试，使得在调试过程中遇到中断时，不会影响其他任务的执行。

以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。

此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。