Skip to content

Making a bug report

Alexander Koblov edited this page Aug 20, 2022 · 3 revisions

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. Include at least the following information:
    • Version of Double Commander (revision and commit if you use development version)
    • CPU architecture, operating system version
    • Widgetset used, where applicable (for example Linux-GTK2 or Linux-Qt5) and version of the underlying library (for example libQt-5.7.2)
    All needed information is displayed in the About box, for example:
    Double Commander
    Version: 1.1.0 alpha
    Revision: 10308
    Commit: 29cea4708
    Build date: 2022/08/14
    Lazarus: 2.2.3.0
    FPC: 3.2.2
    Platform: i386-Win32-win32/win64
    OS version: Windows 10 21H2 x86_64
    
    You can copy it using "Copy to clipboard" button. If you include doublecmd.err in the bug report it already includes needed information.
  3. 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.
  4. 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"
  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/customform.inc
      $0042CA18  TCUSTOMFORM__CREATE,  line 1634 of ./include/customform.inc
      $0042E759  TFORM__CREATE,  line 2556 of ./include/customform.inc
      $00434418  TAPPLICATION__CREATEFORM,  line 2050 of ./include/application.inc
      $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:
      $0060B008  
      $0060D579  
      $006150E1  
      $00448320  
      $00448E49  
      $0044C744  
      $0043FA09  
      $0042AC43  
      $0042CA18  
      $0042E759  
      $00434418  
      $0040335E  
    
    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 $ ./build.sh 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 ./build.sh 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 build.sh 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.