You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I originally mentioned this in a comment at #21022 (comment) "embind: Don't automatically destroy arguments passed into val calls. (#21022)", but it likely got missed there:
Since 6e54690 "embind: Don't automatically destroy arguments passed into val calls. (#21022)" was merged into 3.1.52, the below test program behaves differently than before, and I wonder whether that's intentional. The test setup is
Until 3.1.51 (also in 3.1.47 and 3.1.48, i.e., irrespective of 12777ca "[emval] Reuse method calling optimisation in regular calls (#20383)" that was merged into 3.1.48 and motivated this change), the browser console logs were
create 0
use 0
use 0
destroy 0
create 1
copy 1 to 2
use 2
destroy 2
destroy 1
That is., the instance of Smart used in the call to JS ifc.memFun(*s); from C++ useInterface is properly destroyed.
Since 3.1.52, the browser console logs instead are
create 0
use 0
use 0
destroy 0
create 1
copy 1 to 2
use 2
destroy 1
That is, the instance of Smart used in the call to JS ifc.memFun(*s); from C++ useInterface is leaked now. But even if the new behavior is intentional: Where should that instance be destroyed? I think this commit assumes that the JS implementation
Thanks for the nice reproducer. I don't think we considered this specific case when making the changes above (nor do we have a test case that really covers it). The old behavior in this case is much nicer, but I'd still like operator() and call() to be consistent in how they handle argument lifetimes. A few things we could potentially do:
Add an option to call to auto delete all arguments.
Add an option per argument on how it should be handled.
Auto delete objects that were copy constructed when going from C++->JS. I think this would probably have issues like the previous automatic behavior though.
stbergmann
added a commit
to allotropia/emscripten
that referenced
this issue
Oct 1, 2024
I originally mentioned this in a comment at #21022 (comment) "embind: Don't automatically destroy arguments passed into val calls. (#21022)", but it likely got missed there:
Since 6e54690 "embind: Don't automatically destroy arguments passed into val calls. (#21022)" was merged into 3.1.52, the below test program behaves differently than before, and I wonder whether that's intentional. The test setup is
and
Until 3.1.51 (also in 3.1.47 and 3.1.48, i.e., irrespective of 12777ca "[emval] Reuse method calling optimisation in regular calls (#20383)" that was merged into 3.1.48 and motivated this change), the browser console logs were
That is., the instance of
Smart
used in the call to JSifc.memFun(*s);
from C++useInterface
is properly destroyed.Since 3.1.52, the browser console logs instead are
That is, the instance of
Smart
used in the call to JSifc.memFun(*s);
from C++useInterface
is leaked now. But even if the new behavior is intentional: Where should that instance be destroyed? I think this commit assumes that the JS implementationshould
smart.delete();
it now. But then, that would apparently break the sequence of direct JS to JS callsfrom within
jsRun
.The text was updated successfully, but these errors were encountered: