Memory resource detection method, device, readable medium and electronic device

Abstract

The present disclosure relates to a method, device, readable medium and electronic device for detecting memory resources. The method is applied to a first client, and includes: obtaining a thread local variable array related to an application to be tested, the thread local variable array including the allocation status of each thread local variable, the allocation status including an allocated state and an unallocated state; determining the number of thread local variables in an allocated state according to the allocation status of each thread local variable; and detecting the memory resources of the application to be tested according to the number of thread local variables in an allocated state. In this way, the memory resources of the application are dynamically detected by using the thread local variable array, thereby improving the efficiency of memory resource detection.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular, to a method, device, readable medium and electronic device for detecting memory resources. Background Art

[0002] With the increasing demand for computer applications, the development and operation of applications are becoming increasingly complex, and multi-threading technology is widely used. At the same time, applications use a large number of C / C++ languages ​​to write codes. When using C / C++ languages ​​to write multi-threaded programs or highly complex programs, if a variable is global, then multiple threads in the process access the same variable, and the modification of a certain thread will affect all other threads. Therefore, a variable needs to be accessible in each thread and its value in each thread does not affect each other and is independent of each other. Based on this, it is proposed to use Thread Local Storage (TLS) technology to store global variables to meet the requirements that a variable can be accessed in each thread and its value in each thread does not affect each other and is independent of each other.

[0003] The thread local variable resources in the application process are limited. For example, in the Android 6 and Android 7 operating systems, a process can create a maximum of 140 thread local variables, and in the Android 8 to Android 13 operating systems, a process can create a maximum of 130 thread local variables, that is, thread local variables cannot be created indefinitely. In large-scale software projects, many engineers will develop an application at the same time. During the program writing process, a large number of thread local variables will be defined and used, which may cause memory resource abnormalities. Summary of the invention

[0004] This summary is provided to introduce concepts in a brief form that will be described in detail in the detailed description below. This summary is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] In a first aspect, the present disclosure provides a method for detecting a memory resource, which is applied to a first client, and the method includes:

[0006] Acquire a thread local variable array related to the application to be tested, wherein the thread local variable array includes an allocation state of each thread local variable, wherein the allocation state includes an allocated state and an unallocated state;

[0007] Determining the number of thread local variables in an allocated state according to the allocation state of each of the thread local variables;

[0008] The memory resources of the application to be tested are detected according to the number of the thread local variables in the allocated state.

[0009] In a second aspect, the present disclosure provides a method for detecting memory resources, which is applied to a server, and the method includes:

[0010] After the first client detects the memory resources of the application to be tested according to the number of thread local variables in an allocated state, receiving the dynamic link library identifier and the address of the callback function for creating each thread local variable sent by the first client;

[0011] For each dynamic link library identifier, determining whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if the target callback function exists, determining the dynamic link library identifier as the target dynamic link library identifier, wherein the target function causing the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier;

[0012] Prompt information is sent to a second client corresponding to the target dynamic link library identifier to prompt that the target function causing the memory resource exception is located in the target dynamic link library.

[0013] In a third aspect, the present disclosure provides a memory resource detection device, applied to a first client, the device comprising:

[0014] An acquisition module, used for acquiring a thread local variable array related to the application to be tested, wherein the thread local variable array includes an allocation state of each thread local variable, wherein the allocation state includes an allocated state and an unallocated state;

[0015] A first determining module, configured to determine the number of thread local variables in an allocated state according to the allocation state of each of the thread local variables;

[0016] The detection module is used to detect the memory resources of the application to be tested according to the number of the thread local variables in the allocated state.

[0017] In a fourth aspect, the present disclosure provides a memory resource detection device, which is applied to a server, and the device includes:

[0018] A first receiving module is used to receive a dynamic link library identifier and an address of a callback function for creating each thread local variable sent by the first client after the first client detects the memory resources of the application to be tested according to the number of thread local variables in an allocated state;

[0019] A second determination module is used to determine, for each dynamic link library identifier, whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if the target callback function exists, determine the dynamic link library identifier as the target dynamic link library identifier, wherein the target function that causes the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier;

[0020] The third sending module is used to send prompt information to the second client corresponding to the target dynamic link library identifier to prompt that the target function that causes the memory resource exception is located in the target dynamic link library.

