CODEWITHSUNDEEP
c++crash
Jeffrey
Jeffrey

Reputation: 4506

How to reduce the crash of the C++ program

I have a big software implemented by C++, built by VC10 SP1. There are more than 15 millions of source code lines. It is delivered to Windows platform, both win32 and x64. From the crash reports, the mean time to crash is only about 40 minutes.

I want to try the best to reduce the crash and extend the mean time to crash. Can somebody share what you have done in practice or is there any suggestion? Any comment is appreciated.

Thanks,

Jeffrey

Upvotes: 0

Views: 227

Answers (4)

krammer
krammer

Reputation: 2668

You need to debug the source. For analyzing it, you can put Breakpoints in your source code to analyze the point of problem. But it is going to help you only when you have zeroed on to a specific area of problem within your codebase. For that you can perform test on various modules within your code to locate the problematic area.

Seeing that your program fails in around 40 minutes, it seems to be a problem with memory leak. As you are using VC, VS provides a good mechanism to detect and isolate memory leaks.

Your code may also have errors related to having allocating an array and then accessing elements that do not access there. Or somewhere the code could have been adding elements to the array and instead of replacing the older entries it keeps on adding newer ones.

Upvotes: 0

Matthieu M.
Matthieu M.

Reputation: 300229

This is called debugging, or the Art of Hunting Bugs.

There are many ways to improve Software Quality.

During the Design Phase:

  • Design Reviews
  • Code Reviews
  • Static Analysis Tools

During the Early Life:

  • Unit Testing
  • Fuzzy Testing (where applicable)
  • Integration Testing
  • End-to-End Testing

The whole lot can be run on instrumented code (for example, with STL Debugging activated, with specific debugging memory allocators, with monitoring tools/debuggers hooked up).

Note: Unit/Fuzzy Testing are more easily applicable if the application is in multiple components, as the goal is to test as small units as possible.

Note: do not forget to extend the test suite when you implement new functionalities or fix bugs to prevent regression.

During the Life:

  • Human Crash Reports (and trying to reproduce...) are not so efficient
  • Automated Crash Reports (there are utilities on Windows) are real nice

It's up to you to foster quality.

FYI: the software I work on runs 24h/7d and when we have a crash once or twice a week, we consider we screwed up; 45min is definitely wrong.

Upvotes: 2

stefaanv
stefaanv

Reputation: 14392

Some suggestions (next to the obvious debugging):

Upvotes: 0

Mario
Mario

Reputation: 1851

"Extend mean time to crash"? How about fixing the code such that it doesn't crash? Troll question?

If not, sounds like a memory leak. Run it through a memory profiler: http://en.wikipedia.org/wiki/List_of_performance_analysis_tools#C_and_C.2B.2B

Upvotes: 1

Related Questions