Channels ▼
RSS

C/C++

About Log Files: Part 1


Stefan is a software developer in Berlin specializing in cross-platform development, user interfaces, and reengineering. He can be contacted at StefanWoe@gmail.com

Every program should write a log file. Period. Log files will save you hours and sometimes days of tedious debugging work. They are a basic part of structured debugging and quality assurance. The idea might seem odd in these days of application servers, SOA, and the like, but log files are the most efficient and flexible way to debug software and analyze problems. In the first installment of this two-part article, I examine the basics of logging and log files. In Part 2, I'll examine specialized techniques that you can use for multithreaded application or large data sets.

Why Log Files?

In a perfect world, we wouldn't need customer support, debuggers, or log files. In the real world, the more complex things get, the more difficult problems arise. Some will be seen and fixed before a program is in production/released. Others will show up much later and raise thier heads rarely. That's where log files come in.

A log file has several benefits for analyzing a software problem:

  • It's simple to create and efficient to write
  • It doesn't lie or forget. It's robust.
  • It can be transmitted easily by email. It's flexible

When problems arise in software, tech suppoort will usually receive a call or a email about it. It is amazing, how bad, how little, and how confused the information from customers will be about what they have done, what happened, and what the problem is. If your application writes a log file, even if it only contains the used data sources and the executed commands, you will certainly notice that this information often differs from the information relayed by the customer. This will save time and provide clarity--In the same way that a flight recorder often provides the only valid information source to analyze aircraft crashes.

Tech support people can also learn to read and interpret log files and thereby reduce the number of times they need to contact developers. But most importantly: Log files help you in finding bugs that you can't reproduce. Debugging literature general states " make it fail" as a major step (see Chapter 4: Make it Fail in Debugging, by David J. Aagans. Ifyou can't make it fail, then log files are your last resort.

When and Where Do You Store Log Files?

When creating log files you should consider several conditions:

  • An application should open the log file at startup and close it just before termination.

  • It's important to make sure that a program has write access to the log file's location on all supported platforms. Windows Vista, for instance, is much more restrictive about that than previous versions. The log file should be easy to find and have a name that is self explanatory, such as "AppName".log. The best location is always a folder named "AppName"Logs\ wherever its location is appropriate.

  • You might come up with the idea of creating separate log files for separate modules or for different purposes ( a standard log and debugging log, for example). Generally speaking, this is not a good idea. You'll find yourself searching in multiple log files, comparing timestamps, and so on. It's best to use only one log file at a time. That said, separate instances of an application should use separate files as long as they operate independently.

  • You might also come up with the idea to log not to a file but to a database. This seems high-tech, but it directly contradicts the key concepts of simplicity, flexibility, and robustness.

What to Log

The first entry in a log file should be something like "starting log" and the last entry should be a statement like "closing log file." If this entry is missing, you know that the application terminated unexpectedly.

After this first entry, some general information should be recorded:

  • Operating system version, patches.
  • Size of RAM installed, size of free RAM available, and free space on hard drives.
  • IP address, machine name, username, and so on.
  • Current date and time
  • The version of your program.
  • The version of components, DLLs, and libraries that you use.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video