CN112162893A - 一种内存泄漏定位方法、装置及电子设备 - Google Patents

一种内存泄漏定位方法、装置及电子设备 Download PDF

Info

Publication number
CN112162893A
CN112162893A CN202011191563.5A CN202011191563A CN112162893A CN 112162893 A CN112162893 A CN 112162893A CN 202011191563 A CN202011191563 A CN 202011191563A CN 112162893 A CN112162893 A CN 112162893A
Authority
CN
China
Prior art keywords
memory
source code
code file
line
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011191563.5A
Other languages
English (en)
Inventor
马玮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Big Data Technologies Co Ltd
Original Assignee
New H3C Big Data Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by New H3C Big Data Technologies Co Ltd filed Critical New H3C Big Data Technologies Co Ltd
Priority to CN202011191563.5A priority Critical patent/CN112162893A/zh
Publication of CN112162893A publication Critical patent/CN112162893A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2273Test methods
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请提供了一种内存泄漏定位方法、装置及电子设备,所述方法包括:在检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。采用上述方法,可以快速定位出发生内存泄漏的源代码文件。

Description

一种内存泄漏定位方法、装置及电子设备
技术领域
本申请涉及存储技术领域,尤其涉及一种内存泄漏定位方法、装置及电子设备。
背景技术
内存泄漏(Memory Leak)是指程序中己动态分配的堆内存由于某种原因导致程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。而开源分布式存储软件(Ceph)中经常会有内存泄漏的问题。当内存一直泄漏直到内存耗尽时,会导致设备宕机、丢失数据,进而影响设备的高可用性和可维护性。
目前通常利用一些开源工具套件来检查内存泄漏,但这些工具使用前需要手动杀掉kill进程,然后利用该工具将进程拉起,以代替原有进程执行。采用这种方法会导致kill掉进程的这段时间内的业务中断,影响客户使用;此外,即使拉起进程后也不一定能定位到内存泄漏问题。
因此,如何在发生内存泄漏时有效的定位程序中发生的内存泄漏是值得考虑的技术问题之一。
发明内容
有鉴于此,本申请提供一种内存泄漏定位方法、装置及电子设备,用以有效定位程序中发生的内存泄漏。
具体地,本申请是通过如下技术方案实现的:
根据本申请的第一方面,提供一种内存泄漏定位方法,包括:
在检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;
根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。
可选地,每个源代码文件的内存使用状态信息还包括该源代码文件的文件标识、该源代码文件中用于申请内存的代码所属行的行号和用于申请内存的各行代码各自申请的内存大小,则
根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件,包括:
遍历各个源代码文件分别对应的内存使用状态信息,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
可选地,每个源代码文件的内存使用状态信息还包括用于申请内存的各行代码各自发起内存请求的内存请求次数;则
在根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件之前,还包括:
遍历各个源代码文件的内存请求次数,确定内存请求次数高于设定次数的源代码文件;
根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件,包括:
遍历确定出的内存请求次数高于设定次数的源代码文件,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
可选地,所述内存请求包括内存申请请求,则所述方法,还包括:
在接收到第一源代码文件中第一代码触发的内存申请请求后,为所述第一代码分配内存;
在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数。
可选地,所述内存请求包括内存释放请求,则所述方法,还包括:
在接收到第二源代码文件中第二代码触发的内存释放请求后,释放所述第二代码预先申请的内存;并获取所述第二源代码文件的文件标识和所述第二代码所属的行号;
根据所述第二源代码文件的文件标识和所述第二代码所属的行号,修改所述记录表中与所述第二源代码文件和所述第二代码所属行号相对应的内存大小和内存请求次数。
可选地,在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,包括:
利用ceph插件工具调用包装函数在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,所述包装函数中包括动态申请内存的函数。
根据本申请的第二方面,提供一种内存泄漏定位装置,包括:
检测模块,用于检测当前运行的程序是否发生内存泄漏;
获取模块,用于在所述检测模块检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;
定位模块,用于根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。
可选地,每个源代码文件的内存使用状态信息还包括该源代码文件的文件标识、该源代码文件中用于申请内存的代码所属行的行号和用于申请内存的各行代码各自申请的内存大小,则
所述定位模块,用于遍历各个源代码文件分别对应的内存使用状态信息,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
可选地,每个源代码文件的内存使用状态信息还包括用于申请内存的各行代码各自发起内存请求的内存请求次数;则所述装置,还包括:
确定模块,用于在所述定位模块根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件之前,遍历各个源代码文件的内存请求次数,确定内存请求次数高于设定次数的源代码文件;
所述定位模块,还用于遍历确定出的内存请求次数高于设定次数的源代码文件,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
可选地,所述内存请求包括内存申请请求,则所述装置,还包括:
内存分配,用于在接收到第一源代码文件中第一代码触发的内存申请请求后,为所述第一代码分配内存;
第一记录模块,用于在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数。
可选地,所述内存请求包括内存释放请求,则所述装置,还包括:
内存释放模块,用于在接收到第二源代码文件中第二代码触发的内存释放请求后,释放所述第二代码预先申请的内存;并获取所述第二源代码文件的文件标识和所述第二代码所属的行号;
第二记录模块,用于根据所述第二源代码文件的文件标识和所述第二代码所属的行号,修改所述记录表中与所述第二源代码文件和所述第二代码所属行号相对应的内存大小和内存请求次数。
可选地,所述第一记录模块,具体用于利用ceph插件工具调用包装函数在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,所述包装函数中包括动态申请内存的函数。
根据本申请的第三方面,提供一种电子设备,包括处理器和机器可读存储介质,机器可读存储介质存储有能够被处理器执行的计算机程序,处理器被计算机程序促使执行本申请实施例第一方面所提供的方法。
根据本申请的第四方面,提供一种机器可读存储介质,机器可读存储介质存储有计算机程序,在被处理器调用和执行时,计算机程序促使处理器执行本申请实施例第一方面所提供的方法。
本申请实施例的有益效果:
在检测出当前运行的程序发生内存泄漏时,可以从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件,由此可以快速定位出发生内存泄漏的源代码文件。
附图说明
图1是本申请实施例提供的一种内存泄漏定位方法的流程示意图;
图2是本申请实施例提供的一种内存泄漏定位装置的框图;
图3是本申请实施例提供的一种实施内存泄漏定位方法的电子设备的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相对应的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
下面对本申请提供的内存泄漏定位方法进行详细地说明。
参见图1,图1是本申请提供的一种内存泄漏定位方法的流程图,该方法可包括如下所示步骤:
S101、在检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息。
其中,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小。
本步骤中,每个程序会对应多个源代码文件,实际应用中,每个程序运行时占用的内存的预估内存大小大致是固定的,而当该程序发生内存泄漏时,该程序占用的实际内存大小就会与预估内存大小差别比较大,基于此原理,可以定时或实时监测每个程序占用的实际内存大小,然后与该程序的预估内存大小进行比对,当实际内存大小超过预估内存大小比较多时,则确认该程序发生内存泄漏。为了准确地确定该程序的哪个源代码文件发生内存泄漏,本申请提出会从记录表中获取该程序对应的各个源代码文件各自对应的内存使用状态信息。
需要说明的是,每个源代码文件的内存使用状态信息是在该源代码文件在申请内存时记录下来的,后续详细介绍之。
S102、根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。
本步骤中,由于记录表中记录了当前运行的程序的各个源代码文件所申请的内存的内存大小,参考下述举例1所示,其中size表示内存大小,基于举例1可以确认file2对应的内存大小的取值存在明显异常,则该内存大小对应的源代码文件file2即为发生内存泄漏的文件。通过采用上述方法,可以准确地定位到发生内存泄漏的源代码文件。
举例1:
{文件名:file1,size:8888},
{文件名:file2,size:10241024}
……
可选地,每个源代码文件的内存使用状态信息还包括该源代码文件的文件标识、该源代码文件中用于申请内存的代码所属行的行号和用于申请内存的各行代码各自申请的内存大小,则记录的内存使用状态信息可以参考如下举例2所示,则:
举例2:
{文件名:file1,行号:13,size:8888},
{文件名:file2,行号:66,size:10241024}
……
则在此基础上,可以按照下述过程实施步骤S102:遍历各个源代码文件分别对应的内存使用状态信息,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。具体来说,某个源代码文件可能因为未释放或者无法释放导致所申请的内存大小比较大,基于此原理,可以判断记录表中记录的每行代码对应的内存大小是否超过设定阈值,如果超过则确认该行代码发生内存泄漏,也即,确认该行代码对应的源代码文件发生内存泄漏,参考上述举例所示的源代码文件file1和file2分别对应的内存使用状态信息,则可以确认file2的内存大小size明显为异常值,则可以确认file2发生内存泄漏,此外,还可以确认file2中行号13对应的代码发生内存泄漏。通过采用该步骤,不仅可以准确地定位到发生内存泄漏的源代码文件,还可以定位到源代码文件中发生内存泄漏的代码。
可选地,每个源代码文件的内存使用状态信息还包括用于申请内存的各行代码各自发起内存请求的内存请求次数,参考举例3或举例4所示,count为内存请求次数;则在执行步骤S102之前,还可以执行下述步骤:遍历各个源代码文件的内存请求次数,确定内存请求次数高于设定次数的源代码文件。具体地,由于每个源代码文件中用于申请内存的一行代码可能被执行多次,相应地,内存大小为每次申请的内存大小于申请次数的乘积。基于此原理,在确认发生内存泄漏时,一般情况下,内存请求次数比较多的代码可能发生内存泄漏的情况比较大,因此,可以先筛选出内存请求次数大于设定次数的源代码文件,这样,筛选出的源代码文件发生内存泄漏的可能性比较高,基于举例3可以筛选出file1。
举例3:
{文件名:file1,count:100,size:10241024},
{文件名:file2,count:1,size:8888},
{文件名:file3,count:1,size:8888},
……
举例4:
{文件名:file1,行号:13,count:100,size:10241024},
{文件名:file1,行号:66,count:1,size:8888},
{文件名:file2,行号:11,count:2,size:8888*2},
……
在此基础上,可以按照下述过程执行步骤S102:遍历确定出的内存请求次数高于设定次数的源代码文件,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
具体地,基于举例3在筛选出内存请求次数大于设定次数的源代码文件后,再从筛选出的源代码文件file1确认file对应的内存小于高于设定阈值,则可以确认file为发生内存泄漏的代码文件,由此可以准确地定位发生内存泄漏的源代码文件。
可选地,基于举例4在筛选出内存请求次数大于设定次数的源代码文件后,再从筛选出的源代码文件中确认内存大小高于设定阈值的行号,即可以确认行号13对应的源代码文件file1对应的内存大小高于设定阈值,从而可以确定出源代码文件file1的第13行对应的代码发生内存泄漏。由此,不仅可以定位到发生内存泄漏的源代码文件,还可以定位到源代码文件中发生内存泄漏的代码所属行,以便尽快解决内存泄漏问题。
可选地,上述内存请求包括内存申请请求,则本申请实施例提供的内存泄漏定位方法,还包括下述过程:
在接收到第一源代码文件中第一代码触发的内存申请请求后,为所述第一代码分配内存;在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数。
具体地,在接收到第一源代码文件中第一代码触发的内存申请请求后,可以获取第一源代码文件的文件标识,以及第一源代码文件中当前申请内存的第一代码所属行的行号,然后再记录表中查找是否存在与第一源代码文件的文件标识和第一代码所属行的行号相对应的记录,如果存在相匹配的记录,则将本次分配的内存累加到查找到的记录包括的内存大小上,以上述举例4为例进行说明,若第一源代码文件的文件标识为file1,第一代码所属行的行号为66,则可以确定记录表中存在与第一源代码文件和第一代码所属行的行号相匹配的记录,即举例4中第二条记录,则将本次申请的内存大小累加到第二条记录中的内存大小中,以本次分配的内存大小为8888为例,则将第二条记录更新为:{文件名:file1,行号:66,count:2,size:8888*2}。然而,若判断出记录表中不存在与第一源代码文件的文件标识和第一代码所属行的行号相匹配的记录,则在记录表中新增一条记录,以第一源代码文件的文件标识为file1,第一代码所属行的行号为88,本次申请的内存大小为8888,则在记录表中新增的记录为:{文件名:file1,行号:88,count:1,size:8888}。
需要说明的是,本实施例中的第一源代码文件可以为任一程序中的任一源代码文件,相应地,第一代码可以为任一用于申请内存的代码,第一源代码文件、第一代码仅是为了区分,第一源代码文件其可以为图1涉及的源代码文件中任一一个,相应地,第一代码也可以为图1中任一个源代码文件中的任一个用于申请内存的代码。
可选地,可以利用ceph插件工具调用包装函数在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,所述包装函数中包括动态申请内存的函数。
具体地,把动态申请内存的函数,用动态加载替换的方式封装处理,得到加了一层封装的包装函数。在包装函数里调用原来对应的内存申请函数,并且把申请内存的文件标识、行号、内存大小记录到记录表里。
可选地,上述内存请求还包括内存释放请求,则本实施例提供的内存泄漏定位方法,还包括下述过程:在接收到第二源代码文件中第二代码触发的内存释放请求后,释放所述第二代码预先申请的内存;并获取所述第二源代码文件的文件标识和所述第二代码所属的行号;根据所述第二源代码文件的文件标识和所述第二代码所属的行号,修改所述记录表中与所述第二源代码文件和所述第二代码所属行号相对应的内存大小和内存请求次数。
具体地,在接收到第二源代码文件中第二代码触发的内存释放请求后,可以获取第二源代码文件的文件标识,以及第二源代码文件中当前用于释放内存的第二代码所属行的行号,然后再记录表中查找是否存在与第二源代码文件的文件标识和第二代码所属行的行号相对应的记录,如果存在相匹配的记录,则将查找到的记录中的内存大小减去本次释放的内存大小,以及将查找到的记录中的当前内存请求次数减1,还以上述举例4为例进行说明,若第二源代码文件的文件标识为file2,第二代码所属行的行号为11,则可以确定记录表中存在与第二源代码文件和第二代码所属行的行号相匹配的记录,以本次释放的内存大小为8888为例,即举例4中第三条记录,则将第三条记录中内存大小减去8888,以及将内存请求次数count做减1处理,从而修改后的第三条件记录为{文件名:file2,行号:11,count:1,size:8888}。
需要说明的是,本实施例中的第二源代码文件可以为任一程序中的任一源代码文件,相应地,第二代码可以为任一用于申请内存的代码,第二源代码文件、第二代码仅是为了区分,第二源代码文件其可以为图1涉及的源代码文件中任一一个,相应地,第二代码也可以为图1中任一个源代码文件中的任一个用于申请内存的代码。
需要说明的是,也可以采用ceph插件工具调用包装函数在记录表中修改所述记录表中与所述第二源代码文件和所述第二代码所属行号相对应的内存大小和内存请求次数。
具体地,ceph插件工具是一种将内存工具编译成的一个动态链接库插件,并且根据ceph业务和ceph编译的特点,将插件平滑的集成在ceph工程中,并且设置好工具的开关能够实时动态的打开和关闭该功能。在ceph插件工具运行时,可以平滑方便的和系统结合,动态打开和关闭功能,快速识别内存泄漏,轻巧快捷,无副作用。该插件工具会实时并累计的记录内存申请和内存释放的信息,即内存使用状态信息,可以定时的将记录的信息输出到记录表中,该记录表可以为日志。当发现内存泄露,需要定位的时候,可以查看记录表,根据记录表方便的定位到是哪个源代码文件、代码所属的行号发生了内存泄露,以达到快速定位问题的目的。
需要说明的是,记录表具有读写锁功能,即具有读共享,写互斥的作用,在写记录表时,源代码文件的文件标识和行号可以作为索引,与之对应的内存大小和内存请求次数进行读写锁保护以保证数据互斥同步。在初始填充记录表时,会消耗很小很小一部分性能,在后续正常使用的时候,只是加读锁,几乎不会影响正常业务。此外,发生内存泄露需要定位问题时,只需查看定时输出的记录表,就可以快速地定位出哪个源代码文件的哪一行发生了内存泄漏,具有高可维护性和高稳定性。
需要说明的是,该定位功能可以随时开启随时关闭,具体可以根据实际情况而定。
通过实施本申请提供的内存泄漏定位方法,在检测出当前运行的程序发生内存泄漏时,可以从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件,由此可以快速定位出发生内存泄漏的源代码文件。
基于同一发明构思,本申请还提供了与上述内存泄漏定位方法对应的内存泄漏定位装置。该内存泄漏定位装置的实施具体可以参考上述对内存泄漏定位方法的描述,此处不再一一论述。
参见图2,图2是本申请一示例性实施例提供的一种内存泄漏定位装置,包括:
检测模块201,用于检测当前运行的程序是否发生内存泄漏;
获取模块202,用于在所述检测模块检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;
定位模块203,用于根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。
可选地,每个源代码文件的内存使用状态信息还包括该源代码文件的文件标识、该源代码文件中用于申请内存的代码所属行的行号和用于申请内存的各行代码各自申请的内存大小,则
上述定位模块203,用于遍历各个源代码文件分别对应的内存使用状态信息,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
可选地,每个源代码文件的内存使用状态信息还包括用于申请内存的各行代码各自发起内存请求的内存请求次数;则所述装置,还包括:
确定模块(图中未示出),用于在所述定位模块根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件之前,遍历各个源代码文件的内存请求次数,确定内存请求次数高于设定次数的源代码文件;
在此基础上,上述定位模块203,还用于遍历确定出的内存请求次数高于设定次数的源代码文件,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
可选地,所述内存请求包括内存申请请求,则本实施例提供的内存泄漏定位装置,还包括:
内存分配(图中未示出),用于在接收到第一源代码文件中第一代码触发的内存申请请求后,为所述第一代码分配内存;
第一记录模块(图中未示出),用于在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数。
可选地,所述内存请求包括内存释放请求,则本实施例提供的内存泄漏定位装置,还包括:
内存释放模块(图中未示出),用于在接收到第二源代码文件中第二代码触发的内存释放请求后,释放所述第二代码预先申请的内存;并获取所述第二源代码文件的文件标识和所述第二代码所属的行号;
第二记录模块(图中未示出),用于根据所述第二源代码文件的文件标识和所述第二代码所属的行号,修改所述记录表中与所述第二源代码文件和所述第二代码所属行号相对应的内存大小和内存请求次数。
可选地,上述第一记录模块(图中未示出),具体用于利用ceph插件工具调用包装函数在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,所述包装函数中包括动态申请内存的函数。
本申请实施例提供了一种电子设备,如图3所示,包括处理器301和机器可读存储介质302,机器可读存储介质302存储有能够被处理器301执行的计算机程序,处理器301被计算机程序促使执行本申请实施例所提供的内存泄漏定位方法。
上述计算机可读存储介质可以包括RAM(Random Access Memory,随机存取存储器)、DDR SRAM(Double Data Rate Synchronous Dynamic Random Access Memory,双倍速率同步动态随机存储器),也可以包括NVM(Non-volatile Memory,非易失性存储器),例如至少一个磁盘存储器。可选的,计算机可读存储介质还可以是至少一个位于远离前述处理器的存储装置。
上述处理器可以是通用处理器,包括CPU(Central Processing Unit,中央处理器)、NP(Network Processor,网络处理器)等;还可以是DSP(Digital Signal Processor,数字信号处理器)、ASIC(Application Specific Integrated Circuit,专用集成电路)、FPGA(Field-Programmable Gate Array,现场可编程门阵列)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
另外,本申请实施例提供了一种机器可读存储介质,机器可读存储介质存储有计算机程序,在被处理器调用和执行时,计算机程序促使处理器执行本申请实施例所提供的内存泄漏定位方法。
对于电子设备以及机器可读存储介质实施例而言,由于其涉及的方法内容基本相似于前述的方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
上述装置中各个单元/模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元/模块可以是或者也可以不是物理上分开的,作为单元/模块显示的部件可以是或者也可以不是物理单元/模块,即可以位于一个地方,或者也可以分布到多个网络单元/模块上。可以根据实际的需要选择其中的部分或者全部单元/模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

