Search

EP-4740100-A1 - METHOD AND SYSTEM FOR MANAGING STORAGE IN A COMMUNICATION NETWORK

EP4740100A1EP 4740100 A1EP4740100 A1EP 4740100A1EP-4740100-A1

Abstract

The present disclosure relates to a system (125) and a method (500) for managing storage in a communication network (105). The system (125) includes a transceiver module (220) to receive an alert pertaining to a corrupt application from a User Equipment (110). The system further includes an identification module (225) to identify a corrupt stack of the corrupt application based on the received alert. The system further includes an extraction module (230) to selectively extract a memory image corresponding to the identified corrupt stack and a format convertor module (235) to convert the extracted memory image into acceptable formats. Thereby, the system (125) manages storage in the communication network (105) in an optimized manner to facilitate debugging the corrupt stack of the corrupt application. The method (500) includes various steps for managing the storage in the communication network (105).

Inventors

  • BHATNAGAR, AAYUSH
  • DARSHI, Raj Priya
  • Bisht, Birendra Singh
  • Singh, Harbinder Pal
  • Soren, Rohit
  • SINGH, PRIYANKA
  • Aggarwal, Pravesh
  • Sahu, Bidhu
  • Naskar, Suman
  • KUMAR, Satyajit

Assignees

  • Jio Platforms Limited

Dates

Publication Date
20260513
Application Date
20240627

Claims (16)

  1. 1. A method (500) for managing storage in a communication network (105), the method (500) comprises the steps of: receiving (505), by one or more processors (205), an alert from a User Equipment (UE) (110) pertaining to at least one corrupt application, the UE (110) adapted to host a plurality of applications, each application including a plurality of stacks; identifying (510), by the one or more processors (205), at least one corrupt stack pertaining to the at least one corrupt application based on the received alert from the UE (110); selectively extracting (515), by the one or more processors (205), a memory image corresponding to the identified at least one corrupt stack pertaining to the at least one corrupt application; and converting (520), by the one or more processors (205), the extracted memory image into one or more acceptable formats.
  2. 2. The method (500) as claimed in claim 1 , wherein the at least one corrupt stack is identified utilizing at least one of, stack back trace and Application Programming Interfaces (APIs).
  3. 3. The method (500) as claimed in claim 1, wherein the memory image corresponding to the identified at least one corrupt stack is stored as a crash dump file.
  4. 4. The method (500) as claimed in claim 3, wherein the one or more processors (205) are configured to utilize the crash dump file to initiate a debugging process by mapping the crash dump file to a file which is in the one or more acceptable formats, in order to rectify the at least one corrupt stack.
  5. 5. The method (500) as claimed in claim 1, wherein the alert corresponding to the at least one corrupt application, includes data pertaining to an address of a code section where the corruption has occurred pertaining to the at least one corrupt stack.
  6. 6. The method (500) as claimed in claim 1, wherein the method further comprises the step of: initiating in real time, by the one or more processors (205), a standby mode by providing one or more resources in order to restart the at least one corrupt application during a debugging process of the at least one corrupt stack.
  7. 7. The method (500) as claimed in claim 1 , wherein the method further comprises the step of : debugging, by the one or more processors (205), the at least one corrupt stack pertaining to the at least one corrupt application to manage storage.
  8. 8. A User Equipment (UE) (110), comprising: one or more primary processors (305) coupled with a memory (310), communicatively coupled to one or more processors (205), wherein said memory stores instructions which when executed by the one or more primary processors (305) causes the UE (110) to: host, a plurality of applications, each application including a plurality of stacks; and transmit, an alert pertaining to at least one corrupt application to the one or more processors, wherein one or more processors (205) are further configured to perform the method as claimed in claim 1.
  9. 9. A system (125) for managing storage in a communication network (105), the system comprising: a transceiver module (220) configured to receive, an alert from a User Equipment (UE) (110) pertaining to at least one corrupt application, the UE adapted to host a plurality of applications, each application including a plurality of stacks; an identification module (225) configured to identify, at least one corrupt stack pertaining to the at least one corrupt application based on the received alert from the UE (110); an extraction module (230) configured to selectively extract, a memory image corresponding to the identified at least one corrupt stack pertaining to the at least one corrupt application; and a format convertor module (235) configured to convert, the extracted memory image into one or more acceptable formats.
  10. 10. The system (125) as claimed in claim 9, wherein the at least one corrupt stack is identified utilizing at least one of, stack back trace and Application Programming Interfaces (APIs).
  11. 11. The system (125) as claimed in claim 9, wherein the memory image corresponding to the identified at least one corrupt stack is stored as a crash dump file.
  12. 12. The system (125) as claimed in claim 11, wherein the one or more processors (205) are configured to utilize the crash dump file to initiate a debugging process by mapping the crash dump file to a file which is in the one or more acceptable formats, in order to rectify the at least one corrupt stack.
  13. 13. The system (125) as claimed in claim 9, wherein the alert corresponding to the at least one corrupt application, includes data pertaining to an address of a code section where the corruption has occurred pertaining to the at least one corrupt stack.
  14. 14. The system (125) as claimed in claim 9, wherein the one or more processors (205) are further configured to: initiate in real time, a standby mode by providing one or more resources in order to restart the at least one corrupt application during a debugging process of the at least one corrupt stack.
  15. 15. The system (125) as claimed in claim 9, wherein the one or more processors (205) are further configured to: debugging, by the one or more processors (205), the at least one corrupt stack pertaining to the at least one corrupt application to manage storage.
  16. 16. A non-transitory computer-readable medium having stored thereon computer- readable instructions that, when executed by a processor (205), causes the processor (205) to: receive, an alert from a User Equipment (UE) (110) pertaining to at least one corrupt application, the UE (110) adapted to host a plurality of applications, each application including a plurality of stacks; identify, at least one corrupt stack pertaining to the at least one corrupt application based on the received alert from the UE (110); selectively extract, a memory image corresponding to the identified at least one corrupt stack pertaining to the at least one corrupt application; and convert, the extracted memory image into one or more acceptable formats to facilitate in debugging the at least one corrupt stack pertaining to the at least one corrupt application, thereby managing storage.

