PRIORITY INFORMATION
[001] This patent application does not claim priority from any application.

TECHNICAL FIELD
[002] The present subject matter described herein, in general, relates to debugging a software code and more particularly to enabling dynamic logging of call flow functions to debug the software code.

BACKGROUND
[003] Typically, current systems and methodologies for performing bug fixing of a software code involves manual supervision for trouble shooting. In order to do so, a developer analyses each execution path log of the software code. It is to be noted that the software code comprises a plurality of lines of code, thus analyzing each line of code by a developer becomes not only cumbersome but also open for errors. Further, the current systems and methodologies requires setting up of debugging environment for reproducing the issue during execution of the software code. The developers using the current systems and methodologies fail to locate a root cause of the bug.
[004] Further, as the bugs are typically identified by analyzing the execution path logs, some of the existing software for logging the software code may be utilized to generated the execution path logs. However, logging may be enabled for entire software code which includes of all execution paths and thread, which may also run in distributed environment. Thus, analyzing the execution path logs becomes difficult to identify a required execution path affected by the bug.
SUMMARY
[005] Before the present systems and methods for debugging a software code, are described, it is to be understood that this application is not limited to the particular systems, and methodologies described, as there can be multiple possible embodiments which are not expressly illustrated in the present disclosure. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present application. This summary is provided to introduce concepts related to systems and methods for debugging a software code and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[006] In one implementation, a method for debugging a software code is disclosed. In order to debug the software code, initially, a flag indicating a defect during an execution of a software code comprising a set of functions may be received. Upon receiving the flag, the software code may be parsed to identify a plurality of break points in the software code. In one aspect, the plurality of break points differentiates between one or more call flow functions present in the set of functions. After parsing, a target execution path corresponding to the one or more call flow functions may be determined. Subsequently, logging of the target execution path may be enabled for generating a set of execution path logs associated to the one or more call flow functions. Further, a reference number may be assigned to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect. Furthermore, the software code may be debugged based on the defect in data flow, source of the defect, and location of the defect associated to each reference number. In one aspect, the aforementioned method for debugging the software code may be performed by a processor using programmed instructions stored in a memory.
[007] In another implementation, a system for debugging a software code is disclosed. The system may comprise a processor and a memory coupled to the processor. The processor may execute a set of instructions stored in the memory. Initially, the system may receive a flag indicating a defect during an execution of a software code comprising a set of functions. Further, the system may parse the software code to identify a plurality of break points in the software code. The plurality of break points differentiates between one or more call flow functions present in the set of functions. Subsequently, the system may determine a target execution path corresponding to the one or more call flow functions. Furthermore, the system may enable logging of the target execution path for generating a set of execution path logs associated to the one or more call flow functions. In the next step, the system may assign a reference number to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect. Subsequently, the system may debug the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number.
[008] In yet another implementation, non-transitory computer readable medium embodying a program executable in a computing device for debugging a software code is disclosed. The program may comprise a program code for receiving a flag indicating a defect during an execution of a software code comprising a set of functions. Further, the program may comprise a program code for parsing the software code to identify a plurality of break points in the software code. In one aspect, the plurality of break points differentiates between one or more call flow functions present in the set of functions. The program may comprise a program code for determining a target execution path corresponding to the one or more call flow functions. The program may comprise a program code for enabling logging of the target execution path for generating a set of execution path logs associated to the one or more call flow functions. The program may comprise a program code for assigning a reference number to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect. The program may comprise a program code for debugging the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number.

