bugGNU Octave - Bugs: bug #64687, mxCreateNumericArray allocates...

 
 

bug #64687: mxCreateNumericArray allocates incorrect number of elements for interleaved complex array

Submitter:  None
Submitted:  Mon 18 Sep 2023 04:41:07 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 8.3.0
Operating System:  * GNU/Linux Fixed Release:  8.4.0
Planned Release:  8.4.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 13 Oct 2023 07:21:05 PM UTC, comment #8: 

No complaints from CI or users. Closing as fixed. If problems are reported, this can be reopened.

Arun Giridhar <arungiridhar>
Group Member
Fri 22 Sep 2023 06:10:36 PM UTC, comment #7: 

Awesome. Thank you. Looks like it was quite a complicated problem - I just figured there was a missing 2* somewhere!

Anonymous
Thu 21 Sep 2023 07:32:55 PM UTC, comment #6: 

Thanks.

For the allocation error, I pushed the following changeset on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/fc646b0a8677

I'm also changing the title of this report to be about the incorrect allocation issue only.  Please open a separate report for each of the other issues (thread safety, performance).

John W. Eaton <jwe>
Group administrator
Wed 20 Sep 2023 09:51:44 PM UTC, comment #5: 

Thanks for your comment, John! Yes there is definitely a bug with mxCreateNumericArray (and also mxCreateUnitNumericArray) with complex types. It looks like the MX_HAS_INTERLEAVED_COMPLEX flag is not being taken into account to double the size of the elements.

Attached is TestFunc2.cpp compiled with mex TestFunc2.cpp -R2018a and tested with TestFunc2(3,3).


  octave:1> TestFunc2(3,3);
  Bytes required : 144
  Bytes allocated: 72
  (0,0)(0,0)(0,0)(0,0)(0,2.61855e-322)(6.93935e-310,6.9394e-310)(0,0)(6.9394e-310,2.61855e-322)(0,6.9394e-310)
  fatal: caught signal Segmentation fault -- stopping myself...
  Segmentation fault (core dumped)


The other bug is mxMallox/mxFree which crash when used inside an omp parallel block. Regular malloc/free work fine.

(file #55154)

Anonymous
Wed 20 Sep 2023 08:31:18 PM UTC, comment #4: 

In the example in comment #3, did you use the option to create an array of interleaved complex values?  If not, then I think you are seeing the expected result as mxGetData will return a pointer to the array of real values and that will just contain 9 double values.

BTW, Matlab docs appear to discourage using mxGetData for numeric arrays and warn that the meaning of the pointer it returns depends on whether the mex file has been compiled to use interleaved complex values or not.

If you still think there is a bug here, then please upload a complete mex file that shows the bug and show us exactly what command you use to compile the mex function.

Also, backticks and other markdown formatting commands don't work in the bug tracker.  To avoid confusion, please use the +/-verbatim+/- tags for code snippets.  Without those, code parts probably won't be formatted correctly.

Finally, please open separate bug reports for separate issues.  Inserting new problems in an existing report also leads to confusion.

John W. Eaton <jwe>
Group administrator
Wed 20 Sep 2023 07:47:07 PM UTC, comment #3: 

There's another issue with mxCreateNumericArray in combination with complex. It seems that it allocates on the basis of a real value rather than a complex value.
`
mwSize n[2] = {3,3};

mxArray *arr = mxCreateNumericArray(2, n, mxDOUBLE_CLASS, mxCOMPLEX);

std::complex<double> p = (std::complex<double>)mxGetData(arr);

for (mwSize k=0; k<n[0]*n[1]; k++) std::cout << p[k];
`
Gives: (0,0)(0,0)(0,0)(0,0)(0,3.21143e-322)(6.91622e-310,6.91622e-310)(9.51807e-307,1.63042e-322)(6.91622e-310,6.91622e-310)(3.16202e-322,2.56914e-322)

The first 3x3 elements are zero (correct) but the last 9 are uninitialized. I think actually they are not even allocated because I get core dumps if I access the array.

Anonymous
Wed 20 Sep 2023 06:28:22 PM UTC, comment #2: 

comment #1:

> Another potential bug. The function mxGetElementSize() ignore complexity. It returns 8 for double and also 8 for complex<double> whereas it should return 16. MATLAB returns 16.


Ah, I just realized this is a new(ish) change since 2018 when they switched to interleaved complex numbers. The mex -R2018a flag solves it - apologies for the noise!

Anonymous
Wed 20 Sep 2023 04:42:11 AM UTC, comment #1: 

Another potential bug. The function mxGetElementSize() ignore complexity. It returns 8 for double and also 8 for complex<double> whereas it should return 16. MATLAB returns 16.


Anonymous
Mon 18 Sep 2023 04:41:07 AM UTC, original submission:  

I have been working on a mex function recently that uses OMP threads. It works fine in Matlab but gave a lot of mysterious crashes, and was relatively slow in Octave. I think I narrowed it down to 2 issues (bugs perhaps?):

  1. mxMalloc/mxFree are not thread safe in Octave (replacing them with malloc/free works)
  2. mxCreateNumericArray (initialized with zeros) is significantly slower than mxCreateUninitNumericArray.

I'm attaching a short demo code (TestFunc.cpp). Matlab is much faster in this example but not so much when there is work to do in the loop.

WARNING: creates an 8Gb array

In MATLAB:
>> tic;TestFunc(1000,0);toc
Elapsed time is 0.787033 seconds.
>> tic;TestFunc(1000,1);toc
Elapsed time is 0.866709 seconds.

In Octave:
>> tic;TestFunc(1000,0);toc
Elapsed time is 11.4068 seconds.
>> tic;TestFunc(1000,1);toc
Elapsed time is 6.91305 seconds.


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55154:  TestFunc2.cpp added by None (1KiB - text/x-c++src)
file #55143:  TestFunc.cpp added by None (945B - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-10-13 arungiridhar StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2023-09-21 jwe StatusNone Ready For Test
        Fixed ReleaseNone 8.4.0
        Planned ReleaseNone 8.4.0
        SummarymxMalloc thread safety and mxCreateNumericArray performance mxCreateNumericArray allocates incorrect number of elements for interleaved complex array
    2023-09-20 None Attached File- Added TestFunc2.cpp, #55154
    2023-09-18 None Attached File- Added TestFunc.cpp, #55143

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code