Description

METHOD AND SYSTEM FOR MANAGING STORAGE IN A COMMUNICATION NETWORK FIELD OF THE INVENTION [0001] The present invention generally relates to wireless communication systems, and more particularly relates to managing storage in a communication network during application fault handling. BACKGROUND OF THE INVENTION [0002] In existing applications, whenever any disruption in an ongoing network process occurs or relevant networking system crashes due to any abnormal data, coding bug, segmentation fault, or any interruption from hardware, then a significant amount of incoming data reception during the downtime is lost. To safeguard such losses and to prevent future crashes, a fault handling mechanism is employed. Such a mechanism is implemented to diagnose as to why the crash has happened. In order to successfully diagnose such anomaly, the core dump of the process is implemented. [0003] The core dump process can be depicted in a flow chart where a user/network operator can identify application programming interface (APIs) or segmentation fault in specific code lines. In other words, core dump is an image of the virtual memory map and core dump process includes analyzing the entirety of the virtual memory map. Therefore, the size of the core dump is the same as the total virtual memory taken by the process. Such core dump is used to diagnose the cause of corruption. [0004] However, one of the common issues in fault handling is that during occurrence of crashes in any application which could be due to bugs in coding, corrupt data from network, unhandled network events etc., a large amount of data is produced which needs analysis so as to identify the exact section of the application execution steps/methodology/codes. The size of this data is variable, depending upon the extent of crash occurred. The size of this data can be from a few megabytes (MB) to as big as multiple gigabytes (GB) depending on the application’s virtual memory usage. Considering large scale of activities performed by certain application, some application processes’ virtual memory goes as big as 20-50GBs for which core dumping take significant amount of time thereby downgrading overall system throughput. [0005] Then again, in contemporary systems, core dumping process takes too long (20-30seconds) which is a long time to wait until a stand-by process comes into play which may be an active process. This long duration to generate core dump also impacts the time required to restart the process which has crashed, as a new process cannot be restarted until critical system resources like IP/Port etc. used previously has not been released completely. Moreover, the analysis of such large volume of data results in significant storage consumption resulting overall performance degradation and may sometime lead to prolonged operational shut out or downtime. [0006] Therefore, there is a need for an advancement for a system and method that can overcome at least one of the above shortcomings, particularly to manage the storage during fault handling. BRIEF SUMMARY OF THE INVENTION [0007] One or more embodiments of the present disclosure provide a system and method for managing storage in a communication network. [0008] In one aspect of the present invention, a system for managing storage in a communication network is disclosed. The system includes a transceiver configured to receive an alert from a User Equipment (UE) pertaining to at least one corrupt application. The UE is adapted to host a plurality of applications and each of the plurality of applications includes a plurality of stacks. In one embodiment, the alert corresponding to the at least one corrupt application, includes data pertaining to an address of a code section where the corruption has occurred pertaining to the at least one corrupt stack. The system further includes an identification module and extraction module communicably coupled to the identification module. The identification module is configured to identify at least one corrupt stack pertaining to the at least one corrupt application based on the received alert from the UE. The extraction module is configured to selectively extract a memory image corresponding to the identified at least one corrupt stack pertaining to the at least one corrupt application. The system further includes a format convertor module configured to convert the extracted memory image into one or more acceptable formats [0009] The system is further configured to utilize at least one of stack back trace and Application Programming Interfaces (APIs) to identify the at least one corrupt stack. The system is further configured to store the memory image corresponding to the identified at least one corrupt stack is stored as a crash dump file. The system is further configured to utilize the crash dump file to initiate a debugging process. The system is further configured to initiate the debugging process, by mapping the crash dump file to a file which is in the one or