BRIEF DESCRIPTION OF THE DRAWINGS
[009] The foregoing detailed description of embodiments is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the disclosure, example constructions of the disclosure are shown in the present document; however, the disclosure is not limited to the specific methods and apparatus for debugging a software code as disclosed in the document and the drawings.
[0010] The detailed description is given with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.
[0011] Figure 1 illustrates a network implementation of a system for debugging a software code, in accordance with an embodiment of the present subject matter.
[0012] Figure 2 illustrates the system, in accordance with an embodiment of the present subject matter.
[0013] Figure 3 illustrates a method for debugging a software code, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0014] Some embodiments of this disclosure, illustrating all its features, will now be discussed in detail. The words "receiving," "parsing," "determining," "enabling," "assigning,” and "debugging," and other forms thereof, are intended to be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, the exemplary, systems and methods for debugging a software code are now described. The disclosed embodiments are merely exemplary of the disclosure, which may be embodied in various forms.
[0015] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure is not intended to be limited to the embodiments illustrated, but is to be accorded the widest scope consistent with the principles and features described herein.
[0016] The present invention discloses a system and method for debugging of a software code. Typically, the software code comprises plurality of lines of codes. In order to debug the software means to analyze each line of code from the plurality of lines of codes to identify any defect if present. The defect may be associated to a functionality of the software code. Thus, to identify and resolve the defect in the real time, the present invention may receive a flag during an execution of the software code. The flag indicates the defect in a set of functions. Subsequently, the software code may be parsed to identify a plurality of break points in the software code. The break points may be associated to each functional block present in the software code. It is to be noted that each functional block may comprise one or more call flow functions. Further, a target execution path corresponding to the one or more call flow functions may be determined. The target execution path indicates input and output of each call flow function associated to the defect.
[0017] Once the target execution path is determined, logging of the target execution path may be enabled. It is to be noted that logging of the target execution path may generate a set of execution path logs during each execution of the software code. The logging may be enabled only for the target execution path and not for the plurality of lines of codes. Subsequently, each execution path log form the set of execution path logs may be assigned a reference number. Each reference number may be stored in a system database for subsequent executions. Further to assigning the reference number, a developer may analyze the set of execution path logs to debug the software code. While aspects of described system and method for debugging a software code and may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system.
[0018] Referring now to Figure 1, a network implementation 100 of a system 102 for debugging a software code is disclosed. Initially, the system 102 may receive a flag indicating a defect during an execution of a software code comprising a set of functions. Further, the system 102 may parse the software code to identify a plurality of break points in the software code. The plurality of break points differentiates between one or more call flow functions present in the set of functions. Subsequently, the system 102 may determine a target execution path corresponding to the one or more call flow functions. Furthermore, the system 102 may enable logging of the target execution path for generating a set of execution path logs associated to the one or more call flow functions. In the next step, the system 102 may assign a reference number to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect. Subsequently, the system may 102 debug the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number.
[0019] Although the present disclosure is explained considering that the system 102 for debugging a software code is implemented on a server, it may be understood that the system 102 may be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, a cloud-based computing environment. It will be understood that the system 102 may be used by multiple users through one or more user devices 104-1, 104-2…104-N, collectively referred to as user 104 or stakeholders, hereinafter, or applications residing on the user devices 104 for debugging the software code. In one implementation, the system 102 may comprise the cloud-based computing environment in which a user may operate individual computing systems configured to execute remotely located applications. Examples of the user devices 104 may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, and a workstation. The user devices 104 are communicatively coupled to the system 102 through a network 106.
[0020] In one implementation, the network 106 may be a wireless network, a wired network or a combination thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 106 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further, the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[0021] Referring now to Figure 2, the system 102 for debugging a software code is illustrated in accordance with an embodiment of the present subject matter. In one embodiment, the system 102 may include at least one processor 202, an input/output (I/O) interface 204, and a memory 206. The at least one processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
[0022] The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 204 may allow the system 102 for debugging a software code to interact with the user directly or through the client devices 104. Further, the I/O interface 204 may enable the system 102 to communicate with other computing devices, such as web servers and external data servers (not shown). The I/O interface 204 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 204 may include one or more ports for connecting a number of devices to one another or to another server.
[0023] The memory 206 may include any computer-readable medium or computer program product known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 may include modules 208 and data 210.
[0024] The modules 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules 208 may include a receiving module 212, a parsing module 214, a determination module 216, an enabling module 218, an assigning module 220, a debugging module 222, and other modules 224. The other modules 224 may include programs or coded instructions that supplement applications and functions of the system 102 for debugging a software code. The modules 208 described herein may be implemented as software modules that may be executed in the cloud-based computing environment of the system 102.
[0025] The data 210, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules 208. The data 210 may also include a system database 226 and other data 228. The other data 228 may include data generated as a result of the execution of one or more modules in the other modules 224.
[0026] As there are various challenges observed in the existing art, the challenges necessitate the need to build the system 102 for debugging the software code. In order to debug the software code, at first, a user may use the client device 104 to access the system 102 via the I/O interface 204. The user may register them using the I/O interface 204 in order to use the system 102. In one aspect, the user may access the I/O interface 204 of the system 102. The system 102 may employ the receiving module 212, the identification module 214, the validation module 216, the extraction module 218, the tracking module 220, the detection module 222, the generation module 224, the creation module 226, and the verification module 228. The detail functioning of the modules is described below with the help of figures.
[0027] The present system 102 facilitates debugging of a software code. It is to be understood that the software code comprises a plurality of lines of code. Each line of code from the plurality of lines of code receives an input and perform some computation and provides an output. In most cases, the software code may comprise one or more call flow functions to perform certain functionality. It is to be noted that a developer may become aware about defects in the software code once the software code is executed. Thus, in order to resolve the defect, debugging of the software code is a paramount concern.
[0028] The receiving module 212 receives a flag indicating the defect during an execution of a software code comprising a set of functions. The flag may be displayed on a Graphical User Interface (GUI) of the system 102. In an embodiment, the flag may also be notified via an email notification, a text message, or others. The flag may indicate location of the defect in the software code. In an exemplary embodiment, the flag may indicate a line number and a type of function call associated to a call flow function from the one or more call flow functions. In one implementation, the flag may be stored in the system database 226.
[0029] The parsing module 214 parses the software code to identify a plurality of break points in the software code. The plurality of break points differentiates between one or more call flow functions present in the set of functions. The plurality of break points indicates caller details associated to each call flow function. It is to be noted that each call flow function comprises a set of code elements including, but not limited to, namespace, class, interface, function, variables, literals, keywords, lines, and comments.
[0030] The determination module 216 determines a target execution path corresponding to the one or more call flow functions. The target execution path may be determined by at least one of a Term frequency–Inverse document frequency (Tf Idf) value of filename, a file path, function names, comments, annotations, and a cosine similarity based distance measurements with respect to the defect. It is to be note that the determination module 216 may determine a set of code elements present in each target execution path. The set of code elements include, but not limited to, namespace, class, interface, function, variables, literals, keywords, lines, and comments. In one implementation, the determination module 216 may utilize various defect localization techniques available to determine the target execution path or set of code elements for investigation. One of the method is using a distance measurement (commonly used – cosine similarity) between a tokenized defect information vector with a code elements vector including, but not limited to, a file path, a namespace, a class, n interface, a function, variables used, literals, annotations, keywords, comments.
[0031] Further to determining the target execution path, the enabling module 218 enables logging of the target execution path. The enabling module 218 may generate a set of execution path logs associated to the one or more call flow functions. Once the logging is enabled, a developer may choose to disable the logging in real time. It is to be noted that once the logging is enabled, the enabling module 218 generates the set of execution path logs for every execution of the software code. The set of execution path logs may be stored in the system database 226. In one embodiment, each execution path log from the set of execution path log may correspond to log trace of each call flow function of the one or more call flow functions.
[0032] In order to elucidate further, consider a software code has 3 call flow functions A. B, and C. Considering the B is receiving input from the A and providing input to the C. Thus, in such case if the developer enables the logging for the B, the enabling module 218 may generate the set of execution path logs comprising execution path logs from the A, B and C. The developer may analyze each of the execution path log to resolve the bug. It is to be noted that call flow extraction is a pre-processing activity used to determine the set of execution path logs or call graph. The set of execution path logs may be used to fetch call flow information representing a calling relationship between sub-routines in any application. There are various means and methods provided by each technology stack to achieve the calling relationship. In one implementation, the enabling module 218 may enable logging by using tools including, but not limited to, a doxygen and any code coverage tools.
[0033] Further, the assigning module 220 assigns a reference number to each execution path log in order to track the defect in data flow, source of the defect, and location of the defect. The reference number may be stored in the system database 226. It is to be noted that multiple reference numbers may assigned to one execution path log depending upon the number of execution and the changes observed in each execution path logs after every execution of the software code. In other words, one execution path log may be assigned multiple reference number each time the software code is executed while the logging is enabled.
[0034] Furthermore, the debugging module 222 debugs the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number. In an embodiment, the developer may debug the software code and update the software code with one or more solutions to resolve the bug. It is to be noted that the one or more solutions may be written as a patch to be added in the software code in a debugging environment. Once the defect is resolved from the software code, the developer may disable the logging in real time of the execution. Thus, the system 102 facilitates real time enabling and disabling of the logging of the software code to resolve the defect.
[0035] Referring now to Figure 3, a method 300 for debugging a software code is shown, in accordance with an embodiment of the present subject matter. The method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 300 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0036] The order in which the method 300 for debugging a software code is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 300 or alternate methods. Additionally, individual blocks may be deleted from the method 300 without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300 can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 300 may be considered to be implemented as described in the system 102.
[0037] At block 302, a flag indicating a defect during an execution of a software code may be received. In one implementation, the flag from the user device may be received from a receiving module 212 and stored at a system database 226.
[0038] At block 304, the software code may be parsed to identify a plurality of break points in the software code. In one aspect, the plurality of break points differentiates between one or more call flow functions present in the set of functions. In one implementation, the software code may be parsed by a parsing module 214 and the plurality of break points may be stored at the system database 226.
[0039] At block 306, a target execution path corresponding to the one or more call flow functions may be determined. In one implementation, a target execution path corresponding to the one or more call flow functions may be determined by a determination module 216 and stored at the system database 226.
[0040] At block 308, logging of the target execution path may be enabled for generating a set of execution path logs associated to the one or more call flow functions. In one implementation, logging of the target execution path may be enabled by an enabling module 218 and stored at the system database 226.
[0041] At block 310, a reference number may be assigned to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect. In one implementation, the reference number may be assigned by an assigning module 220 and stored at the system database 226.
[0042] At block 312, the software code may be debugged based on the defect in data flow, source of the defect, and location of the defect associated to each reference number. In one implementation, the software code may be debugged based on the defect in data flow, source of the defect, and location of the defect associated to each reference number by a debugging module 222 and stored at the system database 226.
[0043] Exemplary embodiments discussed above may provide certain advantages. Though not required to practice aspects of the disclosure, these advantages may include those provided by the following features.
[0044] Some embodiments enable a system and a method to debug the software code in real time.
[0045] Some embodiments enable a system and a method to dynamically enable and disable logging of the software code.
[0046] Some embodiments enable a system and a method to analyze limited logs only instead of entire application logs.
[0047] Some embodiments enable a system and a method to avoid complete logging of application.
[0048] Some embodiments enable a system and a method to speed-up the bug fixing and troubleshooting in the software code.
[0049] Although implementations for methods and systems for debugging a software code have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for debugging a software code.

