Make sure that we don't pass bogus RsScriptCall data along to driver.
In the case where there is no actual RsScriptCall data, our rs.spec is
accidentally passing along a stale pointer (with 0 length). Unfortunately,
the RS HAL does not supply the RsScriptCall length along with the data,
making it impossible to determine whether or not the sc data is real or
bogus.
Note that this path only occurs when we are creating packed data in
our JNI layer due to having a usrData parameter too. In other cases,
we don't end up propagating the bogus pointer(s).
Change-Id: Ica66b75abb63bcf33d4d536076cf326b5e4d8338
diff --git a/rsScript.cpp b/rsScript.cpp
index 4b2765a..f2fc5ba 100644
--- a/rsScript.cpp
+++ b/rsScript.cpp
@@ -166,6 +166,13 @@
const void *params, size_t paramLen,
const RsScriptCall *sc, size_t scLen) {
Script *s = static_cast<Script *>(vs);
+ // The rs.spec generated code does not handle the absence of an actual
+ // input for sc. Instead, it retains an existing pointer value (the prior
+ // field in the packed data object). This can cause confusion because
+ // drivers might now inspect bogus sc data.
+ if (scLen == 0) {
+ sc = NULL;
+ }
s->runForEach(rsc, slot,
static_cast<const Allocation *>(vain), static_cast<Allocation *>(vaout),
params, paramLen, sc);