Claims (10)

1.一种内存泄漏定位方法,其特征在于,包括:
在检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;
根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。
2.根据权利要求1所述的方法,其特征在于,每个源代码文件的内存使用状态信息还包括该源代码文件的文件标识、该源代码文件中用于申请内存的代码所属行的行号和用于申请内存的各行代码各自申请的内存大小,则
根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件,包括:
遍历各个源代码文件分别对应的内存使用状态信息,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
3.根据权利要求1所述的方法,其特征在于,每个源代码文件的内存使用状态信息还包括用于申请内存的各行代码各自发起内存请求的内存请求次数;则
在根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件之前,还包括:
遍历各个源代码文件的内存请求次数,确定内存请求次数高于设定次数的源代码文件;
根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件,包括:
遍历确定出的内存请求次数高于设定次数的源代码文件,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
4.根据权利要求3所述的方法,其特征在于,所述内存请求包括内存申请请求,则所述方法,还包括:
在接收到第一源代码文件中第一代码触发的内存申请请求后,为所述第一代码分配内存;
在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数。
5.根据权利要求3所述的方法,其特征在于,所述内存请求包括内存释放请求,则所述方法,还包括:
在接收到第二源代码文件中第二代码触发的内存释放请求后,释放所述第二代码预先申请的内存;并获取所述第二源代码文件的文件标识和所述第二代码所属的行号;
根据所述第二源代码文件的文件标识和所述第二代码所属的行号,修改所述记录表中与所述第二源代码文件和所述第二代码所属行号相对应的内存大小和内存请求次数。
6.根据权利要求4所述的方法,其特征在于,在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,包括:
利用ceph插件工具调用包装函数在记录表中记录所述第一源代码文件的文件标识、所述第一代码所属行的行号和分配的内存大小,并更新所述第一代码所属行的行号对应的内存请求次数,所述包装函数中包括动态申请内存的函数。
7.一种内存泄漏定位装置,其特征在于,包括:
检测模块,用于检测当前运行的程序是否发生内存泄漏;
获取模块,用于在所述检测模块检测出当前运行的程序发生内存泄漏时,从记录表中获取记录的所述程序的各个源代码文件分别对应的内存使用状态信息,每个源代码文件的内存使用状态信息包括该源代码文件申请内存的大小;
定位模块,用于根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件。
8.根据权利要求7所述的装置,其特征在于,每个源代码文件的内存使用状态信息还包括该源代码文件的文件标识、该源代码文件中用于申请内存的代码所属行的行号和用于申请内存的各行代码各自申请的内存大小,则
所述定位模块,用于遍历各个源代码文件分别对应的内存使用状态信息,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
9.根据权利要求7所述的装置,其特征在于,每个源代码文件的内存使用状态信息还包括用于申请内存的各行代码各自发起内存请求的内存请求次数;则所述装置,还包括:
确定模块,用于在所述定位模块根据各个源代码文件申请内存的内存大小,定位发生内存泄漏对应的源代码文件之前,遍历各个源代码文件的内存请求次数,确定内存请求次数高于设定次数的源代码文件;
所述定位模块,还用于遍历确定出的内存请求次数高于设定次数的源代码文件,若存在任一行代码所申请的内存大小高于设定阈值时,则确认内存泄漏发生在该行代码所属的源代码文件。
10.一种电子设备,其特征在于,包括处理器和机器可读存储介质,所述机器可读存储介质存储有能够被所述处理器执行的计算机程序,所述处理器被所述计算机程序促使执行权利要求1-6任一项所述的方法。
CN202011191563.5A 2020-10-30 2020-10-30 一种内存泄漏定位方法、装置及电子设备 Pending CN112162893A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011191563.5A CN112162893A (zh) 2020-10-30 2020-10-30 一种内存泄漏定位方法、装置及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011191563.5A CN112162893A (zh) 2020-10-30 2020-10-30 一种内存泄漏定位方法、装置及电子设备

