I have a (Win64) C# software package allowing users to transfer data to MATLAB for user defined processing through a MATLAB script and transfer back the results.
It relies on the MATLAB API with libeng.dll etc, and was working fine with R2018b, but has stopped working with R2019a. I changed nothing, so assume something changed with the MATLAB API, but can find no mention of such a change here or on the 'News' pages.
Any bright ideas?

댓글 수: 1

James Tursa
James Tursa 2019년 7월 30일
Did you recompile it with R2019a, or are you using the previously compiled code?

댓글을 달려면 로그인하십시오.

답변 (1개)

James Tursa
James Tursa 2019년 7월 30일

0 개 추천

I don't know if this is the cause of your problems, but there was a change to the low level mxArray variable structure in R2019a. So code might have to be recompiled in order to work.

댓글 수: 5

Bo
Bo 2019년 7월 31일
Thanks for the feedback. I recompiled the C# program (in VisualStudio 2017), changing nothing in the code that worked together with MATLAB R2018b.
Trying to singlestep my way through it seems to crash when I call engOpen from Libeng.dll. No error message or other hint about the nature of the problem, it just crashes. So I never even reach the part of my code that might be affected by changes in the lowlevel mxArray structure.
But where did you find that info, perhaps there are other changes that I'm not aware of?
Bruno Luong
Bruno Luong 2019년 7월 31일
James, what is the low-level change of mxArray? I did not notice and my old mex files are still working without recompile them.
James Tursa
James Tursa 2019년 7월 31일
편집: James Tursa 2019년 7월 31일
Documented in my mex MATLAB API version FEX submission here (in the header file):
And here is the low level change for R2019a:
* R2019a - First version where the CrossLink field in the mxArray header
* has been moved next to the reverse CrossLink field. I.e.,
* R2018b-:
* mxArray *RevCrossLink;
* mxClassID ClassID;
* int VariableType;
* mxArray *CrossLink;
* :
* etc.
* R2019a+:
* mxArray *RevCrossLink;
* mxArray *CrossLink;
* mxClassID ClassID;
* int VariableType;
* :
* etc.
If you are only calling API functions that deal with this in the background then I can easily see that this may not affect your mex routines.
Bruno Luong
Bruno Luong 2019년 7월 31일
OK so they change the order of the fields. I can't see the motivation. The aligment is more or less identical for 64-bit pointer (all MATLAB) no?
That looks odd.
James Tursa
James Tursa 2019년 7월 31일
Since ClassID and VariableType are both ints they occupy 4 bytes each. Having them next to each other means they won't mess up any 8-byte boundary alignments for the stuff around them. So, yes, I agree that the compiler won't need to add any padding in either the old or the new definitions to maintain 8-byte boundary alignments of the nearby fields.
Motivation for the change? I suppose the new definition looks nicer having the crosslink stuff next to each other. But I suspect the real motivation is just to irritate me and mess up my mex hacking code ...

댓글을 달려면 로그인하십시오.

카테고리

도움말 센터File Exchange에서 C Matrix API에 대해 자세히 알아보기

제품

태그

질문:

Bo
2019년 7월 30일

댓글:

2019년 7월 31일

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by