Computer implementation methods, computer systems, and computer programs (using containers to clean up runtime resources when unloading shared libraries).

Abstract

To provide a computer-implemented method, computer system and computer program product using containers to clean up runtime resources when unloading a shared library.SOLUTION: Embodiments of the invention include a computer-implemented method that includes using a processor to access a loader library; using the processor to generate a mock library comprising a mock version of the loader library; using the processor to containerize the loader library; and using the processor to unload the loader library.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to programmable computer systems. More specifically, the present invention relates to a computer system, a computer-implemented method, and a computer program product that utilize a container to clean up runtime resources when unloading a shared library, thereby avoiding segmentation errors.

Background Art

[0002] A microservice is a type of software architecture that divides the functions of a software application into smaller fragments to enhance the fault tolerance and scalability of the application. The smaller fragments are called "services". Each service focuses on only a single function of the application and is modularized in that it is separated from other services and each is independent. By modularization, the development team does not need to perform complex design-related orchestration between teams and can work on different services separately.

[0003] Different microservices can communicate with each other through APIs or web services to execute the overall functions of an application. For example, microservices can communicate with each other and with other software applications using the Remote Procedure Call (RPC) protocol. RPC is a protocol that can be used by a program to request a service from a program on another computer on the network without understanding the details of the network. The RPC protocol uses a client-server model. The program that requests is the client, and the program that provides the service is the server.

[0004] Application programs improve efficiency in both development and execution by utilizing libraries. A library is a collection of non-volatile resources used by computer programs. Libraries are commonly used in software development. Libraries can include configuration data, documentation, help data, message templates, pre-written code, and pre-written subroutines. Programmers who want to write more advanced programs can use libraries to create system calls instead of implementing them repeatedly. The code in a library is structured to be usable by multiple unrelated programs, but the code that is part of a program is structured to be usable only within that program. Libraries are structured to be reusable in independent programs and subprograms, and users do not need to know the internal details of the library, only the interface. Libraries enable the reuse of standardized program elements. When a program calls a library, it can obtain the behavior implemented in that library without having to implement it itself. Libraries promote modular code sharing and facilitate code distribution.

[0005] The behavior implemented by a library can be called and linked to the program at different stages of the program's lifecycle. If the library's code is accessed during the construction of the calling program, the library is called a static library. Alternatively, the calling program's executable file can be constructed and distributed separately from the library's implementation. In this case, the library's behavior is linked after the executable file is called and executed, either as part of the process that initiates execution or during execution. In this case, the library is called a dynamic library (loaded at runtime). Dynamic libraries can be loaded and linked by the linker when preparing the program for execution. Furthermore, applications can explicitly request the loading of modules during execution. [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] This invention provides a computer implementation method, computer system, and computer program product that uses a container to clean up runtime resources when unloading shared libraries. [Means for solving the problem]

[0007] Embodiments of the present invention include a computer implementation method that includes using a processor to access a loader library, using a processor to generate a mock library containing a mock version of the loader library, using a processor to containerize the loader library, and using a processor to unload the loader library.

[0008] Embodiments of the present invention also provide computer systems and computer program products having substantially the same features as the computer implementation method described above.

[0009] Additional features and advantages are realized by the technology of the present invention. Other embodiments and aspects of the present invention are described in detail herein and are considered part of the claimed invention. For a better understanding of the present invention, including its advantages and features, please refer to this specification and the drawings. [Brief explanation of the drawing]

[0010] [Figure 1] This is a branch diagram illustrating a system embodying an aspect of the present invention. [Figure 2] This is a branch diagram illustrating a system embodying an aspect of the present invention. [Figure 3] This is a branch diagram illustrating a system embodying an aspect of the present invention. [Figure 4] This is a branch diagram illustrating a system embodying an aspect of the present invention. [Figure 5]This figure shows details of an exemplary computing system that can carry out aspects of the present invention. [Figure 6] This figure shows a cloud computing environment according to an embodiment of the present invention. [Figure 7] This figure shows an abstraction model layer according to an embodiment of the present invention. [Modes for carrying out the invention]

[0011] The subject matter considered to be the present invention is specifically pointed out and explicitly claimed in the claims at the end of this specification. The above and other features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0012] For the sake of brevity, prior art relating to the manufacture and use of embodiments of the present invention may or may not be described in detail herein. In particular, various embodiments of computing systems and specific computer programs for implementing the various technical features described herein are known. Therefore, for the sake of brevity, many prior implementation details are either briefly mentioned herein or omitted entirely without providing details of well-known systems or processes or both.

