Re: In SWIG Ruby, is there a way to disown all objects? I want to prevent any destructors from being called.
William S Fulton <[email protected]> Wed, 14 Feb 2024 08:25:10 +0000
| Newsgroups | gmane.comp.programming.swig |
|---|---|
| Message-ID | <CANGqftAgxn0NHS29Gyc8m49XwbJ2njiTh2oySobuziA8NCa8fg@mail.gmail.com> |
--===============3693594833125320401==
Content-Type: multipart/alternative; boundary="000000000000f265190611534137"
--000000000000f265190611534137
Content-Type: text/plain; charset="UTF-8"
%apply SWIGTYPE *DISOWN {SWIGTYPE *}
will modify the default SWIGTYPE * typemaps to disown all pointer inputs.
Do look carefully at a diff of the generated because it really will leak
like crazy, but that seems to be what you want.
You can also use the following to not create implicit default destructor
wrappers. Explicitly defined destructors will still generate wrappers.
%nodefaultdtor;
You can ignore all destructors (implicit and explicit) using:
%rename("$ignore", %$isdestructor) "";
William
On Tue, 13 Feb 2024 at 18:31, Brett Williams via Swig-user <
[email protected]> wrote:
> Hi all,
>
> I have a SWIG/Ruby application that is 23 years old (started with SWIG
> 1.3). When upgrading to ruby 3.2, we started to see random seg faults
> (using SWIG 4.1.1). With the release of 4.2.0 (where ruby 3.2 is now
> supported), now there is an entirely different problem. It's an object
> ownership issue that has existed since day one, but never mattered due to
> different GC schemes or less full featured swig support. (I am not 100%
> certain why this has recently changed).
>
> For this application, all of the objects are stored in a hierarchy. I
> never want ruby to call the destructor. This hasn't mattered for the last
> 23 years, but it seems to matter now.
>
> The simplest crash is due to the following:
>
> design = Design.new(SpecialObjMgr.new)
>
> The ObjMgr is just a proxy object which indicates what type of objects are
> to be created (pure virtual methods, no data). The Design class keeps a
> copy of the object manager. So if Ruby garbage collects objmgr, seg faults
> occur when the Design object tries to use it's ObjMgr pointer. It's a
> straightforward ownership problem very similar to the Zoo example in the
> SWIG Ruby docs. In this case, since no ruby variable refers to this
> object, it gets swiftly and aggressively deleted. (That never used to
> happen before).
>
> The solution provided by SWIG for this situation is:
> %apply SWIGTYPE DISOWN
>
> Because of the particulars of this application, I want to know if there is
> a way to essentially apply DISOWN behavior across the board. This would
> prevent the generation of free_Classname functions, for example. I am not
> sure where else in this old code base I have a similar situation, but
> because of the memory management philosophy in the project, I know I never
> want the target language to delete objects.
>
> Any suggestions?
> ReplyForward
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
> _______________________________________________
> Swig-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/swig-user
>
--000000000000f265190611534137
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>%apply SWIGTYPE *DISOWN {SWIGTYPE *}<br><br></div><di=
v>will modify the default SWIGTYPE * typemaps to disown all pointer inputs.=
Do look carefully at a diff of the generated because it really will leak l=
ike crazy, but that seems to be what you want.</div><div><br></div><div>You=
can also use the following to not create implicit default destructor wrapp=
ers. Explicitly defined destructors will still generate wrappers.<br></div>=
<div><br></div><div>%nodefaultdtor;<br></div><div><br></div><div>You can ig=
nore all destructors (implicit and explicit) using:</div><div><br></div><di=
v>%rename("$ignore", %$isdestructor) "";</div><div></di=
v><div><br></div><div>William<br></div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 13 Feb 2024 at 18:31, Brett =
Williams via Swig-user <<a href=3D"mailto:[email protected]=
t" target=3D"_blank">[email protected]</a>> wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><di=
v style=3D"border-left:medium none;padding:0px;display:flex;font-family:&qu=
ot;Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-siz=
e:medium"><div style=3D"margin:0px;min-width:0px;padding:0px 0px 20px;width=
:initial"><div><div id=3D"m_-1183941025809487790m_7351075135099883139gmail-=
:u0d" style=3D"direction:ltr;margin:8px 0px 0px;padding:0px;font-size:0.875=
rem;overflow-x:hidden"><div id=3D"m_-1183941025809487790m_73510751350998831=
39gmail-:u0e" style=3D"direction:initial;font-variant-numeric:normal;font-v=
ariant-east-asian:normal;font-variant-alternates:normal;font-kerning:auto;f=
ont-feature-settings:normal;font-stretch:normal;font-size:small;line-height=
:1.5;font-family:Arial,Helvetica,sans-serif;overflow:auto hidden"><div dir=
=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif">Hi all,</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif">I have a SWIG/Ruby application tha=
t is 23 years old (started with SWIG 1.3).=C2=A0 When upgrading to ruby 3.2=
, we started to see random seg faults (using SWIG 4.1.1).=C2=A0 With the re=
lease of 4.2.0 (where ruby 3.2 is now supported), now there is an entirely =
different problem.=C2=A0 It's an object ownership issue that has existe=
d since day one, but never mattered due to different GC schemes or less ful=
l featured swig support.=C2=A0 (I am not 100% certain why this has recently=
changed).</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif">For this application, all of the objects ar=
e stored in a hierarchy.=C2=A0 I never want ruby to call the destructor.=C2=
=A0 This hasn't mattered for the last 23 years, but it seems to matter =
now.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif">The simplest crash is due to the following:</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f"><br></div><div class=3D"gmail_default"><font face=3D"monospace">design =
=3D Design.new(</font><span style=3D"font-family:monospace">SpecialObjMgr.n=
ew)</span><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif">The ObjMgr is just a proxy object which=
indicates what type of objects are to be created (pure virtual methods, no=
data).=C2=A0 The Design class keeps a copy of the object manager.=C2=A0 So=
if Ruby garbage collects objmgr, seg faults occur when the Design object t=
ries to use it's ObjMgr pointer.=C2=A0 It's a straightforward owner=
ship problem very similar to the Zoo example in the SWIG Ruby docs.=C2=A0 I=
n this case, since no ruby variable refers to this object, it gets swiftly =
and aggressively deleted.=C2=A0 (That never used to happen before).</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"=
><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif">The solution provided by SWIG for this situation is:</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">=
%apply SWIGTYPE DISOWN</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif">Because of the particulars of t=
his application, I want to know if there is a way to essentially apply DISO=
WN behavior across the board.=C2=A0 This would prevent the generation of fr=
ee_Classname functions, for example.=C2=A0 I am not sure where else in this=
old code base I have a similar situation, but because of the memory manage=
ment philosophy in the project, I know I never want the target language to =
delete objects.<br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif">Any suggestions?</div></div><div><=
/div><div></div></div></div><div style=3D"padding:0px;width:auto;background=
:rgb(242,242,242);margin:0px;border-bottom-left-radius:1px;border-bottom-ri=
ght-radius:1px"></div></div></div><div style=3D"clear:both"></div></div><di=
v style=3D"font-size:0.875rem;padding:0px;width:auto;border-bottom-left-rad=
ius:0px;border-bottom-right-radius:0px;border-top:medium none;margin:0px;ba=
ckground-image:initial;background-position:initial;background-size:initial;=
background-repeat:initial;background-origin:initial;background-clip:initial=
;font-family:"Google Sans",Roboto,RobotoDraft,Helvetica,Arial,san=
s-serif"><div style=3D"border-top:0px none;padding:0px"><div style=3D"clear=
:both;margin:0px;padding:16px 0px;border-top:medium none"><div id=3D"m_-118=
3941025809487790m_7351075135099883139gmail-:u0a"><table role=3D"presentatio=
n" style=3D"border-collapse:collapse"><tbody><tr><td style=3D"padding:0px 1=
6px;vertical-align:top;width:44px"><img id=3D"m_-1183941025809487790m_73510=
75135099883139gmail-:8e_874" name=3D"m_-1183941025809487790_m_7351075135099=
883139_:8e" style=3D"width: 40px; height: 40px; display: block; border-radi=
us: 50%;"></td><td style=3D"padding:0px;width:655.992px"><div style=3D"box-=
sizing:border-box;border-radius:1px;padding:0px;border:medium none;margin:0=
px"><div style=3D"color:inherit;height:auto;padding:0px;display:flex;line-h=
eight:20px"><span id=3D"m_-1183941025809487790m_7351075135099883139gmail-:u=
42" role=3D"link" style=3D"border:1px solid rgb(116,119,117);display:inline=
-flex;font-size:0.875rem;background:none;border-radius:18px;box-sizing:bord=
er-box;color:rgb(68,71,70);height:36px;outline:none;padding:0px 16px 0px 12=
px;min-width:104px;margin-right:8px">Reply</span><span id=3D"m_-11839410258=
09487790m_7351075135099883139gmail-:u46" role=3D"link" style=3D"border:1px =
solid rgb(116,119,117);display:inline-flex;font-size:0.875rem;background:no=
ne;border-radius:18px;box-sizing:border-box;color:rgb(68,71,70);height:36px=
;outline:none;padding:0px 16px 0px 12px;min-width:104px;margin-right:8px">F=
orward</span></div></div></td></tr></tbody></table></div></div></div></div>=
</div></div>
<br>
<span style=3D"background-color:rgb(255,255,255)"><font size=3D"2">This ele=
ctronic communication and the information and any files transmitted with it=
, or attached to it, are confidential and are intended solely for the use o=
f the individual or entity to whom it is addressed and may contain informat=
ion that is confidential, legally privileged, protected by privacy laws, or=
otherwise restricted from disclosure to anyone else. If you are not the in=
tended recipient or the person responsible for delivering the e-mail to the=
intended recipient, you are hereby notified that any use, copying, distrib=
uting, dissemination, forwarding, printing, or copying of this e-mail is st=
rictly prohibited. If you received this e-mail in error, please return the =
e-mail to the sender, delete it from your computer, and destroy any printed=
copy of it.</font></span>_______________________________________________<b=
r>
Swig-user mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Swig-u=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/swig-user" rel=3D"n=
oreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/s=
wig-user</a><br>
</blockquote></div>
--000000000000f265190611534137--
--===============3693594833125320401==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============3693594833125320401==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user
--===============3693594833125320401==--