Making a bug report
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.
- 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"
- 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 Lazarus: 0.9.30.1-29876 Free Pascal: 2.5.1 Platform: i386-Win32-win32/win64 System: Windows XP SP3
or in the About box. If you include
doublecmd.errin the bug report it already includes needed information.
- 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.errfile 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.errshould 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.zdlifile present in the same directory as
doublecmdexecutable; both files must come from the same build.
doublecmd.zdliis 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
nightlyparameter to the build script, for example
$ ./build.sh nightly
which will generate
doublecmd.zdlifile 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 nightlycommand for building, where Dwarf is already enabled. However,
doublecmd.zdliwill 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.shthat 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.