Click here to Skip to main content
15,667,949 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
I am working on an article about diagnosing errors and analysing behavior of larger native C++ applications. The scenario would roughly look like this:

  • Application runs stable for hours or days in production-like environment.
  • Software consists of several processes, mostly native C++. Some of them are highly multi-threaded.
  • There are different communication interfaces between processes.
  • Tests are executed on production system (no IDE, etc.).
  • Production system is a Windows system (not sure about this restriction)

The overall target is fixing errors and increasing stability (surprise ^^).

By now I have a list of possibilities, how to approach this situation:

  • Application dumps on crash
  • - Analyse dumps, when you have access to debug symbol files
    - What to do with them without debug symbols?
  • Logging: programm flow, errors, unexpected events
  • Performance monitoring
  • - Memory
    - Handles
    - Inter-process / IO calls with long response times
  • Remote debugging (if possible)

What do you think, what are your experiences? Did I miss an important concept or approach? Do you have special tool recommendations (or aversions ^^)?
nv3 27-Jan-16 19:08pm    
And you honestly expect a "quick answer" to this question of all questions! Debugging a system of multiple processes, each of the multi-threaded is going to be tough if the applications are not designed in the right way in the first place. And if they were, you probably wouldn't post this question.

I would start out by looking at the code in a code review and analyze each of them for potential problems. The debugging tools needed pretty much depend on which kind of crashed you are observing. Try to make each process as independent from all others as possible. And finally, if you are not an experienced developer yourself, get one on board. Trying to give you a good strategy at hand is like trying to describe how to fly an airplane safely in ten words -- better get a pilot on board.
Sergey Alexandrovich Kryukov 27-Jan-16 19:14pm    
I totally agree with your point. Great metaphor of a "pilot on board", too. I only want to bring to your attention that the inquirer is looking for the matter for his article. I'm not sure if he asks the question because he faces the diagnostic problem with some particular project. The question is probably about the covering the topic.

Please see my comment below where I explain what I think about it.

Sergey Alexandrovich Kryukov 27-Jan-16 19:11pm    
It feels like you are going to write an article about nothing. Listing more or less of known points makes no value, unless you are writing a textbook. For an article, listing and even explaining well-known techniques would be just the profanation. For an article, you need to write about something new, or not obvious, or providing fresh look at some existing diagnostics technique, something with a twist. It does not have to cover anything comprehensively.

And now, you want to poll opinions from other developers. The article on this site should not be a sociology article :-). And not a dissertation. If you hope to find out something which you did not know yet, it's not you who should be the author of your article. If you hope to find out something you forgot to put together, what you are going to write on this point would not be interesting to anyone. One famous writer told us: you should not write unless you just cannot stay silent anymore. This principle should be applied to articles as well. If you don't know what else to write about, it would be much better not to write anything.

Sorry if you don't like my opinion. First of all, I looked at it from standpoint of a potential reader.


1 solution

What do you think, what are your experiences? Did I miss an important concept or approach? Do you have special tool recommendations (or aversions ^^)?
My experience is:
When I deal with C or C++, I have a special behavior at quotation level.
If I am requested to build an app, I do normal quotation and multiply by 2.
If I am requested to debug another one's app, I do normal quotation and multiply by 3.

All this because C++ is flawed to the core with the subtle mix of manual and automatic (and anything in between) memory allocation.
Share this answer
Sergey Alexandrovich Kryukov 27-Jan-16 20:42pm    
Do you mean "flowed" or "flawed"?
Patrice T 27-Jan-16 20:47pm    
"Flawed", Thanks
translation error :)
Sergey Alexandrovich Kryukov 27-Jan-16 20:58pm    
Thank you for the clarification and fix. Then I want to up-vote this solution (which I think does not answer the inquirer question at all; please see my comments to the question), just to appreciate your understanding of flaws of C++. There are too many people who perceive it religiously. :-)
But I see very different flaws; memory allocation is not the worst thing. How about badly obsolete linking, linking by string names, badly obsolete includes, modularity concept in general? And a lot more...
Patrice T 27-Jan-16 21:06pm    
Totally agree with your comments.
I have just choose the one that best trash memory under the hood while seaming to work (at first).

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900