Claims:1. A method for debugging a software code, the method comprising:
receiving, by a processor, a flag indicating a defect during an execution of a software code comprising a set of functions;
parsing, by the processor, the software code to identify a plurality of break points in the software code, wherein the plurality of break points differentiates between one or more call flow functions present in the set of functions;
determining, by the processor, a target execution path corresponding to the one or more call flow functions;
enabling, by the processor, logging of the target execution path for generating a set of execution path logs associated to the one or more call flow functions;
assigning, by the processor, a reference number to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect; and
debugging, by the processor, the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number.

2. The method of claim 1 further comprises identifying a set of code elements present in each target execution path, wherein the set of code elements comprises namespace, class, interface, function, variables, literals, keywords, lines, and comments.
.
3. The method of claim 1, wherein the plurality of break points indicates caller details associated to each call flow function.

4. The method of claim 1, wherein the target execution path is determined by at least one of a Term frequency–Inverse document frequency (Tf Idf) value of filename, a file path, function names, comments, annotations, and a cosine similarity based distance measurements.

5. A system for debugging a software code, the system comprises:
a processor;
a memory coupled to the processor, wherein the processor executes a set of instructions stored in the memory to:
receive a flag indicating a defect during an execution of a software code comprising a set of functions;
parse the software code to identify a plurality of break points in the software code, wherein the plurality of break points differentiates between one or more call flow functions present in the set of functions;
determine a target execution path corresponding to the one or more call flow functions;
enable logging of the target execution path for generating a set of execution path logs associated to the one or more call flow functions;
assign a reference number to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect; and
debug the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number.