[0021] In a fifth aspect, the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in the first aspect or the second aspect.

[0022] In a sixth aspect, the present disclosure provides an electronic device, including:

[0023] a storage device having a computer program stored thereon;

[0024] A processing device is used to execute the computer program in the storage device to implement the steps of the method described in the first aspect or the second aspect.

[0025] Through the above technical solution, according to the allocation status of each thread local variable in the thread local variable array, the number of thread local variables in the allocated state is determined, and the memory resources of the application to be tested are detected according to the number of thread local variables in the allocated state. In this way, the memory resources of the application to be tested are dynamically detected by using the thread local variable array, thereby improving the efficiency of memory resource detection.

[0026] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale. In the drawings:

[0028] Figure 1 is a flowchart of a method for detecting memory resources according to some embodiments of the present disclosure;

[0029] Figure 2 is a flowchart of another memory resource detection method according to some embodiments of the present disclosure;

[0030] Figure 3 is a flowchart of a method for detecting memory resources according to some embodiments of the present disclosure;

[0031] Figure 4 is an interactive diagram of a method for detecting memory resources according to some embodiments of the present disclosure;

[0032] Figure 5 is a block diagram of a memory resource detection device according to some embodiments of the present disclosure;

[0033] Figure 6 is a block diagram of another memory resource detection device according to some embodiments of the present disclosure;

[0034] Figure 7 It is a schematic diagram of the structure of an electronic device according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0035] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0036] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0037] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0038] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0039] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0040] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0041] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0042] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0043] As an optional but non-limiting implementation, in response to receiving an active request from the user, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0044] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet the relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0045] At the same time, it is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0046] As the development and operation of applications become increasingly complex, the number of thread local variables handled by developers during program implementation has also increased significantly, which may lead to memory resource anomalies. Memory resource anomalies are hidden and cumulative, and are more difficult to detect than other memory access errors. It is difficult for engineers to detect memory resource anomalies in a timely manner. If there is a memory resource anomaly during the operation of an application, it will cause insufficient system memory, and in severe cases, it will cause the system to crash, affecting the user experience.

[0047] In view of this, the present disclosure provides a memory resource detection method, device, readable medium and electronic device, which dynamically detect the memory resources of an application program and improve the efficiency of memory resource detection.

[0048] Figure 1is a flowchart of a method for detecting memory resources according to an exemplary embodiment, which is applied to a first client. Figure 1 , the memory resource detection method may include the following steps.

[0049] Step S11, obtaining a thread local variable array related to the application to be tested, where the thread local variable array includes an allocation status of each thread local variable.

[0050] Step S12, determining the number of thread local variables in an allocated state according to the allocation state of each thread local variable.

[0051] Step S13: Detecting the memory resources of the application to be tested according to the number of thread local variables in the allocated state.

[0052] In the present disclosure, the first client may be a client used by a user, on which one or more applications are deployed. The terminal may be, for example: a smart phone (Mobile Phone), a Pocket Personal Computer (PPC), a personal digital assistant (PDA), a laptop computer, a tablet computer, a wearable device, or a vehicle-mounted device, etc. The present disclosure does not make any specific limitations on this.

[0053] By way of example, the first client may detect the memory resources of the application to be tested in real time, wherein the application to be tested is any application deployed on the first client. By way of another example, when the first client detects that an application is abnormal, such as freezing or flashing back, the first client determines the application as the application to be tested and detects the memory resources of the application to be tested. By way of another example, the first client may also detect the memory resources of the application to be tested upon receiving a user-initiated memory resource detection instruction for the application to be tested. For example, when an application is abnormal, such as freezing or flashing back, the user initiates a memory resource detection instruction for the application, and then the first client determines the application as the application to be tested and detects the memory resources of the application to be tested.

[0054] The allocation state of each thread local variable includes an allocated state and an unallocated state, wherein the allocated state means that the thread local variable is allocated to a thread for use, and for example, the working state of the thread local variable in the allocated thread can be further divided into a using state and a released state. The unallocated state means that the thread local variable is not allocated to any thread for use.

