gpt4 book ai didi

perl - 为什么使用 `DEBUG_LEAKING_SCALARS` 编译 perl 时不报告内存泄漏?

转载 作者:行者123 更新时间:2023-12-04 15:52:54 26 4
gpt4 key购买 nike

我用 DEBUG_LEAKING_SCALARS 编译 perl如所述here

案例 1
我关注这个 DOC测试内存泄漏报告:

env PERL_DESTRUCT_LEVEL=2 valgrind perl -e '@x; $x[0]=\@x'
==7216== Memcheck, a memory error detector
==7216== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7216== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7216== Command: perl -e @x;\ $x[0]=\\@x
==7216==
==7216==
==7216== HEAP SUMMARY:
==7216== in use at exit: 0 bytes in 0 blocks
==7216== total heap usage: 1,310 allocs, 1,310 frees, 171,397 bytes allocated
==7216==
==7216== All heap blocks were freed -- no leaks are possible
==7216==
==7216== For counts of detected and suppressed errors, rerun with: -v
==7216== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

没有任何报道。

案例 2
我什至在我的 XS 潜艇上做 this thing .确切地:
#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include "XSUtils.h"
#include "ppport.h"

void
call_perl() {
SV *sv;
sv = sv_2mortal( newSVpv( "XS::Utils::hello", 0 ) );

newSViv( 323 ); //<<<< SHOULD LEAK
printf( "Hi 3\n" );

ENTERSCOPE;
CALLPERL( sv , G_DISCARD|G_NOARGS );
LEAVESCOPE;
}

MODULE = XS::Utils PACKAGE = XS::Utils

void
test()
CODE:
call_perl();

Link to the REPO
$ env PERL_DESTRUCT_LEVEL=2 valgrind perl -Iblib/arch/ -Iblib/lib -MXS::Utils -e 'XS::Utils::test()' 
==7308== Memcheck, a memory error detector
==7308== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7308== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7308== Command: perl -Iblib/arch/ -Iblib/lib -MXS::Utils -e XS::Utils::test()
==7308==
Hi 3
Hello
==7308==
==7308== HEAP SUMMARY:
==7308== in use at exit: 1,502 bytes in 5 blocks
==7308== total heap usage: 12,876 allocs, 12,871 frees, 1,945,298 bytes allocated
==7308==
==7308== LEAK SUMMARY:
==7308== definitely lost: 0 bytes in 0 blocks
==7308== indirectly lost: 0 bytes in 0 blocks
==7308== possibly lost: 0 bytes in 0 blocks
==7308== still reachable: 1,502 bytes in 5 blocks
==7308== suppressed: 0 bytes in 0 blocks
==7308== Rerun with --leak-check=full to see details of leaked memory
==7308==
==7308== For counts of detected and suppressed errors, rerun with: -v
==7308== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

也没有任何报告

案例 3
我修复了模块 Devel::LeakTrace ( FIX):
$ perl -MDevel::LeakTrace -Iblib/arch/ -Iblib/lib -MXS::Utils -e 'XS::Utils::test()' 
Hi 3
Hello

也没有任何报告

案例 4
我只找到了 Test::LeakTrace做它的工作:
$ perl -MTest::LeakTrace::Script=-verbose -Iblib/arch/ -Iblib/lib -MXS::Utils -e 'XS::Utils::test()' 
Hi 3
Hello
leaked SCALAR(0x208e1c0) from -e line 1.
ALLOCATED at -e:1 by entersub (parent 0x0); serial 9642
SV = IV(0x208e1b0) at 0x208e1c0
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 323

为什么 perl 中的内置工具不报告泄漏?
我做错了什么?如何使用 DEBUG_LEAKING_SCALARS 调试泄漏内存工具?

最佳答案

实际上不是答案,而是来自 Dave Mitchell:

The main purpose of DEBUG_LEAKING_SCALARS isn't to list leaked scalars
(!!)
It's to help in tracking down things generally related to leaked scalars and refcount problems. its two main features are that it turns SV allocation from being a macro to being a function so that you can easy attach a breakpoint; and that it adds instrumentation to each SV showing where it was allocated (as displayed by Devel::Peek).



但我不知道要调试什么,因为我不知道有什么东西在泄漏。点赞 案例 1 到 3 如上所述。我确信:
newSViv( 323 );

没有泄漏。

所以 DEBUG_LEAKING_SCALARS 应该列出泄露的标量

我还在 perl 提交历史中找到了这条评论:

-[ 24088] By: davem on 2005/03/28 21:38:44
- Log: expand -DDEBUG_LEAKING_SCALARS to instrument the creation of each SV



这对 this 非常有用我心目中的任务。

关于perl - 为什么使用 `DEBUG_LEAKING_SCALARS` 编译 perl 时不报告内存泄漏?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42740780/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com