Changes between Initial Version and Version 1 of ReportBugs


Ignore:
Timestamp:
Apr 25, 2007, 3:19:44 PM (15 years ago)
Author:
Nicolas
Comment:

Converted by an automatic script

Legend:

Unmodified
Added
Removed
Modified
  • ReportBugs

    v1 v1  
     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
     18from your email; include text inline rather than as attachments.
     19There'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,
     24we 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
     30Each 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
     32Your 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}}}