[0055] It should be understood that thread local variables in an unallocated state usually do not occupy variable resources. Therefore, in the present disclosure, the number of thread local variables in an allocated state is determined, and the memory resources of the application to be tested are detected based on the number of thread local variables in an allocated state.

[0056] By adopting the above technical solution, the number of thread local variables in the allocated state is determined according to the allocation state of each thread local variable in the thread local variable array, and the memory resources of the application under test are detected according to the number of thread local variables in the allocated state. In this way, the thread local variable array is used to achieve the purpose of detecting the memory resources of the application under test, and the efficiency of memory resource detection is improved.

[0057] In order to enable those skilled in the art to better understand the memory resource detection method provided by the present disclosure, the memory resource detection method is described below with a complete embodiment.

[0058] First, it should be understood that the operating system of the first client may be an Android operating system, a UNIX operating system, a Linux operating system, etc. For ease of description, the following description is made by taking the operating system of the first client as an Android operating system as an example.

[0059] Secondly, it should be understood that in the Android operating system, thread local variables are created by the pthread_key_create() function, deleted by the pthread_key_delete() function, and recorded and managed by the static pthread_key_internal_t ​​key_map[] global static array defined in the libc.so dynamic link library. Among them, the static pthread_key_internal_t ​​key_map[] global static array can be referred to as the key_map array, that is, the thread local variable array in step 11.

[0060] Among them, in C++ language, the key_map array definition code is as follows:

[0061]

[0062] The above code represents the following meanings: the key_map array type is structpthread_key_internal_t ​​(thread local variable internal data), which stores the allocation status seq of each thread local variable and the address of the callback function key_destructor corresponding to the thread local variable. When the pthread_key_create() function is called, the allocation status seq and the callback function key_destructor are assigned values.

[0063] In C++ language, the code of the pthread_key_create() function is as follows:

[0064]

[0065]

[0066] For example, the specific implementation method of step 11 to obtain the thread local variable array related to the application to be tested can be: first, in response to the memory resource detection instruction initiated by the user for the application to be tested, a function that opens a specified dynamic link library file in a specified mode, for example, the dlopen function, is called to obtain the address of the libc.so dynamic link library handle handle. Then, the address key_map_addr of the symbol "_ZL7key_map" of the key_map array is obtained by combining the address of the handle handle through the dlsym function. Among them, the symbol "_ZL7key_map" is the name of the key_map array customized by the Android operating system. In other operating systems, the symbol of the key_map array can also be other symbols, which is not limited by the present disclosure. Finally, the key_map array is obtained according to the address key_map_addr, that is, the thread local variable array related to the application to be tested is obtained.

[0067] In one embodiment, the specific implementation method of step 12 determining the number of thread local variables in the allocated state according to the allocation state of each thread local variable is as follows: traversing the allocation state of each thread local variable included in the thread local variable array, if the currently traversed allocation state is the allocated state, then adding 1 to the number of thread local variables in the allocated state until the allocation states of all thread local variables are traversed.

[0068] It should be understood that the address key_map_addr is the address of the key_map array, that is, the address of the first thread local variable in the key_map array. In this embodiment, the purpose of traversing the allocation status of each thread local variable included in the thread local variable array can be achieved by accumulating the address offset of the address key_map_addr. During the traversal process, if the allocation status of the currently traversed thread local variable is the allocated state, the number of thread local variables in the allocated state is increased by 1 until the allocation status of all thread local variables is traversed.

[0069] For example, a flag bit can be used to represent the allocation state seq of a thread local variable. For example, if the allocation state seq is 0, it represents that the allocation state of the corresponding thread local variable is unallocated. If the allocation state seq is a non-zero value, it represents that the allocation state of the corresponding thread local variable is allocated. Wherein, when the allocation state seq is a non-zero value, the allocation state seq can also be set to an odd number to represent that the corresponding thread local variable is in use in the allocated thread, and the allocation state seq can be set to an even number to represent that the corresponding thread local variable is in a released state in the allocated thread.

[0070] In addition, in the present disclosure, the value of the subscript count of the thread local variable array can be used to represent the number of thread local variables in the allocated state. The initial value of the subscript count is 0. When the currently traversed allocation state seq is a non-zero value, the value of the subscript count is increased by 1. When the allocation states of all thread local variables are traversed, the value of the subscript count of the thread local variable array is determined as the number of thread local variables in the allocated state.

