[Octave-bug-tracker] [bug #61813] memory management bug when calling MEX that returns an output

[John W. Eaton]

Update of bug #61813 (project octave):

                  Status:                   Fixed => In Progress            
             Open/Closed:                  Closed => Open                   

    _______________________________________________________

Follow-up Comment #15:

It would be helpful to have a test case but it might be enough just to know
something about the sparse array you are passing back to Octave through the
mexCallMATLAB function.  What are the dimensions and is it complex, real, or
logical?

In any case, I realize now that I haven't extended the allocator idea to the
Sparse<T> object, so either we'll have to do that or revert to always copying
for sparse arrays.  Currently, we are unconditionally attempting to transfer
ownership of sparse array data from mxArray objects to octave_value objects. 
I'm not sure that mutation is a problem here, but mixing malloc and delete[]
could cause trouble for complex data.

I'll look at using std::pmr::polymorphic_allocator for the release, but for
now, can you try the attached patch and see whether it avoids the problem?  It
should revert to copying always for sparse arrays.

(file #52914)
    _______________________________________________________

Additional Item Attachment:

File name: sparse-mx-2-ov-diffs.txt       Size:1 KB
   
<https://file.savannah.gnu.org/file/sparse-mx-2-ov-diffs.txt?file_id=52914>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61813>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/