Obtaining internal pointer of array with method chaining leads to dangling pointer

This isn’t strictly an issue but a subtle mistake I happened to find in my code and I wanted to share it.

Trying to obtain a pointer to the internal data of an array wrapped in an octave_value using the data () or fortran_vec () methods in this way:

double * array_ptr = array_ov.array_value ().data ();

can cause the array_ptr to be a dangling pointer as the intermediate NDArray object being created might have its own unique pointer which will be destroyed after this statement as the object won’t be in scope.

The only case when this won’t happen is when the original array wrapped in an octave_value was an NDArray originally as the constructor won’t need to make a copy and the pointer will be shared with the original array so it will be kept around.

The solution is to simply create the object in a separate line before the call to data so the object will always be in scope.

I am not sure if something can be done about this to make it fire a compiler warning or even an error but this was a little hard to catch at least for me.

I also noticed there were other places with a statement similar to this and I am not sure if they happen to be the safe case or not, for example:


That’s a difficult pattern to detect indeed. And it is one of those errors that might occur sometimes on some platforms and maybe only with some compilers.

We should definitely fix those when we find them. Both instances you pointed out look suspicious to me, too.

Would you like to submit patches for them?

Sure, as per the patch tutorial, I should submit a patch through savannah, is that right?

savannah.gnu.org seems down. Here is the patch file:
fvec_fix.patch (2.7 KB)


Thanks for the patch. I pushed it to the stable branch of Octave here:
octave: 820d2c802247 (gnu.org)

1 Like

I used grep and I couldn’t find any other instances that looked suspicious like the three fixed here. This was a good catch, and I think we’re fine now.

1 Like