Unexpected NullReferenceException in parallel_do
In case of a (partially) unitialized vec[cube]
vector, accessing an element of the vector can lead to an error message “Object reference not set to an instance of an object” in a parallel_do
function call, which is correct behavior, but which is more difficult to trace.
A = vec[cube](4)
A0 = A[0]
parallel_do(1, A0, __kernel__ (x : cube, pos : ivec3) -> x[pos] = 0.0)
Better would be that an error is generated earlier when accessing A[0]
stating that no matrix was assigned
While I think this should simply read “A0 = null” and let the user handle poorly initialized reference arrays, I think it’s pretty weird that there is a difference between executing those lines in the immediate window and in a compiled file.
In the immediate window, I do get:
:: A = vec[cube](4)
{ (null), (null), (null), (null)}
:: A0 = A[0]
Error: Object reference not set to an instance of an object
While the compiled function results in
Object reference not set to an instance of an object
randomtest.q - line 3: parallel_do(1, A0, __kernel__ (x : cube, pos : ivec3) -> x[pos] = 0.0)
Which is, to me, descriptive enough. Once the quasar user learns that “Object reference not set to an instance of an object” is basically a NullPointerException/segfault, at least 🙂
The error in the intermediate window is due to the attempt to print the value of A0
.
Actually I would like to avoid nullable vector/matrix types, perhaps forcing the vec[cube]
elements to be initialized with a default object zeros(0)
. Especially inside kernel/device functions these matrix null references are troublesome…