Related
Its easy to create a block of GPU memory in CUDA/OpenCL that persists over multiple GPU calls. But how is that done in Visual Studio AMP? The best I've seen is an incorrect answer on another site that says just make local references to host-persistent data. But I know that's wrong because it would still do a host-to-GPU copy every time you instantiate the reference, right?
Surely Microsoft wouldn't go to all the trouble of developing AMP and then neglect a thing that makes it worth using! Any thoughts or ideas welcome.
I'm using Visual Studio 2015 C++11.
I have a fairly complex (approx 200,000 lines of C++ code) application that has decided to crash, although it crashes a little differently on a couple of different systems. The trick is that it doesn't crash or trap out in debugger. It only crashes when the application .EXE is run independently (either the debug EXE or the release EXE - both behave the same way). When it crashes in the debug EXE, and I get it to start debugging, the call stack is buried down into the windows/MFC part of things, and isn't reflecting any of my code. Perhaps I'm seeing a stack corruption of some sort, but I'm just not sure at the moment. My question is more general - it's about tools and techniques.
I'm an old programmer (C and assembly language days), and a relative newcomer (couple/few years) to C++ and Visual Studio (2003 for this projecT).
Are there tricks or techniques anyone's had success with in tracking down crashing issues when you cannot make the software crash in a debugger session? Stuff like permission issues, for example?
The only thing I've thought of is to start plugging in debug/status messages to a logfile, but that's a long, hard way to go. Been there, done that. Any better suggestions? Am I missing some tools that would help? Is VS 2008 better for this kind of thing?
Thanks for any guidance. Some very smart people here (you know who you are!).
cheers.
lint.
C/C++ Free alternative to Lint?
I've not done C++ professionally for over 10 years, but back in the day I used Rational PurifyPlus, which will be a good start, as is BoundsChecker (if it still exists!) These products find out of bounds accesses, corrupted memory, corrupted stack and other problems that can go undetected until "boom" and then you have no idea where you are.
I would try these first. If that fails, then you can start typing in logging statements.
If the debugger mitigates the crash, this can be for these reasons:
memory corruption: under a debug build memory is allocated with space before an after, so rogue writes may not corrupt under a debug session
timing and multi-threading: the debugger alters timing of threads and can make tricky multi-threaded problems hard to nail down.
If it's memory corruption, a memory tracking/diagnostic tool (I used to use BoundsChecker to great effect in the good old days of C++) may help you to locate and fix the cause in minutes, where any other technique coud take days or even months.
For other cases, you've suggested another approach yourself: a sometimes labour-intensive but very effective approach to getting a "real" stack trace is to simply use printf - a vastly underrated debugging tool available in every environment. If you have a rough idea you can straddle the crash area with only a few log messages to narrow down the location, and then add more as you home in on the problem area. This can often unearth enough clues that you can isolate the cause of the crash in a few minutes, even though it can seem like a lot of work and perhaps a hopeless cause before you start.
edit:
Also, if you have the application under source control, then get a historical version from when you think it was working, and then do a binary chop between that date and "now" to isolate when the issue began to occur. This can often narrow down a bug to the precise checkin that introduced the bug, and if you're lucky it will point you at a few lines of code. (If you're unlucky the bug won't be so easily repeatable, or you'll narrow it down to a 500-file checkin where a major refactoring or similar took place)
Get the debugging tool kit from MS ( http://www.microsoft.com/whdc/devtools/debugging/default.mspx ).
Set adplus up for crash mode monitoring ( http://www.microsoft.com/whdc/devtools/debugging/default.mspx ).
This should get you a crash dump when the app crashes. Load the dump up in WindDbg from the debugging toolkit and analyze using that. It is a painful, but very powerful, process to anaylyze out-of-debugger crashes.
There are quite a few resources around for using WinDbg - a good book on general Windows unmanaged debugging and the tools in the debugging kits is: http://www.amazon.com/Advanced-Windows-Debugging-ebook/dp/B000XPNUMW
I couldn't recommend more the blog of Mark Rusinovich. Absolutely brilliant guy from whom you can learn a whole bunch of debugging techniques for windows and many more. Especially try read some of the "The Case of" series! Amazing stuff!
For example take a look at this case he had investigated - a crash of IE. He shows how to capture the stack of the failing thread and many more interesting stuff. His main tools are windows debugging tools and also his sysinternals tools!
Enough said. Go read it!
Also I would recommend the book: Windows Internals 5. Again by Mark and company.
Might be that you have a too big object on the stack...
Explainations (from comments):
I gives this answer because that's the only case I've seen that a debuger (VS or CodeWarrior) couldn't catch and seeemed mysterious. Most of the time, that was the big application object that was defined on the stack in the main() function, and having members not allocated on the heap. Just calling new to instantiate the object fixed the obscure problem. Didn't need to get a specific tool for that in the end.
My experience is that sometime indeed program launched by the debugger (release or debug mode) don't crash as they do when launch on their own.
But I don't recall a case when the very same program launch on it's own, and then attached and continued through a debugger don't reproduce the crash.
An other and better approach if the crash doesn't always happens, would be to be able to produce a minidump (equivalent of unix coredump) and do a postmortem analysis,
there are plenty of tools on windows to do that, for example look at:
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx?df=100&forumid=3419&exp=0&select=1114393
(perhaps someone may have a better link that this one).
Anyone know of a profiler and leak detector that will work with VS2010 code? Preferably one that runs on Win7.
I've searched here and in google. I've found one leak detector that works (Memory Validator) but I'm not too impressed. For one thing it shows a bunch of menu leaks and stuff which I'm fairly confident are not real. I also tried GlowCode but it's JUST a profiler and refuses to install on win7.
I used to use AQtime. It had everything I needed, memory/resource leak detection, profiling various things, static analysis, etc. Unfortunately it gives bogus results now.
My main immediate issue is that VS2010 is saying there are leaks in a program that had none in VS2005. I'm almost certain it's false positives but I can't seem to find a good tool to verify this. Memory Validator doesn't show the same ones and the reporting of leaks from VS doesn't seem rational.
For finding memory leaks you can try Visual Leak Detection tool.
Noah, as Ori mentioned, DevPartner Studio from Micro Focus has both leak detection and other runtime profiling features. Unlike the lofty prices DPS had under Compuware, you can now license just the runtime profilers and not the whole suite if that's what you need. Shameless plug: I work on the DevPartner team. Our 64-bit application support ships in the 10.5 release on February 4, 2011. Look for release news and eval downloads on http://www.DevPartner.com.
Personally, I'm fond of DevPartner. If you work in a big company, maybe you can convince them to pay for the hefty license. It's expensive, but it's very very sturdy.
I used several commercial alternatives and although they can deliver fantastic results, they also often simply fail to work because of unknown reasons:
Rational Quantity: fantastic product for performance profiling, but they failed to release new versions during several years, and often (in my case) the software often refused to work
AQTime: also very good (less than Rational Quantity) but also sometimes refuses to work for unknown reasons.
Performance validator: same
In the last years I returned to the rather crude way of sampling the application. This is not as perfect as using instrumentation, but it's much faster, can be run on any application and always works. My favorite is "Very Sleepy" (http://www.codersnotes.com/sleepy) but also Luke StackWalker (http://lukestackwalker.sourceforge.net/) is quite good. Because the applications can be run immediately and without a noticeable slowdown, the "change app, profile" loop is very short and efficient.
For finding memory leaks, there are several tools in Windows that you can use. Again, they are far from perfect, and often can only investigate running applications from the outside, not simply reporting leaks at the end of the application. Look for the "Microsoft Debugging Tools" (UMDH, LeakDiag, gflags). Personally, I find it much easier just to write my own memory manager, and let it report the leaks at the end of the application. It's not that hard to write. What you have to do is:
Implement the correct new and delete operators (I think you should implement 4 new and 4 delete operators)
In the implementation of new, get the call stack (look for StackWalk) and store this with the allocated memory.
Make a class that starts your memory manager in the constructor, and report all the leaks (including the call stack) in the destructor.
Make a global variable of that class-type. It might be needed to make it a special global variable using a #pragma(init_seg).
There's really simple and easy to use Leak Detection code here too: http://www.codeproject.com/kb/cpp/MemLeakDetect.aspx
Not sure how to link to this, which I previously posted in response to a similar question:
You can use umdh.exe to capture and compare snapshots of the process before and after leak happens. This works best with Debug binaries but is viable with Release provided symbol paths are correctly set - it will give you the callstacks of memory allocated between the 1st and the 2nd snapshot.
http://support.microsoft.com/kb/268343
This approach has the advantage of being free.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I was looking into Valgrind to help improve my C coding/debugging when I discovered it is only for Linux - I have no other need or interest in moving my OS to Linux so I was wondering if there is a equally good program for Windows.
As jakobengblom2 pointed out, valgrind has a suit of tools. Depending which one you are talking about there are different windows counter parts. I will only mention OSS or free tools here.
1. MemCheck:
Dr. Memory. It is a relatively new tool, works very well on Windows 7. My favorite feature is that it groups the same leaks' allocation stacks in the report.
http://code.google.com/p/drmemory/
I have also used UMDH( http://support.microsoft.com/kb/268343 ) and found it quiet useful and easy to setup. It works from Win2000 to Win7.
AppVerifier is a must have swissknife for windows native code developers, its "memory" checker does similar job
http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx
2. Callgrind:
My favorite is verysleepy ( http://www.codersnotes.com/sleepy ) It is tiny but very useful and easy to use.
If you need more features, AMD CodeAnalyst™ Performance Analyzer is free:
http://developer.amd.com/documentation/videos/pages/introductiontoamdcodeanalystperformanceanalyzer.aspx
Windows Performance Analysis tools is free from Microsoft, not very easy to use but can get the job done if you are willing to spend the time. http://blogs.microsoft.co.il/blogs/sasha/archive/2008/03/15/xperf-windows-performance-toolkit.aspx
Download:
http://msdn.microsoft.com/en-us/performance/cc752957
3. Massif:
Similar(not quite exact match) free tools on windows are:
VMMap from sysinternals : http://technet.microsoft.com/en-us/sysinternals/dd535533
!heap command in windbg : http://hacksoflife.blogspot.com/2009/06/heap-debugging-memoryresource-leak-with.html
4. Cachegrind:
Above mentioned Windows Performance Tools has certain level of L2 cache miss profiling capability but not quite as good and easy to use as Cachegrind.
5. DRD:
Haven't found anything free and as powerful on Windows yet, the only free tool for windows I can find that is slightly close is the "lock" checker in
AppVerifier:
http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx
Why not use Valgrind + Wine to debug your Windows app? See
http://wiki.winehq.org/Wine_and_Valgrind
(Chromium uses this to check the Windows version for memory errors; see
build.chromium.org
and look at the experimental or memory waterfalls, and search for wine.)
There's also Dr. Memory, see
dynamorio.org/drmemory.html
Some more good commercial tools:
Purify
Insure++
For Visual C++, try Visual Leak Detector. When I used it, it detected a memory leak from a new call and returned the actual line in source code of the leak. The latest release can be found at http://vld.codeplex.com/.
Development environment for Windows you are using may contain its own tools. Visual Studio, for example, lets you detect and isolate memory leaks in your programs
i would like to list some tool , hope will be useful
read this article for more detail
Purify
Bounds Checker
Coverity (basically its a code analyzer but, it will catch memory leak in static )
Glow Code
dmalloc
ccmalloc
NJAMD
YAMD
Valgrind
mpatrol
Insure++
Try DUMA
There is Pageheap.exe part of the debugging tools for Windows. It's free and is basically a custom memory allocator/deallocator.
See http://support.microsoft.com/kb/286470
In combination with Visual Studio I generally use Visual Leak Detector or simply _CrtDumpMemoryLeaks() which is a win32 api call. Both are nothing fancy but they get the job done.
I had the chance to use Compuware DevPartner Studio in the past and that was really good, but it's quite expensive.
A cheaper solution could be GlowCode, i just worked with a 5.x version and, despite some problems in attaching to a process i needed to debug, it worked quite well.
I've been loving Memory Validator, from a company called Software Verification.
Viusual Studio can help detecting memory leaks itself. See Microsoft Visual C++ Tips and Tricks -> "Memory Leaks" section.
See also this post in SO
Although real tracing is only possible with the Team Edtion of Visual Studio.
See the "Source Test Tools" link on the Software QA Testing and Test Tool Resources page for a list of similar tools.
I've used BoundsChecker,DevPartner Studio and Intel V-Tune in the past for profiling. I liked V-Tune the best; you could emulate various Intel chipsets and it would give you hints on how to optimize for that platform.
Does Jochen Kalmbach's Memory Leak Detector qualify?
PS: The URL to the latest version is buried somewhere in the article's comment thread.
LeakDiag, UMDH, App Verifier, DebugDiag, are all useful tools to improve robustness of code and find memory leaks.
The Boost Test library can detect memory leaks.
How about the Purify?
Try Intel's Inspector XE product which can help you detect both memory and threading issues: http://software.intel.com/en-us/articles/intel-inspector-xe/
Perhaps CodeSnitch would be something you're after? http://www.entrek.com/codesnitch.html
If you are developing with Borland/CodeGear/Embarcadero C++ Builder, you could use CodeGuard.
More or less all Profilers include checking for memory leaks and show you the stack when the memory was allocated.
I can recommend Intels Parallel Inspector. Simple to use and no recompilation needed. The trial version runs for 30 days.
GlowCode and AtromatedQA also include such capabilites. They all offer free trials.
Compuware DevPartner (aka BoundsChecker) in Contrast needs a slowed down "instrumentation" recompile and the application also runs slower when checking for errors. And BoundsChecker can not work with 64 Bit evsrions at all. We gave up on that tool.
The best tool I ever used is DevPartner BoundsChecker - it's not free but it has an evaluation period.
Another memory tool for your list: Memory Validator.
Not free, but nowhere near as expensive as Purify or Boundschecker.
If you're not afraid of mingw, here are some links (some might work with MSVC)...
http://betterlogic.com/roger/?p=1140
We are just completing a Memory Safety checking tool for Windows, that handles GCC and Micrsoft Visual C (not C++ yet), and are looking for Beta testers.
EDIT June 12, 2011: Not Beta anymore, now production for GCC and Microsoft Visual Studio C.
I found this SF project today:
http://sourceforge.net/p/valgrind4win/wiki/Home/
They are porting valgrind to Windows. Probably in several years we will have a reliable valgrind on windows.
Check out this question: Is there a good Valgrind substitute for Windows? . Though general substitute for valgrind is asked, it mainly discusses memory leak detectors and not race conditions detections.
I used Insure++ which does excellent job in finding c++ memory leaks/corruptions and many other bugs like uninitialized variables, pointer errors, strings etc., It also does visual "Code coverage" and run time memory usage etc.. which give more confident on your code.. You can try it for trail version..
You might want to read what Mozilla is doing regarding memory leaks. One tool in their toolbox is the Hans Boehm garbage collector used as memory leak detector.
You can give a try to RuntimeChecker trial ot to IBM Purify trial..
A free solution would be to use the following code in Visual Studio:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Just write this in the top of all your cpp files.
This will detect memory leaks of your application whenc stopping debug run and list them in the output window. Double clicking on a memory leaks line will higlight you the line where memory is allocated and never released. This may help you : http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
Using Microsoft Visual Studio 98, Microsoft Visual C++ 6.0 SP6
When running under the debugger, there's only one problem. If I pause the program and resume, everything's fine.
The problem? When I hit a breakpoint, my program stops. But not in a good way; execution halts, I'm thrown out of debug mode into edit mode. All's fine until a breakpoint is hit. And I know it's hitting the breakpoint - I see a flash of the little yellow arrow pointing at the right line of code, local variables in the inspect window and the call stack in that window. And then I'm staring at the editor.
This happens in all projects.
I've uninstalled and re-installed MSVC6. It didn't help.
I'm about to start over on a new PC; before I go that far, anyone know what I've done to this one?
Note: MSVC6 is not my choice, but there are reasons. It's the tool I work with. And, we get to target NT4, so given 2008 can't target NT4 and 2005 has issues with MFC and NT4, MSVC6 it is.
Stop beating on VC6. It's old. The STL was updated in 1996 from HP code written in 1994. C++ was ratified in 1998.
What is the code doing when you are breaking? Can you reduce the situation into a simple test. When I try that I usually find the cause. If you can do that so it still happens then I'll take a look at it for you. I too am unfortunate enough to use VC6 for my day to day work.
Visual C++ Express 2008 can't be used in certain situations.
The first thing I would check is if this project does the same thing on other machines. If not, it could be your box is heading south. If not it's the VC6 project itself.
Typically I get goofiness with the debugger when my program is doing something with the hardware, especially the video.
I would recommend turning off parts of your program until you figure out what part is causing this. If your program is small and not doing much it might be that the project is corrupted and needs to get rebuilt. Make a new project from scratch and put your files and settings back in by hand.
Is it specific to the app you're working on or do all breakpoints in any app break the debugger?
Is anything different if you attach the debugger manually after launching the app normally?
Is the device running out of memory and therefore gives up the ghost when it requires the additional memory to stop at the breakpoint?
Is the device running out of memory and therefore gives up the ghost when it requires the additional memory to stop at the breakpoint?
No, there's over a gig of RAM to go, and even more of virtual memory.
I haven't used MSVC6 in years, but I remember the debugger basically being a flaky piece of crap. Things like this would regularly happen for no apparent reason because it just didn't like your code that day.
In addition to the debugger being a flaky piece of crap, the rest of it was too.
It's STL implementation isn't threadsafe, it doesn't support very much of the C++ standard, and the IDE is sorely lacking in niceties.
I'm pretty sure you also just simply can't use any versions of the Platform SDK from the last 5 years because it's too old to grok them. Not a good thing.
You'd be mad to keep using it when there is Visual C++ Express 2008 which you can download for free.