A cross-language debugging method, device and equipment and storage medium

Abstract

The application discloses a cross-language debugging method and device, equipment and storage medium, relates to the technical field of software debugging, and is applied to a debugging server, and comprises the following steps: when a cross-language debugging request is acquired, a communication connection is established with debugging adapters corresponding to each programming language, and a global virtual debugging session is established; the global virtual debugging session is used for representing a global state generated after the runtime states of each programming language are aggregated; a running instruction is acquired, and the running instruction is issued to each debugging adapter, so that the global virtual debugging session enters a running state; when the runtime of a target programming language executes to a corresponding breakpoint position, the global virtual debugging session enters a pause state; call stack frame information is acquired from the runtime of each programming language respectively, and a mixed stack frame view is generated by fusion, and then the mixed stack frame view is returned to a debugging front end for display. The application can uniformly debug multiple languages in a cross-language scene, and ensures the continuity of the debugging process.

Description

Technical Field

[0001] This invention relates to the field of software debugging technology, and in particular to a cross-language debugging method, apparatus, device, and storage medium. Background Technology

[0002] With the widespread application of artificial intelligence engineering in scenarios such as inference services, data processing, and online learning, multi-language hybrid architecture has become the mainstream development model. In typical AI engineering practices, high-performance engineering frameworks are often implemented using compiled languages ​​such as Go and C++, while core algorithm models are developed using interpreted languages ​​such as Python. The two are integrated through plug-in or service-oriented approaches. While this hybrid architecture combining multiple languages ​​balances performance and development efficiency, it also brings challenges to cross-language debugging, such as context fragmentation, inconsistent breakpoints, difficulties in variable representation, and complex fault location.

[0003] Traditional solutions employ separate debugging, requiring developers to simultaneously launch both the native Go debugger and the native Python debugger, switching between two independent debugging sessions. However, this approach completely fragments the debugging context, leaving developers unaware of cross-language call chains. Furthermore, breakpoints are managed independently in the two debuggers, lacking consistency guarantees. Additionally, when viewing Python variables on the Go side, complex data structures are difficult to visualize due to differences in type systems.

[0004] Therefore, the aforementioned technical problems urgently need to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a cross-language debugging method, apparatus, device, and storage medium, which can perform unified debugging of multiple languages ​​in cross-language scenarios and ensure the continuity of the debugging process. The specific solution is as follows: The first aspect of this application provides a cross-language debugging method for use on a debugging server, including: When a cross-language debugging request is received from the debugging front end, a communication connection is established with the debugging adapter corresponding to each programming language, and a global virtual debugging session is established; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language; Obtain the running command issued by the debugging front end, and issue the running command to each debugging adapter so that the global virtual debugging session enters the running state; When the runtime of the target programming language reaches the preset breakpoint, the global virtual debugging session is paused. The corresponding call stack frame information is obtained from the runtime of each programming language, and the call stack frame information is merged to generate a hybrid stack frame view. The hybrid stack frame view is then returned to the debugging front end for display.

[0006] Optionally, before obtaining the execution instructions issued by the debugging front-end, the method further includes: Obtain the breakpoint setting request issued by the debugging front end, and parse the breakpoint setting request to obtain the source file characteristics corresponding to the breakpoint to be set; wherein, the source file characteristics are source file path suffix or metadata characteristics; Based on the source file features, the programming language type corresponding to the breakpoint to be set is identified, and a breakpoint setting instruction is sent to the debug adapter corresponding to the programming language type to mark the breakpoint position and obtain the preset breakpoint position.

[0007] Optionally, the process of sending the breakpoint setting instruction to the debug adapter corresponding to the programming language type further includes: If the code module corresponding to the breakpoint to be set is not loaded in the runtime of the programming language corresponding to the programming language type, the breakpoint setting instruction is cached in the preset pending list and the breakpoint setting instruction is marked as pending activation. Listen for the module loading event of the programming language runtime corresponding to the programming language type. When the code module is loaded, activate the breakpoint setting instruction in the preset pending list and send it to the corresponding debug adapter.

[0008] Optionally, after the runtime of the target programming language reaches the corresponding breakpoint, the process further includes: In response to a stop signal sent by the debug adapter corresponding to the target programming language, communication protection is provided for the runtime of other programming languages ​​based on a preset communication protection mechanism.

[0009] Optionally, the provision of runtime communication protection for other programming languages ​​based on a preset communication protection mechanism includes: Controls the runtime of other programming languages ​​to enter a logical suspension state; Intervene on the communication stubs of the other programming languages ​​to suppress the timeout retry mechanism or error reporting mechanism on the other programming language side; wherein, the intervention process includes modifying the communication context of the communication stub or injecting a preset debugging delay instruction into the communication stub.

[0010] Optionally, the cross-language debugging method further includes: For the current call stack frame information corresponding to the target programming language, the variable data in the current call stack frame information is processed based on the preset cross-language type mapping rules to obtain the processed variable data; Accordingly, returning the hybrid stack frame view to the debugging front end for display includes: The hybrid stack frame view is encapsulated with the processed variable data to obtain an encapsulated stack frame view, and the encapsulated stack frame view is returned to the debugging front end for display.

[0011] Optionally, the process of processing the variable data in the current call stack frame information based on a preset cross-language type mapping rule to obtain processed variable data includes: Identify the variable type of the variable data in the current call stack frame information and obtain a pre-established type mapping table; wherein, the type mapping table is used to record the mapping relationship between the original variable type and the structured format; Determine whether the variable type of the variable data exists in the type mapping table; If it exists, the target variable type of the variable data is converted into the corresponding structured format using the type mapping table to obtain the processed variable data; If it does not exist, the variable data is processed based on a preset rollback strategy to obtain the processed variable data.

