I am using VS 2008 and get compiler errors sporadically when adding a dll reference to a managed c++ file in my C++ project. I am trying to add a reference to the dll so as to be able to use smart pointers.
ex: #import items.tlb
The problem is that the compiler crashes at sporadic places inside of items.tlh almost as though chunks of bytes where erased of missings , but when i open the file i can't find any reference to the aforementioned errors.
I tried to rebuild the whole project several times, tried on different machine, but although the compiler errors are not consistents and disappear alltogether sometimes , a fresh rebuild sometimes brings back the problem. I was told that the size of the generated .tlh file may be a reason but it doesn't really solve my problem or point me in the right direction.
Did anybody experienced the same symptoms?
Thank you
Whenever I've had this problem, it was caused by linking a Debug build to a Release DLL or a Release build to a Debug DLL.
Related
I'm following the gtkmm tutorial for gtkmm4 and I'm getting an odd error when I try to run my program. The program is an exact copy of the provided code, and it compiles successfully:
However, when I run the program it gives me a series of errors:
I'm not sure what to do at this point. I've tried googling, but I don't get anything helpful. I've check that the DLL in question does exist. Any advice is appreciated!
Edit: I ran the Dependency Walker program, and got some errors, not sure what this means though.
Edit2: I did some research on Dependency Walker, and it seems to have some known issues, so I also ran lucasg's "Dependencys" program, with this output. I'm still not really sure what this means, but it seems fine.
Edit3: I moved the 4 offending dll files into the build directory, and these are the new errors I'm getting. Its the same error, but now it points to the more local file.
Check your .exe file with Dependency Walker to see which issues there are loading the .dll files.
One possible cause could be that you're mixing 32-bit and 64-bit.
The issue was something to do with finding the correct DLLs. The solution, as outlined here, is to copy all the DLLs from C:\msys64\mingw64\bin into the build directory. Then, using ntldd or some other profiler, determine which DLLs are unnecessary and remove them.
In this case I do have the source for both the application and the dll.
When both are compiled without /NXCOMPAT, they work together fine. But when I compile both with /NXCOMPAT, I get a segfault deep in kernelspace.
If I compile the dll with /NXCOMPAT, and compile the executable without, it also works fine. (not surprising I suppose, since the DEP settings for the executable get forced on the loaded dll.)
I have previously seen a segfault in MainCRTStartup (Note: not the dll version), after enabling DEP, which was caused by another linker option. However, in this case that other linker option is NOT set, so I know that's not the answer.
Anyone have an idea where I should look for the cause?
Edit: Further strangeness. I've been running this in the debugger in VS 2008 the whole time, but when I tried running it without the debugger attached, the segfault disappears. I find this a very unsatisfactory solution, as I still don't know why it's been doing this.
Edit the 2nd: Also segfaults running in the debugger in VS 2013 Express.
Lacking code, we have to guess by the symptoms. My crystal ball says you're doing things inside LoadLibrary (i.e. inside DllMainCRTStartup) which are banned. And there is a very long list of things which are banned in LoadLibrary, including loading any other DLL.
Note that your global objects are created from DllMainCRTStartup and therefore have to respect the LoadLibrary rules as well.
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
I'm working on a pretty tricky problem that I've been on for literally a week now. I've hit a very hard wall and my forehead hurts from banging it so I'm hoping someone can help me out.
I am using Visual Studio 2005 for this project - I have 2008 installed but was running into similar issues when I tried it.
We have an application currently working compiled against OpenCv1.1 and I'm trying to update it to 2.2. When we switch over statically link to the new libs, the application crashes - but only in release mode. So dynamic linking and debug both work fine.
The crash is in std::vector when calling push_back.
I then came up with a sample test application which runs some basic code in opencv which works fine and then took that exact same code and added it to our application. That code fails.
I then gutted the application so it didn't instantiate any code objects except the main gui and 1 class which called that code and it still crashed. However, if I ran that code directly in the main gui, it worked fine.
I then started commenting out huge amounts of the application (in components that should never be instantiated) and eventually I worked my way down down down until...
I have a class that has a method
void Foo()
{
std::vector<int> blah;
blah.begin();
}
If this method is defined in the header, the test code works, but if this code is defined in the cpp file, it crashes. Also, if I use std::vector<double> instead of int, it also works.
I then tried to play with the compiler options and if I have optimizations turned off (/Od) and Inline Function Expansion set to Only __inline (/Ob1) it works even with the code being in the cpp file.
Of course, if we go back to the ungutted application and change those compiler options by themselves, it crashes.
If anyone has any insights on this, please let me know.
Thanks,
Liron
ARGH! Solution figured out.
In our solution we had defined _SECURE_SCL = 0, but in the 3rd party libs we had build, that was undefined (which means = 1). Setting _SECURE_SCL to 0 supposedly reduces runtimes drastically, but it has to be done the same across all included libs otherwise they will treat array sizes differently.
http://msdn.microsoft.com/en-us/library/aa985896%28v=vs.80%29.aspx
That was a fun week.
The STL classes, like vector<>, have a layout mismatch between the release and the debug builds, caused by iterator debugging support. Your problem behaves exactly like the kind of trouble you get into when you link a debug build of a .lib or DLL in the release build of your application and exchange an STL object between them. Heap corruption and access violation exceptions are the result.
Triple check your build settings and ensure that you only ever link the release build of the .libs in your Release build and the debug build of the .libs in your Debug build.
could you try:
void Foo()
{
std::vector<int> blah;
blah.reserve(5);
blah.begin();
}