Visual Studio: runtime problems for an exe

I compiled this code http://www.vision.ee.ethz.ch/~surf/download_ac.html for VC8.0 (2005) with Visual Studio 2008

The code is essentially a simple console exe file which calls an external dll (provided in the archive but without source) to compute some data

The problem is that I am getting a "Violation Access" error calling the second function of the dll (the first one goes along well)

I did a bit of debugging and I discovered my executable tries (due to the library I suppose) to call CRT 8.0 while the executable compiled with Visual Studio 2008 is linked against CRT 9.0

These pictures better explain my problem


Debugging error and call stack
http://img227.imageshack.us/img227/6370/problem1u.jpg
Executable IAT (Import Address Table)
http://img263.imageshack.us/img263/9615/problem2m.jpg




How to solve this problem?

Thanks for any help you may provide me

It's usually not a problem having different runtime dll versions as long as all those runtime dll's are properly installed. Whatever installed the dll should have done that. As a general rule, a dll should handle all its memory allocation and deallocation internally and not rely on the caller to delete objects, etc. It is possible that your dll doesn't follow these conventions. What is the nature of the call that causes the crash?

I don't know dude because it's included in this package:
http://www.vision.ee.ethz.ch/~surf/S...nDLLVC8.tar.gz

and ****... the source isn't included.

Searching for another opensource implementation of the same algorithm would be a solution but the thought I have to discard a project created with Visual Studio which gives no errors in the compilation process (and that's not a thing every opensource project gives under VS environment), make me want to cry.

Quote:

---

Originally Posted by leKoxn

I don't know dude because it's included in this package:

---

I can't/won't go to those links you posted. Attach those images instead of posting links to them.

What are the parameters to the functions that fails? If those parameters are STL objects, then there is your answer -- you can't just have STL objects as parameter types to external DLL functions. Doing so means that you have to build the DLL with the same compiler options and compiler as the application.

Quote:

---

Searching for another opensource implementation of the same algorithm would be a solution but the thought I have to discard a project created with Visual Studio which gives no errors in the compilation process

---

I see this line too many times, and that is "it compiles with no errors". Compiling with no errors means nothing -- all it means is that the C++ syntax is OK. Anyone can eventually get code to compile.

The problem is that the program is doing something that is not logically correct, and my suspicion is that your code was not compiled with the right compiler options (the same options used to compile the DLL). The reason this is my suspicion is that a DLL that has exported functions created with generic, Windows parameters (i.e. LPCSTR, LONG, WPARAM, etc.) should work with any compiler, and your DLL's exported functions uses C++ object types as parameters.

Regards,

Paul McKenzie

I believe OpenCV has a SURF implementation, and it works fine with Visual Studio.

Thank you both for you answers. OpenCV will be the next road to be taken then.

Meanwhile, I think Paul had a point..

Here's the code of the executable that incapsulates the DLL methods in a namespace:

----------------------------------------fasthessian.h

namespace surf {

class Ipoint;
class Image;

class SURFWINDLL_API FastHessian {
public:
//! Destructor
~FastHessian();

//! Constructor with parameters
FastHessian(Image *im, std::vector< Ipoint >& ip, double thres = 0.2, bool doub = false,
short int initMasksize = 9, short int samplingStep = 2,
short int octaves = 4);

//! Pass the integral image
void setIimage( Image *iim );

//! Detect the interest Points, write into ipts
void getInterestPoints();

... other code....
------------------------------------

and this is the executable code where these functions get called:

------------------------------------main.cpp

.. other code..

// These are the interest points
vector< Ipoint > ipts;
ipts.reserve(1000);

// Extract interest points with Fast-Hessian
FastHessian fh(&iimage, /* pointer to integral image */
ipts,
thres, /* blob response threshold */
doubleImageSize, /* double image size flag */
initLobe * 3 /* 3 times lobe size equals the mask size */,
samplingStep, /* subsample the blob response map */
octaves /* number of octaves to be analysed */);

if( bLoadRegions ) {
// Load the interest points from disk
loadIpoints( sRegionFile, ipts, bVerbose );
} else {
// Extract them and get their pointer
fh.getInterestPoints(); <- THIS FAILS AND RAISES THE ERROR
}

... other code...
----------------------------------------


I am not sure whether this may be possible... I mean the author doing an error and then posting this code on his website. I believe the code worked with him (i hope so)

Anyway I cannot solve this problem I suppose, because I don't know how data is processed by the library (which probably does not accept such a STL vector as parameter)

Well, whoever wrote that didn't understand the fundamental principal that C++ objects cannot safely pass a DLL boundary as anything other than an opaque handle.....

I have another exe file which calls the SAME library (I compared MD5 hases and they are identical... dimensions too so let's not jump to collision exploits with fantasy) and it does not crash. It works perfectly but I have not his source code, it was told me the source code is the same as the one I am using.

So I'm assuming Visual Studio 2008 is screwing up everything in the DLL linking, what do you think about this?

It may be working. This is why it's called "undefined behavior". VS is not screwing anything up. As Lindley said, C++ objects cannot safely pass a DLL boundry.

Viggy

I'll change my question so maybe there will be more chances to succeed: an executable has been created with this same source code I am using.

Why do I get an "Access Violation" error (reading at 0x00000 or nearby) while it does not?

Is there any Visual Studio compiler option specific to "safely" pass a vector STL address like the code do?


I need a hand, I don't know where to bang my head against

No. As said before, you need to compile the EXE with the same compiler and use the same options as the DLL.

Viggy

Ok, anyway thank you all guys for giving me help in solving this matter

I'll find a solution with your advices!