Printable View
In some cases identifying which types of code movement tend to hide the bug can be helpful for solving it. But I agree----always return the code to the non-working state after such tests, until you have pinned down the cause.Quote:
Originally Posted by Paul McKenzie
It does indeed contain Windows specific code. I have read a lot of the wonders of valgrind.
As far as I know, we don't do anything other than standard use but it's a good idea to investigate. Thanks!Quote:
By the way, usage of STL containers does not guarantee lack of out-of-bounds access. It's true that Microsoft's vector implementation does bounds-checking by default on both [] and at(), but this can be disabled (and often is for speed reasons), and checking of [] is actually not mandated by the standard so if you aren't using the default Dinkumware implementation, you may not even get this.
Hmm yes there was a .dmp file (I assume that is what you are referring to) however, it generated at 0 bytes. It would be a good idea to investigate why.Quote:
Your application should have produced a crash dump. If not, then consider putting one in your application and have it enabled. Then when the application crashes, you get the dump from your clients and you can then debug the issue on your machine by loading the crash dump in Visual Studio.
Very true, I have mentioned this to management however, we have not got round to setting all this up correctly yet (some networking issues).Quote:
Also, you have something called "remote debugging" if you have TCP/IP access to one of these machines.
While I see your point, it is a perfectly valid possibility in my humble opinion and I am in no way trying to 'fob off' this problem onto the hardware. I have been fighting this crash for days. I was merely musing 'out loud'.Quote:
If you're a C++ programmer and said anything like that, in many companies, it could get you fired, or at the very least, have your stature as a C++ program greatly diminished. A C++ (or C) programmer never blames hardware or anything else for their program crashing.
Oh tell me about it! We are behind on the project, and management has one guy fixing bugs and two of us trying to track this crash; no matter how much I tell them we need a version with the crash in to test. After all, if you can't reproduce the bug with some frequency or certainty, how can you confidently say you have fixed it?Quote:
Another thing you don't do -- don't start moving code around until you've debugged the crash and know exactly why it happened
Another problem is we only have one live machine to test with.
Thank you both for your posts, they have given me some solid extra things to think about and pursue.
You need to actually write code to enable the crash dump. The issue is that relying solely on the OS to produce the dump on the crash (i.e. Dr. Watson), will not reliably produce a dump for you, at least that's my experience.Quote:
Originally Posted by nixius
In your code, you should set up the "crash handler", and when a crash occurs, the code calls the functions in DBGHELP.DLL to write the dump file (if you ever saw this DBGHELP.DLL show up on Windows systems -- well now you know what it does). There are examples here and on the Internet that you can use that shows proper usage.
Also, for every build you generate that you release to the public -- save the PDB files and source code! They are your lifeline in debugging crash dumps.
If everything is set up correctly and you've saved the PDB and source files, the next crash you get will produce a crash dump. You then get the crash dump and load the dump file in Visual Studio (as a project). Then you "run" the dump file in Visual Studio, the code will point in the source where the bug occurred, or approximately where the bug occurred (since you are probably releasing an optimized build).
In any event, you must have a solid contingency plan when a crash occurs in the field that cannot be produced in the shop. Crash dumps and remote debugging have the most power when it comes to debugging these issues, log files are third on the list.
Regards,
Paul McKenzie
adding to what others said,
firstly, what were the results of overloading new/delete ? I ask, because you didn't mentioned that after post #1 ...
secondly and as a last resort, if introducing logging functions failed to reproduce the crash because of the compiler changing the code in proximity of the offending code or because of logging-induced changes in the state of the program heap memory, then you could try the Microsoft Detour library to inject the logging function logic at runtime ( eventually, with it's own heap ) to be the less intrusive as possible on the original code ...
Thanks for the post Paul, I will definitely do some searching around the .dmp topic (I was told it should already be working but this blatantly isn't the case) and take on board what you said about the release procedure.
Thanks for the post also superbonzo, so far I have been having difficulties getting the new/delete overloading working because we rely on a lot of third party libraries; this is causing some conflicts and I am looking into some possible work arounds. Nonetheless, I will do some searching on the Microsoft Detour library you mentioned and keep it in mind.
What you can do to test things is that somewhere in your program where you know the code will be executed, do this:Quote:
Originally Posted by nixius
This should produce a crash. If the crash reporting system you have set up does work, then it should create a dump file. If a crash dump file is not produced, or one is produced with 0 bytes, then there is an issue that needs to be resolved.Code:char *p = 0;
*p = 'x';
But again, the only sure-fire way to resolve any issue is to write code to enable the crash dump mechanism. You control where to write the crash dump file, and how the crash is reported. For example, you can override the default dialog box stating stuff about "Do you want to report this to Microsoft" and replace it with your company's "crash dialog". If you've run your share of Windows apps, you must have seen apps that have their own crash reporting dialogs with the company's logo, copyright, etc. listed in the dialog -- this is what you should be striving for.
Regards,
Paul McKenzie
I think you need to do a drawing and follow each &value you`re using. I would perhaps try to do full inline branch of parameter checks to get a same*value check`d for pointer-homogenity. For instance a cerro class (class error reporting) may output and trace each value modification and diplay error if values are greater than initial 'values'.
Second think I can imagine is to avoid full instanciate of program down to a start-up logo: firstly boot skeleton then load logo; then inst class/value1 ->get confirmation, then further so on inst class/values2 ->get confirmation... Most apps nowadays either get started or opens a bluescreen. If memory fault appears at startup then runtime then Paul McKenzie is right about your programers credit, and if error appears during operation then you.. must become a better programmer.
It`s better to use your program w/ drawings to help work w/ blocks/parts of your program. Most users instanciate 'a fileopendialog() inline' by prefference in the midst of program. Better way I did is I wrote a fopen() procedure that requires a char argument and fills in other structs a-macly (the fileopenstruct and path structures there is left out).
====================================================================
kirchoff hadn`t write ebooks for branches:D
In addition to what everyone said, and this is more of a preventive measure, make sure you set the warning level to the highest (/W4 or /WAll) and "Treat warnings as errors" is on. Also use a static syntax checking tool, such as the free CppCheck, or preferably a more powerful commercial tool such as Parasoft's C++test.