• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 307
  • Last Modified:

Problem with release build accessing a dll

I have added a public-domain fast numerical solver to my computational fluid dynamics code.  The solver is written in C and seems to me (as someone who went straight to C++ and therefore doesn't know much about these things) as a bit strange in places.  I thought the best approach for me would be to compile the code as a dll, with a single function declared as __declspec( dllexport) to provide the input/output to the solver.

I compiled a release version of the dll and added appropriate code to my C++ project (using LoadLibrary & GetProcAddress) to access the function.  It all works fine for a debug build of my project, but when I compile a release version of my project, the dll is called correctly but seems to corrupt the array that contains the solution.  It is mysteriously shifted to the next array in the argument list.

I'm assuming that there is some memory corruption problem, but does anyone have any ideas what it could be?

The function declaration is:

__declspec( dllexport ) int fastlap(int *plhsSize,int *prhsSize,int *pnumSing,double *px,int *pshape,int *pdtype,int *plhsType,int *prhsType,int *plhsIndex,int *prhsIndex,double *plhsVect,double *prhsVect,double *pxf,double *pxnrm,int *pnumLev,int *pnumMom,int *pmaxItr,double *ptol,int *pjob);

The solution should be returned in the plhsVect array, but for a release version it is returned in the prhsVect array.

Just to stress again – in each instance I am using the release build of the dll.

I am using Visual C++ 6.0 on Windows 2000.

Thanks for your help.

NeilCFD
0
NeilCfd
Asked:
NeilCfd
  • 2
  • 2
1 Solution
 
jkrCommented:
Have you tried to turn off the optimizations?
0
 
NeilCfdAuthor Commented:
Thanks jkr - that must be the easiest 250 points you've ever earned!

Do you know why the optimisation (optimised for speed in my case) makes this happen?  I thought speed optimisation would be appropriate for my code as the runtime is pretty serious (>24 hours in a lot of cases) but I must admit I haven't done any testing to see what difference it was making.

Thanks again,

NeilCFD
0
 
jkrCommented:
>>Do you know why the optimisation (optimised for speed in my case) makes this happen?

Actually, to see what is going wrong, you'd have to disassemble and compare both the optimized and the non-optimized version. Optimizers are known for being less-than-perfect, and when I saw the lengthy parameter list, I was afraid that the compiler would try to optimize that one in the 1st place, especially after your remark that said "It is mysteriously shifted to the next array in the argument list"
0
 
NeilCfdAuthor Commented:
Yes - that makes sense.  Thanks!

NeilCFD
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now