| | 1 | = Reporting 'hard' bugs = |
| | 2 | |
| | 3 | 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. |
| | 4 | == Background == |
| | 5 | 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: |
| | 6 | |
| | 7 | |
| | 8 | * core client |
| | 9 | * message log: stdoutdae.txt |
| | 10 | * crash reports: stderrdae.txt |
| | 11 | * Manager |
| | 12 | * message log: stdoutgui.txt |
| | 13 | * crash reports: stderrgui.txt |
| | 14 | |
| | 15 | When BOINC does something wrong, one or more of these files often contain information that allows us (i.e. BOINC developers) to easily find and fix the problem. |
| | 16 | == Reporting hard bugs == |
| | 17 | Report hard bugs by email, either to the [http://www.ssl.berkeley.edu/mailman/listinfo/boinc_alpha boinc_alpha] email list or directly to [ProjectPeople David and Rom]. '''Note: when you post to boinc_alpha, attachments are stripped |
| | 18 | from your email; include text inline rather than as attachments. |
| | 19 | There's a 200KB limit.''' Your bug report should include: |
| | 20 | * The context: what platform, what version of BOINC, anything else that might be relevant. |
| | 21 | * What sequence of actions caused the problem. |
| | 22 | * The exact nature of the problem. |
| | 23 | * All relevant crash reports or message logs (see below). '''If you don't include this information, |
| | 24 | we probably won't be able to fix the bug.''' |
| | 25 | |
| | 26 | In general we're only interested in bug reports for the current public release, or for the latest testing release. |
| | 27 | == Crashes == |
| | 28 | If the Manager suddenly does blank and says 'not connected', it's almost certainly because the core client has crashed. You can verify this by running the Windows Task Manager (ctrl-alt-del) and checking that there's no process named 'boinc.exe'. |
| | 29 | |
| | 30 | Each crash appends an entry to the crash-report file (stderrdae.txt for the core client). Here's [http://boinc.berkeley.edu/stderrdae.txt 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. |
| | 31 | |
| | 32 | 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. |
| | 33 | |
| | 34 | |
| | 35 | == Incorrect behavior == |
| | 36 | 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): |
| | 37 | {{{ |
| | 38 | <cc_config> |
| | 39 | <log_flags> |
| | 40 | <task_debug>1</task_debug> |
| | 41 | <cpu_sched>1</cpu_sched> |
| | 42 | <sched_op_debug>0</sched_op_debug> |
| | 43 | <cpu_sched_debug>0</cpu_sched_debug> |
| | 44 | </log_flags> |
| | 45 | </cc_config> |
| | 46 | }}} |
| | 47 | A typical message log is shown [http://boinc.berkeley.edu/stdoutdae.txt here]. Note that each line contains |
| | 48 | |
| | 49 | |
| | 50 | * The date and time when the message was written |
| | 51 | * The name of the project involved (if any) |
| | 52 | * The name of the logging flag. |
| | 53 | |
| | 54 | Many of the logging flags produce large amounts of output, so you should |
| | 55 | * enable only the flags that are relevant to the problem you're reporting; |
| | 56 | * email us only the range of your message log during which the problem occurred. |
| | 57 | |
| | 58 | (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. A complete list of logging flags is [ClientMessages here]. |
| | 59 | |
| | 60 | |
| | 61 | === BOINC fails to get more work === |
| | 62 | |
| | 63 | {{{ |
| | 64 | <work_fetch_debug>1</work_fetch_debug> |
| | 65 | }}} |
| | 66 | |
| | 67 | === BOINC thinks apps are running but they aren't === |
| | 68 | |
| | 69 | {{{ |
| | 70 | <task_debug>1</task_debug> |
| | 71 | <cpu_sched_debug>1</cpu_sched_debug> |
| | 72 | <mem_usage_debug>1</mem_usage_debug> |
| | 73 | }}} |
| | 74 | |
| | 75 | === CPU benchmark problems === |
| | 76 | |
| | 77 | {{{ |
| | 78 | <benchmark_debug>1</benchmark_debug> |
| | 79 | }}} |
| | 80 | |
| | 81 | === Bad CPU scheduling decisions === |
| | 82 | |
| | 83 | {{{ |
| | 84 | <cpu_sched>1</cpu_sched> |
| | 85 | <debt_debug>1</debt_debug> |
| | 86 | <cpu_sched_debug>1</cpu_sched_debug> |
| | 87 | }}} |
| | 88 | |
| | 89 | === Memory usage preferences === |
| | 90 | |
| | 91 | {{{ |
| | 92 | <mem_usage_debug>1</mem_usage_debug> |
| | 93 | }}} |
| | 94 | |
| | 95 | === File transfer problems === |
| | 96 | |
| | 97 | {{{ |
| | 98 | <file_xfer_debug>1</file_xfer_debug> |
| | 99 | <http_debug>1</http_debug> |
| | 100 | }}} |
| | 101 | |
| | 102 | === Screensaver problems === |
| | 103 | |
| | 104 | {{{ |
| | 105 | <scrsave_debug>1</scrsave_debug> |
| | 106 | }}} |
| | 107 | |
| | 108 | === Applications not reporting CPU time, fraction done correctly === |
| | 109 | |
| | 110 | {{{ |
| | 111 | <app_msg_receive>1</app_msg_receive> |
| | 112 | }}} |