Publications (1)

Publication Number Publication Date
CN112162893A true CN112162893A (zh) 2021-01-01

Family

ID=73865303

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011191563.5A Pending CN112162893A (zh) 2020-10-30 2020-10-30 一种内存泄漏定位方法、装置及电子设备

Country Status (1)

Country Link
CN (1) CN112162893A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113157477A (zh) * 2021-04-14 2021-07-23 北京字节跳动网络技术有限公司 内存泄漏的归因方法、装置、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080072007A1 (en) * 2006-06-22 2008-03-20 Dspave Digital Signal Processing And Control Engineering Gmbh Method and computer programming product for detecting memory leaks
CN101908018A (zh) * 2010-07-20 2010-12-08 北京海泰方圆科技有限公司 一种判断内存泄露的系统及方法
CN105243011A (zh) * 2015-09-09 2016-01-13 浪潮(北京)电子信息产业有限公司 内存泄露定位方法及装置
CN105243003A (zh) * 2015-09-09 2016-01-13 浪潮(北京)电子信息产业有限公司 内存分配的监测方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080072007A1 (en) * 2006-06-22 2008-03-20 Dspave Digital Signal Processing And Control Engineering Gmbh Method and computer programming product for detecting memory leaks
CN101908018A (zh) * 2010-07-20 2010-12-08 北京海泰方圆科技有限公司 一种判断内存泄露的系统及方法
CN105243011A (zh) * 2015-09-09 2016-01-13 浪潮(北京)电子信息产业有限公司 内存泄露定位方法及装置
CN105243003A (zh) * 2015-09-09 2016-01-13 浪潮(北京)电子信息产业有限公司 内存分配的监测方法及装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113157477A (zh) * 2021-04-14 2021-07-23 北京字节跳动网络技术有限公司 内存泄漏的归因方法、装置、电子设备和存储介质
WO2022218057A1 (zh) * 2021-04-14 2022-10-20 北京字节跳动网络技术有限公司 内存泄漏的归因方法、装置、电子设备和存储介质
CN113157477B (zh) * 2021-04-14 2024-02-06 北京字节跳动网络技术有限公司 内存泄漏的归因方法、装置、电子设备和存储介质