[0071] Optionally, the specific implementation method of step S13 detecting the memory resources of the application to be tested according to the number of thread local variables in the allocated state is: if the number of thread local variables in the allocated state is greater than or equal to a preset threshold, it is determined that there is a memory resource anomaly in the application to be tested; wherein the preset threshold is less than the number of thread local variables that can be created by the process of the application to be tested.

[0072] In the present disclosure, memory resource anomaly is used to indicate that there is a risk that the memory required by the application under test exceeds the memory limit allocated by the system.

[0073] For example, in the first version of the operating system, the process of the application to be tested can create a maximum of 140 thread local variables, and in the second version of the operating system, the process of the application to be tested can create a maximum of 130 thread local variables. For example, if the application to be tested is an application in the first version of the operating system, the number of thread local variables that can be created by the process of the application to be tested is 140, and accordingly, the preset threshold is a value less than 140, such as the preset threshold is 130. For another example, if the application to be tested is an application in the second version of the operating system, the number of thread local variables that can be created by the process of the application to be tested is 130, and accordingly, the preset threshold is a value less than 130, such as the preset threshold is 125.

[0074] After determining that the application to be tested has a memory resource anomaly, in one embodiment, a prompt message can be output to prompt the engineer that the application to be tested has a memory resource anomaly, so that the engineer can analyze and locate the target function that causes the memory resource anomaly. However, in large-scale software projects, many engineers will develop an application at the same time. Since it is uncertain which engineer is responsible for the part that causes the memory resource anomaly, it is necessary to send a prompt message to each engineer so that each engineer can analyze the part he is responsible for to determine whether the function in the part he is responsible for is the cause of the memory resource anomaly. In this way, the workload of locating the target function that causes the memory resource anomaly is large, and the target function that causes the memory resource anomaly cannot be determined in time. Therefore, in order to locate the target function that causes the memory resource anomaly in time, so that engineers can fix the problem of memory resource anomaly in time, in the present disclosure, after determining that the application to be tested has a memory resource anomaly, the first client can send relevant information to the server to achieve the purpose of locating the target function that causes the memory resource anomaly in time.

[0075] For example, Figure 2 is a flow chart of another method for detecting memory resources according to an exemplary embodiment. Figure 2 ,The memory resource detection method includes the following steps:

[0076] Step 21, obtaining a thread local variable array related to the application to be tested, where the thread local variable array includes the allocation status of each thread local variable.

[0077] Step 22, determining the number of thread local variables in an allocated state according to the allocation state of each thread local variable.

[0078] Step 23: If the number of thread local variables in the allocated state is greater than or equal to a preset threshold, it is determined that a memory resource anomaly exists in the application to be tested.

[0079] Step 24, obtaining the address of the callback function corresponding to each thread local variable, and determining to create a dynamic link library for each thread local variable according to the address of the callback function.

[0080] As shown in the key_map array definition code above, the thread local variable array includes not only the allocation status of each thread local variable, but also the address of the callback function corresponding to each thread local variable, that is, the address of the callback function key_destructor.

[0081] It should be understood that determining the dynamic link library for creating thread local variables according to the address of the callback function key_destructor is a relatively mature technology, which will not be elaborated in this disclosure.

[0082] Step 25, sending to the server a dynamic link library identifier and the address of the callback function for creating each thread local variable.

[0083] After receiving the dynamic link library identifier and the address of the callback function, the server determines the target dynamic link library where the target function that causes the memory resource exception is located based on the dynamic link library identifier and the address of the callback function. Then, the server or the corresponding engineer can directly determine the target function that causes the memory resource exception in the target dynamic link library. In this way, the target function that causes the memory resource exception can be determined in time, which makes it easier for engineers to repair the memory resource exception in time, thereby improving the efficiency of repairing the memory resource exception.

[0084] The specific implementation of the server determining the target dynamic link library and the specific implementation of the server or the corresponding engineer determining the target function causing the memory resource exception in the target dynamic link library will be described below.