[0012] Optionally, the step of processing the variable data based on a preset rollback strategy to obtain processed variable data includes: Extract common attributes from the variable data; If the common attribute is extracted, a structured summary is generated based on the common attribute, and the structured summary is used as the processed variable data; If the public attribute is not extracted, the variable data is converted into corresponding string data based on the string representation method, and the string data is used as the processed variable data. If the string conversion fails, an overview of the memory address and binary size of the variable data is generated, as well as a prompt message indicating the failure of variable parsing. The overview and the prompt message are then used as the processed variable data.

[0013] Optionally, the process of processing the variable data in the current call stack frame information based on a preset cross-language type mapping rule to obtain the processed variable data further includes: If the number of elements in the variable data exceeds a preset threshold, the target header data of the variable data is processed based on a preset cross-language type mapping rule to obtain the processing result. A target handle is generated for the remaining part of the variable data; wherein, the target handle is used to implement lazy loading processing for the remaining part of the data; The processed variable data is obtained based on the processing result and the target handle.

[0014] Optionally, the step of fusing the call stack frame information to generate a hybrid stack frame view includes: The concatenation order is determined based on the call chain identifier or execution timing logic; The call stack frame information is concatenated according to the concatenation order to generate a hybrid stack frame view.

[0015] Optionally, the cross-language debugging method further includes: When a debugging event is generated at runtime in any programming language, a global event identifier is generated based on the current timestamp and the source file identifier, and the existence of the global event identifier is queried in a preset hash table. If the global event identifier does not exist in the preset hash table, then the global event identifier is stored in the preset hash table; If the global event identifier exists in the preset hash table, the debug event is discarded.

[0016] Optionally, the cross-language debugging method further includes: When an interruption in the communication connection between the debug adapter corresponding to any programming language is detected, the debug instructions received during the communication interruption are cached in a buffer queue and their logical order is recorded. Once the communication connection is restored, the debugging instructions in the cache queue are replayed to the debugging adapter corresponding to any of the programming languages ​​in the logical order described above.

[0017] A second aspect of this application provides a cross-language debugging apparatus for use on a debugging server, comprising: The connection establishment module is used to establish a communication connection with the debugging adapters corresponding to each programming language when a cross-language debugging request is received from the debugging front end, and to establish a global virtual debugging session; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language; The running module is used to obtain the running instructions issued by the debugging front end and issue the running instructions to each debugging adapter so that the global virtual debugging session enters the running state; The breakpoint stop module is used to pause the global virtual debugging session when the runtime of the target programming language reaches a preset breakpoint position. The stack frame fusion module is used to obtain the corresponding call stack frame information from the runtime of each programming language, merge the call stack frame information to generate a hybrid stack frame view, and then return the hybrid stack frame view to the debugging front end for display.

[0018] A third aspect of this application provides an electronic device including a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned cross-language debugging method.

[0019] A fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the aforementioned cross-language debugging method.

[0020] As can be seen, when the debugging server in this application receives a cross-language debugging request from the debugging front end, it establishes a communication connection with the debugging adapters corresponding to each programming language and establishes a global virtual debugging session. The global virtual debugging session represents the global state generated after aggregating the runtime states of each programming language. It obtains the running instructions issued by the debugging front end and sends the running instructions to each debugging adapter to enable the global virtual debugging session to enter a running state. When the runtime of the target programming language reaches a preset breakpoint, the global virtual debugging session enters a paused state. It obtains the corresponding call stack frame information from the runtime of each programming language and merges the call stack frame information to generate a hybrid stack frame view, which is then returned to the debugging front end for display.

[0021] In this application, upon receiving a cross-language debugging request from the debugging frontend, a communication connection needs to be established with the corresponding debugging adapters for each programming language to facilitate bidirectional communication between the debugging server and the debugging adapters. Furthermore, by establishing a global virtual debugging session, the debugging states that were originally scattered across different language runtimes can be uniformly aggregated and managed. Compared to existing separate debugging solutions, this allows developers to monitor and manipulate multi-language code simultaneously within a single debugging interface, eliminating the problem of fragmented debugging contexts. When the runtime of the target programming language hits a breakpoint and pauses, the global virtual debugging session enters a paused state. Then, by fusing the call stack frame information from the runtimes of each programming language, a unified hybrid stack frame view is formed, virtually stitching together the originally physically isolated execution links of different languages ​​into a coherent execution flow. This achieves a seamless debugging experience and significantly improves the efficiency of cross-language fault location. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0023] Figure 1 This application discloses a system architecture diagram applicable to a cross-language debugging scheme; Figure 2 This is a flowchart of a cross-language debugging method disclosed in this application; Figure 3 This is a schematic diagram of a cross-language type mapping process disclosed in this application; Figure 4 This is a flowchart of a specific cross-language debugging method disclosed in this application; Figure 5 This is a schematic diagram of the structure of a cross-language debugging device disclosed in this application; Figure 6 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Traditional debugging methods employ a separate approach, requiring developers to simultaneously launch both the native Go debugger and the native Python debugger, switching between two independent debugging sessions. However, this approach completely fragments the debugging context, leaving developers unaware of the cross-language call chain. Furthermore, breakpoints are managed independently in the two debuggers, lacking consistency guarantees. Additionally, when viewing Python variables on the Go side, complex data structures are difficult to visualize due to differences in type systems. To address these issues, this application discloses a cross-language debugging method, apparatus, device, and storage medium, enabling unified debugging of multiple languages ​​in cross-language scenarios and ensuring the continuity of the debugging process.

[0026] Figure 1This application discloses a system architecture diagram for a cross-language debugging solution, which mainly adopts a layered architecture design, including a debugging front-end, debugging services and core logic, debugging agents and communication adapters, and language runtime adapters. The debugging front-end is responsible for user interaction and issuing debugging commands; the debugging service mainly includes a debugging server, used to interface with the IDE (Integrated Development Environment) protocol and coordinate various functional modules; the core logic mainly includes a unified session management module, a breakpoint consistency maintenance module, and a variable semantic mapping module. The unified session management module is responsible for cross-language debugging session state machine and context management; the breakpoint consistency maintenance module is responsible for global breakpoint IDs, version updates, and conflict merging; and the variable semantic mapping module is responsible for cross-language variable type conversion and rollback strategies. The debugging agent and communication adapter modules are responsible for protocol conversion and connection to the underlying runtime; and the language runtime adapters interface with the native debuggers of each programming language.