[0013] Many of the functional units of the systems described herein are referred to as modules. Embodiments of the present invention apply to a wide variety of module implementations. For example, a module can be implemented as a hardware circuit including a custom VLSI circuit or commercially available semiconductors such as a gate array, logic chip, transistor, or other discrete component. Alternatively, a module can be implemented in a programmable hardware device such as a field-programmable gate array, programmable array logic, or programmable logic device. Furthermore, a module can be implemented in software for execution by various types of processors. A specified module of executable code may include one or more physical or logical blocks of computer instructions, which can be organized as, for example, objects, procedures, or functions. However, the executable code of a specified module does not need to be physically located together and may include heterogeneous instructions stored in different locations; when they are logically combined, they function as a module and achieve the stated purpose for a module.

[0014] The various components, modules, subfunctions, etc. of the system illustrated herein are depicted separately for the sake of illustration and explanation. In embodiments of the present invention, the operations performed by the various components, modules, subfunctions, etc. may be distributed differently from those shown without departing from the scope of the various embodiments of the present invention described herein, unless otherwise specified.

[0015] For convenience, some of the technical functions and / or operations described herein will be communicated using informal language. For example, a processor having data stored in cache memory can be described as the processor "knowing" that data. Similarly, a user sending a load data command to a processor can be described as the user "telling" the processor to load data. Such informal language in this detailed description should be read in conjunction with the more formal technical description that corresponds to that informal language, and it is understood that those skilled in the art will understand the extent to which such informal language is covered.

[0016] Now, turning to an overview of the technology more specifically related to aspects of the present invention, as already described herein, microservices are a type of software architecture that divides the functionality of a software application into smaller fragments to improve the fault tolerance and scalability of the application. These smaller fragments are called “services.” Each service is modular in that it focuses on only one function of the application, is isolated from other services, and is independent of each other. Modularity allows development teams to work on different services separately without requiring complex design-related orchestration between teams.

[0017] Different microservices can communicate with each other through APIs or web services to perform the overall functionality of an application. For example, microservices can communicate with each other and with other software applications using the Remote Procedure Call (RPC) protocol. RPC is a protocol that can be used for a program to request services from a program on another computer on a network without understanding the network details. The RPC protocol uses a client-server model. The program making the request is the client, and the program providing the service is the server.

[0018] Application programs improve efficiency in both development and execution by utilizing libraries. A library is a collection of non-volatile resources used by computer programs. Libraries are commonly used in software development. Libraries can include configuration data, documentation, help data, message templates, pre-written code, and pre-written subroutines. Programmers who want to write more advanced programs can use libraries to create system calls instead of implementing them repeatedly. The code in a library is structured to be usable by multiple unrelated programs, but the code that is part of a program is structured to be usable only within that program. Libraries are structured to be reusable in independent programs and subprograms, and users do not need to know the internal details of the library, only the interface. Libraries enable the reuse of standardized program elements. When a program calls a library, it can obtain the behavior implemented in that library without having to implement it itself. Libraries promote modular code sharing and facilitate code distribution.

[0019] The behavior implemented by a library can be linked to the calling program at different stages of the program's lifecycle. If the library's code is accessed during the construction of the calling program, the library is called a static library. Alternatively, the calling program's executable file can be constructed and distributed separately from the library implementation. In this case, the library's behavior is linked after the executable file is called and executed, either as part of the process that initiates execution or during execution. In this case, the library is called a dynamic library (loaded at runtime). Dynamic libraries can be loaded and linked by the linker when preparing the program for execution. Furthermore, applications can explicitly request the loading of modules during execution.

[0020] Dynamic loading is a mechanism by which a computer program loads a library (or other binary) into memory at runtime, obtains the addresses of functions and variables contained in the library, executes those functions or accesses the variables, and can unload the library from memory. gRPC (Google (registered trademark) Remote Procedure Call) is the latest open-source high-performance RPC framework and can be run in any environment. Some RPC frameworks (such as gRPC) do not support "cross-process calls" and accordingly cannot unload the gRPC library. More specifically, in such RPC frameworks, a segmentation violation occurs when unloading a shared object.

[0021] Turning to an overview of aspects of the present invention, embodiments of the present invention provide a computer system, a computer-implemented method, and a computer program product that avoid segmentation violations that occur when attempting to unload a shared library by using a container to clean up runtime resources when a known RPC framework unloads the shared library. An innovative computer-implemented method according to embodiments of the present invention is provided to unload a shared library and safely clean up the execution environment. Embodiments of the present invention use a containerized libld.so (i.e., a containerized dynamic linker / loader) and a target shared library (i.e., the shared library to be unloaded) to create a language environment that can be safely destroyed when unloading the target shared library. The suffix of a shared library is always ".so". The program instructions / functions "libtarget_go.so" and "libld.so" are shared libraries. However, "libld.so" (or ld.so) is a dynamic linker / loader and is a special shared library in that it provides dlopen() / dlsym() / dlclose() for loading / unloading other shared libraries.

