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:
- It is always good to check the latest development version to see if the bug hasn't already been fixed.
- 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)
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 includedoublecmd.err
in the bug report it already includes needed information. - 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.
- 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
- Crash when dragging file from panel to the toolbar
- File is not copied when "Queue as first" mode is chosen and I press "Start"
- 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).
- 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.
- 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 indoublecmd.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 havedoublecmd.zdli
file present in the same directory asdoublecmd
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 addnightly
parameter to the build script, for example$ ./build.sh nightly
which will generatedoublecmd.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 inbuild.sh
that strip the binary of debugging info:strip --strip-all doublecmd
Resulting binary will be much larger but has necessary debugging information. - Usage of either English or Russian language is allowed when submitting a bug report to the bugtracker.