[0027] Figure 2 A flowchart illustrating a cross-language debugging method provided in this application embodiment. See also... Figure 2 As shown, this cross-language debugging method includes: Step S11: When a cross-language debugging request is received from the debugging front end, a communication connection is established with the debugging adapter corresponding to each programming language, and a global virtual debugging session is established; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language.

[0028] In this embodiment, users can issue cross-language debugging requests through a debugging frontend. The debugging frontend specifically refers to the IDE client or frontend, responsible for user interaction and issuing debugging commands. It should be noted that this application is primarily applicable to training and inference scenarios in AI engineering. In typical AI engineering practices, high-performance engineering frameworks are often implemented using compiled languages ​​such as Go and C++, while core algorithm models are developed using interpreted languages ​​such as Python. The two are integrated through plug-in or service-oriented methods, resulting in multi-language mixed-language programming and causing cross-language debugging challenges.

[0029] Therefore, when this application receives a cross-language debugging request from the debugging frontend, it first needs to establish a communication connection with the debugging adapter corresponding to each programming language, and simultaneously activate the native debugger corresponding to each programming language according to the configuration. This facilitates bidirectional communication between the debugging server and the native debugger of the programming language through the debugging adapter. For example, the native debugger for Go is Delve, and the native debugger for Python is debugpy.

[0030] Furthermore, a global virtual debugging session needs to be established. This session represents the global state generated by aggregating the runtime states of various programming languages, essentially converging event streams from different language adapters into a single virtual debugging session. In other words, the system no longer independently views the runtime state of a single programming language, but maintains an aggregated global state machine to unify the runtimes of different languages. Specifically, to achieve cross-language consistency, this application maintains an atomic state machine containing seven core states: Connecting, Attached, Running, Paused, Stepping, Detached, and Error.

[0031] The logic for determining the state transition is as follows: From Connecting state to Attached state: Initial conditions: Debug session started, system in setup state; Transition conditions: The state atomically transitions to the additional state if and only if the debug proxy layer reports that all target runtimes (Go / Python) have completed the handshake and returned the Ready signal. If any connection times out, the state transitions to the error state.

[0032] Attached state to Running state: Flow conditions: When the Start or Continue command is received from the user, the system broadcasts the recovery command to all underlying runtime environments.

[0033] From Running to Paused: Flow conditions: When any underlying runtime reports a pause event (such as hitting a breakpoint), the system immediately locks the global state to a paused state and forcibly suspends other language runtimes that are still running.

[0034] From Paused to Stepping: Flow condition: Received Next, StepIn, or StepOut instruction.

[0035] Boundary handling: In this state, the system will detect in real time whether the instruction pointer crosses the language boundary. If it does, the control target will be dynamically switched. After the single-step instruction is completed, it will automatically return to the paused state.

[0036] From any state to a detached state (Detached): Flow conditions: Receive an explicit Disconnect request from the user, or detect the exit of the underlying runtime process.

[0037] From any state to an error state: Transition conditions: In the heartbeat detection mechanism, if the heartbeat packets are lost continuously for more than the threshold (e.g., 3 times), or the underlying adapter reports an unrecoverable fatal error, the state machine is forced to transition to the error state to end the process and print the error message.

[0038] In this way, by establishing a global virtual debugging session, this application can unify and manage the debugging states that were originally scattered across different language runtimes. Compared with the existing separate debugging solutions, this allows developers to monitor and operate multi-language code simultaneously in a single debugging interface, eliminating the problem of fragmented debugging context.

[0039] Step S12: Obtain the running instruction issued by the debugging front end, and issue the running instruction to each debugging adapter so that the global virtual debugging session enters the running state.

[0040] In this embodiment, before receiving the execution instructions from the debugging frontend, the user can also set breakpoints in the user interface of the debugging frontend by sending a breakpoint setting request, which will be intercepted by the breakpoint consistency maintenance module. After receiving the breakpoint setting request from the debugging frontend, the debugging server will distribute the breakpoint setting instructions based on the characteristics of the source file, thereby achieving accurate matching between breakpoints and the target language runtime and avoiding debugging interference caused by invalid breakpoints.

[0041] Furthermore, when the user clicks "Continue Running," the running instruction issued by the debugging front-end is received. At this time, the debugging server can broadcast the running instruction to all controlled runtimes, and the global virtual debugging session enters the running state.

[0042] Step S13: When the runtime of the target programming language reaches the preset breakpoint, the global virtual debugging session is paused.

[0043] In this embodiment, it should also be noted that after the runtime of the target programming language reaches the corresponding breakpoint, the process further includes: responding to a stop signal sent by the debugging adapter corresponding to the target programming language, and performing communication protection on the runtimes of other programming languages ​​based on a preset communication protection mechanism. It is understood that when the runtime of the target programming language hits a preset breakpoint, the debugging adapter corresponding to that target programming language will send a stop signal to the system. At this time, the global virtual debugging session enters a paused state. Furthermore, this application will also intervene in the runtimes of other languages ​​through a preset communication protection mechanism, avoiding cross-language call chain interruptions or errors caused by a single language pause, ensuring the continuity of the debugging process, and thus providing developers with sufficient time to investigate the variable states and execution logic at the breakpoint. For example, in a typical AI engineering scenario, the execution flow initiates a cross-language request from the Go side. At this time, the corresponding thread on the Go side enters a synchronous blocking waiting state, and control is transferred to the Python side. When the execution flow hits the breakpoint on the Python side, the Python debug adapter sends a stop signal to the system. After receiving the signal, the session management module will automatically identify and mark the caller thread that is waiting on the Go side and enter a logical suspension state.