6. The system of claim 5 further comprises identifying a set of code elements present in each target execution path, wherein the set of code elements comprises namespace, class, interface, function, variables, literals, keywords, lines, and comments.
.
7. The system of claim 5, wherein the plurality of break points indicates caller details associated to each call flow function.

8. The system of claim 5, wherein the target execution path is determined by at least one of a Term frequency–Inverse document frequency (Tf Idf) value of filename, a file path, function names, comments, annotations, and a cosine similarity based distance measurements.

9. A non-transitory computer readable medium embodying a program executable in a computing device for debugging a software code, the program comprising:
a program code for receiving a flag indicating a defect during an execution of a software code comprising a set of functions;
a program code for parsing the software code to identify a plurality of break points in the software code, wherein the plurality of break points differentiates between one or more call flow functions present in the set of functions;
a program code for determining a target execution path corresponding to the one or more call flow functions;
a program code for enabling logging of the target execution path for generating a set of execution path logs associated to the one or more call flow functions;
a program code for assigning a reference number to each execution path log from the set of execution path logs in order to track the defect in data flow, source of the defect, and location of the defect; and
a program code for debugging the software code based on the defect in data flow, source of the defect, and location of the defect associated to each reference number.

10. The program of claim 9 further comprises identifying a set of code elements present in each target execution path, wherein the set of code elements comprises namespace, class, interface, function, variables, literals, keywords, lines, and comments.