[0022] The Dynamic Link (DL) Interceptor module manages the container lifecycle, including container creation / destruction and delivery of data and function requests from the host to the container. It also manages the session lifecycle. Sessions are used to interact with the container when dl functions arrive. The Stack Processing module handles conversions between the stack and Protocol Buffers. Protocol Buffers is a language- and platform-independent, extensible mechanism for serializing structured data. Once a user defines the data structure, they can easily write and read the structured data to and from various data streams using specially generated source code and various languages. The DL Interceptor module and the Mapping Stub module use this function to convert and deliver data to and from each other. The Mapping Stub module uses libdl.so within the container created by the DL Interceptor module to load the target shared library into memory address space and record the session ID and handler mapping. When a dl function arrives, the data is routed to the target library. When a dlclose request arrives, the DL Interceptor module destroys the container and invalidates the session ID. Therefore, in embodiments of the present invention, by containerizing the shared library, the shared library can be unloaded without causing a segmentation fault. Segmentation may occur inside the container, but according to embodiments of the present invention, the entire container is destroyed when unloaded. Therefore, using embodiments of the present invention, end users outside the container do not see the "segmentation fault" problem.

[0023] Turning now to a more detailed description of aspects of the present invention, FIG. 1 shows a system 100 in an embodiment of the present invention. Before describing the system 100, some open-source concepts related to aspects of the present invention will be described. The programs "libld.so" and "ld-linux.so" find and load shared objects (shared libraries) required by a program, prepare for the execution of the program, and then execute the program. Therefore, "libld.so" is a dynamic linker / loader. It provides dlopen() / dlsym() / dlclose() for loading / unloading other shared libraries. Also, a protocol buffer is an extensible mechanism independent of language and platform for serializing structured data. Once a user defines the structuring of data, it is possible to easily write and read structured data between various data streams using various languages with the use of specially generated source code.

[0024] Referring again to Figure 1, System 100 includes an external entity 110 that communicates with the containerization platform 150 via a stack processing module 134 configured and arranged as shown. Entity 110 includes a set of software instructions (or computer code) 112 and a dynamic link (DL) interceptor module 114. The software instructions 112 are configured to use the dlclose() instruction. More specifically, the software instructions 112 are a program / application that loads a shared library. The program "libtarget_go.so" is an example of the name of the shared library; it could be any shared library. The program instructions dlopen() / dlsym() / dlclose() in computer code 112 are three functions provided by libld.so for loading the shared library. Computer code 112 demonstrates the process of loading / unloading the shared library libtarget_go.so using mocked dlopen() / dlsym() / dlclose() provided by a mocked dynamic linker / loader (i.e., libld.so).

[0025] Without the benefit of an aspect of the present invention, computer code 112 would interact with or call "libld.so". However, "libld.so" cannot clean up the entire environment when unloading the shared library. Sometimes, "libld.so" will produce an error during unloading, such as a "segmentation fault" error, affecting computer code 112. According to an aspect of the present invention, the DL interceptor module 114 introduces a new mocked libld.so116 so that computer code 112 can interact with (or call) a mocked libld.so116 instead of the real "libld.so". The DL interceptor module 114 is configured to manage the container lifecycle and also deliver data and function requests from computer code 112 to the containerized platform 150. The DL interceptor module 114 also manages the session lifecycle. It unloads the shared library by destroying the container that has the shared library inside. Therefore, unexpected errors inside the container do not affect the application / program on the host. The mocked libld.so116 is a mocked "libld.so". The mocked libld.so116 receives a request from computer code 112, which is then processed and delivered to the real "libld.so". When an end user calls a dl function (i.e., dlopen / dlsym / dlclose), they are actually calling a mocked dl function within the mocked libdl.so116.

[0026] The DL interceptor module 114 also includes a session lifecycle management module 118 and a container processing module 120, configured and arranged as shown in the figure. The session lifecycle management module 118 creates a session structure where one program / application corresponds to a unique session structure. The session structure includes a "session ID," which is the "target shared library name." When a customized container is started, the dynamic linker / loader (libld.so) within the container will load the "target shared library name." In the container processing module 120, DL stands for "dynamic link," and "dynamic link library" is synonymous with "shared library." Therefore, the "DL name" is the dynamic link library name, which is the shared library name. In this way, the container processing module 120 provides functions for managing the container. For example, this module 120 provides the Init() function and the Destroy() function. Init(session ID, DL name) creates the container and passes the DL name (shared library name) to the container so that the dynamic linker / loader (libld.so) knows which shared libraries need to be loaded into the container. The Destroy() method destroys the created container.

[0027] The stacking processing module 132 includes the parsing and transition module 134, and module 132 is communicatively coupled to the call stack 136 and the protocol (proto) buffer 138. Generally, a call stack is a stack data structure that stores information about the active subroutines of a computer program. Maintaining the call stack is crucial for most software to function properly, but the details are usually hidden and automated in high-level programming languages. Many computer instruction sets provide special instructions for manipulating the stack. A call stack is used for several related purposes, but the main reason for having one is to track the point at which each active subroutine should return control when it finishes execution. An active subroutine is a subroutine that has been called but has not yet finished executing, after which control should be returned to the caller's point. The invocation of such subroutines can be nested to any level (recursively as a special case), hence the stack structure.

