Bug reports - EurekaLog Documentation

Bug report is a report about possible Bug in the application. It usually contains information about Exception or Leak. Bug report usually contains one or more Call stacks and some information about system itself and application.

Bug reports are stored in files. EurekaLog's Bug reports have .el, .elp, .elx file extensions. The .el files are usual text files, which can be opened in any text editor:

Notepad showing content of Project4.el file

Textual bug reports (.el) contain human-readable description of the problem, which can be analyzed by developer to get the idea what was going wrong. Such reports can be saved locally or sent to developers. Such reports can be viewed in any text viewer/editor. However, you can also use EurekaLog Viewer tool to view these files in a more convenient way:

EurekaLog Viewer tool showing content of the same Project4.el file

Textual bug reports can hold only text. You can't add files to such bug reports. .elp (EurekaLog Packed) format is capable of holding both text report and any additional files - such as screenshots, logs, currently opened files, etc. Packed bug reports (.elp) can not be viewed by text editors - because this bug report format is binary format. These bug reports can be viewed in EurekaLog Viewer tool. .elp files can be sent to developers, these files are not saved locally.

Notes:

•	.elp-file is renamed zip-file which holds .el report and any additional files;

•	.elp-file is used only for sending bug reports to developers (via e-mail, bug tracker, etc.). Local bug reports can be only in .el format. This means that you can not include screenshot or any additional files into local report.

Bug report contain information about running application when it encountered a bug. This information can be split in the following categories:

•	Information about bug (exception or leak) itself - such as error message, location's address, CPU state, etc. This information is most important in bug reports and it's used to resolve bug.

•	Information about application in general - such as version information of executable, name, description, etc. This information is used to identify application which encountered a bug.

•	Information about current user - such as name, e-mail, etc. This information is used to identify user that sent the report. This information can also be used to contact user later for more infos.

•	Information about run-time environment - such as loaded DLLs, installed hardware, running processes, etc. This is auxiliary information which is used to make guesses when searching for bug's reason.

All of the above can also be divided into two mutually exclusive groups:

•	Immediate. This information is captured when the problem occurs. This includes error message and type, address, call stack, CPU state, etc.

•	Delayed. This information is captured when bug report is created. Examples are list of loaded DLLs, running modules, hardware info, etc.

Immediate information is collected right away (when exception raised or leak found) - because it's very important to capture as much of detailed and precise information about the problem as possible. On the other hand, capturing any piece of information takes time. Thus it's not wise to capture ALL information right when exception or leak is detected - due to performance reasons. Not all exceptions will be reported as bugs, and leaks are usually grouped into a single report. That's why some information is captured later: when final bug report is created. This information doesn't change very rapidly (harware info, running processes, etc.), so a bit later snapshot will be close enough.

EurekaLog's bug report contain the following sections:

•	General - this section includes all non-list (i.e. single valued) information: error message, user's infor, computer's info, etc. All other sections contain specialized lists;

•	Call Stack - this section includes one or more call stacks. Call stack is a sequence of addresses (mostly with textual description) which leads us to place of the problem;

•	Modules - this section includes list of the loaded DLLs in the current process;

•	Processes - this section includes list of running processes on the current machine;

•	Assembler - this section includes machine code listing near problem's location;

•	CPU - this section includes CPU dump;

•	Screenshot (.elp only) - this section shows screenshot of a running application when it encountered a bug;

•	Files (.elp only) - this section shows list of attached files.

Usually, analyzing of bug report is starting with reading and understanding call stack. However, there are some specific issues when you need to start with auxiliary information in bug report - such as leaks.