Re: Having memory leak issues with perl-c
demerphq <[email protected]> Thu, 28 Jul 2022 10:50:00 +0200
| Newsgroups | gmane.comp.lang.perl.quality-assurance |
|---|---|
| Message-ID | <CANgJU+VesY3ef-q7Xqk+Vvswc9OPsCRiV5=juDOtgTdCEwY9sg@mail.gmail.com> |
--00000000000012802c05e4d99f1a Content-Type: text/plain; charset="UTF-8" On Thu, 28 Jul 2022 at 10:35, demerphq <[email protected]> wrote: > On Wed, 27 Jul 2022 at 22:41, Mark Murawski <[email protected]> > wrote: > >> >> >> On 7/27/22 13:20, demerphq wrote: >> >> Spectacular. I'll be reviewing and making changes that you're suggesting >> and this helps my understanding for sure. >> > > I was a bit off my game yesterday. I should have told you to make liberal > use of sv_dump() when you are debugging. That will help you visualize what > is going on. It's the XS equivalent to the Dump function from Devel::Peek > (or more accurately it is what the Dump functions uses under the hood). > > You can pass any SV like structure (Eg, HV, AV, etc) into it with casting > and it will dump out all the useful details, including refcounts. > > Good luck! > Last comment. You might find the code in Sereal::Encoder and Sereal::Decoder helpful. Sereal is a serialization package I maintain, and as such it contains all the code for serializing perl data structures and then reconstituting them. It was written in a style where it avoids mortal values as much as possible, where it mortalizes the root of the data structure being deserialized and then does not mortalize anything else (barring state data), and passes down the variables being "filled in" (usually called the SV *into). So for instance if it is deserializing an array ref, it first creates an SV with refcount 1, it then passes that into the code that parses array refs, which turns the into into an SvRV pointing at a newAV, then for each element in the array it creates a newSV, pushes it into the array, and then calls the parse logic with that new element as the into argument, etc. Thus it bypasses all of the recount twiddling. If the code dies in the middle the root is mortal so Perl will free it later. A mortal pattern might look like this: HV *sv= newSV(0); sv_2mortal(sv); /* if we die this will get freed when perl cleans up later! */ /* do stuff that could die */ ... /* Yay, we didn't die! increment sv's refcount to demortalize it and then return it */ SvREFCOUNT_inc(sv); return sv; Sorry, just trying to arm you with as much useful info as I can. I happened to be working on very similar code the last day or two for Sereal. :-) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" --00000000000012802c05e4d99f1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Thu, 28 Jul 2022 at 10:35, demerphq &l= t;<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<b= r></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Wed, 27 Jul 2022 at 22:41, = Mark Murawski <<a href=3D"mailto:[email protected]" target=3D"= _blank">[email protected]</a>> wrote:<br></div><div class=3D"g= mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> =20 =20 =20 <div> <br> <br> <div>On 7/27/22 13:20, demerphq wrote:<br> </div> <br> Spectacular.=C2=A0 I'll be reviewing and making changes that you= 9;re suggesting and this helps my understanding for sure.<br></div></blockqu= ote><div><br></div><div>I was a bit off my game yesterday. I should have to= ld you to make liberal use of sv_dump() when you are debugging. That will h= elp you visualize what is going on. It's the XS equivalent to the Dump = function from Devel::Peek (or more accurately it is what the Dump functions= uses under the hood).</div><div><br></div><div>You can pass any SV like st= ructure (Eg, HV, AV, etc) into it with casting and it will dump out all the= useful details, including refcounts.</div><div><br></div><div>Good luck!</= div></div></div></blockquote><div><br></div><div>Last comment. You might fi= nd the code in Sereal::Encoder and Sereal::Decoder helpful. Sereal is a ser= ialization package I maintain, and as such it contains all the code for ser= ializing perl data structures and then reconstituting them. It was written = in a style where it avoids mortal values as much as possible, where it mort= alizes the root of the data structure being deserialized and then does not = mortalize anything else (barring state data), and passes down the variables= being "filled in" (usually called the SV *into). So for instance= if it is deserializing an array ref, it first creates an SV with refcount = 1, it then passes that into the code that parses array refs, which turns th= e into into an SvRV pointing at a newAV, then for each element in the array= it creates a newSV, pushes it into the array, and then calls the parse log= ic with that new element as the into argument, etc. Thus it bypasses all of= the recount twiddling. If the code dies in the middle the root is mortal s= o Perl will free it later.</div><div><br></div><div>A mortal pattern might = look like this:</div><div><br></div><div>HV *sv=3D newSV(0);</div><div>sv_2= mortal(sv); /* if we die this will get freed when perl cleans up later! */<= /div><div>=C2=A0</div><div>/* do stuff that could die */</div><div>...</div= ><div><br></div><div>/* Yay, we didn't=C2=A0die! increment sv's ref= count to demortalize it and then return it */</div><div>SvREFCOUNT_inc(sv);= </div><div>return sv;</div><div><br></div><div>Sorry, just trying to arm yo= u with as much useful info as I can. I happened to be working on very simil= ar code the last day or two for Sereal. :-)</div><div><br></div><div>Yves</= div></div><div><br></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature">= perl -Mre=3Ddebug -e "/just|another|perl|hacker/"</div></div> --00000000000012802c05e4d99f1a--