I'm making game engine in c++ which is compiled into dll. For last 2 weeks i was doing very boring cleaning of code to make it easier to use, unfortunantely didnt make any backup. Now when i put call to any function from that dll inside executable code it shows error window, when executable starts, which tells error code 0xc0000142. Compiler doesnt show any warning that could lead to this, no linking error, nothing. I have no clue what could do this. I'm using linker to link dll instead of loading it dynamically. Does anybody know what can trigger this error?
if not delay-load, when you load the process, the dll will also be brought to memory. so this error happens.
How to tackle?
I suggest you to make a fresh plain executable with just basic code and insert this dll. try it.
if successful, insert a function call on a non-functional code (should not be called on startup) and try it.
if the above succeeds, try to add the function call on functional code and try it.
if works means simple DLL is clean.
Then what happens to your original exe, there is a good chance that the a bad copy of DLL is placed in PATH. it is causing the error.
if anything fails in between, you can figure out the issue from DLL. in that case, I suggest you to comment out all code with a fresh blank function. DllMain way next.
sorry for the 'open ended' answer. but for debugging I think you need some pointers to think. you are the one ultimately going to find the result. please post the findings.
Good. Usage of exception is good in scenarios like construction. It does not add much performance overhead when things go well. But neat when nasty things happen. especially good when you give the code to others to maintain.
Related
I migrated a project from Qt4 to Qt5, and it compiles and everything but the application crashes before it even reaches the main function. I know there is a null value that fucks up something at some point, maybe a file that cant find or something, but there are so many .cpps and .h and libraries that its pretty hard to locate the source of the error plus I cant set any breakpoints. I have a lot of debugging data so maybe any of you can guide me in the right direction. I dont know what I would be doing without stack overflow honestly, so thankyou in advance.
When debugging I get different crashes:
The stack in each case shows different crashes, but all of them have something in common, which is this __do_global_ctors thingy, I have researched and apparently it has to do with constructors, but I have no idea what I should be looking for.
if I missed any info please do ask. I hope someone can enlighten me, I am so so close to get this working.
The __do_global_ctors() is called before your main(), as the framework needs to instantiate all of the global objects that main() might use.
This method will call the constructors for all static objects, and their component objects. I.e. all static constructors.
From the look of the stack trace, it appears that the segfault occurs during the construction of a QGlobalStatic<QMutex, [incomlpete types - see trace for details]> object, which makes sense. This is being constructed by qRegisterResourceData as part of qInitResources_mimetypes.
Try placing a breakpoint in this function in qrc_mimetypes.cpp (if you have the source) and see where that gets you. Or look at the Qt documentation for mimetypes initialisation and make sure you've specified your application's resources correctly.
I managed to solve the issue by thoughtfully re-compiling all the libraries to Qt5 and making sure all the cpps that the program refered were Qt5 too. Also double-checked the linkings. I thought I had done it but apparently I missed one library.
Mind that some libraries need to be migrated and there are others that you can download and compile directly with Qt5. If you are having this same problem make sure that there are no Qt5 versions of that library before migrating them yourself.
First of all, thank you for taking the time to view my question and help. I noticed that a lot of questioners here show little or no appreciation, but I'm sincerely appreciative for the help and the community here :)
I wrote a C++ plugin (compromised of hundreds of source files) for an application I do not have the source code for (it's a video game). In other words, I only have the source code for my plugin, but not the game. Now, somewhere in those thousands of lines in my plugin, something causes the game engine to throw (probably an access violation) and I don't know where. By the time the debugger breaks, the stack is corrupted and all I get are hex addresses for DLLs I do not have the source for (but the exception occurs in my DLL for sure). I tried everything... I just can't seem to find where the exception occurs. Sometimes the debugger points to a "memory relocation" function (which I never used in my plugin), sometimes it points to the engine's GameFrame(), and other times it points to a damage callback (all these are just different member functions of a class).
I tried practically everything... I googled for hours trying to find out how to use other debuggers like WinDbg and Microsoft Application Verifier. I tried to comment out one or the other, or both, where the debugger points, but it still crashes. I even inserted OUTPUT("The name of the last executed function is: %s", __FUNCTION__) into EVERY function in my application hoping to painstakingly catch the last function but it seems any kind of I/O prevents the exception from occurring for some reason... And 10 minutes of debugging and the crash happens at some random last executed function.
I can't find out where this access violation is happening or where some temporary object is removed to cause these bad pointers (I check every pointer before using it), but damn, I'm reaching my limit's end here.
So, how does one debug the impossible... a random crash with a crappy debugger call stack? Thanks in advance for your patient and kind help!
My suggestion: try different debuggers (non MS), they catch different things.
My experience: a program I have source code and full debugging symbols corrupt the stack, VS nor WinDbg can help but Ollydbg comments a non-string var with the value "r for pattern.", so I had overwrote some string buffer onto this var. Also Ollydbg have option to walk the stack the hard way (not using dbghelp.dll)
From my experience, the old adage "Prevention is better than cure" is very relevant. It is best to prevent the bugs from creeping in, by following good software development practices (unit tests, regressions, code review, etc.) than to work it out later once the bugs show up.
Of course, real world is not perfect, and bugs do show up. To debug memory corruption, you have some nice tools like valgrind, which at least narrow down the problem sections for you to take a closer look at. Debugging a complex program is not easy, and if your debugger throws up, it requires a lot of persistence on your part. One technique I find useful is to selectively enable or disable certain modules, to narrow down the module has the problem.
Sometimes you need to use "referential transparency" to unload some modules. To give you a stripped down example, consider:
int foo = factorial(3);
If I suspect there's a problem in this code (and the debugger crashes before I can see the call stack), I have to try by removing this code, and see if the problem persists. However, foo may be used later, so I cannot just remove it. Instead I can replace it with int foo = 6; and continue.
Another important point is to always maintain a trace file, where your code keeps logging what it is doing. When a program crashes, the trace file can often help narrow down the problem. Of course, you disable the tracing by default, so that it doesn't cause a performance bottleneck.
COM+ application, building with MS Visual Studio 6, SP 6 on Windows XP SP 3, and debugging remotely.
My main question is this; why would I not be able to step into 'new' if I can step into 'delete'? I'm mostly looking for ideas as to what I should look into.
I'm working on a fairly large project that I'm only just getting familiar with. The current issue is a heap corruption problem in which a release build will eventually exhaust its working set and crash. The problem is so pervasive that the following code will corrupt the heap:
int * iArray = new int [100];
delete [] iArray;
I say 'corrupt the heap' because the debug output displays "heap[dllhost.exe]: invalid address specified to rtlvalidateheap" on the 'delete'.
I can step into the 'delete' call fine and it seems to be calling the proper one (located in DELOP.cpp in ...\Microsoft Visual Studio\VC98\CRT\SRC) but, for whatever reason, I cannot step into any call to 'new'. I'm grasping at straws here but I have a feeling somewhere in the code base someone overrode the 'new' operator and the code I'm looking at is unintentionally using it. The symptoms of the release build seem like memory is being allocated to one heap and attempted to be deleted from another, at least that's my hunch.
EDIT:
Ack! Sorry everyone, I posted too soon, should have given more info.
I've searched the code base and found a few overrides but they are all in classes, not globally defined. The only one that isn't in a class is the following:
struct _new_selector
{
};
inline void* operator new(size_t, void *ptr, _new_selector)
{
return (ptr);
}
But that's a placement new and I'm pretty sure it doesn't count in this situation. What is the library that I should be stepping into for the original 'new'? I'm guessing it's the same as the 'delete' but if not, maybe I just don't have debug info for it?
EDIT 2:
Messing around with this I've found that on a debug build this issue does not exist. I've already looked into the run-time libraries, it's using /MD and /MDd for debug. Not only that, but I've built the release version with /MDd jut to make sure and there was still no change. Looking at the maps of both a debug build and a release build the new operator (with it's mangling) is at the following:
Release:
0001:00061306 ??2#YAPAXI#Z 10062306 f MSVCRTD:MSVCRTD.dll
0002:00000298 _imp??2#YAPAXI#Z 1006e298 MSVCRTD:MSVCRTD.dll
Debug:
0001:00077d06 ??2#YAPAXI#Z 10078d06 f MSVCRTD:MSVCRTD.dll
0004:00000ad4 _imp??2#YAPAXI#Z 100b5ad4 MSVCRTD:MSVCRTD.dll
I also checked the delete operator:
Release:
0001:000611f0 ??3#YAXPAX#Z 100621f0 f msvcprtd:delop_s.obj
Debug:
0001:00077bf0 ??3#YAXPAX#Z 10078bf0 f msvcprtd:delop_s.obj
Also, and I don't have a print out of them but I can get it if it would help, the disassembly of the new operator looks the same in release and debug. So I guess it's not an override? Would an inline override of an operator make this untrue?
Also, being a COM+ application which spawns multiple dllhost.exe processes, would it be possible for a call to the new operator go to another DLL, or the exe, and a call to delete go to the opposite?
Going with your hunch that there is possibly an overloaded new somewhere in the code, few things you can check
the disassembly of the code and find out the library name in that file, generally there is something in the assembly that will give you a hint
If you are not able to find out the library name, check the address in the assembly that you are entering. Then in the debug output window, check the load addresses for the various libraries - that could give you a clue as to which library to check
If the above doesn't help, check if you can generate a map file for the complete project. If you can, then you can look up the address in the map file and that might help
Try to use the debug version of the runtime libraries. Can't recollect what was the option that will turn on the debug_malloc. That can help you figure out what is happening on the heap
The community can add a few more that I might have missed. And finally, if you do crack the problem, please share how you did so. Either here or as a link to your blog. Working on heap problems for a large project is generally not easy and we all can learn a new trick or two.
Ok, so here is what it ended up being.
The program I'm working on has about thirty or so projects within it. Some create libs, others dlls, still others exes. In any case, it's all intermingled. Add into that the fact that we use ATL and COM and it starts getting crazy pretty quick. The end result is that some, not all, of the projects were being built with the _ATL_MIN_CRT compiler definition, even though this is a desktop application, not a web based one in which a client would need to download a few modules.
Here is some info on _ATL_MIN_CRT:
• http://support.microsoft.com/default.aspx?scid=kb;EN-US;q166480
• http://msdn.microsoft.com/en-us/library/y3s1z4aw%28v=vs.80%29.aspx
Notice, from the first link, that this also will eliminate the use of memory allocation routines. I’m unsure what the original motive behind using this was, or if it was really intentional, but it certainly causes issues with allocating memory. Also, this only affects Release builds, hence why it was such a pain to find.
Basically, module A was built with _ATL_MIN_CRT and module B was built without it but had a dependency to module A. Since this is also using COM and everything was run in dllhost.exe, when module B tried to use the new operator it seems to have gone out of its dll to attempt to allocate memory on the heap. Then, when calling delete, it tried to delete it within its dll. Thus, we have a crazy memory leak.
Mind, removing _ATL_MIN_CRT fixes this but what I mention above is only my understanding of it. It may very well be more/less complicated but, regardless, this was the issue.
Thanks to everyone's suggestions, they really did help me find this thing!
Someone has reported a bug in my program, which brings up the following error message:
The error occours in a C++ DLL of the program, which was compiled by VS2008. I can reproduce the error, but am not able to find out what´s the problem. I´ve already done a bunch of tests for memory leaks or wrong alloctions, but with no success.
Now the weird thing: when I add a main function to the code, compile it as an EXE and then run the exactly same thing, all is ok. The error occours only as a DLL.
The next strange thing is, that when I press "Ignore", the program continues and does its job as expected.
So, I´m looking for 2 types of answers:
- Answers that help me find the bug
- Answers that help me to "auto-ignore" or hide this errormessage, so that it does not occour. That would be ok, since there is no difference in the result.
I´m thankful for any help or advise.
Thanks!
Update
Like Joachim Pileborg said, I´ve created a simple test c++ project, that calls my DLL, and it works perfectly! The program that normally calls the DLL is written in DELPHI, so I think it could be a bug of DELPHI... Weird: The call of the DLL works for 99.9999..%, but in one specific case, there occours an error IN the Dll. It´s not the call that fails... Really, really strange story :S
Ok... that is a negative number. The simpler thing... perhaps your code is doing a malloc with an invalid\negative size?
The strange thing is that that number in binary is 11111111111111111111111111111100, probably your size calculation is wrong. It can be however a more complicated error, for example due a buffer overflow.
You should not ignore this error at all, can be a symptom of a more complicated and dangerous error.
Try to debug your allocation, try to get exactly the piece of code that is doing this invalid allocation.
You can overload the new operator or redefine the malloc replacing them your debug functions where you can check the passed arguments (size).
4294967292 - that is (unsigned)-4. You are either doing some computation of the size to be allocated wrong, some integer has overflown or somesuch.
I'd try to put a breakpoint on malloc (or whatever allocation function that is) and check where does the bad value come from.
Through the debugger, I was able to see the call stack, and what function in the code displayed the error. After searching for this routine, I could find out how to disable displaying it.
I had a question about debugging in Visual Studio (2010 if it actually matters). Sometimes I am running an application and I want to break out of it to debug or to see where it has hung, etc. However, I find that very very often the "break-out point" seems to be in some random .c file in the standard library. I understand why this is (its executing some method somewhere), but I want to know where the last point it was in the code I have written is. Is there a way to do this?
If I try and "step", the debugger seems to always return something like "there is no code to debug for the current location" or something, which I am guess means that it is making its way through some machine code. Again, that's fine, but I want to know what the last executed call in my main.cpp file was; is there a way to get this information? The call stack doesn't seem to help either, it always has a list of non-sensicle calls and even if I can locate the latest point in the call stack that is from my main.cpp, it doesn't seem to provide any useful information (like a line number or a function name... I
think it's showing the mangled name).
What do most people do in this situation? I apologize, I know I'm a beginner, and I'm sorry I don't have a concrete example, but I feel I see this often at work.
Any help appreciated, thanks!
K
Once you've paused the program observe the call stack (Debug->Windows->Call Stack) at that point, find where the last layer of your code is and get there by clicking on the corresponding line in the call stack window.
The "Step Out" command, Shift+F11, will finish execution of the current function and break immediately after the return.
You can use Step Out a few times to step out of the system calls back to your code.
The "Step Into Just My Code" option sounds like it may do what you want, but I've never used it.