If a bug can be easily reproduced, it's easy for us to fix. 'Hard' bugs are those that happen rarely or only on specific machines. The following information tells BOINC Alpha Testers (and anyone else who wants to help) how to report hard bugs, so that we can fix them even if we can't reproduce them.
The BOINC client software consists of two programs: the core client, which runs applications and does network communication, and the Manager, which provides a graphical user interface (GUI) to the core client. It's possible to run the core client without a GUI. Each program produces two files in your BOINC directory: one for messages, one for crash reports. These files are named as follows:
- core client
- message log: stdoutdae.txt
- crash reports: stderrdae.txt
- BOINC Manager
- message log: stdoutgui.txt
- crash reports: stderrgui.txt
When BOINC does something wrong, one or more of these files often contain information that allows BOINC developers to easily find and fix the problem.
Reporting hard bugs
Report hard bugs by email, either to the boinc_alpha email list or directly to David and Rom. Note: when you post to boinc_alpha, attachments are stripped from your email; include text inline rather than as attachments. There's a 200KB limit. Your bug report should include:
- The context: what platform, what version of BOINC, anything else that might be relevant.
- What sequence of actions caused the problem.
- The exact nature of the problem.
- All relevant crash reports or message logs (see below). If you don't include this information, we probably won't be able to fix the bug.
In general we're only interested in bug reports for the current public release, or for the latest testing release.
If the Manager suddenly goes blank and says 'not connected', it's almost certainly because the core client has crashed. You can verify this by
- Run the Windows Task Manager (ctrl-shift-esc) and check that there's no process named 'boinc.exe'.
Linux / Unix
- Run ps and check that there's no process named 'boinc'.
Each crash appends an entry to the crash-report file (stderrdae.txt for the core client). Here's an example of such an entry. It has a long list of DLLs in use at the time of the crash, followed by several 'stack traces' showing where the various threads were executing.
Your bug report email should include the most recent entry from your crash-report file. Please edit the file to remove old entries, so that we don't get confused by them.
If BOINC behaves incorrectly, we usually need the core client's message log to figure out what's going on. The message log describes what the core client is doing. It's identical to what's shown in the Messages tab of the Manager. By default the core client writes only a few messages. More detailed messages are enabled by turning on logging flags. This is done by editing the file cc_config.xml in your BOINC directory. For example, the following turns on the task_debug and cpu_sched flags (1 turns a flag on; 0 or unspecified turns it off):
<cc_config> <log_flags> <task_debug>1</task_debug> <cpu_sched>1</cpu_sched> <sched_op_debug>0</sched_op_debug> <cpu_sched_debug>0</cpu_sched_debug> </log_flags> </cc_config>
Have a look at this message log example. Note that each line contains
- The date and time when the message was written.
- The name of the project involved (if any).
- The name of the logging flag.
Many of the logging flags produce large amounts of output, so you should
- enable only the flags that are relevant to the problem you're reporting;
- email us only the range of your message log during which the problem occurred.
(in both cases, it's better to err on the side of including too much).
Some common problem types, and the suggested logging flags, are listed below. You should also check the complete list of logging flags.
BOINC gets too much or too little work
BOINC thinks apps are running but they aren't
<task_debug>1</task_debug> <cpu_sched_debug>1</cpu_sched_debug> <mem_usage_debug>1</mem_usage_debug>
CPU benchmark problems
Bad CPU scheduling decisions
<cpu_sched>1</cpu_sched> <debt_debug>1</debt_debug> <cpu_sched_debug>1</cpu_sched_debug>
Memory usage preferences
File transfer problems
Applications not reporting CPU time, fraction done correctly