Double check handling of trusted setup by bindings

[George Kadianakis]

Two things to check here:

• Are bindings freeing the trusted setup correctly? Are they calling free_trusted_setup() and also freeing the pointer (see #172).
• Are we correctly protecting the bindings from double-freeing the trusted setup?

[George Kadianakis]

For example, the nodejs bindings do something like this:

c-kzg-4844/bindings/node.js/src/kzg.cxx

Lines 43 to 48 in cc10ef0

 void delete_kzg_addon_data(napi_env /*env*/, void *data, void* /*hint*/) { 
   if (((KzgAddonData*)data)->is_setup) { 
     free_trusted_setup(&((KzgAddonData*)data)->settings); 
   } 
   free(data); 
 } 

Should we also be freeing data->settings? Should we also set data->settings to NULL after doing so like the Java bindings are doing?

(/cc @matthewkeil )

[George Kadianakis]

Similar question for nim bindings:

c-kzg-4844/bindings/nim/kzg.nim

Lines 34 to 35 in cc10ef0

 proc destroy*(x: KzgCtx) = 
   free_trusted_setup(x.val) 

Should it be freeing x.val? And setting it to NULL? Or is nim somehow doing it?

(/cc @jangko )

[andri lim]

Similar question for nim bindings:
Should it be freeing x.val?

yes, it's tested in test_kzg_ex.nim (not in test_kzg.nim)

And setting it to NULL? Or is nim somehow doing it?

no need, x.val is not a pointer, but a pass by reference type. we can call it 'nim somehow doing it'.

[Matthew Keil]

Should we also be freeing data->settings? Should we also set data->settings to NULL after doing so like the Java bindings are doing?

The KzgAddonData struct stores the KZGSettings as a member and then the whole struct is heap allocated. I think when we free the struct it will cleanup that member too. At least that is the way I understand it, but I also know you know c way better than I do so i say that with pause.

As for setting it to NULL that does seem like a good practice. On the next line L#47 we free the whole struct though so that NULL member value will be invalid almost immediately. I would honestly leave that decision up to you and @jtraglia though, and will be happy to add the line setting the member value to NULL if either of you feel it is best for it to be there.

[Matthew Keil]

As a note, the addon data is stored as a pointer on the Env object that is managed by the runtime. Node is structured so that a "context handle" gets passed to all function calls. The Env class is the n-api representation. Its the magic behind a few things but in this context its for JS allocations. The result from a JS perspective is developers get garbage collection and lexical scoping.

The cleanup function gets run by the runtime when the Env object is garbage collected at environment tear-down.

So in theory the KzgAddonData pointer will be valid until the runtime is ready for it to be free'd on shut down, and for the same reason @xrchz mentioned here, it is passed back to the implementer to be cleaned up. Technically there "should not" be a time when the KzgAddonData struct or its members will be referenced once the cleanup function is called.

Empirically this is the behavior that I witnessed. There is output that happens when the node bits and pieces shut down and the logs from inside the cleanup function were almost to the end, but not necessarily the last line, at program completion.

[George Kadianakis]

So in theory the KzgAddonData pointer will be valid until the runtime is ready for it to be free'd on shut down, and for the same reason @xrchz mentioned here, it is passed back to the implementer to be cleaned up. Technically there "should not" be a time when the KzgAddonData struct or its members will be referenced once the cleanup function is called.

typedef struct {
  bool is_setup;
  KZGSettings settings;
} KzgAddonData;

Ah I see. It also seems like settings is not a pointer; it's an actual KZGSettings struct, so there is no need to manually free settings.

[George Kadianakis]

FWIW, I only had questions about the node bindings and the nim bindings which have been answered.

@jtraglia should we close this ticket? Do you want to do any investigation yourself? If not, feel free to close this.

[Justin Traglia]

Yeah let's close this.