Regarding IntelliTrace equivalent tool in C++
-
Hi All, My C++ console application is crashing randomly. I heard about a Visual Studio 2010(Ultimate) version's feature "IntelliTrace". But, sad part is that IntelliTrace in VS2010 is not available for debugging C++ applications. Does anybody know about any debugger which has similar feature? Or any suggestions about how to approach to solve this kind of random crash problems? Ramana G
-
Hi All, My C++ console application is crashing randomly. I heard about a Visual Studio 2010(Ultimate) version's feature "IntelliTrace". But, sad part is that IntelliTrace in VS2010 is not available for debugging C++ applications. Does anybody know about any debugger which has similar feature? Or any suggestions about how to approach to solve this kind of random crash problems? Ramana G
Typically I don't rely on debuggers, they aren't helping me much (for small programs there is no need, and for large complex ones they just aren't good enough). This is what I do: 1. include good old-fashioned logging to a file, i.e. append one line of text telling what piece of code is executing, what the value is of some key variables, etc, all with a timestamp and a thread ID. 2. run the program a number of times; if it doesn't fail frequently enough, try and force it to fail more often by either stressing the system (less free RAM, more CPU load, whatever is relevant) or by increasing its activity (e.g. lowering its timer's periods or feeding it more input). 3. then compare all the logs, looking for a pattern at the moments of the crashes. It is essential to have the latest information in the log file, therefore I open-append-close it for each and every line; and it may need locking for thread synchronization (although I typically try it without, as that is less intrusive). All this (and anything you might do) may alter the timing a bit (and change thread synchronization, and cause more or fewer deadlocks), but most often it is adequate to pinpoint the problem. Of course, when the log file isn't detailed enough, I keep adding log statements. It all may sound antiquated, in my experience it works great, and all it takes is intimate knowledge about your app, and some energy; no need to get familiar with debugger idiosyncrasies. Note: Having only one author for all the code is a big help; having lots of programmers, third party products, etc. all contributing to the crashing app may make it almost unsolvable. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Typically I don't rely on debuggers, they aren't helping me much (for small programs there is no need, and for large complex ones they just aren't good enough). This is what I do: 1. include good old-fashioned logging to a file, i.e. append one line of text telling what piece of code is executing, what the value is of some key variables, etc, all with a timestamp and a thread ID. 2. run the program a number of times; if it doesn't fail frequently enough, try and force it to fail more often by either stressing the system (less free RAM, more CPU load, whatever is relevant) or by increasing its activity (e.g. lowering its timer's periods or feeding it more input). 3. then compare all the logs, looking for a pattern at the moments of the crashes. It is essential to have the latest information in the log file, therefore I open-append-close it for each and every line; and it may need locking for thread synchronization (although I typically try it without, as that is less intrusive). All this (and anything you might do) may alter the timing a bit (and change thread synchronization, and cause more or fewer deadlocks), but most often it is adequate to pinpoint the problem. Of course, when the log file isn't detailed enough, I keep adding log statements. It all may sound antiquated, in my experience it works great, and all it takes is intimate knowledge about your app, and some energy; no need to get familiar with debugger idiosyncrasies. Note: Having only one author for all the code is a big help; having lots of programmers, third party products, etc. all contributing to the crashing app may make it almost unsolvable. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
If you tell the debugger to stop on exceptions (except for a few that might be expected in your application), the debugger will stop about half of the time exactly where the problem occurs. If you are developing native C++ application and use STL then using checked iterators will also find most misuse although if will run much more slowly in that case. Generally the performance of C++ application is more affected by debugging than C# application (or safe C++/CLI). Very often, it is possible to just put a breakpoint at the appropriate location and find the problem really fast. You just have to learn to use the debugger. Most of the time, simply inspecting a few variable give an hint on the problem. Well, maybe with some habit... "Edit and continue" is also very powerful as you can often correct the code as soon as the error is detected (and maybe execute the code again after ensuring it won't cause undesirable side-effect). It is possible to compile your C++ code as managed and then see if you can use Intellitrace. In Visaul Studio 11 Ultimate Preview, it works for safe C++/CLI code... I haven't tried other options. Adding a lot of check in code (assertions) and tracing some information also help find problems. In my case, most of the time, assertion and validation done in libraries (STL, .NET) and the use of a debugger let me find problems relatively quickly... Well, maybe doing .NET development and using C# for more than half my code probably do help also...
Philippe Mori
-
Hi All, My C++ console application is crashing randomly. I heard about a Visual Studio 2010(Ultimate) version's feature "IntelliTrace". But, sad part is that IntelliTrace in VS2010 is not available for debugging C++ applications. Does anybody know about any debugger which has similar feature? Or any suggestions about how to approach to solve this kind of random crash problems? Ramana G
Get windbg off the net'o'sphere and attach it to your exe. Set up the symbols, paths etc, and when it gacks up, do a (possibly) break and then !analyze -v and windbg will tell you exactly where it went wrong. Great tool windbg, truly greatr. Massive, complex, quirky, but a hell of a good debugger.
============================== Nothing to say.
-
Hi All, My C++ console application is crashing randomly. I heard about a Visual Studio 2010(Ultimate) version's feature "IntelliTrace". But, sad part is that IntelliTrace in VS2010 is not available for debugging C++ applications. Does anybody know about any debugger which has similar feature? Or any suggestions about how to approach to solve this kind of random crash problems? Ramana G
I may be wrong but my understanding is that the information IntelliTrace assembles requires Reflection, managed code, or both. So, most likely, there are no tools with similar functionality for C++. I'm quite sure if it were possible, MS would provide it already. With regard to random crashs, IME they are caused most of the time by inproper memory access, i. e. writing to or reading from memory areas that don't belong to you or the like. Your best bet is to look for tools that find memory problems. I'm using Insure++ for this purpose, which comes with the added advantage that it finds many problems before you even start the program. It is very slow though and requires a lot of additional memory, so it might be a good idea to look around for competitive products and see which suits your needs best.
-
Hi All, My C++ console application is crashing randomly. I heard about a Visual Studio 2010(Ultimate) version's feature "IntelliTrace". But, sad part is that IntelliTrace in VS2010 is not available for debugging C++ applications. Does anybody know about any debugger which has similar feature? Or any suggestions about how to approach to solve this kind of random crash problems? Ramana G
Hi, Console Application? the old adage is: "When in Doubt, Print more Out". The Macro's
__LINE__
and
__FILE__
are realy handy there. Write a Dump Function, and do something like:
Dump(__FILE__,__LINE__,"Still Alive")
That is how you narrow down problems. You know your code, because you wrote it. It is hard to see how an Intellitrace debugger can have a better idea about what you wanted to write in the first place than that you can have. (It could work well in those highly structured Wizzard ridden area's such as Web Matrix. There the Author has no notion of what was written on his behalf, the only thing known to him there is what he wanted to achieve. Commandline Programs? Not very likely Candidates for that technology. When it trashes, you can narrow down where it happens. Also, occasional trashing tends to happen in retail code. Not much code is tested long enough in debug mode to catch an occasional trashing. Even MS Word trashes occasionally, and that is also not always a software issue of your making. Anyway, Debuggers don't work very well with retail code. LogFiles Do! Also, You Don't need to log in Text, You can create your own logging format, plus a (windows) app that can read and display the info. If your code is perfect, but on occasion Windows trashes it anyways, there is little you can do (apart from re-writing Windows) However, What are the Consequences of trashing. Did the User loose their input(inconvenience) or was an entire network or database crashed(Unmitigated Disaster). The former, Let it Go, if it is infrequent. The Latter: write your software mindfull of this, and be aware of the transaction technology you implement or wrote. Hope this is Helpful, :)
Bram van Kampen