[0085] In addition, after determining the number of thread local variables in the allocated state, the first client can also send the number of thread local variables in the allocated state to the server, so that the server can determine the change trend of the thread local variables in the allocated state according to the number of thread local variables in the allocated state sent by each first client, and send the change trend to the second client so that the second client can display the change trend. In this way, engineers can determine whether the application under test has memory resource anomalies according to the change trend.

[0086] Figure 3 The flowchart of a method for detecting memory resources according to an exemplary embodiment is shown, and the method is applied to a server. Figure 3 , the memory resource detection method may include the following steps:

[0087] Step 31 , after the first client detects the memory resources of the application to be tested according to the number of thread local variables in the allocated state, receives the dynamic link library identifier and the address of the callback function for creating each thread local variable sent by the first client.

[0088] Step 32, for each dynamic link library identifier, determine whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if there is a target callback function, determine the dynamic link library identifier as the target dynamic link library identifier.

[0089] The target function causing the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier.

[0090] For example, after receiving the dynamic link library identifier and the address of the callback function for creating each thread local variable sent by the first client, the server performs aggregation processing and obtains an aggregation result. For example, the aggregation result is as follows:

[0091] Dynamic Link Library 1

[0092] key_destructor address a1(10)

[0093] key_destructor address b1

[0094] key_destructor address c1

[0095] Dynamic Link Library 2

[0096] key_destructor address a2

[0097] key_destructor address b2

[0098] Dynamic Link Library 3

[0099] key_destructor address a3

[0100] Among them, in the aggregation result, key_destructor address a1, key_destructor address b1 and key_destructor address c1 belong to dynamic link library 1, and the number of key_destructor address a1 in dynamic link library 1 is 10, that is, there is a target callback function with the same address in dynamic link library 1, and accordingly, dynamic link library 1 is the target dynamic link library.

[0101] The key_destructor address a2 and the key_destructor address b2 belong to the dynamic link library 2, and the dynamic link library 2 is not the target dynamic link library. Similarly, the dynamic link library 3 is not the target dynamic link library either.

[0102] Step 33: Send prompt information to the second client corresponding to the target dynamic link library identifier to prompt that the target function causing the memory resource exception is located in the target dynamic link library.

[0103] The second client is a client tested by an engineer. It should be understood that the dynamic link library corresponds to the second client, that is, the corresponding relationship between the engineer of the second client and the dynamic link library is known.

[0104] In this way, the target dynamic link library is automatically determined by the server, so that the target function that causes the memory resource exception can be determined in time later, and engineers can then repair the memory resource exception in time, thereby improving the efficiency of repairing the memory resource exception.

[0105] In one embodiment, the prompt information includes a target dynamic link library identifier. After determining the target dynamic link library, the server sends the target dynamic link library identifier to the corresponding second client. After the second client receives the target dynamic link library identifier, the corresponding engineer searches the target dynamic link library for the target function that causes the memory resource exception.

[0106] In another embodiment, after determining the target dynamic link library, the server determines the target function that causes the memory resource exception from the target dynamic link library, and sends the symbol of the target function to the second client. For example, the prompt information also includes request information for obtaining the symbol table of the target dynamic link library. Accordingly, the above method may also include:

[0107] Receiving a symbol table of a target dynamic link library sent by a second client, wherein the function symbols included in the symbol table correspond one-to-one to the addresses of callback functions in the target dynamic link library;

[0108] A function symbol corresponding to the address of the target callback function is determined as the symbol of the target function that causes the memory resource exception, and the symbol of the target function is sent to the second client.

[0109] In this way, after receiving the symbol of the target function, the second client can directly locate the address of the target function, and then enter the address to modify the target function to fix the memory resource abnormality problem. In addition, in order to further facilitate engineers to locate the address of the target function, the target dynamic link library identifier can also be sent to the second client.

[0110] In this way, after determining the target dynamic link library, the server determines the target function that causes the memory resource exception from the target dynamic link library, and sends the symbol of the target function to the second client, thereby further improving the efficiency of determining the target function that causes the memory resource exception, and thereby improving the efficiency of repairing the memory resource exception.

[0111] Figure 4 is an interactive diagram showing a method for detecting memory resources according to an exemplary embodiment. Figure 4 , the memory resource detection method may include the following steps:

[0112] The first client obtains a thread local variable array related to the application to be tested.

[0113] The first client determines the number of thread local variables in an allocated state according to the allocation state of each thread local variable.

[0114] If the number of thread local variables in the allocated state is greater than or equal to a preset threshold, the first client determines that a memory resource anomaly exists in the application to be tested.

[0115] The first client obtains the address of the callback function corresponding to each thread local variable, and determines to create a dynamic link library for each thread local variable according to the address of the callback function.

[0116] The first client sends a dynamic link library identifier and an address of a callback function for creating local variables of each thread to the server.

[0117] The server determines, for each dynamic link library identifier, whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if there is a target callback function, determines the dynamic link library identifier as the target dynamic link library identifier.

[0118] The server sends a request message for obtaining a symbol table of the target dynamic link library to a second client corresponding to the target dynamic link library identifier.

[0119] The second client sends the symbol table of the target dynamic link library to the server.

[0120] The server determines the function symbol corresponding to the address of the target callback function as the symbol of the target function that causes the memory resource exception.

[0121] The server sends the symbol of the target function and the target dynamic link library identifier to the second client.

[0122] In addition, there may be multiple first clients, and the above method may further include:

[0123] receiving the number of the thread local variables in the allocated state sent by each first client;

[0124] Determine a change trend of the thread local variables in the allocated state according to the number of the thread local variables in the allocated state;

[0125] The change trend is sent to the second client so that the second client displays the change trend.

[0126] For example, the server can draw a change trend graph of thread local variables according to the number of thread local variables in the allocated state sent by each first client, wherein in the change trend graph, the horizontal axis is time and the vertical axis is the number of thread local variables in the allocated state. The change trend graph represents the number of thread local variables in the allocated state of multiple first clients at each time. For example, assuming that the indicator for drawing the change trend graph is p50, the change trend graph represents the number of thread local variables in the allocated state of 50% of the clients among the multiple first clients at time t. In this way, engineers can determine from the change trend that a memory resource anomaly occurs in a certain time period.

[0127] Based on the same concept, the present disclosure also provides a memory resource detection device. Figure 5 is a block diagram of a memory resource detection device according to an exemplary embodiment, which is applied to a first client. Figure 5 , the memory resource detection device 500 includes:

[0128] A first acquisition module 501 is used to acquire a thread local variable array related to the application to be tested, wherein the thread local variable array includes an allocation state of each thread local variable, wherein the allocation state includes an allocated state and an unallocated state;

[0129] A first determining module 502, configured to determine the number of thread local variables in an allocated state according to the allocation state of each of the thread local variables;

[0130] The detection module 503 is used to detect the memory resources of the application to be tested according to the number of the thread local variables in the allocated state.

[0131] Optionally, the detection module 503 is used to:

[0132] If the number of the thread local variables in the allocated state is greater than or equal to a preset threshold, it is determined that a memory resource anomaly exists in the application to be tested;

[0133] The preset threshold is smaller than the number of thread local variables that can be created by the process of the application to be tested.

[0134] Optionally, the first determining module 502 is used to:

[0135] The allocation status of each thread local variable included in the thread local variable array is traversed, and if the currently traversed allocation status is an allocated state, the number of thread local variables in the allocated state is increased by 1 until the allocation status of all thread local variables is traversed.

[0136] Optionally, when it is determined that the application to be tested has a memory resource anomaly, the memory resource detection device 500 further includes:

[0137] A second acquisition module is used to acquire the address of the callback function corresponding to each of the thread local variables, and determine to create a dynamic link library for each of the thread local variables according to the address of the callback function;

[0138] The first sending module is used to send a dynamic link library identifier and the address of the callback function for creating each thread local variable to the server, so that the server determines a target dynamic link library identifier based on the dynamic link library identifier and the address of the callback function, wherein the target function that causes the memory resource exception is located in a target dynamic link library corresponding to the target dynamic link library identifier.

[0139] Optionally, the memory resource detection device 500 further includes:

[0140] The second sending module is used to send the number of thread local variables in the allocated state to the server.

[0141] Based on the same concept, the present disclosure also provides a memory resource detection device. Figure 6 The block diagram of a memory resource detection device according to an exemplary embodiment is shown, and is applied to a server. Figure 6 , the memory resource detection device 600 includes:

