Calling 64 bit third party dll from mex doesn't work for one function

Question

Jim Hokanson 2014-8-7

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/146620-calling-64-bit-third-party-dll-from-mex-doesn-t-work-for-one-function

回答： Jim Hokanson 2014-8-25

Hi all,

I wrote a mex function to wrap a third party library that is provided as a dll with an "import library" .lib file provided. Everything works great for 32bit Matlab. I am now trying the 64 bit dll with 64 bit Matlab and almost everything seems to work except for a call to read data. I have simplified the program significantly and it seems as if the problem somehow stems from running the code in Matlab. Compiling essentially the same code as an executable in Visual Studio without the mex libraries works.
I'm using MATLAB Version: 8.1.0.604 (R2013a) although I think I've had this problem with 2014a as well. I'm using Visual Studio 2012 to compile the mex code.
This third party library is very Windows heavy. I'm wondering if there is some sort of conflict between libraries with Matlab and this dll. Is that possible?
The data reading in the third party library uses some sort of decompression algorithm and I notice (using Dependency Walker) that libmx.dll references zlib1.dll which is x86, not x64. Is there something going on there ...?
General thoughts as to how to procede?

Thanks, Jim

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Jim Hokanson 2014-8-25

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/146620-calling-64-bit-third-party-dll-from-mex-doesn-t-work-for-one-function#answer_149707

The problem ended up having to do with the allocation address of the memory for the data being read into memory. When the allocation address exceeded the 32 bit boundary the program would crash.

This also led to other people testing the code and it working for them. Presumably they were only using 4GB of RAM in their computer (or were just getting really lucky).

I also would occasionally get the code to work. I thought this might have something to do with processes that were running, without realizing that it had to do with where there were gaps in the memory for allocation.