QA/BugReport/Debug Information/tr

From The Document Foundation Wiki
Jump to: navigation, search

This page describes Debug Information that you may wish to provide to the developers when submitting a BugReport.

Bu alan GELİŞMİŞ bilgiler içerir

Lütfen aşağıdaki koşullardan birini sağlamıyorsanız bu sayfadaki bilgileri sağlamak zorunda hissetmeyin;

  • Burada yazanların ne olduğunu bilen bir geliştirici/programcıysanız,
  • Bir geliştirici veya QA takımından biri sizden özellikle bu bilgileri istemişse,
  • Kalite Kontrol takımının bir üyesiyseniz.

İşletim Sistemi tarafından sağlanan hata ayıklama bilgisi

Buradaki açıklamalar işletim sistemine fazlasıyla bağlı olduğundan sayfanın geri kalanı işletim sistemlerine göre ayrılacaktır

GNU/Linux

Hata ayıklama günlüklerini üretebilmek için önce hata ayıklama paketlerini kurmanız gerekir. Debian, Ubuntu veya türevleri için hata ayıklama paketi libreoffice-dbg olarak adlandırılırken diğer dağıtımlar için libreoffice*-debuginfo adında olabilir. Lütfen bu paketlerin kurulumunun 2.5GB'dan fazla disk alanına ihtiyaç duyduğunu unutmayın.

GNU/Linux: How to get a backtrace

The backtrace is useful for analysing the reasons why an application crashes or freezes. The backtrace can be run without the debugging packages, but it wont be as useful, but still could potentially provide at least some information. You might use the following steps:

  1. start a terminal / shell (in some distros you can press Ctrl+Alt+T to do this)
  2. run `$ soffice --backtrace`
  3. reproduce the crash or hang. If its a hang, you will need to force a crash, so open another console and type `$ pkill -15 soffice.bin` or alternatively type `$ xkill` and click on the hung libreoffice window.
  4. a gdbtrace.log file will be created in the same folder.
  5. compress it as a .tar.gz file and attach it to the bug.

GNU/Linux: How to get an strace log

strace traces the system calls that a process makes. If there is some problem around file-I/O this can be a great way of detecting exactly what is going on at an operating-system level. It's also a fast way to see whether the program continues executing and/or has hung, and finding information about the system libreoffice is run on.

  1. start a terminal
  2. soffice --strace
  3. reproduce your problem
  4. compress the log: bzip2 strace.log
  5. now attach the strace.log.bz2 file that is produced to the bug report.

GNU/Linux: How to get a Valgrind log

The valgrind log is invaluable for tracing obscure memory corruption errors that can be extremely difficult to find otherwise. It achieves this by emulating a CPU. The slight downside of that is that the code runs around eighty (80x) slower, which will seem slow to you. The plus side is that it shows us problems that are un-findable in any other way, and that the traces produced very often pinpoint the issue in such a way that it is rather easy for a developer to fix: your patience is much appreciated. Valgrind can also produce a number of false-positives.

  1. install the valgrind package
  2. start a terminal
  3. soffice --valgrind >& /tmp/valgrind.log
  4. be patient ... 80x is a lot slower ... reproduce the problem.
  5. attach /tmp/valgrind.log to the bug report.

If you want to specify some additional options for valgrind, you can use VALGRIND_OPTS environment variable.

GNU/Linux: How to get a cachegrind trace

A cachegrind trace will ~immediately point the finger at a performance problem, callgrind uses valgrind to model a CPU and, more importantly, its cache hierarchy to find poorly performing pieces of code, and provide (in kcachegrind) a hierarchical, navigable histogram view of where the time is spent in the code.

  1. get LibreOffice build with --enable-symbols
  2. install the valgrind package
  3. start a terminal
  4. unset MALLOC_CHECK_
  5. unset MALLOC_PERTURB_
  6. unset G_SLICE # these three stop us getting poor performance from unusual allocators
  7. export SAL_DISABLE_FLOATGRAB=1 # if we wedge at least we don't do it while grabbing the mouse
  8. export OOO_DISABLE_RECOVERY=1 # turns off recovery dialog which can be a pain
  9. valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin --splash-pipe=0

Cachegrind runs around 150x slower than normal - after running it and exiting cleanly (in extremis press ctrl-c only once! on the console). You should have quite a large file called: callgrind.out.12345 where 12345 is the PID. gzip this file, and link / up-load it somewhere for a developer. Or - if you are interested in pretty pictures - load it in kcachegrind and have a play.

Windows

Windows: How to get a backtrace

If you have LibreOffice 4.2.0 and higher installed, you have a development debug version, there is a test symbol server containing the corresponding debugging symbols. Read How to get a backtrace with WinDbg to set the debugging environment and you can also watch this video to help understand the process.

Mac OSX

Mac OSX: How to get debug information

The debug information is useful for analyzing the reasons why an application crashes or freezes. On Mac OS X, you can receive the standard debug information very simply, without installing any additional software. (This information even includes a simple stack trace, which misses full symbols, but can nevertheless be very useful.)

The exact steps vary depending on your Mac OS X version and setup, but in general you get the debug information as follows:

  • When an application crashes, Mac OS X prompts you with a dialog window saying “LibreOffice quit unexpectedly.” and asks you if you want to send a report to Apple. Click on the button labelled “Report…”. Now a larger window with the title “Problem Report for LibreOffice” opens; under “Problem Details and System Configuration”, you find an edit field with a long text containing much technical details. You can just click into this long text, press ⌘ Cmd+a to select all the text, then press ⌘ Cmd+c to copy it and then switch to any text editor (e.g. Apple’s TextEdit) and press ⌘ Cmd+v to insert the text. Then you can save the text as a new file; the best would be to use a plain text (.txt) format. Please attach that file to your bug report. (You do not need to send the report to Apple, so click on the “Don’t Send” in the “Problem Report” window.)
  • When an application hangs or freezes, you can force quit it by pressing ⌘ Cmd+Alt+Esc. Mac OS X prompts you with a dialog window entitled “Force Quit Applications”, asking which application(s) you want to quit; in that list, you can recognize the application which hangs or freezes often by the hint “(not responding)”. Select it and click the button “Force quit”. Depending on your system configuration, you will be asked if you want to send a report about that to Apple; if you confirm this, you will get the same “Problem Report” window as described above, and can copy and save the debug information text in the same way.

NB: Depending on your system configuration and user setup, you may or may not be asked about sending a report to Apple; you may need to be logged in as an admin user to see these dialogs.