[0044] Step S14: Obtain the corresponding call stack frame information from the runtime of each programming language, merge the call stack frame information to generate a hybrid stack frame view, and then return the hybrid stack frame view to the debugging front end for display.

[0045] In this embodiment, the debugging server obtains the corresponding call stack frame information from the runtime of each programming language, and then merges the call stack frame information of each programming language runtime to form a unified hybrid stack frame view. This virtually splices the originally physically isolated execution links of different languages ​​into a coherent execution flow, achieving a seamless debugging experience and greatly improving the efficiency of cross-language fault location.

[0046] Furthermore, the above method also includes: processing the variable data in the current call stack frame information corresponding to the target programming language based on a preset cross-language type mapping rule to obtain processed variable data; correspondingly, returning the hybrid stack frame view to the debugging front end for display includes: encapsulating the hybrid stack frame view and the processed variable data to obtain an encapsulated stack frame view, and returning the encapsulated stack frame view to the debugging front end for display. That is, when the system pauses at the breakpoint position of the target programming language, this application needs to obtain the current call stack frame information corresponding to the target programming language, and process the variable data in the current call stack frame information based on a preset cross-language type mapping rule to obtain processed variable data. The purpose is to convert the variable data into a representation that the debugging interface can understand. Then, the complete hybrid stack frame view and the mapped processed variable data are encapsulated to obtain an encapsulated stack frame view, and the encapsulated stack frame view is returned to the debugging front end for display, thereby presenting the user with a unified debugging view that integrates multiple language contexts.

[0047] In a specific implementation, the step of processing the variable data in the current call stack frame information based on a preset cross-language type mapping rule to obtain processed variable data includes: identifying the variable type of the variable data in the current call stack frame information and obtaining a pre-established type mapping table; wherein, the type mapping table is used to record the mapping relationship between the original variable type and the structured format; determining whether the variable type of the variable data exists in the type mapping table; if it exists, then using the type mapping table to convert the target variable type of the variable data into the corresponding structured format to obtain processed variable data; if it does not exist, then processing the variable data based on a preset fallback strategy to obtain processed variable data.

[0048] That is, such as Figure 3As shown, this application can identify the specific variable types of each variable in the current call stack frame information, specifically covering basic types, composite types, and user-defined types. Basic types include int, float, bool, string, bytes, etc., while composite types include list, smap, struct, class, and tensor types commonly used in AI projects. Furthermore, this application can pre-establish a type mapping table that explicitly records the correspondence between the primitive variable types of different programming languages ​​and a unified structured format. For example, it maps Python's dict to a common key-value structure used in debugging protocols, and lists to array structures, etc. In addition, for nested complex objects, a recursive traversal algorithm can be used for deep parsing, ensuring that the front-end IDE can view the variable details of heterogeneous languages ​​layer by layer, just like displaying native variables. In other words, this application uses a predefined type mapping table and a recursive traversal algorithm to standardize and convert complex data structures of specific languages ​​(such as Python dictionaries or Go structs) and logically related data in cross-language interactions into a hierarchical structure (such as key-value or array views) that is common to debugging protocols. This shields the differences in underlying storage and ensures that the front-end IDE can expand and display heterogeneous data layer by layer in a natively compatible manner.

[0049] Furthermore, this application needs to determine whether the variable type of the variable data exists in the type mapping table, that is, whether it can be accurately mapped through the type mapping table. If it exists, the target variable type of the variable data is directly converted into the corresponding structured format using the type mapping table. This allows for recursive parsing and format conversion of the variable data. For composite type variables, nested structures and container elements need to be expanded as needed, and pagination or truncation processing is supported to adapt to large object scenarios. Finally, the variable data is converted into the corresponding structured format that the debugging front-end can directly recognize, resulting in processed variable data containing complete metadata and hierarchical structure. Conversely, if it does not exist, it means that the variable type of the variable data may be a user-defined type, such as a custom C extended type variable. In this case, the variable data is processed based on a preset fallback strategy to obtain the processed variable data.

[0050] Specifically, the step of processing the variable data based on a preset rollback strategy to obtain processed variable data includes: extracting common attributes from the variable data; if the common attributes are extracted, generating a structured summary based on the common attributes, and using the structured summary as processed variable data; if the common attributes are not extracted, converting the variable data into corresponding string data based on a string representation method, and using the string data as processed variable data; if the string conversion fails, generating overview information containing the memory address and binary size of the variable data, and generating a prompt message to indicate variable parsing failure, and using the overview information and the prompt message as processed variable data.

[0051] In other words, when executing the rollback strategy, priority is given to extracting common attributes of the variable data to generate a structured summary, which is then used as the processed variable data. These common attributes can include basic metadata such as variable type name, memory usage, and data encoding format; business-specific attributes such as the shape, data type, and total number of elements of an AI tensor; and state attributes such as whether the object is initialized, its reference count, and the thread it belongs to. If common attributes cannot be extracted (e.g., the variable has no public attributes or reflection is disabled), the variable's native string representation method is called to convert the variable data into the corresponding string data, which is then used as the processed variable data. For example, the object's `str()` method can be called first, as it aims to return a user-friendly, readable string. If `str()` does not exist or fails, the `repr()` method is called, which returns an official, usually more detailed, string representation (often used for debugging). Furthermore, if string conversion also fails, an overview of the variable data's memory address and binary size is generated, returning only the most basic hardware-level information and explicitly indicating that variable resolution failed. In this context, the memory address is the virtual memory address of the variable during runtime, used to locate the variable's physical location; the binary size is the number of bytes of memory occupied by the variable, reflecting the variable's scale. By setting a rollback strategy, processed variable data can be obtained that ensures the debugging process is not interrupted and provides developers with effective reference information.

