Re: In SWIG Ruby, is there a way to disown all objects? I want to prevent any destructors from being called.
Brett Williams via Swig-user <[email protected]> Mon, 11 Mar 2024 11:02:50 -0600
| Newsgroups | gmane.comp.programming.swig |
|---|---|
| Message-ID | <CAGqoRfpNiiR=wFbR2NTAAOA7cQBhVT1VPSBUkWMT-1R6cPTOHQ@mail.gmail.com> |
--===============7572528528315957108==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
boundary="0000000000002b52f10613658505"
--0000000000002b52f10613658505
Content-Type: multipart/alternative; boundary="00000000000025d8640613658504"
--00000000000025d8640613658504
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
In case this happens to anyone else, I will include the resolution to this
issue.
This turned out to be a bug in mmap on CentOS 7. It was not related to
SWIG at all, and wasn't a ruby bug, but rather caused by ruby's use of the
mmap library. This could occasionally happen to any ruby program when
compiled with mmap on CentOS 7 when memory usage became high.
Thank you for the assistance on helping work around the destructor related
issue (which was independent).
On Wed, Feb 14, 2024 at 3:59=E2=80=AFPM Brett Williams <brett.williams@broa=
dcom.com>
wrote:
> Thank you, William. I used the rename ignore method, and that solved the
> issue.
>
> Unfortunately for me, now I am still having a crash in the same place tha=
t
> I was with SWIG 4.1.1. The seg fault happens in a slightly different lin=
e
> (it is not deterministic) but seems to be due to a typemap which converts
> an STL std::unordered_map to a Ruby hash. This typemap was written befor=
e
> any significant STL support was added to SWIG. Has there been any change
> in these calls in SWIG that might explain why this is an issue? In
> particular, the SWIG_NewPointerObj function?
>
> %define STRING_PTR_HASH_ADDOUTTYPEMAP(hashclassname, valueclassname)
> %typemap(out) hashclassname &, const hashclassname & {
> VALUE hsh =3D rb_hash_new();
> hashclassname::iterator i =3D $1->begin(), iend =3D $1->end();
> for ( ; i !=3D iend; i++ ) {
> VALUE key =3D rb_str_new2(i->first.c_str());
> VALUE val =3D SWIG_NewPointerObj((void *)i->second,
> $descriptor(valueclassname *),0);
> rb_hash_aset(hsh, key, val);
> }
> $result =3D hsh;
> }
> %enddef
>
>
>
> On Wed, Feb 14, 2024 at 1:25=E2=80=AFAM William S Fulton <wsf@fultondesig=
ns.co.uk>
> wrote:
>
>> %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 l=
ast
>>> 23 years, but it seems to matter now.
>>>
>>> The simplest crash is due to the following:
>>>
>>> design =3D 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 ke=
eps
>>> 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 w=
ould
>>> 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 ne=
ver
>>> 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 intend=
ed
>>> solely for the use of the individual or entity to whom it is addressed =
and
>>> may contain information that is confidential, legally privileged, prote=
cted
>>> by privacy laws, or otherwise restricted from disclosure to anyone else=
. If
>>> you are not the intended recipient or the person responsible for delive=
ring
>>> 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 erro=
r,
>>> please return the e-mail to the sender, delete it from your computer, a=
nd
>>> destroy any printed copy of it.
>>> _______________________________________________
>>> Swig-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>>
>>
--=20
This electronic communication and the information and any files transmitted=
=20
with it, or attached to it, are confidential and are intended solely for=20
the use of the individual or entity to whom it is addressed and may contain=
=20
information that is confidential, legally privileged, protected by privacy=
=20
laws, or otherwise restricted from disclosure to anyone else. If you are=20
not the intended recipient or the person responsible for delivering the=20
e-mail to the intended recipient, you are hereby notified that any use,=20
copying, distributing, dissemination, forwarding, printing, or copying of=
=20
this e-mail is strictly prohibited. If you received this e-mail in error,=
=20
please return the e-mail to the sender, delete it from your computer, and=
=20
destroy any printed copy of it.
--00000000000025d8640613658504
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">In case this happens to anyone else, I will include the=
resolution to this issue.</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif">This turned out to be a bug=
in mmap on CentOS 7.=C2=A0 It was not related to SWIG at all, and wasn'=
;t a ruby bug, but rather caused by ruby's use of the mmap library.=C2=
=A0 This could occasionally happen to any ruby program when compiled with m=
map on CentOS 7 when memory usage became high.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">Thank y=
ou for the assistance on helping work around the destructor related issue (=
which was independent).</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Feb 14, 2024 at 3:59=E2=80=AFPM Brett=
Williams <<a href=3D"mailto:[email protected]">brett.williams=
@broadcom.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif">Thank you, William.=C2=A0 I used the renam=
e ignore method, and that solved the issue.=C2=A0=C2=A0</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=
">Unfortunately for me, now I am still having a crash in the same place tha=
t I was with SWIG 4.1.1.=C2=A0 The seg fault happens in a slightly differen=
t line (it is not deterministic) but seems to be due to a typemap which con=
verts an STL std::unordered_map to a Ruby hash.=C2=A0 This typemap was writ=
ten before any significant STL support was added to SWIG.=C2=A0 Has there b=
een any change in these calls in SWIG that might explain why this is an iss=
ue?=C2=A0 In particular, the SWIG_NewPointerObj function?</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><br></d=
iv><div class=3D"gmail_default"><font face=3D"monospace">%define STRING_PTR=
_HASH_ADDOUTTYPEMAP(hashclassname, valueclassname)<br>%typemap(out) hashcla=
ssname &, const hashclassname & {<br>=C2=A0 VALUE hsh =3D rb_hash_n=
ew();<br>=C2=A0 hashclassname::iterator i =3D $1->begin(), iend =3D $1-&=
gt;end();<br>=C2=A0 for ( ; i !=3D iend; i++ ) {<br>=C2=A0 =C2=A0 VALUE key=
=3D rb_str_new2(i->first.c_str());<br>=C2=A0 =C2=A0 VALUE val =3D SWIG_=
NewPointerObj((void *)i->second, $descriptor(valueclassname *),0);<br>=
=C2=A0 =C2=A0 rb_hash_aset(hsh, key, val);<br>=C2=A0 }<br>=C2=A0 $result =
=3D hsh;<br>}<br>%enddef</font><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif"><br></div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, =
Feb 14, 2024 at 1:25=E2=80=AFAM William S Fulton <<a href=3D"mailto:wsf@=
fultondesigns.co.uk" target=3D"_blank">[email protected]</a>> wrot=
e:<br></div><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"l=
tr"><div>%apply SWIGTYPE *DISOWN {SWIGTYPE *}<br><br></div><div>will modify=
the default SWIGTYPE * typemaps to disown all pointer inputs. Do look care=
fully at a diff of the generated because it really will leak like crazy, bu=
t that seems to be what you want.</div><div><br></div><div>You can also use=
the following to not create implicit default destructor wrappers. Explicit=
ly defined destructors will still generate wrappers.<br></div><div><br></di=
v><div>%nodefaultdtor;<br></div><div><br></div><div>You can ignore all dest=
ructors (implicit and explicit) using:</div><div><br></div><div>%rename(&qu=
ot;$ignore", %$isdestructor) "";</div><div></div><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]" target=3D"=
_blank">[email protected]</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif"><div style=3D"bo=
rder-left:medium none;padding:0px;display:flex;font-family:"Google San=
s",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><di=
v style=3D"margin:0px;min-width:0px;padding:0px 0px 20px;width:initial"><di=
v><div id=3D"m_-2572126279894396496m_8747115512061323640m_-1183941025809487=
790m_7351075135099883139gmail-:u0d" style=3D"direction:ltr;margin:8px 0px 0=
px;padding:0px;font-size:0.875rem;overflow-x:hidden"><div id=3D"m_-25721262=
79894396496m_8747115512061323640m_-1183941025809487790m_7351075135099883139=
gmail-:u0e" style=3D"direction:initial;font-variant-numeric:normal;font-var=
iant-east-asian:normal;font-variant-alternates:normal;font-kerning:auto;fon=
t-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,san=
s-serif">Hi all,</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif">I have a SWIG/Ruby application that i=
s 23 years old (started with SWIG 1.3).=C2=A0 When upgrading to ruby 3.2, w=
e started to see random seg faults (using SWIG 4.1.1).=C2=A0 With the relea=
se of 4.2.0 (where ruby 3.2 is now supported), now there is an entirely dif=
ferent problem.=C2=A0 It's an object ownership issue that has existed s=
ince day one, but never mattered due to different GC schemes or less full f=
eatured swig support.=C2=A0 (I am not 100% certain why this has recently ch=
anged).</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif">For this application, all of the objects are s=
tored 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,sa=
ns-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif">The simplest crash is due to the following:</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">=
<br></div><div class=3D"gmail_default"><font face=3D"monospace">design =3D =
Design.new(</font><span style=3D"font-family:monospace">SpecialObjMgr.new)<=
/span><br></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">The ObjMgr is just a proxy object which ind=
icates what type of objects are to be created (pure virtual methods, no dat=
a).=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 tries=
to use it's ObjMgr pointer.=C2=A0 It's a straightforward ownership=
problem very similar to the Zoo example in the SWIG Ruby docs.=C2=A0 In th=
is case, since no ruby variable refers to this object, it gets swiftly and =
aggressively deleted.=C2=A0 (That never used to happen before).</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><br=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif">The solution provided by SWIG for this situation is:</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">%app=
ly SWIGTYPE DISOWN</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif">Because of the particulars of this =
application, I want to know if there is a way to essentially apply DISOWN b=
ehavior across the board.=C2=A0 This would prevent the generation of free_C=
lassname 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 management=
philosophy in the project, I know I never want the target language to dele=
te objects.<br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"fon=
t-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-right-=
radius:1px"></div></div></div><div style=3D"clear:both"></div></div><div st=
yle=3D"font-size:0.875rem;padding:0px;width:auto;border-bottom-left-radius:=
0px;border-bottom-right-radius:0px;border-top:medium none;margin:0px;backgr=
ound-image:initial;background-position:initial;background-size:initial;back=
ground-repeat:initial;background-origin:initial;background-clip:initial;fon=
t-family:"Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-se=
rif"><div style=3D"border-top:0px none;padding:0px"><div style=3D"clear:bot=
h;margin:0px;padding:16px 0px;border-top:medium none"><div id=3D"m_-2572126=
279894396496m_8747115512061323640m_-1183941025809487790m_735107513509988313=
9gmail-:u0a"><table role=3D"presentation" style=3D"border-collapse:collapse=
"><tbody><tr><td style=3D"padding:0px 16px;vertical-align:top;width:44px"><=
img id=3D"m_-2572126279894396496m_8747115512061323640m_-1183941025809487790=
m_7351075135099883139gmail-:8e_874" name=3D"m_-2572126279894396496_m_874711=
5512061323640_m_-1183941025809487790_m_7351075135099883139_:8e" style=3D"wi=
dth: 40px; height: 40px; display: block; border-radius: 50%;"></td><td styl=
e=3D"padding:0px;width:655.992px"><div style=3D"box-sizing:border-box;borde=
r-radius:1px;padding:0px;border:medium none;margin:0px"><div style=3D"color=
:inherit;height:auto;padding:0px;display:flex;line-height:20px"><span id=3D=
"m_-2572126279894396496m_8747115512061323640m_-1183941025809487790m_7351075=
135099883139gmail-:u42" 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:border-box;color:rgb(68,71,70);height:36px;outline:none;pad=
ding:0px 16px 0px 12px;min-width:104px;margin-right:8px">Reply</span><span =
id=3D"m_-2572126279894396496m_8747115512061323640m_-1183941025809487790m_73=
51075135099883139gmail-:u46" role=3D"link" style=3D"border:1px solid rgb(11=
6,119,117);display:inline-flex;font-size:0.875rem;background:none;border-ra=
dius:18px;box-sizing:border-box;color:rgb(68,71,70);height:36px;outline:non=
e;padding:0px 16px 0px 12px;min-width:104px;margin-right:8px">Forward</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>
</blockquote></div>
</blockquote></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>
--00000000000025d8640613658504--
--0000000000002b52f10613658505
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIQcwYJKoZIhvcNAQcCoIIQZDCCEGACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg3KMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD
VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE
AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT
AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS
MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t
rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e
aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1
e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH
cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG
MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ
KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB
/wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu
TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i
YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j
b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs
c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo
CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN
BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf
jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8
9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ
/oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ
jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC
AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v
dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5
MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB
IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E
XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J
J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u
nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv
riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj
QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N
UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH
M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU
Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V
14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy
a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/
XzCCBVIwggQ6oAMCAQICDFInb3eMcQ3Y+ImrdTANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC
RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg
UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAxMDEyMzlaFw0yNTA5MTAxMDEyMzlaMIGS
MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU
BgNVBAoTDUJyb2FkY29tIEluYy4xFzAVBgNVBAMTDkJyZXR0IFdpbGxpYW1zMSowKAYJKoZIhvcN
AQkBFhticmV0dC53aWxsaWFtc0Bicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCv8QKYJhW9RgHi8lJ1ScZxuCS2mdaFbhpUJtDKs+AHqAFlGRLR5EyyPNWPf87FTe9a
9HuLB2H/F26MLQhbV5jWeiyKUihCT1H/4MH3opmMZ8tuxW84BH290XBN0zIFU4okX6U7BQTSy9dB
63uQEnheyA6qDKCzwIFcZ5BhB4I/vUrGLCkNoY1AtTCd9XIzd1XFuZjlxFRKkwz7IM71/VVE8Kxs
4BwfcXrcOHDqkmYJ9+tRdh5z4a5am3zvkkf/8xitTAmrOtFUalVu28OMo7kXOQqWviBuqVBFJxXF
HPFHmG2ceeeBKYpH34sTLysqxfk1lPEJoKUJClxi07oy6WjFAgMBAAGjggHcMIIB2DAOBgNVHQ8B
Af8EBAMCBaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRwOi8vc2VjdXJlLmds
b2JhbHNpZ24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcnQwQQYIKwYB
BQUHMAGGNWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2Ey
MDIwME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n
bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0
dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3JsMCYG
A1UdEQQfMB2BG2JyZXR0LndpbGxpYW1zQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcD
BDAfBgNVHSMEGDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUZvdpTndIe+snTdqo
sH9aP+XT5j4wDQYJKoZIhvcNAQELBQADggEBAFMqTVylT9uYo/zt8vdgXsXVDFtQDeOaL5X6jmsP
qGe6NRAWUKIIr1qDy3uIDfIUtq4VCRKDUnuFfOyAGVl/FmsOiRWNCYvURSd+zYLgefAKdm3ryyL/
2TWUsuKs+uSQaIvaxbXTp9Y5qr2DVdHqw4oxjdfndv4ux+w0J84UjN9ue7oWg8vzGtT/tfJF7iv9
xcCRMfdClC++kxuH/iIKKSY6ElgBPBb1WcqNiiDUCYhk6BjAjXQnDa5XeBJGKyvAphxeZHagSyZz
GcmF+OOAzjdqzfWGT0jdULDJlWSebZ37s6mYkU85YQa7T9aAh3ogw1COMU5GvotgwYl9XKJtKeIx
ggJtMIICaQIBATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEw
LwYDVQQDEyhHbG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgxSJ293jHEN
2PiJq3UwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIILx6wdbGLUtL1AYlI+BWdBs
IxAVru47XvShF7g0KLXbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTI0MDMxMTE3MDMyN1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEW
MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCG
SAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCY5as9TuocjxKJGTSkdm0I+v0Qy+vCGtOaqfjJ/Cjn
XBnMLpnwDkhKVjKlD8uDrzR0HpGckhT7YWLWDOxTv6HOiYrwN16qMsXejKY1BSmGePMCtpI2gTCW
6aUA93Ffh6a5/1iKgoFGpzARCq/euqg2kxQHyE14YGcCmITyy/fp2esX+hJzOqvdYAA8VAAO/zj9
EFk5oXe9SkOjhxIQQyeDRXRgiNPPa2+NqZJNcTLQDaKlURexKc5oCmfwgabYHTmMVmaf1M+qRxDN
mrjdqpBjiFFo/tSla3XmwdmhgLST+3MoR8n1rKaMw5woqGGKSvAQ7uDRvj3PMMeCG+V1WmrP
--0000000000002b52f10613658505--
--===============7572528528315957108==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============7572528528315957108==
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
--===============7572528528315957108==--