[0028] The analysis and transition module 134 of module 132 is responsible for performing the main tasks of the stack processing module 132. Parameters in "stack" format computer code are difficult to transfer, while parameters in protocol buffer format are easy to transfer. Therefore, the analysis and transition module 134 provides two parameter manipulation methods, Pack() and UnPack(), for performing the conversion. The stack processing module 132 reads parameters from the call stack 136 of the executing computer code and converts those parameters to protocol buffer format (protocol buffer 138). It can also convert parameters from protocol buffer format and then write the parameters back to the call stack 136 of the computer code. As mentioned above, through the analysis and transition module 134, the stack processing module 132 provides two parameter manipulation methods, namely Pack() and UnPack(). The Pack() method reads parameters from the call stack 136 of the executing computer code and converts those parameters to proton buffer format (protocol buffer 138). The UnPack() method converts the parameters from protocol buffer format and then writes the parameters to the computer code's call stack 136.

[0029] The containerization platform 150 includes a mapping stub module 152, a set of libld.so commands / functions, and a set of libtarget_go.so commands / functions. Generally, the containerization platform 150 can be an open-source containerization platform configured and deployed for building, deploying, and managing containerized applications. Open-source containerization platforms enable developers to package applications into containers—standardized executable components that combine the application's source code with the operating system (OS) libraries and dependencies necessary to run that code in any environment. Containers simplify the delivery of distributed applications and are gaining popularity as enterprises move towards cloud-native development and hybrid multi-cloud environments. Essentially, an open-source containerization platform is a toolkit that allows developers to build, deploy, run, update, and stop containers using simple commands, automating the process through a single API. Containers are enabled by the process isolation and virtualization capabilities built into the Linux kernel. These features—such as control groups (Cgroups) for allocating resources between processes and namespaces for restricting access and visibility of processing to other resources and areas of the system—enable multiple application components to share resources from a single host operating system instance, much like how a hypervisor allows multiple virtual machines (VMs) to share the CPU, memory, and other resources of a single hardware server. As a result, container technology offers all the features and benefits of VMs, including application isolation, cost-effective scalability, and disposability.

[0030] Containerization platforms use what's called an "image," which contains the source code for an executable application and all the tools, libraries, and dependencies necessary for the application code to run as a container. When an image is run, it becomes one (or more) instances of a container. While it's possible to build an image from scratch, most developers obtain images from common repositories. Multiple images can be created from a single base image, and these images share a common stack. Images are composed of layers, each corresponding to a version of the image. Every time a developer makes changes to an image, a new top layer is created, replacing the previous top layer with the current version of the image. The previous layers are saved for rollback or reuse in other projects. Each time a container is created from an image, another new layer called the container layer is created. Changes made to the container, such as adding or deleting files, are stored only in the container layer and only exist while the container is running. This iterative process of creating images allows multiple live container instances to run from a single base image, leveraging a common stack and improving overall efficiency. A container is a live running instance of an image. While an image is a read-only file, a container is live, temporary, and executable content. Users interact with containers, and administrators can use Docker commands to adjust the container's configuration and state.

[0031] More specifically, referring to the containerized platform 150, platform 150 is a container that includes the mapping stub module 152, the dynamic linker / loader (i.e., libdl.so), and other shared libraries such as libtarget_go.so. When dlclose() is called by computer code on system 100, dlclose() utilizes the DL interceptor module 114 to destroy the entire container. Thus, everything inside the container is destroyed. Failures occurring inside the container (e.g., segmentation faults) do not affect the language environment of system 100.

[0032] The mapping stub module 152 loads the real libld.so into the memory address space of the containerization platform 150. Then libld.so loads libtarget_go.so into the memory address space of the containerization platform 150. It also records a map between session IDs and handlers. When a dl function is received, it routes the data and dlsym() request to the target library. The "apply libld.so function" module receives protocol buffer data from the host. The mapping stub module 152 maintains a map of session IDs and handlers so that it knows which target to route to when a dlsym() request is received.

[0033] "libtarget.go.so" is a shared library containing the serials of functions such as "func1()", "func2()", and "func3()". Figure 1 shows how a "func1" request is handled by system 100. When computer code 112 wants to call "func1()" in "libtarget_go.so", it uses a mocked dlopen() in the DL interceptor module 114 to create a containerized platform 150. It uses a mocked dlsym(p, "func1") to send a request to the containerized platform 150. It uses a mocked dlclose() to destroy the containerized platform 150.

