Memory errors under specific conditions

[Ledzz]

I have this issue in js bindings in yoga-layout@3.2.1.

If we have a tree-like structure and call freeRecursive on a node, updating measure function on children will cause memory errors, depending on memory content it can be:

• null function or function signature mismatch
• out of memory
• memory access out of bounds

Here's a quick repro:

import {loadYoga} from 'yoga-layout/load';

const yoga = await loadYoga();

const root = yoga.Node.create();
const node1 = yoga.Node.create();
const node2 = yoga.Node.create();

root.insertChild(node1, 0)
node1.insertChild(node2, 0)

node2.setMeasureFunc(() => {
    return {
        width: 100,
        height: 100,
    };
})

node1.freeRecursive();

node2.setMeasureFunc(() => {
    return {
        width: 100,
        height: 100,
    };
})

I understand that this is not a good to free memory and then try to use it again, but maybe we can add some checks in the js bindings code?

[NickGerleman]

FinalizationRegistry is getting to be well supported now: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry

I haven't been able to prioritize much work on Yoga or the JS bindings recently, but there is a series of refactoring that I think would dramatically improve perf and usability of the JS bindings:

1. Switch to GC, instead of manual memory management, using something like the above. The way this works for Yoga's Java bindings, is that we have a managed node, that has children managed nodes, and each managed node owns the unmanaged node. If the managed Yoga node is garbage collected, the unmanaged node can safely be freed.
2. Either removing embind entirely, and moving to direct calls, or moving to a version of it with AOT binding allow for loading wasm without unsafe wasm execution #1793 (comment)

Longer term, we can also rely on WASM ESM integration, to get out of the packaging shenanigans we have, where we currently bundle into a single JS file, that requires dynamic execution to eval (Emscripten started adding support recently emscripten-core/emscripten#23985)