I have an MFC application which needs to display a webpage. I've added a CHtmlView through CSingleDocTemplate which spawns a window and displays the page fine but it leaks memory when running javascript.
The page I'm looking at is genereated by Madcap flare and so it very heavy with javascript. I'm losing about 4K a second just sitting watching the page.
I've tried to reduce the problem by letting the user close the document but then I run into a problem with not knowing if the CFrameWnd was closed or not in the main application so not knowing if I need to create a new one or just reuse it.
I'm running this on windows 7 with IE9 installed so if I'm right I should be well clear of the old IE javascript circular references bug.
Does it happen in both Release and Debug build? I've seen similar (somewhat deterministic) errors when freeing dangling pointers or blowing the stack. With a bit of bad luck, the undefined behavior from faulty code could produce memory leaks.
Try enabling all possible runtime checks in your build and see if the error goes away (or is somehow detected).
Try commenting out large code blocks and see if the error goes away.
I'm just guessing here :)
Related
I have a C++ program written together with QT5.3.2 + VTK 6.1. The program compiles fine and can run after deployment. Each function button also works fine.
The problem happens when I run this program for weeks (its a motion control software, so it needs to be on for a long time). Randomly(probably not random at all...) it quits/crashes without a frozen window. In another word, the program window just closes and no error message window appears.
I met the memory leak issue before, the program window first froze and the cursor kept busy status and unresponsive. But this time it just closes itself without any error message or unresponsiveness.. Could this also be a memory leak issue?
So I really appreciate it if someone can give me some hint or direction to troubleshoot this issue by their rich experience in programming.
Since there is a lot of code and I do not know where the problem comes from. I will not post code for now but I am happy to include some key aspects:
It uses ADS communication to communicate with hardware drives.
Callback function to fetch the monitoring data and display in QT interface, meaning a lot of actions like LineEdit->SetText() are used repeatedly. SetText() is called with a global qapplication pointer *tp->SetText().
VTK just displays the 3D data. And I separately tested there is no memory leak.
I am happy to share more information if needed.
Memory leak test.
When running my asmjs\emscripten application, compiled from C++, it has suddenly started to log: "run() called, but dependencies remain, so not running" to the web console, and nothing more happens.
I've added some cout's at the absolute start of my main, but even they aren't reached.
The application executed successfully before, but suddenly this started to happen and I don't know what change triggered this.
Does anyone know how to debug this?
Update
After removing as much source code as I could, this happens as soon as I #include , even due my main simply consists of a single cout.
Ideally you would have the entire environment when it was running in version control, and build every version since to see where it broke.
You might have your code in version control, but perhaps not Emscripten itself. If you've updated Emscripten, this could lead to differences in behaviour. I would try going back to whatever version you used when it was running. Note that sometimes various cache directories survive an Emscripten version change, and might need to be cleared manually (I forgot which exactly).
The dependencies remaining could mean that you are trying to do something before Emscripten has loaded any other files it needs to, say files requested by --preload-file or --memory-init-file. Note that according to https://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#faq-when-safe-to-call-compiled-functions you should not try to run any Emscripten functions, until the C++ main function has run. To detect this, you can, for example, call your own Javascript function from main (there are other ways).
The fact this wasn't causing a problem before could have been something that seems quite unrelated: a change or update in the web browser, changing limits of concurrent downloads, or a change in the web server this is running from. You could look in the Network tab in the browser to see if anything leaps out at you as being different or suspicious.
However, as main isn't even reached, then it might not be that. I would try commenting out virtually all of your code, and make it so you have practically nothing but a hello-world program. Perhaps you don't have a correct setting in the Module object, or maybe the request for the memory initialization file is failing (you can check in the Network tab in the browser for that one). If your basic hello world program still isn't working, then you could post again, with its code, in a separate question.
This can also happens when the browser runs out of memory. Unfortunately, the browser's memory handling is not in our control so there isn't much you can do beside reducing your payload. This includes code size, preload content size, etc. Basically anything that can reduce the total memory consumption of your program will help fixing this. Browser vendors are constantly working to improve this, but it's going to take a while still.
I think you haven't given enough information to really know for sure. But it might be for instance that your js suddenly crossed some memory threshold which exceeds what the browser wants to allocate to it. You could try reducing the amount of memory used / streaming some assets instead of preloading them / ship less code / use -Os optimization level?
We have a program which is proving difficult to debug. The MFC application runs fine for a few hours but over a day it will crash. Sometimes it will not throw any errors and simply exit the "dlg.DoModal()" section of our code without the user (or any obvious part of the code) closing the dialog. Other times it will crash and throw an error outside of our code and have a horrendous call stack that has nothing to do with our code, it has a lot of calls to system DLLs however.
A bit of background to our problem.
We are trying to develop a MFC bases C++ application (with a dialog). We have multiple threads and the code is rather large which makes debugging a nightmare. We have been experiencing intermittent crashes that we have been unable to locate the source of so far.
We are well past the use of breakpoints for debugging as we are pretty sure it is an issue somewhere in MFC, maybe not a bug but more a problem with the way we are using MFC.
Now we've tried simple things to help us like:
Enable all debug exceptions:
Debug -> Exceptions and then checking all the boxes so that we can
trap silly mistakes.
This proved helpful but we've now corrected all the errors it throws
within a few hours of running.
Search for memory leaks
We then tried Visual Leak Detector (which works beautifully by the
way) located here: http://vld.codeplex.com/ Our code now reports no
memory leaks so it is not an obvious memory leak issue. We have
included vld.h in the very top of our code near the entry point.
Adding Microsoft Symbol Server to obtain debug symbol files.
We then tried making our call stacks more human readable by using MS
Symbol servers shown in these tutorials:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3f1825e1-6770-48c0-91b0-12d8946ab259/2-how-do-i-configure-visual-studio-to-use-microsoft-symbol-server?forum=vsdebug and http://support.microsoft.com/kb/311503
This ultimately did nothing as it still doesn't tell you enough about any errors.
Using the Thread window to see all call stacks, and using the
Parallel Stack window
We have been using the Thread and Parallel stack windows to aid our
debugging but ultimately they have proved nothing more than pretty
pictures and fancily formatted call stacks that makes you feel good
more than anything. We have been using the tutorial here which has
been very handy
http://www.codeproject.com/Articles/79508/Mastering-Debugging-in-Visual-Studio-A-Beginn
Now for the more interesting things we've tried that do not throw errors straight away but can be detected as problems:
GDI Objects not being destroyed
This one is not obvious in VS2010 as an issue. Basically if you use a call like "CDC* pDC = lChild->GetDC();" and do not use the call "ReleaseDC(pDC);" then you have just created a GDI Object that will not be destroyed until your program terminates. VS2010 is a bit dumb in this regard and will keep creating these objects until your program crashes, and the call stack will look horrible and you will probably have no idea why it has crashed.
To find this issue, start Windows Task Manager -> Click Processes Tab -> Click the View Toolbar item -> Select Columns. Now check Handles, Threads, User Objects, and GDI Objects. Now start your program, find it's process in the list under Image Name, and watch to see if the GDI Objects column keeps growing or stabilizes.
Objects Not being destroyed
This is another not so obvious error, if you create a bitmap like this: "reinterpret_cast(LoadImage( GetModuleHandle(NULL), MAKEINTRESOURCE(IDB_BITMAPNPR), IMAGE_BITMAP, 0, 0, 0))" and assign it straight to a picture control, the bitmap will not be destroyed if you assign another bitmap to this picture control using similar code. Instead you need to assign the above to a HBITMAP variable which you then need to destroy when you are done.
This situation can also arise if you create a font or colour in a similar fashion.
Now with all that being said, we have tried all the methods above and we still can't find our issue. Sometimes our program will exit normally and we won't be given any debug info (this is usually after is has been running overnight), other times our program will lockup the PC (tested on multiple PCs), other times it will throw an error but we can't locate the culprit because it simply points to the ".DoModal()" part of our code and the rest is native windows DLLs which is useless for debugging purposes.
We suspect something is either being created and not destroyed properly but we aren't sure what and VS2010 is not telling us anything useful to point us in the right direction.
Does anyone have any ideas? How do we trap errors that aren't obvious to VS2010? Or rather how do we easily trap "GDI leaks" and the like?
Thanks in advance
Edit:
We've been using Microsoft's Application Verifier, it's found a few errors so far. To use it download it here http://www.microsoft.com/en-us/download/details.aspx?id=20028 run Application Verifier, add your .exe file in your Debug or Release directories and run the program in VS2010 as normal. VS2010 will break when Application Verifier 'sees' an error. It hasn't found anything too outrageous yet so I assume that we still have issues with our code.
Alright, I presented this question on the MSDN forums but have yet to receive any kind of response so I figured I'd give StackOverflow a try.
I'm currently developing a DirectX application using VS2008 on Win7. I recently experienced a nasty memory corruption bug with a memory allocation class that grabbed byte aligned memory. During this bug I could still run the debug and release executables however it would crash due the instructions getting corrupted or whatever, but it would still execute for a bit until the crash.
I then stripped out the entire memory allocation class. The application runs perfectly in the IDE (release and debug builds) but I can't run any of the executables at all. They immediately crash with a non-responding/stop working error. And I don't think it is my environment because I get the same issue on another computer that wasn't having problems before either.
Dependency walker gives a "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." error and indicates that GPSVC.dll and IESHIMS.DLL can't be found. I've read that this can be misleading and just indicates a potential problem somewhere. And Dependency walker wasn't giving me this error the day before.
I haven't tinkered with any of the configuration or project settings or added new code. Any idea of what could be causing this behavior?
Also another note, I installed the Windows 7.1 sdk the same day. Think this could be some kind of compiler related bug?
Just in case some useful information pops up on the MSDN post, here is the link
http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
Thanks!
Edit -
Here is the last couple lines of Dependency Walker's profiling output
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF60 and returned 0x77B60FDB.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF70 and returned 0x77B59D65.
Second chance exception 0xC0000005 (Access Violation) occurred in "c:\users\joel\desktop\DXAPP.EXE" at address 0x0110152E.
Exited "c:\users\joel\desktop\DXAPP.EXE" (process 0x27D8) with code 255 (0xFF).
Is this referring to a DLL grabbing a null pointer or to my actual instructions? Going to read up on how to use WinDbg real quick and I'll post it's output if this doesn't shed any immediate light on the issue.
Edit 2 -
Simply running the application and hitting debug to bring up Visual Studio consistently brought me to where I'm compiling my shaders. I'm assuming at the moment that the root of the problem lies around this. However, I still don't understand the change of behavior during execution between using the IDE and not.
Solution! -
I was so thrown off by the previous memory corruption bug that I didn't realize my shaders weren't in a local directory to the executables. This in turn was generating a null pointer that wasn't handled properly after calling D3DX11CompileFromFile().
Shoot, sorry I meant to post this as a comment...
I can only suggest more diagnostic attempts.
One would be to profile the app from within Depends, this will also show dynamic DLL loads and might show something new. Also it captures the debug output. It may behave differently than launching in the debugger itself and provide a clue. You don't mention actually profiling so I thought I'd suggest it in case you hadn't. Also, pay very close attention to the paths for the DLL's loaded - you might be surprised at a DLL loading from a location other than you intended.
Another suggestion is to try at attach to the stopped app after the crash (before dismissing the error dialog). See if you can get a stack trace or anything out of it.
Finally try attaching (or even launching from) WindDbg rather than the IDE. Like the Depends profile, the difference in debugger behavior and how it hooks the app may allow the crash to happen, while providing the clues you need.
Good Luck!
I don't suppose there is a way to programmatically enable/disable Valgrind memcheck the way you can with callgrind? (Start/stop instrumentation).
It's painfully, unusably slow (which is okay if the code you want to test starts automatically and you just leave it running), but I can't actually get into the code that's important without clicking a few buttons in the app, which is rendered completely unresponsive. (My code is a plug-in to another app)
Thanks
It's pretty nearly impossible in principle. If valgrind doesn't know the complete history of all your memory, how can it know for sure that something is a leak, or even a reference to invalid memory?
You can't stop/start instrumentation but you can programmatically do incremental leak checks. See http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs and specifically VALGRIND_DO_LEAK_CHECK, VALGRIND_DO_ADDED_LEAK_CHECK and VALGRIND_DO_CHANGED_LEAK_CHECK.