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.
Related
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.
I am working on the largest project I've ever worked on, and I've never debugged something like this, so I don't know where to get started.
Some info on the crash:
I am using Visual Studio, and the debugger is completely useless. The only information it gives me is that it appears to be happening during a call to "memcpy". The call stack is completely empty except for the memcpy function, and the local variables are listed but it does not have values for any of them.
It happens occasionally on any computer.
It does not ALWAYS happen under any (known) condition, but it only ever happens under a few conditions. In particular it only happens when a particular type of object is destroyed, although that's not necessarily the direct cause, and investigating the destruction process has not been helpful.
A little more about the project:
It is a game using SFML 2.0, linked statically.
I am not calling memcpy anywhere in my own code.
Some questions:
Where could the call to memcpy be coming from? Is it in SFML or elsewhere?
How do I (using visual studio) get more information on a crash when the debugger isn't working?
This is an answer to "Where could the call to memcpy be coming from?"
In most cases this is the result of a call to the copy constructor of std::string with a this pointer of NULL, or a string operation on an already destructed string. This string can be a member of a class of you, of course.
This in itself won't help you to find the problem when the project is really large. However, you can almost certainly assume that you are using a reference or pointer (or iterator) to a custom object that is already destructed. A most straightforward way to find this access would be by running your program, compiled without optimization and with debug info, in valgrind. Unfortunately that isn't available for windows (see Is there a good Valgrind substitute for Windows?).
The main problem here seems to be that you aren't even getting a backtrace, because that would give a strong hint to where to look into, at least. I'm not familiar with windows though, so I can only guess what is the cause of that. Are you sure you have everything compiled with debug info?
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!
For a while, I've been using a small collection of files I wrote making it easier to interface with WinAPI. Although, it's become a pain to keep moving the files around when I want to reuse them, waiting for them to recompile, etc. I finally decided to just throw them in a DLL, and be done with it, but I'm getting an odd link error every time I try to use the library.
The error is really as specific as the title, providing little information about where the definition actually originates(considering, that kind of information can't really be collected from a DLL, as far as I'm aware). Could someone please explain exactly what would cause this error, as well as providing some possible fixes to the problem?
I'm using MinGW(the same version provided by the SFML site, 4.4) along with Code::Blocks, if that information helps any. If any more information is required, I'll do my best to provide it.
The problem is that there are multiple definitions for a symbol (function or variable) named _Unwind_Resume.
The DLL is exporting such a name. Rebuild it so that it only exposes desired symbols. Apparently, it is now built with all public symbols being exported.
Good morning all,
Forgive me if the title is not too clear, I'll try to explain more here:
I am currently working with the ASI for VBS2. VBS2 executes functions from a VBS2 DLL plugin. I have my own application which I want to use to modify variables within that plugin whilst it is being used, to change what is being executed by VBS2. I began by, foolish as it may be, directly changing the variables with my application whilst the VBS2 program was running.
When this did not work I tested and found that the VBS2 program was using a different instance of the "message" object, in which I was storing the variable, to the one being accessed by my application.
What I would like to do is have my application access the same instance of the object being accessed by VBS2. I have experimented a bit with
#pragma data_seg(".testseg")
Message msg;
void foo(...); //etc.
#pragma data_seg()
but for some reason or another it still appears there are two instances being used.
I would greatly appreciate any and all help, and would add that C++ is a new language to me so please be gentle. :)
Thanks,
M
You need to use linker flags to tell the linker to place that segment in sharable memory.
See http://msdn.microsoft.com/en-us/library/ms933104.aspx
I belive you need to add something like
#pragma comment(linker, "/SECTION:.testseg,RWS")
to your program.
I'm not sure, this may only work in a DLL...
If I understand correctly what you want, you can't do this with standard C/C++ tools. Your program and the other program live in separate memory spaces and they are completely insulated from each other. If your program has administrative privileges, you can attempt to read & write the memory space of the other process using WriteProcessMemory():
http://msdn.microsoft.com/en-us/library/ms681674%28v=VS.85%29.aspx
But then there's a problem of finding the right object in that memory space.
It's not clear whether you have the source for the plugin. If you do, there are other interprocess communication techniques that can be utilised. None as simple as just changing the variable, unfortunately.