Similar Documents

Publication Publication Date Title
KR100350484B1 (ko) 저장 디바이스에서 스택과 관련된 커랩션을 검출하기 위한장치 및 방법
US7698690B2 (en) Identifying code that wastes time performing redundant computation
US10204016B1 (en) Incrementally backing up file system hard links based on change logs
CN105335443A (zh) 一种用于数据同步中的异常检测的方法与设备
CN110765076B (zh) 数据存储方法、装置、电子设备及存储介质
CN112579327B (zh) 一种故障检测方法、装置及设备
CN109634682A (zh) 应用程序的配置文件更新方法及装置
CN100392606C (zh) 一种定位虚拟操作系统内存泄漏的方法
CN112162893A (zh) 一种内存泄漏定位方法、装置及电子设备
CN101515242B (zh) 一种查找改写内存的任务的方法和系统
CN107368330B (zh) 客户端补丁修复方法、装置和系统
CN110780815A (zh) 日志的删除方法及装置
CN112230947A (zh) 一种操作系统的升级方法、升级系统
US20180089059A1 (en) Non-coupled software lockstep
CN108536822A (zh) 数据迁移方法、装置、系统及存储介质
US20150378799A1 (en) Automatic memory leak detection
CN114500249B (zh) 一种根因定位方法和装置
CN112650645B (zh) 堆内存使用情况监测方法、装置和5g基站设备
CN102156631B (zh) 程序设计语言中管理指针的方法及系统
CN109343953B (zh) 内存管理方法、装置及电子设备
CN115328851A (zh) 一种数据保护方法、装置、设备及介质
CN109003643A (zh) 一种数据处理方法及装置
EP2960798B1 (en) Automatic memory leak detection
CN106959888B (zh) 云存储系统中的任务处理方法及装置
CN108234196B (zh) 故障检测方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20210101