Skip Menu |

This queue is for tickets about the RPC-Xmlrpc_c CPAN distribution.

Report information
The Basics
Id: 87795
Status: resolved
Priority: 0/
Queue: RPC-Xmlrpc_c

People
Owner: Nobody in particular
Requestors: jiangkai [...] 360.cn
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.04



Subject: Memory leak for arrry type
Date: Mon, 12 Aug 2013 13:58:57 +0000
To: "bug-RPC-Xmlrpc_c [...] rt.cpan.org" <bug-RPC-Xmlrpc_c [...] rt.cpan.org>
From: 蒋凯 <jiangkai [...] 360.cn>
Hi, I found a memory leak issue in my application that uses RPC::xmlrpc-c I use valgrind to trace it and get below result: ==4648== 1,478,037 (363,760 direct, 1,114,277 indirect) bytes in 4,547 blocks are definitely lost in loss record 26 of 27 ==4648== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==4648== by 0x99375C2: xmlrpc_createXmlrpcValue (xmlrpc_data.c:332) ==4648== by 0x993A171: xmlrpc_array_new (xmlrpc_array.c:194) ==4648== by 0x99368BD: xmlrpc_parseValue (parse_value.c:75) ==4648== by 0x9936E44: xmlrpc_parseValue (parse_value.c:52) ==4648== by 0x993D362: convert_params (xmlrpc_parse.c:138) ==4648== by 0x993D62F: xmlrpc_parse_response2 (xmlrpc_parse.c:453) ==4648== by 0x97281A9: xmlrpc_client_call2 (xmlrpc_client.c:565) ==4648== by 0x952320C: XS_RPC__Xmlrpc_c__Client__clientCall (Client.xs:205) ==4648== by 0x3515090A95: Perl_pp_entersub (in /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so) ==4648== by 0x351508A33D: Perl_runops_standard (in /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so) ==4648== by 0x3515038089: perl_run (in /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so) After analyze the codes. It seems in value.c, the function getItemHandles calls xmlrpc_array_read_item to read the array item, which will call xmlrpc_INCREF(*valuePP), and make valueP->ref_count = 2. It will be decreased only once in the destructor of the value object, so the memory won’t be released. It needs an additional decrease. I add below line in freeItemHandles, the problem seems gone. xmlrpc_DECREF( SvIV( handles[i] ) ); It already did the same thing in addStructMemberToHash. Could anyone review it and verify? Thanks Kai
Subject: Re: [rt.cpan.org #87795] Memory leak for arrry type
Date: 12 Aug 2013 15:36:58 +0000
To: bug-RPC-Xmlrpc_c [...] rt.cpan.org
From: Bryan Henderson <bryanh [...] giraffe-data.com>
I don't think that's right. Show quoted text
>I add below line in freeItemHandles, the problem seems gone. >xmlrpc_DECREF( SvIV( handles[i] ) );
So you must have put that statement right next to this comment, which directly contradicts it: /* Note that we do not release the xmlrpc_value handle which handles[i] holds. Caller transferred that handle to someone else. */ Do you have reason to believe that "Caller transferred that handle to someone else" isn't true? There is another comment in getItemHandles() that says to whom the handle was transferred: /* The referencet to *itemP we got above now becomes the reference from handles[] */ And then another in XS(XS_RPC__Xmlrpc_c__Value__valueArray): /* The references from itemHandles to the various xmlrpc_values are now the references from 'perlArray'. */ So it looks to me like that xmlrpc_DECREF is supposed to happen when you destroy the Perl array (i.e. the Perl variable passes out of scope in the Perl program), which should destroy each element of the Perl array, which should call XS(XS_RPC__Xmlrpc_c__Value__valueDestroy) on each of those elements. But it has been a long time since I looked at this code or any Perl extension, so maybe I don't know how the extension interface works. Show quoted text
>It already did the same thing in addStructMemberToHash.
I don't see anything like that. In fact, I see an analogous comment explaining that the reference count is _not_ decreased. -- Bryan Henderson San Jose, California
Subject: 答复: [rt.cpan.org #87795] Memory leak for arrry type
Date: Tue, 13 Aug 2013 03:33:00 +0000
To: "bug-RPC-Xmlrpc_c [...] rt.cpan.org" <bug-RPC-Xmlrpc_c [...] rt.cpan.org>
From: 蒋凯 <jiangkai [...] 360.cn>
Thanks for that quick response, Bryan. I saw that comment,and the reference count is really be decreased by one when the 'perlArray' is destroyed. But as I said before, the xmlrpc_array_read_item has make reference count up to 2, so the object can't be released. My application goes out of memory, so I debug by looking into the codes of both xmlrpc-c and the perl module. I added some debug codes in both xmlrpc-c and this module and run the test before and after the fix. It could show that. The original: the last lines show the object reference count is 1 after destroy, and the object is not released. Valgrind also proves that. xmlrpc_array_new 495172048 xmlrpc_INCREF 495170912, 2 xmlrpc_INCREF 495171680, 2 xmlrpc_INCREF 495171856, 2 In Value::DESTROY, start destroying 495171856 xmlrpc_DECREF 495171856, 1 In Value::DESTROY, finish destroying 495171856 In Value::DESTROY, start destroying 495171680 xmlrpc_DECREF 495171680, 1 In Value::DESTROY, finish destroying 495171680 In Value::DESTROY, start destroying 495170912 xmlrpc_DECREF 495170912, 1 In Value::DESTROY, finish destroying 495170912 xmlrpc_INCREF 495170912, 2 xmlrpc_DECREF 495170912, 1 xmlrpc_INCREF 495171680, 2 xmlrpc_DECREF 495171680, 1 xmlrpc_INCREF 495171856, 2 xmlrpc_DECREF 495171856, 1 xmlrpc_array_new 495182144 xmlrpc_array_new 495182240 xmlrpc_array_new 495182368 xmlrpc_INCREF 495182496, 2 xmlrpc_DECREF 495182496, 1 xmlrpc_INCREF 495182624, 2 xmlrpc_DECREF 495182624, 1 xmlrpc_INCREF 495182368, 2 xmlrpc_DECREF 495182368, 1 xmlrpc_array_new 495182784 xmlrpc_INCREF 495182912, 2 xmlrpc_DECREF 495182912, 1 xmlrpc_INCREF 495183040, 2 xmlrpc_DECREF 495183040, 1 xmlrpc_INCREF 495182784, 2 xmlrpc_DECREF 495182784, 1 xmlrpc_array_new 495183200 xmlrpc_INCREF 495183328, 2 xmlrpc_DECREF 495183328, 1 xmlrpc_INCREF 495183456, 2 xmlrpc_DECREF 495183456, 1 xmlrpc_INCREF 495183200, 2 xmlrpc_DECREF 495183200, 1 xmlrpc_INCREF 495182240, 2 xmlrpc_DECREF 495182240, 1 xmlrpc_INCREF 495182240, 2 xmlrpc_DECREF 495182144, 0 xmlrpc_DECREF 495182240, 1 xmlrpc_client_call2 resultP=495182240 In Value::DESTROY, start destroying 495172048 xmlrpc_DECREF 495172048, 0 xmlrpc_DECREF 495170912, 0 xmlrpc_DECREF 495171680, 0 xmlrpc_DECREF 495171856, 0 In Value::DESTROY, finish destroying 495172048 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495182368, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495182368 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495182784, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495182784 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495183200, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495183200 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495182496, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495182496 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495182624, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495182624 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495182912, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495182912 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495183040, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495183040 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495183328, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495183328 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 495183456, 2 In getItemHandles xmlrpc_array_read_item ends itemp=495183456 In Value::DESTROY, start destroying 495182240 xmlrpc_DECREF 495182240, 0 xmlrpc_DECREF 495182368, 1 xmlrpc_DECREF 495182784, 1 xmlrpc_DECREF 495183200, 1 In Value::DESTROY, finish destroying 495182240 After the fix: the last lines show all the reference count is 0 after destroy. Valgrind also doesn't report the memory leak. xmlrpc_array_new 233011664 xmlrpc_INCREF 233010528, 2 xmlrpc_INCREF 233011296, 2 xmlrpc_INCREF 233011472, 2 In Value::DESTROY, start destroying 233011472 xmlrpc_DECREF 233011472, 1 In Value::DESTROY, finish destroying 233011472 In Value::DESTROY, start destroying 233011296 xmlrpc_DECREF 233011296, 1 In Value::DESTROY, finish destroying 233011296 In Value::DESTROY, start destroying 233010528 xmlrpc_DECREF 233010528, 1 In Value::DESTROY, finish destroying 233010528 xmlrpc_INCREF 233010528, 2 xmlrpc_DECREF 233010528, 1 xmlrpc_INCREF 233011296, 2 xmlrpc_DECREF 233011296, 1 xmlrpc_INCREF 233011472, 2 xmlrpc_DECREF 233011472, 1 xmlrpc_array_new 233021760 xmlrpc_array_new 233021856 xmlrpc_array_new 233021984 xmlrpc_INCREF 233022112, 2 xmlrpc_DECREF 233022112, 1 xmlrpc_INCREF 233022240, 2 xmlrpc_DECREF 233022240, 1 xmlrpc_INCREF 233021984, 2 xmlrpc_DECREF 233021984, 1 xmlrpc_array_new 233022400 xmlrpc_INCREF 233022528, 2 xmlrpc_DECREF 233022528, 1 xmlrpc_INCREF 233022656, 2 xmlrpc_DECREF 233022656, 1 xmlrpc_INCREF 233022400, 2 xmlrpc_DECREF 233022400, 1 xmlrpc_array_new 233022816 xmlrpc_INCREF 233022944, 2 xmlrpc_DECREF 233022944, 1 xmlrpc_INCREF 233023072, 2 xmlrpc_DECREF 233023072, 1 xmlrpc_INCREF 233022816, 2 xmlrpc_DECREF 233022816, 1 xmlrpc_INCREF 233021856, 2 xmlrpc_DECREF 233021856, 1 xmlrpc_INCREF 233021856, 2 xmlrpc_DECREF 233021760, 0 xmlrpc_DECREF 233021856, 1 xmlrpc_client_call2 resultP=233021856 In Value::DESTROY, start destroying 233011664 xmlrpc_DECREF 233011664, 0 xmlrpc_DECREF 233010528, 0 xmlrpc_DECREF 233011296, 0 xmlrpc_DECREF 233011472, 0 In Value::DESTROY, finish destroying 233011664 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233021984, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233021984 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022400, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022400 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022816, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022816 xmlrpc_DECREF 233021984, 1 xmlrpc_DECREF 233022400, 1 xmlrpc_DECREF 233022816, 1 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022112, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022112 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022240, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022240 xmlrpc_DECREF 233022112, 1 xmlrpc_DECREF 233022240, 1 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022528, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022528 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022656, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022656 xmlrpc_DECREF 233022528, 1 xmlrpc_DECREF 233022656, 1 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233022944, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233022944 In getItemHandles start xmlrpc_array_read_item xmlrpc_INCREF 233023072, 2 In getItemHandles xmlrpc_array_read_item ends itemp=233023072 xmlrpc_DECREF 233022944, 1 xmlrpc_DECREF 233023072, 1 In Value::DESTROY, start destroying 233021856 xmlrpc_DECREF 233021856, 0 xmlrpc_DECREF 233021984, 0 xmlrpc_DECREF 233022112, 0 xmlrpc_DECREF 233022240, 0 xmlrpc_DECREF 233022400, 0 xmlrpc_DECREF 233022528, 0 xmlrpc_DECREF 233022656, 0 xmlrpc_DECREF 233022816, 0 xmlrpc_DECREF 233022944, 0 xmlrpc_DECREF 233023072, 0 In Value::DESTROY, finish destroying 233021856 -----邮件原件----- 发件人: bryanh@giraffe-data.com via RT [mailto:bug-RPC-Xmlrpc_c@rt.cpan.org] 发送时间: 2013年8月12日 23:52 收件人: 蒋凯 主题: Re: [rt.cpan.org #87795] Memory leak for arrry type <URL: https://rt.cpan.org/Ticket/Display.html?id=87795 > I don't think that's right. Show quoted text
>I add below line in freeItemHandles, the problem seems gone. >xmlrpc_DECREF( SvIV( handles[i] ) );
So you must have put that statement right next to this comment, which directly contradicts it: /* Note that we do not release the xmlrpc_value handle which handles[i] holds. Caller transferred that handle to someone else. */ Do you have reason to believe that "Caller transferred that handle to someone else" isn't true? There is another comment in getItemHandles() that says to whom the handle was transferred: /* The referencet to *itemP we got above now becomes the reference from handles[] */ And then another in XS(XS_RPC__Xmlrpc_c__Value__valueArray): /* The references from itemHandles to the various xmlrpc_values are now the references from 'perlArray'. */ So it looks to me like that xmlrpc_DECREF is supposed to happen when you destroy the Perl array (i.e. the Perl variable passes out of scope in the Perl program), which should destroy each element of the Perl array, which should call XS(XS_RPC__Xmlrpc_c__Value__valueDestroy) on each of those elements. But it has been a long time since I looked at this code or any Perl extension, so maybe I don't know how the extension interface works. Show quoted text
>It already did the same thing in addStructMemberToHash.
I don't see anything like that. In fact, I see an analogous comment explaining that the reference count is _not_ decreased. -- Bryan Henderson San Jose, California
RT-Send-CC: bryanh [...] giraffe-data.com
use the scritp below to test, there's indead memory leak. while (1) { my $bar = [ RPC::Xmlrpc_c::Value->newInt(1), RPC::Xmlrpc_c::Value->newInt(2), ]; my $foo = RPC::Xmlrpc_c::Value->newArray($bar); my $result = $foo->valueSimple(); } I think the problen is at here: --- Value/Value.pm 2006-12-31 03:10:43.000000000 +0800 +++ Value/Value.pm.new 2013-08-14 00:54:33.000000000 +0800 @@ -684,6 +684,7 @@ sub valueArraySimple_($) { foreach my $_item (@{$handlesR}) { push (@returnArray, valueSimple_($_item)); + _valueDestroy($_item); } return \@returnArray; } In valueArraySimple, no reference transferred to returnArray. So should manually invoke _valueDestroy to decrease the refcount of a xmlrpc_value. Thanks. 在2013-八月-12 23:33:41 星期一时,jiangkai@360.cn写到: Show quoted text
> Thanks for that quick response, Bryan. > > I saw that comment,and the reference count is really be decreased by > one when the 'perlArray' is destroyed. But as I said before, the > xmlrpc_array_read_item has make reference count up to 2, so the object > can't be released. My application goes out of memory, so I debug by > looking into the codes of both xmlrpc-c and the perl module. > > I added some debug codes in both xmlrpc-c and this module and run the > test before and after the fix. It could show that. > > The original: the last lines show the object reference count is 1 > after destroy, and the object is not released. Valgrind also proves > that. > > xmlrpc_array_new 495172048 > xmlrpc_INCREF 495170912, 2 > xmlrpc_INCREF 495171680, 2 > xmlrpc_INCREF 495171856, 2 > In Value::DESTROY, start destroying 495171856 > xmlrpc_DECREF 495171856, 1 > In Value::DESTROY, finish destroying 495171856 > In Value::DESTROY, start destroying 495171680 > xmlrpc_DECREF 495171680, 1 > In Value::DESTROY, finish destroying 495171680 > In Value::DESTROY, start destroying 495170912 > xmlrpc_DECREF 495170912, 1 > In Value::DESTROY, finish destroying 495170912 > xmlrpc_INCREF 495170912, 2 > xmlrpc_DECREF 495170912, 1 > xmlrpc_INCREF 495171680, 2 > xmlrpc_DECREF 495171680, 1 > xmlrpc_INCREF 495171856, 2 > xmlrpc_DECREF 495171856, 1 > xmlrpc_array_new 495182144 > xmlrpc_array_new 495182240 > xmlrpc_array_new 495182368 > xmlrpc_INCREF 495182496, 2 > xmlrpc_DECREF 495182496, 1 > xmlrpc_INCREF 495182624, 2 > xmlrpc_DECREF 495182624, 1 > xmlrpc_INCREF 495182368, 2 > xmlrpc_DECREF 495182368, 1 > xmlrpc_array_new 495182784 > xmlrpc_INCREF 495182912, 2 > xmlrpc_DECREF 495182912, 1 > xmlrpc_INCREF 495183040, 2 > xmlrpc_DECREF 495183040, 1 > xmlrpc_INCREF 495182784, 2 > xmlrpc_DECREF 495182784, 1 > xmlrpc_array_new 495183200 > xmlrpc_INCREF 495183328, 2 > xmlrpc_DECREF 495183328, 1 > xmlrpc_INCREF 495183456, 2 > xmlrpc_DECREF 495183456, 1 > xmlrpc_INCREF 495183200, 2 > xmlrpc_DECREF 495183200, 1 > xmlrpc_INCREF 495182240, 2 > xmlrpc_DECREF 495182240, 1 > xmlrpc_INCREF 495182240, 2 > xmlrpc_DECREF 495182144, 0 > xmlrpc_DECREF 495182240, 1 > xmlrpc_client_call2 resultP=495182240 > In Value::DESTROY, start destroying 495172048 > xmlrpc_DECREF 495172048, 0 > xmlrpc_DECREF 495170912, 0 > xmlrpc_DECREF 495171680, 0 > xmlrpc_DECREF 495171856, 0 > In Value::DESTROY, finish destroying 495172048 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495182368, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495182368 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495182784, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495182784 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495183200, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495183200 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495182496, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495182496 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495182624, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495182624 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495182912, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495182912 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495183040, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495183040 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495183328, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495183328 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 495183456, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=495183456 > In Value::DESTROY, start destroying 495182240 > xmlrpc_DECREF 495182240, 0 > xmlrpc_DECREF 495182368, 1 > xmlrpc_DECREF 495182784, 1 > xmlrpc_DECREF 495183200, 1 > In Value::DESTROY, finish destroying 495182240 > > > > After the fix: the last lines show all the reference count is 0 after > destroy. Valgrind also doesn't report the memory leak. > > xmlrpc_array_new 233011664 > xmlrpc_INCREF 233010528, 2 > xmlrpc_INCREF 233011296, 2 > xmlrpc_INCREF 233011472, 2 > In Value::DESTROY, start destroying 233011472 > xmlrpc_DECREF 233011472, 1 > In Value::DESTROY, finish destroying 233011472 > In Value::DESTROY, start destroying 233011296 > xmlrpc_DECREF 233011296, 1 > In Value::DESTROY, finish destroying 233011296 > In Value::DESTROY, start destroying 233010528 > xmlrpc_DECREF 233010528, 1 > In Value::DESTROY, finish destroying 233010528 > xmlrpc_INCREF 233010528, 2 > xmlrpc_DECREF 233010528, 1 > xmlrpc_INCREF 233011296, 2 > xmlrpc_DECREF 233011296, 1 > xmlrpc_INCREF 233011472, 2 > xmlrpc_DECREF 233011472, 1 > xmlrpc_array_new 233021760 > xmlrpc_array_new 233021856 > xmlrpc_array_new 233021984 > xmlrpc_INCREF 233022112, 2 > xmlrpc_DECREF 233022112, 1 > xmlrpc_INCREF 233022240, 2 > xmlrpc_DECREF 233022240, 1 > xmlrpc_INCREF 233021984, 2 > xmlrpc_DECREF 233021984, 1 > xmlrpc_array_new 233022400 > xmlrpc_INCREF 233022528, 2 > xmlrpc_DECREF 233022528, 1 > xmlrpc_INCREF 233022656, 2 > xmlrpc_DECREF 233022656, 1 > xmlrpc_INCREF 233022400, 2 > xmlrpc_DECREF 233022400, 1 > xmlrpc_array_new 233022816 > xmlrpc_INCREF 233022944, 2 > xmlrpc_DECREF 233022944, 1 > xmlrpc_INCREF 233023072, 2 > xmlrpc_DECREF 233023072, 1 > xmlrpc_INCREF 233022816, 2 > xmlrpc_DECREF 233022816, 1 > xmlrpc_INCREF 233021856, 2 > xmlrpc_DECREF 233021856, 1 > xmlrpc_INCREF 233021856, 2 > xmlrpc_DECREF 233021760, 0 > xmlrpc_DECREF 233021856, 1 > xmlrpc_client_call2 resultP=233021856 > In Value::DESTROY, start destroying 233011664 > xmlrpc_DECREF 233011664, 0 > xmlrpc_DECREF 233010528, 0 > xmlrpc_DECREF 233011296, 0 > xmlrpc_DECREF 233011472, 0 > In Value::DESTROY, finish destroying 233011664 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233021984, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233021984 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022400, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022400 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022816, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022816 > xmlrpc_DECREF 233021984, 1 > xmlrpc_DECREF 233022400, 1 > xmlrpc_DECREF 233022816, 1 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022112, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022112 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022240, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022240 > xmlrpc_DECREF 233022112, 1 > xmlrpc_DECREF 233022240, 1 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022528, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022528 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022656, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022656 > xmlrpc_DECREF 233022528, 1 > xmlrpc_DECREF 233022656, 1 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233022944, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233022944 > In getItemHandles start xmlrpc_array_read_item > xmlrpc_INCREF 233023072, 2 > In getItemHandles xmlrpc_array_read_item ends itemp=233023072 > xmlrpc_DECREF 233022944, 1 > xmlrpc_DECREF 233023072, 1 > In Value::DESTROY, start destroying 233021856 > xmlrpc_DECREF 233021856, 0 > xmlrpc_DECREF 233021984, 0 > xmlrpc_DECREF 233022112, 0 > xmlrpc_DECREF 233022240, 0 > xmlrpc_DECREF 233022400, 0 > xmlrpc_DECREF 233022528, 0 > xmlrpc_DECREF 233022656, 0 > xmlrpc_DECREF 233022816, 0 > xmlrpc_DECREF 233022944, 0 > xmlrpc_DECREF 233023072, 0 > In Value::DESTROY, finish destroying 233021856 > > > > > > > > > -----邮件原件----- > 发件人: bryanh@giraffe-data.com via RT [mailto:bug-RPC- > Xmlrpc_c@rt.cpan.org] > 发送时间: 2013年8月12日 23:52 > 收件人: 蒋凯 > 主题: Re: [rt.cpan.org #87795] Memory leak for arrry type > > <URL: https://rt.cpan.org/Ticket/Display.html?id=87795 > > > I don't think that's right. >
> > I add below line in freeItemHandles, the problem seems gone. > > xmlrpc_DECREF( SvIV( handles[i] ) );
> > So you must have put that statement right next to this comment, which > directly contradicts it: > > /* Note that we do not release the xmlrpc_value handle which > handles[i] holds. Caller transferred that handle to someone else. > */ > > Do you have reason to believe that "Caller transferred that handle to > someone else" isn't true? > > There is another comment in getItemHandles() that says to whom the > handle was transferred: > > /* The referencet to *itemP we got above now becomes the > reference from handles[] > */ > > And then another in XS(XS_RPC__Xmlrpc_c__Value__valueArray): > > /* The references from itemHandles to the various xmlrpc_values > are now the references from 'perlArray'. > */ > > So it looks to me like that xmlrpc_DECREF is supposed to happen when > you destroy the Perl array (i.e. the Perl variable passes out of scope > in the Perl program), which should destroy each element of the Perl > array, which should call XS(XS_RPC__Xmlrpc_c__Value__valueDestroy) on > each of those elements. > > But it has been a long time since I looked at this code or any Perl > extension, so maybe I don't know how the extension interface works. >
> > It already did the same thing in addStructMemberToHash.
> > I don't see anything like that. In fact, I see an analogous comment > explaining that the reference count is _not_ decreased. > > -- > Bryan Henderson San Jose, California >
Subject: Re: [rt.cpan.org #87795] Memory leak for arrry type
Date: 16 Aug 2013 02:19:39 +0000
To: bug-RPC-Xmlrpc_c [...] rt.cpan.org
From: Bryan Henderson <bryanh [...] giraffe-data.com>
Thanks for finding this. I have released a fix in version 1.04 of the package. I made valueArraySimple_() get the array contents with valueArray_() instead of _valueArray(), which causes it to get RPC::Xmlrpc_c::Value objects instead of raw executable object pointers, so the reference gets properly destroyed when the RPC::Xmlrpc_c::Value object gets destroyed. I made the same fix for structs. -- Bryan Henderson San Jose, California