Crails Framework

1. The Logger

It can be useful to save information to log files at runtime. Crails can help you display debugging information and save the logging history in files.

1.1 What is the Logger ?

Crails provides its own logger, designed to record logging information in a thread-safe fashion, providing useful information alongsides the logs, such as process id, thread id and timestamp.

The logger also implements a log rotation mechanism, particularly useful in production environments.

1.2 Log Levels

When something is logged, it's printed into the corresponding log if the log level of the message is equal to or higher than the configured log level. If you want to know the current log level, you can use the Logger::log_level global variable.

The available log levels are: Debug, Info, Warning, Error, corresponding to the log level numbers from 0 up to 4, respectively. To change the default log level, update the logger configuration file:

#include <crails/logger.hpp>

using namespace Crails;

const Logger::Symbol Logger::log_level = Debug;
//const Logger::Symbol Logger::log_level = Info;

1.3 Sending messages

To write in the log from anywhere within your application, use Crails::logger, such as:

using namespace Crails;
logger << Logger::Info << "Processing a request" << Logger::endl;
logger << Logger::Error << "Something unexpected has happened" << Logger::endl;

1.3 Logging to files

By default, the logger outputs the log to the standard and error output (stdout and stderr). But you can have it write the logs to files instead, by launching your server with the following options:

build/server --log logs/info

This will redirect all your logs to the logs/info file. If a file with the same name already exists, it will be renamed to logs/info.1, up until logs/info.10. Logs start rotating after 10 files have been stored.

You may also split info and error logs to different files by adding the following option:

build/server --log logs/info --errors logs/errors

1.4 Impact of logs on performance

Logging will always have a small impact on the performance of your Crails app, particularly when logging to disk. Additionally, there are a few subtleties:

Using the Debug level will have a greater performance penalty than Error, as a far greater number of strings are being evaluated and written to the log output (e.g. disk).

Another potential pitfall is too many calls to Logger in your code:

logger << Logger::Debug << "New person model: " << model.to_json() << Logger::endl;

In the above example, there will be a performance impact even if the allowed output level doesn't include debug. The reason is that the values are still being passed to the logger, meaning model.to_json() will run, even if nothing gets printed as a result.

Therefore, it's recommended to pass lambdas to the logger methods, as these are only evaluated if the output level is the same as — or included in — the allowed level (i.e. lazy loading). The same code rewritten would be:

logger << Logger::Debug << [&]() { return "New person model: " + model.to_json(); } << Logger::endl;

The contents of the block, and therefore the string interpolation, are only evaluated if debug is enabled. This performance savings are only really noticeable with large amounts of logging, but it's a good practice to employ.

2. Debugging using GDB

There are many GDB tutorials out there. Pick one !

3. Debugging Memory Leaks

Any application may leak memory. In this section, you will learn how to find and fix such leaks by using tools such as Valgrind.

3.1 Valgrind

Valgrind is an application for detecting C-based memory leaks and race conditions.

There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. It will for instance give you a report of the memory that your application has leaked while it was running, alongside with precise details to help you find where such memory was allocated.

For further information on how to use Valgrind, refer to Valgrind's Quick Start Guide.