<p>An example is.</p>
<p>ioSetCursorARGB in interp.c calls the C interface ioSetCursorARGB in sqSqueakCursorAPI.m<br>
where there is a call to execute the Obj-C methods in sqSqueakOSXApplication+cursor.m, the ioSetCursorARGB contain a autorelease pool wrapper.</p>
<p>However this is fine grained as the sqSqueakOSXApplication+cursor.m code could change and introduce a autorelease object before the guard clauses, etc.</p>
<p>This is what happened in<br>
pumpRunLoopEventSendAndSignal where there was no autorelease pool because the code didn't require it, but over the years a code change introduced the autorelease object leak.</p>
<p>So a safer choice would be to wrap ioSetCursorARGB in  sqSqueakCursorAPI.m to ensure mistakes don't happen as the actual implementation code is changed.</p>
<p>In general I originally wrote the code to call from interp.c to an exposed C routine, to the obj-c logic, so I am hoping this change will be 'simple'.</p>
<p>There is more of an issue for plugins, as they are of course C routines, but could call Obj-C. For those it might just fall back to the authors to ensure they don't leak.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/374#issuecomment-472532202">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AhLyW3y-XMYkKc5ZEqSv-tjh9x3PViWNks5vWTkugaJpZM4bXsAc">mute the thread</a>.<img src="https://github.com/notifications/beacon/AhLyW6DJG8eUSUuRqD-XFOO0QvuL4F2wks5vWTkugaJpZM4bXsAc.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSmalltalk/opensmalltalk-vm","title":"OpenSmalltalk/opensmalltalk-vm","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@johnmci in #374: An example is. \r\n\r\nioSetCursorARGB in interp.c calls the C interface ioSetCursorARGB in sqSqueakCursorAPI.m\r\nwhere there is a call to execute the Obj-C methods in sqSqueakOSXApplication+cursor.m, the ioSetCursorARGB contain a autorelease pool wrapper. \r\n\r\nHowever this is fine grained as the sqSqueakOSXApplication+cursor.m code could change and introduce a autorelease object before the guard clauses, etc. \r\n\r\nThis is what happened in \r\npumpRunLoopEventSendAndSignal where there was no autorelease pool because the code didn't require it, but over the years a code change introduced the autorelease object leak. \r\n\r\nSo a safer choice would be to wrap ioSetCursorARGB in  sqSqueakCursorAPI.m to ensure mistakes don't happen as the actual implementation code is changed. \r\n\r\nIn general I originally wrote the code to call from interp.c to an exposed C routine, to the obj-c logic, so I am hoping this change will be 'simple'.  \r\n\r\nThere is more of an issue for plugins, as they are of course C routines, but could call Obj-C. For those it might just fall back to the authors to ensure they don't leak. "}],"action":{"name":"View Issue","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/374#issuecomment-472532202"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/374#issuecomment-472532202",
"url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/374#issuecomment-472532202",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>