Clone objects being returned from trait methods before return from Java
authorMatt Corallo <git@bluematt.me>
Thu, 2 Dec 2021 18:24:05 +0000 (18:24 +0000)
committerMatt Corallo <git@bluematt.me>
Thu, 2 Dec 2021 19:55:54 +0000 (19:55 +0000)
commit5b51b5128856c7cb273b95297aa26fca21c4796d
tree161017ba32440c84bbac2a2b642d5096a283b454
parent74893948607429b046f8cd3b10fa5bc95880038b
Clone objects being returned from trait methods before return from Java

When we return an object from a trait method called from Rust, we
often return complex Java "Human" objects. Because the underlying
object is owned by Java, we clone them before passing the objects
back to Rust, if possible. However, the clone call happens after
the Java method returns, at which point Java does not have any
references to the original "Human" object, which upon free will
free the underlying object.

While the time between when the Java method returns and the C FFI
code clones the object is incredibly short, CI did manage to find
the race here in ASAN, where the original object may be freed
before being accessed again for the clone in C.

Here we fix this by simply cloneing the object being returned
directly from Java.
gen_type_mapping.py