[0142] The first receiving module 601 is used to receive the dynamic link library identifier and the address of the callback function for creating each thread local variable sent by the first client after the first client detects the memory resources of the application to be tested according to the number of thread local variables in the allocated state;

[0143] The second determination module 602 is used to determine, for each dynamic link library identifier, whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if the target callback function exists, determine the dynamic link library identifier as the target dynamic link library identifier, wherein the target function that causes the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier;

[0144] The third sending module 603 is used to send prompt information to the second client corresponding to the target dynamic link library identifier to prompt that the target function causing the memory resource exception is located in the target dynamic link library.

[0145] Optionally, the prompt information further includes request information for obtaining a symbol table of the target dynamic link library; the memory resource detection device 600 further includes:

[0146] A second receiving module, used for receiving a symbol table of the target dynamic link library sent by the second client, wherein the function symbols included in the symbol table correspond one-to-one to the addresses of the callback functions in the target dynamic link library;

[0147] The third determination module is used to determine the function symbol corresponding to the address of the target callback function as the symbol of the target function that causes the memory resource exception, and send the symbol of the target function to the second client.

[0148] Optionally, there are multiple first clients; the memory resource detection device 600 further includes:

[0149] A third receiving module, configured to receive the number of the thread local variables in the allocated state sent by each of the first clients;

[0150] a fourth determining module, configured to determine a change trend of the thread local variables in the allocated state according to the number of the thread local variables in the allocated state;

[0151] The fourth sending module is used to send the change trend to the second client so that the second client displays the change trend.

[0152] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0153] Based on the same concept, the present disclosure also provides a non-temporary computer-readable medium on which a computer program is stored. When the program is executed by a processing device, the program implements the steps of any of the above-mentioned methods for detecting memory resources applied to the first client or to the server.

[0154] Based on the same concept, the present disclosure also provides an electronic device, comprising: a storage device on which a computer program is stored; a processing device for executing the computer program in the storage device to implement any step of the above-mentioned memory resource detection method applied to a first client or to a server.

[0155] Reference below Figure 7, which shows a schematic diagram of the structure of an electronic device 700 suitable for implementing the embodiment of the present disclosure. The terminal device in the embodiment of the present disclosure may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0156] like Figure 7 As shown, the electronic device 700 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 are also stored. The processing device 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0157] Typically, the following devices may be connected to the I / O interface 705: an input device 706 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 707 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 708 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 709. The communication device 709 may allow the electronic device 700 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 7 The electronic device 700 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0158] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 709, or installed from a storage device 708, or installed from a ROM 702. When the computer program is executed by the processing device 701, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0159] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0160] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0161] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0162] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: obtains a thread local variable array related to the application to be tested, the thread local variable array includes an allocation status of each thread local variable, and the allocation status includes an allocated state and an unallocated state; determines the number of thread local variables in an allocated state according to the allocation status of each thread local variable; and detects the memory resources of the application to be tested according to the number of thread local variables in an allocated state.

[0163] Alternatively, the computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: after the first client detects the memory resources of the application to be tested according to the number of thread local variables in an allocated state, receives the dynamic link library identifier and the address of the callback function sent by the first client for creating each of the thread local variables; for each dynamic link library identifier, determines whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if the target callback function exists, determines the dynamic link library identifier as the target dynamic link library identifier, wherein the target function that causes the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier; and sends a prompt message to the second client corresponding to the target dynamic link library identifier to prompt that the target function that causes the memory resource exception is located in the target dynamic link library.

[0164] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0165] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0166] The modules involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a module does not, in some cases, limit the module itself.

[0167] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0168] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0169] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0170] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0171] Although the subject matter has been described in language specific to structural features and / or method logic actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims. Regarding the device in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Claims

1. A method for detecting memory resources, characterized in that: Applied to a first client, the method includes: Acquire a thread local variable array related to the application to be tested, wherein the thread local variable array includes an allocation state of each thread local variable, wherein the allocation state includes an allocated state and an unallocated state; Determining the number of thread local variables in an allocated state according to the allocation state of each of the thread local variables; The memory resources of the application to be tested are detected according to the number of the thread local variables in the allocated state.