[0034] The operation of system 100 is shown in Figures 2, 3, and 4, and will be explained by referring to the various operational steps shown in Figures 2, 3, and 4. Figures 2 and 3 provide additional details to some of the components of system 100 shown in Figure 1, so these additional details will be introduced before explaining the methodology shown in Figures 2, 3, and 4. As shown in Figure 2, the mocked libld.so116 contains "mocked dlsym", "mocked dlclose", and "mocked dlopen". The existing "libld.so" contains "dlsym()", "dlclose()", and "dlopen()". By using the methodology depicted in Figures 2-4, when computer code 112 calls "dlsym()", "dlclose()", and "dlopen()", it actually calls the "mocked dlsym", "mocked dlclose", and "mocked dlopen" of the mocked libld.so116. The mocked libld.so116 routes function requests to the real libld.so within the containerized platform 150.

[0035] As shown in Figure 2, the session lifecycle management 118 contains internal elements such as "session," "ID," "DL name," "container options," and "parameter options." When computer code calls the dlopen function, it is actually calling a mocked dlopen in the libdl.so shared library. The mocked dlopen interacts with the session lifecycle management module 118. The session lifecycle management module 118 creates a session structure. Each piece of computer code 112 creates a unique session structure, which includes a unique session ID. The "session ID" is the session identity. The "DL name" is the dynamic link library name, which is the shared library name. The "container options" include the behavior for the Init(), Destroy(), and Invoke() functions. Init() initializes the container. Destroy() destroys the container. Invoke() calls the actual functions (functions 1, 2, and 3) of libtarget_go.so within the container. The "parameter options" refer to the Pack() and UnPack() methods. The Pack() method reads parameters from the call stack 136 of the executing computer code 112 and converts those parameters into "protocol buffer" format. The Unpack() method converts the parameters back from "protocol buffer" format and then writes the parameters back into the call stack 136 of the computer code 112.

[0036] As shown in Figure 2, the container processing module 120 contains "Container Operation," "Init," "Destroy," and "Invoke shared library." The container processing module 120 provides these operations to initialize the containerization platform 150, destroy the containerization platform 150, and deliver dlsym() requests to the containerization platform 150.

[0037] As shown in Figure 2, the box labeled "Analysis and Transition 134" contains "Parameter Behavior," "Pack()," and "UnPack()." "Parameter Options" refers to the Pack() and UnPack() methods, which are intended to pack the data for transformation and unpack it once it arrives.

[0038] As shown in Figure 3, the containerized platform 150 contains "libtarget_golang.so". "libtarget_go.so" is an example of a shared library name; it can be any name. Embodiments of the present invention focus on completely unloading the shared library "libtarget_go.so" without polluting the original language environment in any way.

[0039] Referring to the methodology shown in Figures 2-4, in Figure 2, for dlopen, in S1, when the end user calls the dlopen function, a "mocked" dlopen in the libdl.so shared library is actually called. In S2, the mocked dlopen interacts with the session lifecycle management module 118. The session lifecycle management module 118 creates a session structure that includes a new UUID as the session ID, a new DL name, the target shared library to load, the registration container behavior provided by the container processing module 120, and the registration parameter behavior provided by the stack processing module 132. In S3, the mocked dlopen uses the init() method to create a new container.

[0040] Regarding dlclose, in S4, when an end user calls the dlclose function, a mocked dlclose in the libdl.so shared library is actually called. In S5, the mocked dlclose invalidates the session ID in the session structure. In S6, the destroy() method is used to destroy the container and release the session structure.

[0041] Regarding dlsym, in S7, when an end user calls the dlsym function, a mocked dlsym in the libdl.so shared library is actually called. In S8, the mocked dlsym interacts with the session lifecycle management module 118. In S9, the session lifecycle management module 118 uses the pack() method registered by the stack processing module 132 in S2 to convert parameters from the stack 136 to the protocol buffer 138. In S10, the mocked dlsym uses the invoke() method registered by the container processing module 120 in S2 to make the call to the protocol buffer 138 from the previous step. In S11, after obtaining the result and parameters, the mocked dlsym uses the unpack() method to convert from the protocol buffer 138 to the stack 136.

[0042] Figures 3 and 4 show the additional operations S1 to S8. Note that the names S1 to S8 in Figures 3 and 4 are used for convenience, and that S1 to S8 shown in Figures 3 and 4 are different from S1 to S8 shown in Figure 2. As shown in Figure 3, in S1, the init() method creates a container and uses the host image as the base image. It maps system directories, in particular library directories, to the container on the host and initializes the mapping stub module 152. The mapping stub module 152 loads libld.so into the address space. In S2, protocol buffer data including the session ID, target library name, and function name is passed to the container. libld.so uses Dlopen() to load the target library into the address space. Dlopen() returns a handler, which is used by dlsym() and dlclose(). In S4, the session ID is mapped to the handler generated in the previous step. In S5, the `destroy()` method is used to destroy containers created in S1.