[0052] It should also be noted that the process of processing the variable data in the current call stack frame information based on the preset cross-language type mapping rules to obtain the processed variable data further includes: if the number of elements in the variable data exceeds a preset threshold, processing the target header data of the variable data based on the preset cross-language type mapping rules to obtain a processing result; generating a target handle for the remaining data of the variable data; wherein the target handle is used to implement lazy loading processing of the remaining data; and obtaining the processed variable data based on the processing result and the target handle.

[0053] Understandably, considering the large tensors or datasets often involved in AI engineering, a pagination and truncation mechanism is implemented within the variable semantic mapping module to avoid blocking the debugging channel. Specifically, when the number of elements in the variable data exceeds a preset threshold (e.g., more than 100 elements), the target header data is processed based on preset cross-language type mapping rules to obtain the processing result. In other words, for sets exceeding the threshold, only the header data is parsed, while a lazy-loaded handle is generated for the remaining parts. A secondary request is only initiated when the user clicks to expand. It should be noted that the lazy-loaded handle is a lightweight, unique reference identifier generated by the debugging server to address performance issues caused by full parsing and transmission of large objects / complex variables. It is not the variable data itself, but rather a carrier encapsulating the context information needed to locate the variable and obtain the specified segment data. Only when the debugging frontend (such as an IDE) triggers an expand or view operation does the debugging server use this handle to pull the target segment data of the variable from the corresponding language runtime, achieving on-demand loading and partial loading.

[0054] As can be seen, when this application receives a cross-language debugging request from the debugging front-end, it needs to establish a communication connection with the debugging adapters corresponding to each programming language to facilitate bidirectional communication between the debugging server and the debugging adapters. Furthermore, by establishing a global virtual debugging session, the debugging states that were originally scattered across different language runtimes can be uniformly aggregated and managed. Compared with existing separate debugging solutions, this allows developers to monitor and operate multi-language code simultaneously in a single debugging interface, eliminating the problem of fragmented debugging contexts. When the runtime of the target programming language hits a breakpoint and pauses, the global virtual debugging session enters a paused state. Then, by fusing the call stack frame information of each programming language runtime, a unified hybrid stack frame view is formed, virtually stitching together the originally physically isolated execution links of different languages ​​into a coherent execution flow, achieving a seamless debugging experience and significantly improving the efficiency of cross-language fault location.

[0055] Figure 4 A flowchart illustrating a specific cross-language debugging method provided in this application embodiment. See also... Figure 4 As shown, this cross-language debugging method includes: Step S21: When a cross-language debugging request is received from the debugging front end, a communication connection is established with the debugging adapter corresponding to each programming language, and a global virtual debugging session is established; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language.

[0056] Step S22: Obtain the breakpoint setting request issued by the debugging front end, and parse the breakpoint setting request to obtain the source file characteristics corresponding to the breakpoint to be set; wherein, the source file characteristics are source file path suffix or metadata characteristics.

[0057] In this embodiment, a breakpoint setting request is obtained from the debugging front end. This request may contain core information such as the source file identifier, line number, and function name associated with the breakpoint to be set. After receiving the request, the debugging server starts the breakpoint request parsing process. The core objective is to accurately identify the target programming language type to which the breakpoint to be set belongs, thereby realizing the targeted distribution of breakpoint setting instructions.

[0058] During the parsing process, the focus is on extracting the characteristics of the source files corresponding to the breakpoints to be set. These characteristics are specifically source file path suffixes or metadata features. The source file path suffix is ​​the most direct identification criterion; for example, the .go suffix corresponds to the Go language, the .py suffix to the Python language, and the .java suffix to the Java language. This can be quickly determined by truncation and matching of the path string. Metadata features cover implicit features such as the source file's encoding format, language identifier field, and module declaration information. These are suitable for source files with unclear path suffixes or dynamically generated source files, such as script files without suffixes transmitted over the network in a distributed deployment. In such cases, the language type can be determined by parsing the metadata in the source file header.

[0059] Step S23: Based on the source file features, identify the programming language type corresponding to the breakpoint to be set, and send a breakpoint setting instruction to the debug adapter corresponding to the programming language type to mark the breakpoint position and obtain the preset breakpoint position.

[0060] In this embodiment, after identifying the programming language type corresponding to the breakpoint to be set based on the source file characteristics, the breakpoint setting instruction is sent to the debugging adapter corresponding to the programming language type. For example, for files ending in .go, the breakpoint setting instruction is only encapsulated and sent to the Go debugging adapter; for files ending in .py, the instruction is sent to the Python debugging adapter. This precise routing mechanism avoids sending invalid instructions to runtimes that do not support the file, effectively preventing the underlying debugger from reporting errors due to file not being found.

[0061] In a specific implementation, the process of sending a breakpoint setting instruction to the debug adapter corresponding to the programming language type further includes: if the code module corresponding to the breakpoint to be set is not loaded in the runtime of the programming language corresponding to the programming language type, then the breakpoint setting instruction is cached in a preset pending list and the breakpoint setting instruction is marked as pending activation; the module loading event of the runtime of the programming language corresponding to the programming language type is monitored, and when the code module is detected to be loaded, the breakpoint setting instruction in the preset pending list is activated and sent to the corresponding debug adapter. Understandably, in response to the dynamic loading characteristics common in interpreted languages ​​such as Python, this solution also designs a shadow breakpoint mechanism. That is, if the code module corresponding to the breakpoint to be set is not loaded in the runtime of the programming language corresponding to the programming language type, the breakpoint setting instruction will be marked as a shadow breakpoint and stored in a preset pending list. The shadow breakpoint can be understood as being in a pending state. Furthermore, this application will monitor the module loading event of the runtime of the programming language corresponding to the programming language type in real time. When the code module is detected to be loaded, the breakpoint setting instruction in the preset pending list will be activated immediately and sent to the corresponding debug adapter.

