Memory corruption with fftw mingw precompiled binaries and vs 2010?

Question

I would like to know if anyone has never experienced memory corruption problems using precompiled mingw fftw binaries linked with visual studio 2010 project. The strange thing is that just the fftw libs linking (generated with lib /def:libfftw3-3.def as explained by fftw doc) brings troubles in my project even if none of fftw API gets invoked. Well, I'll try compiling fftw from scratch in vs 2010 as the author suggests, but I'm curious about the fact that just linking the lib can cause side effects. As far as I can tell, it does not seem a problem of our c++ code...

Some env. details: win 32 bits, unmanaged c++ project in vs 2010

Thank you!

Answer 1

I don't know that the fftw library is, so I'm not sure what it might specifically be doing to cause instability. It's possible for a DLL to execute code when it's loaded, so the fact that you're not actively calling it doesn't necessarily mean it's not doing anything.

However, MinGW links to the msvcrt.dll runtime that's distributed with the Windows system, while a normal build using the DLL runtime in VS 2010 will link against MSVCRT100.DLL. Mixing runtime DLLs is an area that can cause mysterious problems, in particular if allocations are made from one runtime and freed in another (or even used in another I believe if the debug runtime is involved).

Your best bet might be to try to recompile the fftw library with VS 2010 (I assume the source is available - hopefully it's not too difficult to rebuild with MSVC).

It's possible to convince VS 2010 to use the msvcrt.dll runtime (Microsoft does it), but the details are non-obvious and my notes are elsewhere.

Answer 2

fftw does do some hefty code generation/profiling/CPU targeting;

Apparently they do this the first time it's run. So there may be

1. a bug that prevents the initial profiling run to succeed (try to run as admin for one time?)
2. a leftover config from an incompatible installation; I gues fftw will do a sanity check to verify that the config found matches the currently running architecture, but in case something is amiss in that process, you could benefit from finding and manually deleting that config data

Sorry I donot remember specifics (locations)