[0043] As shown in Figure 4, in S6, the invoke() method passes protocol buffer data containing the session ID, function name, and function parameters to the mapping stub module 152. In S7, the mapping stub module 152 obtains a handler using the session ID. In S8, the mapping stub module 152 invokes the target function by using libld.so along with the handler, function name, and function parameters. In S9, libld.so invokes the actual function.

[0044] Therefore, embodiments of the present invention can be seen to provide technical advantages and effects. Embodiments of the present invention can clean up all resources of a shared library when unloading the shared library. This change is transparent to the end user, and the code change must be made by the end user. Embodiments of the present invention have no limitations on shared libraries or programming languages. A mocked library (mocked libld.so) container is outside the container. libld.so is inside the container, and mocked libld.so delivers requests to libld.so inside the container. libld.so is a loader library, and mocked libld.so is a mocked loader library.

[0045] Accordingly, embodiments of the present invention provide a novel computer implementation method configured to unload a shared library and safely clean up the language environment using a DL interceptor, stack processing, and a containerized target shared library. The DL interceptor module manages the session and container lifecycle of the shared library, creating a container when a dlopen request arrives and destroying the container when a dlclose request arrives. When a dlsym arrives, data and function requests are transferred from the host to the container. A session associated with a handler is created and destroyed. The stack processing module performs translation between the stack and protocol buffers. The DL interceptor module and the mapping stub module utilize this function to translate and distribute data to each other. The mapping stub module uses libdl.so to load the target shared library into memory address space and records the session ID and the map between handlers. When a DL function arrives, it routes the data and dlsym requests to the target library.

[0046] Figure 5 shows an example of a computer system 500 that can be used to implement any of the computer-based components of various embodiments of the present invention described herein. The computer system 500 includes an exemplary computing device ("computer") 502 configured to perform various aspects of content-based semantic monitoring operations as described herein in accordance with aspects of the present invention. In addition to the computer 502, the exemplary computer system 500 includes a network 514 connecting the computer 502 to additional systems (not shown), which may include one or more wide area networks (WANs) or local area networks (LANs), or both, such as the Internet, an intranet, or a wireless communication network or a combination thereof. The computer 502 and the additional systems communicate via the network 514, for example, to communicate data between them.

[0047] An exemplary computer 502 includes a processor core 504, main memory ("memory") 510, and input / output components 512, which are communicated via a bus 503. The processor core 504 includes a cache memory ("cache") 506 and a control unit 508, which include branch prediction structures and associated lookup, hit, detection, and update logic, which are described in more detail below. The cache 506 may include multiple cache levels (not shown) that are on-chip or off-chip from the processor 504. The memory 510 may include various data stored therein, such as instructions, software, routines, etc., which can be transferred to or from the cache 506 by the control unit 508 for execution by the processor 504, for example. The input / output components 512 may include one or more components (not shown) that facilitate local, remote, or both local and remote input / output operations to or from the computer 502, such as a display, keyboard, modem, or network adapter.

[0048] While this disclosure includes a detailed description of cloud computing, it should be understood that implementations of the teachings described herein are not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in combination with any other type of computing environment that is currently known or may be developed in the future.

[0049] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and deployed with minimal administrative effort or interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0050] The characteristics are as follows:

[0051] On-demand self-service: Cloud consumers can unilaterally prepare computing power, such as server time and network storage, automatically as needed, without requiring human interaction with service providers.

[0052] Broad network access: Computing power is available over the network and accessible through standard mechanisms. This facilitates utilization by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, PDAs).

[0053] Resource pooling: A provider's computing resources are pooled and delivered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated as needed. Generally, consumers have a sense of location independence because they do not manage or know the exact location of the resources provided. However, consumers may be able to identify the location at a higher level of abstraction (e.g., country, state, data center).

[0054] Rapid Elasticity: Computing power can be prepared quickly and flexibly, allowing it to scale out automatically and immediately, and to be quickly released and scale in immediately. To consumers, the computing power available for preparation often appears unlimited and can be purchased in any quantity at any time.

[0055] Measured Services: Cloud systems leverage metric capabilities at a certain level of abstraction, appropriate for the type of service (e.g., storage, processing, bandwidth, active user accounts), to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0056] The service model is as follows:

[0057] Software as a Service (SaaS): The functionality offered to consumers is the ability to use the provider's applications running on a cloud infrastructure. These applications can be accessed from various client devices via thin client interfaces such as web browsers (e.g., webmail). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for configuring a limited number of user-specific applications.

[0058] Platform as a Service (PaaS): The functionality offered to consumers is the ability to deploy applications they have created or acquired to cloud infrastructure using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, and storage, but they can control the deployed applications and, in some cases, the configuration of their hosting environment.

[0059] Infrastructure as a Service (IaaS): The functionality provided to consumers is the provision of processors, storage, networking, and other basic computing resources that enable consumers to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they can control the operating system, storage, and deployed applications, and in some cases, partially control certain network components (e.g., host firewalls).