[0062] Step S24: Obtain the running instruction issued by the debugging front end, and issue the running instruction to each debugging adapter so that the global virtual debugging session enters the running state.

[0063] Step S25: When the runtime of the target programming language reaches the preset breakpoint, in response to the stop signal sent by the debug adapter corresponding to the target programming language, the runtime of the other programming languages ​​is controlled to enter the logical suspension state, and the global virtual debug session is put into a pause state.

[0064] In this embodiment, when the runtime of the target programming language (such as the Python runtime) reaches a pre-marked breakpoint, the corresponding debug adapter for that language immediately detects the breakpoint hit event and sends a standardized stop signal to the debug server. Upon receiving this stop signal, the debug server first triggers a state transition of the global virtual debug session, synchronously switching the global session from its running state to a paused state. This ensures unified state management for cross-language debugging and avoids context fragmentation caused by asynchronous states of multiple language runtimes. Simultaneously, based on the cross-language call chain association information maintained by the global virtual debug session, the debug server accurately identifies other programming language runtimes (such as the Go runtime) that have call dependencies with the target language runtime and issues logical suspension instructions to the debug adapters for these languages, controlling the other runtimes to enter a logical suspension state. At this time, the other runtimes only pause the execution flow related to cross-language debugging, while the core business processes remain alive, preventing program crashes or data loss due to forced interruption.

[0065] Step S26: Intervene with the communication stubs of the other programming languages ​​to suppress the timeout retry mechanism or error reporting mechanism on the other programming language side; wherein, the intervention process includes modifying the communication context of the communication stub or injecting a preset debugging delay instruction into the communication stub.

[0066] In this embodiment, to further ensure the continuity of the cross-language debugging link, the debugging server will intervene in the communication stubs of other programming languages. The core purpose is to suppress the timeout retry mechanism or error reporting mechanism caused by debugging pauses in that language. The specific intervention process employs two flexibly switchable implementation methods: First, by modifying the communication context parameters of the communication stub, such as extending the timeout waiting threshold for cross-language calls and temporarily marking the debugging status bit, the communication stub is made to believe that it is currently in a normal waiting response phase, rather than a timeout exception. Second, a preset debugging delay instruction is injected into the communication stub. This instruction will temporarily block the execution of the timeout detection logic, or return a virtual response in the debugging delay before the timeout detection is triggered, avoiding triggering retry requests or error alarms. Through the above intervention measures, the communication link between the runtimes of other languages ​​and the runtime of the target language can be maintained during the period when the target language runtime is paused due to a breakpoint. This provides developers with sufficient time to investigate the variable status and execution logic at the breakpoint, solving the core pain point of call chain interruption caused by a single language pause in cross-language debugging.

[0067] Step S27: Obtain the corresponding call stack frame information from the runtime of each programming language, determine the splicing order based on the call chain identifier or execution timing logic, splice the call stack frame information according to the splicing order to generate a hybrid stack frame view, and then return the hybrid stack frame view to the debugging front end for display.

[0068] In this embodiment, assuming a breakpoint on the Python side is hit, after the system logic is suspended, the debugging proxy layer obtains the current execution stack frame on the Python side and traces back to the blocked call stack frame on the Go side. Using a unique TraceID or session identifier, the two physically isolated call chains are glued together, thus returning a complete hybrid stack frame view to the IDE, extending from the Go logic entry point to the Python algorithm core, achieving a seamless debugging experience. It is understandable that in common AI engineering RPC calls or plugin calls, the Go debugger typically only sees the Go stack frame, while Python only sees the Python stack frame. This application maintains a logical call stack. When a cross-language call is detected (e.g., the Go side is in a waiting state while the Python side has just started execution), the proxy layer automatically extracts the bottom of the Go stack and the top of the Python stack, virtually splicing them together based on the call chain ID (TraceID) or timing logic. Finally, a list of stack frames from both languages ​​is returned to the IDE, allowing developers to trace back from the Python function to the source of the Go function call.

[0069] Furthermore, the above method also includes: when a debugging event is generated by the runtime of any programming language, a global event identifier is generated based on the current timestamp and the source file identifier, and the existence of the global event identifier is checked in a preset hash table; if the global event identifier does not exist in the preset hash table, the global event identifier is stored in the preset hash table; if the global event identifier exists in the preset hash table, the debugging event is discarded. It is understood that this application, in order to solve the signal duplication and out-of-order problem in a distributed debugging environment, adopts a strict event governance strategy, that is, when a debugging event is generated by the runtime of any programming language, the system will use the timestamp combined with the source file identifier to generate a global event identifier (EventID). When processing the event, the system will first check whether the EventID exists in the preset hash table. If the EventID already exists, the debugging event is directly discarded to achieve idempotent processing; if the EventID does not exist in the preset hash table, the debugging event is processed, and the corresponding EventID is stored in the preset hash table.

[0070] For example, when Go runtime reaches a breakpoint, the Go adapter generates a breakpoint hit event, and the system automatically generates a globally unique EventID for this event. However, due to the distributed network latency / retry mechanism, the Go adapter sends the breakpoint hit event twice (with the same EventID). When the debug service layer receives the first event: it queries the preset hash table (initially empty), finds no record of the EventID, changes the global session state to Paused, suspends the Python runtime logic, and stores the EventID in the preset hash table, marking it as processed. Then, when it receives the second breakpoint hit event with the same EventID, it queries the hash table, finds the EventID already exists, and directly discards the duplicate event without executing any logic, achieving idempotent processing and avoiding repeated session state changes and debug logic confusion caused by duplicate events.

