[ffi] Data corruption from native thread

[LeoBound]

Hi,
I'm having an issue where a NativeCallable.listener callback is receiving garbled data.
My callback is void Function(Pointer<Char> json) => json.cast<Utf8>().toDartString();
This fails ~80% of the time as it fails to decode the UTF-8 in the call to toDartString(). This string should always be valid UTF-8, and indeed in the remaining 20% of the time it succeeds and behaves as expected.

I believe it is similar to the issue described here.

Is there a workaround for this? I think the proposed NativeCallable.blocking might solve it but in the meantime is there anything I can do from the dart side?

Dart SDK version: 3.4.4

Thanks

[dart-github-bot]

Summary: NativeCallable listener callback receives corrupted data (~80% failure rate) when converting UTF-8 Pointer<Char> to Dart String. User suspects thread race condition, similar to a known Flutter issue.

[dcharkes]

I believe it is similar to the issue described here.

It does sound like the same issue, the String memory being released on the native code side before the Dart callback is run (asynchronously).

Is there a workaround for this?

Yes, malloc the String in C and pass ownership to Dart.

I think the proposed NativeCallable.blocking might solve it but in the meantime is there anything I can do from the dart side?

It would (and would make the callback synchronous instead of asynchronous).

No, you cannot do anything from the Dart side.

You'll have to write a C function that copies the String into malloced memory and pass that copy of the string to Dart so that then in Dart you can free it when you're done with it.

[LeoBound]

Ok I'll make the changes on the C side for now.

If I had a library for which I didn't have the source code (only binaries and headers) am I right in saying the only workaround for this at the moment to wrap that library in a layer that makes copies for all of the callbacks?

[dcharkes]

If I had a library for which I didn't have the source code (only binaries and headers) am I right in saying the only workaround for this at the moment to wrap that library in a layer that makes copies for all of the callbacks?

Correct 👍

[LeoBound]

Fair enough, thanks for getting back to me quickly! 🙂