2. The method according to claim 1, characterized in that The detecting the memory resources of the application to be tested according to the number of the thread local variables in the allocated state includes: If the number of the thread local variables in the allocated state is greater than or equal to a preset threshold, it is determined that a memory resource anomaly exists in the application to be tested; The preset threshold is smaller than the number of thread local variables that can be created by the process of the application to be tested.

3. The method according to claim 1, characterized in that The step of determining the number of thread local variables in an allocated state according to the allocation state information of each thread local variable comprises: The allocation status of each thread local variable included in the thread local variable array is traversed, and if the currently traversed allocation status is an allocated state, the number of thread local variables in the allocated state is increased by 1 until the allocation status of all thread local variables is traversed.

4. The method according to any one of claims 1 to 3, characterized in that: When it is determined that the application to be tested has a memory resource anomaly, the method further includes: Obtaining the address of the callback function corresponding to each of the thread local variables, and determining to create a dynamic link library for each of the thread local variables according to the address of the callback function; The dynamic link library identifier and the address of the callback function for creating each of the thread local variables are sent to the server, so that the server determines the target dynamic link library identifier according to the dynamic link library identifier and the address of the callback function, wherein the target function that causes the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier.

5. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The number of thread local variables in the allocated state is sent to the server.

6. A method for detecting memory resources, characterized in that: Applied to a server, the method comprises: After the first client detects the memory resources of the application to be tested according to the number of thread local variables in an allocated state, receiving a dynamic link library identifier and an address of a callback function for creating each of the thread local variables sent by the first client; For each dynamic link library identifier, determining whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if the target callback function exists, determining the dynamic link library identifier as the target dynamic link library identifier, wherein the target function causing the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier; Prompt information is sent to a second client corresponding to the target dynamic link library identifier to prompt that the target function causing the memory resource exception is located in the target dynamic link library.

7. The method according to claim 6, characterized in that The prompt information also includes request information for obtaining a symbol table of the target dynamic link library; the method also includes: Receiving a symbol table of the target dynamic link library sent by the second client, wherein the function symbols included in the symbol table correspond one-to-one to the addresses of the callback functions in the target dynamic link library; A function symbol corresponding to the address of the target callback function is determined as the symbol of the target function that causes the memory resource exception, and the symbol of the target function is sent to the second client.

8. The method according to claim 6, characterized in that There are multiple first clients; and the method further includes: receiving the number of the thread local variables in the allocated state sent by each of the first clients; Determining a change trend of the thread local variables in the allocated state according to the number of the thread local variables in the allocated state; The change trend is sent to the second client so that the second client displays the change trend.

9. A memory resource detection device, characterized in that: Applied to a first client, the device comprises: A first acquisition module, configured to acquire a thread local variable array related to the application to be tested, wherein the thread local variable array includes an allocation state of each thread local variable, wherein the allocation state includes an allocated state and an unallocated state; A first determining module, configured to determine the number of thread local variables in an allocated state according to the allocation state of each of the thread local variables; The detection module is used to detect the memory resources of the application to be tested according to the number of the thread local variables in the allocated state.

10. A memory resource detection device, characterized in that: Applied to a server, the device comprises: A first receiving module is used for receiving a dynamic link library identifier and an address of a callback function for creating each thread local variable sent by the first client after the first client detects the memory resources of the application to be tested according to the number of thread local variables in an allocated state; A second determination module is used to determine, for each dynamic link library identifier, whether there is a target callback function with the same address in the dynamic link library corresponding to the dynamic link library identifier, and if the target callback function exists, determine the dynamic link library identifier as the target dynamic link library identifier, wherein the target function that causes the memory resource exception is located in the target dynamic link library corresponding to the target dynamic link library identifier; The third sending module is used to send prompt information to the second client corresponding to the target dynamic link library identifier to prompt that the target function that causes the memory resource exception is located in the target dynamic link library.

11. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processing device, the steps of the method described in any one of claims 1 to 8 are implemented.

12. An electronic device, characterized in that: include: a storage device having a computer program stored thereon; A processing device, configured to execute the computer program in the storage device to implement the steps of the method according to any one of claims 1 to 8.

Images