[0071] In this embodiment, the method further includes: when an interruption in the communication connection between the debug adapter and any programming language is detected, a cache queue is used to cache the debug instructions received during the communication interruption and record their logical order; when the communication connection is restored, the debug instructions in the cache queue are replayed to the debug adapter corresponding to any programming language in the logical order. That is, for scenarios involving disconnection and reconnection due to network fluctuations, this application also maintains a cache queue sorted by a logical clock. When an interruption in the communication connection between the debug adapter and any programming language is detected, this cache queue is used to cache the debug instructions received during the communication interruption and record their logical order. When the communication connection is restored, the debug instructions in the cache queue are replayed to the debug adapter corresponding to any programming language in the logical order, thereby ensuring that the evolution order of the debugging context is strictly consistent with the actual execution logic.

[0072] It's also worth noting that the debug proxy layer maintains a real-time language attribution table for currently active threads. When it receives a control command (such as "Next" for stepping) from the frontend, the proxy layer queries which language runtime currently holds control. If it's currently in Python code, the command is automatically forwarded to the Python adapter; otherwise, it's forwarded to the Go adapter. This mechanism allows users to continuously step through mixed code without manually switching debugger contexts.

[0073] The communication adapter module, located at the lowest level of the system, is responsible for shielding the specific network transmission details, achieving decoupling and replaceability of the transport layer. This application defines a unified internal communication interface, ITransportAdapter, covering methods for sending requests, subscribing to events, and connection management. Regardless of the underlying communication protocol used (e.g., JSON-RPC on the Go side, DAP over TCP on the Python side), this module encapsulates it into a unified interface implementation. This means that when the underlying transmission method changes due to architectural adjustments (e.g., switching from local Socket to remote gRPC), the upper-layer session management and breakpoint logic do not require any modification, greatly improving the system's scalability and maintainability.

[0074] In this embodiment, the specific processes of steps S21 and S24 can be referred to the corresponding contents disclosed in the foregoing embodiments, and will not be repeated here.

[0075] As can be seen, existing cross-language debugging solutions mainly rely on separate multi-debugger orchestration, request pass-through proxies, or shared-store state synchronization, which suffer from problems such as context fragmentation, difficulty in ensuring breakpoint consistency, insufficient real-time performance and robustness, and coupling with specific communication methods. This application proposes a unified debugging solution for multiple languages, systematically addressing the above problems from aspects such as session abstraction, breakpoint consistency, variable semantics, and communication adaptation.

[0076] See Figure 5 As shown in the illustration, this application also discloses a cross-language debugging device, applied to a debugging server, comprising: The connection establishment module 11 is used to establish a communication connection with the debugging adapters corresponding to each programming language when a cross-language debugging request is received from the debugging front end, and to establish a global virtual debugging session; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language; The running module 12 is used to obtain the running instructions issued by the debugging front end and issue the running instructions to each debugging adapter so that the global virtual debugging session enters the running state; The breakpoint stop module 13 is used to pause the global virtual debugging session when the runtime of the target programming language reaches a preset breakpoint position. The stack frame fusion module 14 is used to obtain the corresponding call stack frame information from the runtime of each programming language, fuse the call stack frame information to generate a hybrid stack frame view, and then return the hybrid stack frame view to the debugging front end for display.

[0077] As can be seen, when this application receives a cross-language debugging request from the debugging front-end, it needs to establish a communication connection with the debugging adapters corresponding to each programming language to facilitate bidirectional communication between the debugging server and the debugging adapters. Furthermore, by establishing a global virtual debugging session, the debugging states that were originally scattered across different language runtimes can be uniformly aggregated and managed. Compared with existing separate debugging solutions, this allows developers to monitor and operate multi-language code simultaneously in a single debugging interface, eliminating the problem of fragmented debugging contexts. When the runtime of the target programming language hits a breakpoint and pauses, the global virtual debugging session enters a paused state. Then, by fusing the call stack frame information of each programming language runtime, a unified hybrid stack frame view is formed, virtually stitching together the originally physically isolated execution links of different languages ​​into a coherent execution flow, achieving a seamless debugging experience and significantly improving the efficiency of cross-language fault location.

[0078] Since the embodiments of the device section correspond to the embodiments of the method section, please refer to the description of the embodiments in the method section for the embodiments of the device section, and they will not be repeated here. Furthermore, it has the same beneficial effects as the cross-language debugging method mentioned above.

[0079] Furthermore, embodiments of this application also provide an electronic device. Figure 6 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0080] Figure 6 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the cross-language debugging method disclosed in any of the foregoing embodiments.

[0081] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0082] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222 and data 223, etc., and the storage method can be temporary storage or permanent storage.

[0083] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system can be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the cross-language debugging methods executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks. The data 223 may include image quality control strategies collected by the electronic device 20, etc.

[0084] Furthermore, this application also discloses a storage medium storing a computer program, which, when loaded and executed by a processor, implements the cross-language debugging method steps disclosed in any of the foregoing embodiments.

[0085] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0086] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0087] The present invention provides a detailed description of a cross-language debugging method, apparatus, device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A cross-language debugging method, characterized in that, Used in debugging servers, including: When a cross-language debugging request is received from the debugging front end, a communication connection is established with the debugging adapter corresponding to each programming language, and a global virtual debugging session is established; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language; Obtain the running command issued by the debugging front end, and issue the running command to each debugging adapter so that the global virtual debugging session enters the running state; When the runtime of the target programming language reaches the preset breakpoint, the global virtual debugging session is paused. The corresponding call stack frame information is obtained from the runtime of each programming language, and the call stack frame information is merged to generate a hybrid stack frame view. The hybrid stack frame view is then returned to the debugging front end for display.

2. The cross-language debugging method according to claim 1, characterized in that, Before obtaining the execution instructions issued by the debugging front-end, the method further includes: Obtain the breakpoint setting request issued by the debugging front end, and parse the breakpoint setting request to obtain the source file characteristics corresponding to the breakpoint to be set; wherein, the source file characteristics are source file path suffix or metadata characteristics; Based on the source file features, the programming language type corresponding to the breakpoint to be set is identified, and a breakpoint setting instruction is sent to the debug adapter corresponding to the programming language type to mark the breakpoint position and obtain the preset breakpoint position.

