Making a bug report

From Double Commander Wiki
Jump to: navigation, search

If you find a bug in Double Commander report it to the bugtracker.

How to write a bug report:

  1. It is always good to check the latest development version to see if the bug hasn't already been fixed.
  2. Make a separate report for each issue. It is much easier for developers to track single items, so don't include several issues into one report.
  3. Write a fairly distinct title of the report, so that it is easier to recognize when looking through the list. Titles such as
    • Crash in Double Commander
    • Cannot copy file
    are not good. Better to specify:
    • Crash when dragging file from panel to the toolbar
    • File is not copied when "Queue as first" mode is chosen and I press "Start"
  4. Include at least the following information:
    • Version of Double Commander (SVN revision if you use development version)
    • CPU architecture, operating system version
    • Widgetset used, where applicable (for example Linux-GTK2 or Linux-QT4) and version of the underlying library (for example libQT-4.7.2)

    All needed information is displayed when Double Commander is run from console, for example:

    Starting Double Commander
    Double Commander 0.4.6 alpha
    Revision: 3427
    Build: 2011/03/18
    Free Pascal: 2.5.1
    Platform: i386-Win32-win32/win64
    System: Windows XP SP3

    or in the About box. If you include doublecmd.err in the bug report it already includes needed information.

  5. Explain how to reproduce the bug. Without being able to reproduce the bug it is not likely that it will be fixed. This is especially needed on platforms where the development is limited (like x86_64 architecture for example).
  6. If it is possible attach a screenshot of the issue. It is always helpful to also see what is happenning, especially if a developer does not fully understand the explanation or is not proficient in the language of the report.
  7. If you had a crash include the doublecmd.err file as instructed by the popup window that is shown. The stack trace included in the file will usually result in fixing the bug much faster and is essential if the bug cannot be reproduced. A proper report in doublecmd.err should look like this:
    --------------- 04-05-2010, 18:52:31 ---------------
    | DC v0.4.6 alpha Rev. 2780 -- i386-Win32-win32/win64
    | Windows XP SP1
    Unhandled exception: EAccessViolation: Access violation
      Stack trace:
      $0060B008  TFILEVIEW__LOADCONFIGURATION,  line 470 of ./newdesign/ufileview.pas
      $0060D579  TCOLUMNSFILEVIEW__LOADCONFIGURATION,  line 668 of ./newdesign/ucolumnsfileview.pas
      $006150E1  TCOLUMNSFILEVIEW__CREATE,  line 2584 of ./newdesign/ucolumnsfileview.pas
      $00448320  TFRMMAIN__CREATEFILEVIEW,  line 2907 of fmain.pas
      $00448E49  TFRMMAIN__LOADTABSXML,  line 3079 of fmain.pas
      $0044C744  TFRMMAIN__LOADWINDOWSTATE,  line 3777 of fmain.pas
      $0043FA09  TFRMMAIN__FORMCREATE,  line 689 of fmain.pas
      $0042AC43  TCUSTOMFORM__DOCREATE,  line 759 of ./include/
      $0042CA18  TCUSTOMFORM__CREATE,  line 1634 of ./include/
      $0042E759  TFORM__CREATE,  line 2556 of ./include/
      $00434418  TAPPLICATION__CREATEFORM,  line 2050 of ./include/
      $0040335E  main,  line 71 of doublecmd.lpr

    If you instead get something like this:

    --------------- 04-05-2010, 18:52:31 ---------------
    | DC v0.4.6 alpha Rev. 2780 -- i386-Win32-win32/win64
    | Windows XP SP1
    Unhandled exception: EAccessViolation: Access violation
      Stack trace:

    that means debugging information was not available. Such stack trace is generally useless. Make sure you have doublecmd.zdli file present in the same directory as doublecmd executable; both files must come from the same build. doublecmd.zdli is currently generated only in nightly builds to save space and yet retain debugging line information (note that it is not compatible with GDB). If you build Double Commander yourself you have to include debugging information to generate useful stack traces (compiler options "-g -gl"). For this reason add nightly parameter to the build script, for example

    $ ./ nightly

    which will generate doublecmd.zdli file containing debug line information.

    On MacOSX Dwarf format needs to be used ("-gw -gl"), see FPC issue nr 7 on Issues with FPC, Lazarus page. This means that you should use ./ nightly command for building, where Dwarf is already enabled. However, doublecmd.zdli will not be generated on MacOSX because the extractor utility only supports ELF and WinPE file formats. Therefore you must comment or remove lines in that strip the binary of debugging info:

    strip --strip-all doublecmd

    Resulting binary will be much larger but has necessary debugging information.

  8. Usage of either English or Russian language is allowed when submitting a bug report to the bugtracker.
Personal tools