For some reason the integrated debugger is causing an error as soon as I make reference to a third party vendor's dll class. This same code runs when it is built and ran as a release, stand alone. The two properties for debug and release should be the same as I have not really altered them. I added the lib file to the path for both builds. I simply have:
ClassNameFromDll blah;
When it gets to here, I get this exception:
Unhandled exception at 0x78a3f623 (mfc90ud.dll) in MTGO SO Bot.exe:
0xC0000005: Access violation reading location 0xf78e4568.
It occurs in: afxtls.cpp, line 252.
This is an MFC app, but I am not really using any MFC other than a very simple gui which fires off an event that is all win32. I am using Visual Studio 2008 Express.
Looking at the atltls.cpp file from my VC9 install, the crash is occurring here:
inline void* CThreadSlotData::GetThreadValue(int nSlot)
{
EnterCriticalSection(&m_sect);
ASSERT(nSlot != 0 && nSlot < m_nMax);
ASSERT(m_pSlotData != NULL);
ASSERT(m_pSlotData[nSlot].dwFlags & SLOT_USED); // <== crash
// ...
}
So the reason the crash doesn't occur in release build is because the ASSERT() is a no-op in that build. I'm not familiar with ATL's use of thread local storage, but this assertion indicates that something is asking for a value in a slot where nothing has been stored yet.
Whether the initialization of that TLS slot is your responsibility or the 3rd party DLL's responsibility, I don't know.
It looks like GetThreadValue() has some additional protections such that it'll return a NULL pointer in the release build for an uninitialized slot (though I'm not sure that this would be guaranteed) - I'd bet that the 3rd party DLL relies on that behavior (ie., it checks for a NULL return) so no crash occurs in release builds. Note that the vendor might be using the CThreadSlotData class indirectly (the stack trace would give a clue about this), so they might not be aware of its expectations.
engaging psychic debugging
The fact that it runs in release mode fine and crashes in debug mode leads me to believe that you've somehow managed to reference, specifically, the release version of that DLL (mfc90u.dll), rather than referencing the library itself and allowing the linker to decide which version to import.
You may not be using MFC for anything in this app, but if it's building as an MFC application, you will get all of the MFC stuff whether you want it or not (which means you also have to solve the MFC dependency problem and ship the MFC DLLs with your app).
Do you have a stack trace you can post? It might have some helpful information.
If the 3rd party DLL is still actively supported by the vendor, then the first thing you should do is see if you can have the same problem occur with a very simple program that you can send to the vendor and ask them to fix it.
If the vendor is not available or responsive enough:
If you have source of the 3rd party DLL and can easily build your own version, you have probably the best way to debug this (short of getting the vendor to support you). Even if you cannot easily build a source-debuggable DLL, you can trace into the constructor's assembly instructions and use the source as a map to help you understand what's going on.
Even if you don't have source for the 3rd party DLL then I think the best course of action is to trace through the constructor for ClassNameFromDll to try to figure out whats going wrong. It might help to compare the instructions path in the Debug build vs. the Release build.
MFC source is distributed with MSVC (probably not with the Express version, but I think with all other versions) so when you get in to the MFC DLL's code you might find the source to be useful in helping to figure out what's going on.
Related
I am reproducing the following behavior in VS2008 (native C++):
attach to an executable that consumes a custom dll (for which I have the source)
debug the code from the dynamic lib
encounter an access violation error (probably caused by the code in the executable - closed source)
break on access violation error with the attached debugger
After this, no matter how many times I reattach, rebuild, restart the application, computer, any breakpoint I will set in the .dll source code becomes inactive (No executable code associated with this line is the alleged cause, according to VS).
I suspect this is an issue with VS2008, as I did the same on a different machine and now I have two machines where debugging is no longer possible.
Are there any recorded solutions of this issue? What can be done to overcome it?
What I have done:
deleting everything (the entire solution, pdbs, binaries, etc.) and starting with the code from scratch (cloning the latest version from the repository)
restarting the machine
changing the machine (it worked once, until the error occurred, then the other computer exhibited the same behavior)
What I cannot do:
change compiler/VS version
debug the executable (sadly no source code available and lack of assembly skills)
The root of the issue was more subtle. Although the project was intended to be native C++, I have found that on the configuration I was testing the code, the entire project was built with CLR support.
When attaching to the application the first time on any machine, in native debugging mode, the breakpoints would trigger. However, when encountering the native access violation error, these breakpoints became permanently inactive thereafter. After deciding to check what happens if I let the debugger attach in auto mode, I have discovered that the breakpoints became active and hence found out that all code had been compiled with the /clr flag except for the entrypoint in the consumed dll, which had no CLR support.
The question here is why VS2008 behaves like this and does not directly disable breakpoints whenever one attempts to debug a managed context using native debug settings.
TL;DR: check if your C++ project is built with CLR support and attach either as native or managed, depending on your needs. Alternatively, if only some of your files require C++-CLI usage, enable the /clr flag only for those. It is more often a better choice since C++-CLI often clashes with certain native libraries (e.g. not std::mutex support, linking against native static libs Linking unmanaged C++ DLL with managed C++ class library DLL, etc.).
I've done some searching and seen questions similar in nature to mine, but none that quite hit the nail on the head of the issue I'm having.
I'm making C++ game in Visual Studio (with the Allegro 5 library) and encountering difficulty running it on other computers. I'm well aware of the 'MSVCR##.dll is missing from this computer' issue, but what I'm wondering is why I'm unable to run my Release build because I'm missing the MSVCR##'D'.dll on a certain computer, when I was under the impression that the 'D' suffixed .dll was exclusively required for running the debugger. I've checked in my configuration manager for release build settings and I have 'Generate Debug Info' set to No, which I thought was the only thing I needed to do. My question I guess is whether or not there are any other settings I need to configure to make sure my Release build isn't looking for the MSVCR##D.dll. Thanks in advance anyone who has any info!
You're a bit confused about the use of the *D libraries. They're indeed used for debug builds, but debug builds differ in multiple ways from release builds. For starters, debug builds by default come with a *.PDB file that contains all the function names (This is your "Generate Debug Info" option). A debugger looks into the .PDB file to find a readable name for a crash site.
Another debug option is to not inline code - this keeps your named functions intact. Inlining may put that single finction inside three other functions, which complicates debugging a bit.
Finally the Debug CRT includes functions that perform extra error checking against bad arguments. Many functions exhibit Undefined Behavior when passed a null pointer, for instance. The Debug libraries will catch quite a few of those, whereas the Release versions assume you pass valid pointers only.
Now DLL's can reference each other; there's a whoel dependency graph. That's why the Dependency Walker tool exists: it figures out which DLL's rqeuire which other DLL's, and this will tell you why you need the *D version.
Thank you very much for all your inputs, I was able to learn a fair bit from this. It turns out the issue was (of course) entirely my fault, as when setting up the Allegro 5 dependencies in the project settings (under General->Linker) I was accidentally including a dependency for the debug version of the Allegro monolith-md.dll as well as the non-debug version in my Release build, and that .dll was in turn referencing the *D version of the MSVCR .dll. The issue has been resolved by removing that dependency from the Release build of my game.
Install dependency walker on that machine. Load the exe. Check if any of the dependent dlls are missing.
I am writing a program using OSG and I would like to step through it to see how stuff works, change a few lines and debug again. However every time I need to load a file using osgDB plugin for openflight. The debug version of the plugin works quite slow. I have no intention of debugging the plugin itself, so I figured I might as well use the release dll. I read that I can do this as long as there are no memory allocation in program and freeing in dll or visa versa and if the dll was designed to avoid problems that might occur with release/debug mixing. I'm not sure if osgdb_openflight.dll was designed like that.
My question: can I use the release plugin dll in my debug build, and how can I make my program use it?
UPD: I achieved my goal following the #XenonofArcticus's advice.
Some additional thoughts on the topic for the sake of better understanding:
I also tried to simply rename the release dll, so it would get loaded in the debug build. (I thought this would work, because I usually use release dlls in debug builds - Windows's, SQL's and other 3rd party dlls, that do not come with debug info. Also see Igor Tandetnik's comments on this question). It did and the program didn't crash, however it also didn't load the file. Apparently this particular dll wasn't designed to be used in debug builds. Any other explanation?
I'm not sure you're going to achieve what you want trying to mix debug and release. However, perhaps it would work to build a release with debug symbols target? This can allow you to do SOME debugging, but it's still a release build and behaves like one.
I have a MFC project that uses libpqxx. All settings are default.
Release mode is working properly as i expected. But when i switch to Debug mode, it shows an exception and says Debug Assertion:
The most interesting thing is, If I use Shared DLL instead of Static (on Debug of course) it works!
Basicaly, Debug with Static Library shows this exception/error. If i switch to Shared DLL it works again. Of course i can use shared as debug and static as release but Is this the right thing?
Note: This project is base and fresh. I did not changed any config from Configuratrion Manager.
Any suggestion?
Alright, I am not sure if libpqxx uses MFC or not (and which one?). I suspect that you are allocating some memory from one heap, and de-allocating it from another heap. Mixing MFC versions, as well as Static/non-Static mixture of MFC will cause this assertion.
Do not treat it as working on Release build! It is just not defending itself (i.e. now showing any assertion message). Your best bet is to locate the cause of this problem, and first one goes by looking-up the call stack (hit Retry on this assertion dialog).
See, if libpqxx depends on MFC, or it disallws mixing Static version of MFC. You can either see the documentation of libpqxx, and/or use Dependency Walker to see if library is using MFC.
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();
}