3. The cross-language debugging method according to claim 2, characterized in that, The process of sending breakpoint setting instructions to the debug adapter corresponding to the programming language type also includes: If the code module corresponding to the breakpoint to be set is not loaded in the runtime of the programming language corresponding to the programming language type, the breakpoint setting instruction is cached in the preset pending list and the breakpoint setting instruction is marked as pending activation. Listen for the module loading event of the programming language runtime corresponding to the programming language type. When the code module is loaded, activate the breakpoint setting instruction in the preset pending list and send it to the corresponding debug adapter.

4. The cross-language debugging method according to claim 1, characterized in that, After the target programming language runtime reaches the corresponding breakpoint location, the process further includes: In response to a stop signal sent by the debug adapter corresponding to the target programming language, communication protection is provided for the runtime of other programming languages ​​based on a preset communication protection mechanism.

5. The cross-language debugging method according to claim 4, characterized in that, The provision of runtime communication protection for other programming languages ​​based on a preset communication protection mechanism includes: Controls the runtime of other programming languages ​​to enter a logical suspension state; Intervene on the communication stubs of the other programming languages ​​to suppress the timeout retry mechanism or error reporting mechanism on the other programming language side; wherein, the intervention process includes modifying the communication context of the communication stub or injecting a preset debugging delay instruction into the communication stub.

6. The cross-language debugging method according to claim 1, characterized in that, Also includes: For the current call stack frame information corresponding to the target programming language, the variable data in the current call stack frame information is processed based on the preset cross-language type mapping rules to obtain the processed variable data; Accordingly, returning the hybrid stack frame view to the debugging front end for display includes: The hybrid stack frame view is encapsulated with the processed variable data to obtain an encapsulated stack frame view, and the encapsulated stack frame view is returned to the debugging front end for display.

7. The cross-language debugging method according to claim 6, characterized in that, The variable data in the current call stack frame information is processed based on a preset cross-language type mapping rule to obtain processed variable data, including: Identify the variable type of the variable data in the current call stack frame information and obtain a pre-established type mapping table; wherein, the type mapping table is used to record the mapping relationship between the original variable type and the structured format; Determine whether the variable type of the variable data exists in the type mapping table; If it exists, the target variable type of the variable data is converted into the corresponding structured format using the type mapping table to obtain the processed variable data; If it does not exist, the variable data is processed based on a preset rollback strategy to obtain the processed variable data.

8. The cross-language debugging method according to claim 7, characterized in that, The process of processing the variable data based on a preset rollback strategy to obtain processed variable data includes: Extract common attributes from the variable data; If the common attribute is extracted, a structured summary is generated based on the common attribute, and the structured summary is used as the processed variable data; If the public attribute is not extracted, the variable data is converted into corresponding string data based on the string representation method, and the string data is used as the processed variable data. If the string conversion fails, an overview of the memory address and binary size of the variable data is generated, as well as a prompt message indicating the failure of variable parsing. The overview and the prompt message are then used as the processed variable data.

9. The cross-language debugging method according to claim 6, characterized in that, The process of processing the variable data in the current call stack frame information based on the preset cross-language type mapping rules to obtain the processed variable data also includes: If the number of elements in the variable data exceeds a preset threshold, the target header data of the variable data is processed based on a preset cross-language type mapping rule to obtain the processing result. A target handle is generated for the remaining part of the variable data; wherein, the target handle is used to implement lazy loading processing for the remaining part of the data; The processed variable data is obtained based on the processing result and the target handle.

10. The cross-language debugging method according to claim 1, characterized in that, The step of fusing the call stack frame information to generate a hybrid stack frame view includes: The concatenation order is determined based on the call chain identifier or execution timing logic; The call stack frame information is concatenated according to the concatenation order to generate a hybrid stack frame view.

11. The cross-language debugging method according to any one of claims 1 to 10, characterized in that, Also includes: When a debugging event is generated at runtime in any programming language, a global event identifier is generated based on the current timestamp and the source file identifier, and the existence of the global event identifier is queried in a preset hash table. If the global event identifier does not exist in the preset hash table, then the global event identifier is stored in the preset hash table; If the global event identifier exists in the preset hash table, the debug event is discarded.

12. The cross-language debugging method according to any one of claims 1 to 10, characterized in that, Also includes: When an interruption in the communication connection between the debug adapter corresponding to any programming language is detected, the debug instructions received during the communication interruption are cached in a buffer queue and their logical order is recorded. Once the communication connection is restored, the debugging instructions in the cache queue are replayed to the debugging adapter corresponding to any of the programming languages ​​in the logical order described above.

13. A cross-language debugging device, characterized in that, Used in debugging servers, including: The connection establishment module is used to establish a communication connection with the debugging adapters corresponding to each programming language when a cross-language debugging request is received from the debugging front end, and to establish a global virtual debugging session; wherein, the global virtual debugging session is used to represent the global state generated after aggregating the runtime states of each programming language; The running module is used to obtain the running instructions issued by the debugging front end and issue the running instructions to each debugging adapter so that the global virtual debugging session enters the running state; The breakpoint stop module is used to pause the global virtual debugging session when the runtime of the target programming language reaches a preset breakpoint position. The stack frame fusion module is used to obtain the corresponding call stack frame information from the runtime of each programming language, merge the call stack frame information to generate a hybrid stack frame view, and then return the hybrid stack frame view to the debugging front end for display.

14. An electronic device, characterized in that, The electronic device includes a processor and a memory, wherein: The memory is used to store computer programs; The computer program is loaded and executed by the processor to implement the cross-language debugging method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, Used to store computer-executable instructions, which, when loaded and executed by a processor, implement the cross-language debugging method as described in any one of claims 1 to 12.

Images