[0060] The deployment model is as follows:

[0061] Private Cloud: This cloud infrastructure is operated exclusively for a specific organization. This cloud infrastructure can be managed by that organization or a third party and can reside on-premises or off-premises.

[0062] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by the organization or a third party and can reside on-premises or off-premises.

[0063] Public Cloud: This cloud infrastructure is provided to a large number of people or large industry groups and is owned by organizations that sell cloud services.

[0064] Hybrid Cloud: This cloud infrastructure combines two or more cloud models (private, community, or public). While maintaining the unique entities of each model, they are bound together by standards or individual technologies to achieve data and application portability (e.g., cloud bursting for load balancing across clouds).

[0065] Cloud computing environments are service-oriented environments that emphasize statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure, which includes a network of interconnected nodes.

[0066] Here, Figure 6 shows an exemplary cloud computing environment 50. As shown in the figure, the cloud computing environment 50 includes one or more cloud computing nodes 10. Local computer devices used by cloud consumers (e.g., PDAs or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or a combination thereof) can communicate with these nodes. The nodes 10 can communicate with each other. The nodes 10 can be grouped physically or virtually (not shown) in one or more networks, such as the private, community, public, or hybrid clouds or a combination thereof. This allows the cloud computing environment 50 to provide infrastructure, platforms, or software as a service, or a combination thereof, without requiring cloud consumers to maintain resources on their local computer devices. Note that the types of computer devices 54A-N shown in Figure 6 are merely examples, and it should be understood that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network addressable connection (e.g., using a web browser) or both.

[0067] Here, Figure 7 shows the set of functional abstraction layers provided by the cloud computing environment 50 (Figure 6). It should be understood that the components, layers, and functions shown in Figure 7 are merely illustrative, and the embodiments of the present invention are not limited to these. As illustrated, the following layers and corresponding functions are provided.

[0068] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include a mainframe 61, a reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage 65, and a network and network components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0069] The virtualization layer 70 provides an abstraction layer. From this layer, for example, the following virtual entities can be provided: virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems 74, and virtual clients 75.

[0070] As an example, the management layer 80 can provide the following functions: Resource preparation 81 enables the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 enables cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. As an example, these resources may include licenses for application software. Security enables not only protection of data and other resources, but also identification and verification of cloud consumers and tasks. The user portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 enables the allocation and management of cloud computing resources to ensure that requested service levels are met. Service Level Agreement (SLA) planning and execution 85 enables the pre-arrangement and procurement of cloud computing resources that are expected to be needed in the future in accordance with the SLA.

[0071] Workload layer 90 provides examples of the capabilities available in a cloud computing environment. Examples of workloads and capabilities available from this layer include mapping and navigation 91, software development and lifecycle management 92, delivery of virtual classroom education 93, data analytics processing 94, transaction processing 95, and automated avoidance of segmentation errors 96 by utilizing containers that clean up runtime resources when unloading shared libraries.

[0072] The present invention may be a system, method, or computer program product or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium storing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0073] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. Examples of computer-readable storage media may be electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or appropriate combinations thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory stick, floppy disk, punch cards, or grooved raised structures, and mechanically encoded devices on which instructions are recorded, and appropriate combinations thereof. Computer-readable storage devices as used herein should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0074] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer device / processor. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, LAN, WAN, or wireless network, or a combination thereof). The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers or edge servers, or a combination thereof. A network adapter card or network interface within each computer device / processor receives computer-readable program instructions from the network and transfers them for storage in a computer-readable storage medium in the respective computer device / processor.

[0075] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions can be executed as a standalone software package, either entirely on the user's computer or partially on the user's computer. Alternatively, they can be executed partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including LANs and WANs, or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), and programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of computer-readable program instructions in order to customize the electronic circuits for the purpose of performing aspects of the present invention.

[0076] Embodiments of the present invention are described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. Each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, are executable by computer-readable program instructions.

[0077] The above computer-readable program instructions may be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable data processing device for the purpose of producing a machine. This creates a means for these instructions, executed via the processor of such computer or other programmable data processing device, to perform functions / operations identified in one or more blocks in a flowchart or block diagram, or both. The above computer-readable program instructions may further be stored in a computer-readable storage medium that can be instructed to function in a particular manner to a computer, a programmable data processing device, or other device, or a combination thereof. This constitutes a product in which the computer-readable storage medium containing the instructions includes instructions for performing functions / operations identified in one or more blocks in a flowchart or block diagram, or both.

[0078] Alternatively, a computer execution process may be generated by loading computer-readable program instructions into a computer, another programmable device, or other device, and having a series of operational steps executed on that computer, other programmable device, or other device. This ensures that the instructions executed on the computer, other programmable device, or other device perform functions / operations identified in one or more blocks in a flowchart, block diagram, or both.

[0079] The flowcharts and block diagrams in the drawings of this disclosure illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for performing a particular logical function. In some other implementations, the functions shown within a block may be executed in an order different from the order shown in each figure. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or in some cases in reverse order, depending on the functions involved. Each block in a block diagram or flowchart, or both, and combinations of multiple blocks in a block diagram or flowchart, or both, are executable by a dedicated hardware-based system that performs a particular function or operation, or executes a combination of dedicated hardware and computer instructions.

[0080] The terms used herein are intended solely to describe and not to limit specific embodiments. Where used herein, the singular forms “a,” “an,” and “the” are intended to include the plural form unless the context explicitly indicates otherwise. Where used herein, the terms “comprises” or “comprising” or both specify the presence of a described feature, integer, step, operation, element, or component or combination thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups or combinations thereof.

[0081] Furthermore, the term “exemplary” is used herein to mean “to serve as an example, illustration, or representation.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as being preferable or advantageous to other embodiments or designs. The terms “at least one” and “one or more” are understood to include one or more, i.e., any integer such as 1, 2, 3, 4, etc. The term “more” is understood to include two or more, i.e., any integer such as 2, 3, 4, 5, etc. The term “connection” may include both indirect and direct “connections.”

[0082] The terms “approximately,” “substantially,” and their equivalents are intended to include the degree of error associated with measuring a particular quantity based on the equipment available at the time of filing. For example, “approximately,” “substantially,” and their equivalents may include a range of ±8%, 5%, or 2% of a particular value.

[0083] Although the present invention has been described in detail in relation to only a limited number of embodiments, it should be readily understood that the present invention is not limited to such disclosed embodiments. Rather, the present invention can be modified to incorporate any number of variations, alterations, substitutions or equivalent arrangements that are in line with the spirit and scope of the invention, although these have not been described herein. Furthermore, although various embodiments of the present invention have been described, it will be understood that aspects of the present invention may include only a portion of the embodiments described. Accordingly, the present invention should not be considered limited by the foregoing description, but only by the appended claims.

Claims

1. Using the processor to access the loader library, Using the aforementioned processor, a mock library containing a mock version of the loader library is generated, Using the aforementioned processor, the loader library is containerized, A computer implementation method comprising unloading the loader library using the aforementioned processor.

2. The computer implementation method according to claim 1, further comprising transmitting an unload signal to the loader library.

3. The computer implementation method according to claim 1, wherein the processor includes a dynamic link (dl) interceptor module.

4. The computer implementation method according to claim 3, wherein the processor further includes a stack processing module that is communicatively coupled to the dl interceptor module.

5. The computer implementation method according to claim 4, wherein the processor further includes a mapping stub module that is communicably coupled to the stack processing module.

6. The aforementioned mapping stub module is part of the containerization platform, The computer implementation method according to claim 5, wherein the mock library is stored in the dl interceptor module.

7. The computer implementation method according to claim 1, wherein the dlcclose instruction is used to instruct the processor to unload the loader library.

8. A computer system including memory communicatively coupled to a processor, wherein the processor is Accessing the loader library, This involves generating a mock library that includes a mock version of the aforementioned loader library, Containerizing the aforementioned loader library, A computer system configured to perform processor operations including unloading the aforementioned loader library.

9. The computer system according to claim 8, wherein the processor operation further includes sending an unload signal to the loader library.

10. The computer system according to claim 8, wherein the processor includes a dynamic link (dl) interceptor module.

11. The computer system according to claim 10, wherein the processor further includes a stack processing module that is communicably coupled to the dl interceptor module.

12. The computer system according to claim 11, wherein the processor further includes a mapping stub module that is communicably coupled to the stack processing module.

13. The aforementioned mapping stub module is part of the containerization platform, The computer system according to claim 12, wherein the mock library is stored in the dl interceptor module.

14. The computer system according to claim 8, wherein the processor operation includes using a dlcclose instruction to instruct the processor to unload the loader library.

15. A computer program for unloading a library, wherein, when the computer program is executed on a processor, the processor, Accessing the loader library, This involves generating a mock library that includes a mock version of the aforementioned loader library, Containerizing the aforementioned loader library, A computer program that performs the action of unloading the aforementioned loader library.

16. The computer program according to claim 15, further causing the processor to transmit an unload signal to the loader library.

17. The computer program according to claim 15, wherein the processor includes a dynamic link (dl) interceptor module.

18. The computer program according to claim 17, further comprising a stack processing module communicatively coupled to the dl interceptor module.

19. The processor further includes a mapping stub module that is communicably coupled to the stack processing module, The computer program according to claim 18, wherein the mock library is stored in the dl interceptor module.

20. The computer program according to claim 15, wherein the dlclose instruction is used to instruct the processor to unload the loader library.

Images