QA/Bibisect/ru

    From The Document Foundation Wiki
    < QA(Redirected from QA/HowToBibisect/ru)
    This page is a translated version of the page QA/Bibisect and the translation is 24% complete.
    Outdated translations are marked like this.

    Введение

    Bibisect означает "деление пополам" и предназначен для помощи членам команды QA LibreOffice занимающихся регрессиями. Регрессия наиболее раздражающий артефакт, который, к сожалению, приходит с разработкой программы. Однако, мы хотим иметь дело с ними как можно раньше, так как их поиск и исправление со временем становятся всё сложнее и сложнее. Git хранит свои вещи так, что одна программа Bibisect может содержать несколько полных 64-разрядных офисных пакетов Linux установленных в очень сжатом размере. И это не требует установки всех версий параллельно, так как можно перейти к любому из них быстро через git checkout source-hash-XXXXXX, что занимает менее 1 секунды.

    Ограничения

    При помощи Bibisect возможно находить только те ошибки, для которых в репозитории Bibisect есть в наличии круг подтверждённых вопросов. На сегодняшний день это верно для всех регрессий в Linux. Для macOS и Windows мы медленно приближаемся к цели.

    Если вы не готовы испытывать одну и туже версию LibreOffice несколько раз на одну и туже ошибку, чтобы собрать статистику и обезопасить свои выводы, этот способ не сможет гарантировать нахождение той версии в которой с которой она появилась, тем более если она не 100% воспроизводима.

    Видео урок на Youtube

    10-ти минутный ролик (Youtube)] от Florian Reisinger. - Урок на английском. Но вроде бы, все ключевые моменты понятны. Качество звука не очень хорошее, но достаточное, чтобы понять что говорят.

    Please accept this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

    YouTube privacy policy

    Details

    A successful bibisect will leave developers with only a few commits to search through to find the 'culprit' commit that we believe introduced a regression. QA can go the additional step of fully bisecting (determining the exact commit) or can leave this to the developers. It's often easy to find the commit that caused the issue after bibisecting the bug.

    With approximately 10 gigs, you'll have hundreds of builds to work with. A bibisect can take as little as 15 minutes.

    Currently, bibisecting is possible on:

    As can be seen from the Commits in range and Number of builds, depending upon the particular bibisect repository, this range might be on average 80 commits for old "43max" repository (reaching hundreds of source commits in some builds) to just 1 or 2 commits for newer repositories. (We also have some very 'coarse' bibisect repositories that use released versions + beta + RC builds, and these may have ranges spanning multiple hundreds of commits).

    If build commit or range is found, bug is marked with keyword "bibisected", and if source commit is found, bug is additionally marked "bisected".

    General Instructions

    It might be a good idea for beginners to start by tracing the steps of a bibisect that was already completed successfully. For this purpose we have a bibisecting tutorial.

    Note pin.svg

    Обратите внимание:
    Each operating system is different, so please read the page that corresponds to your specific operating system (GNU/Linux, macOS or Windows) for more specific instructions, tips and troubleshooting.

    Короткие инструкции - Только для Linux

    1. Скачайте репозиторий (12 Гбайт, но не беспокойтесь - это нужно только один раз).
    2. Распакуйте его в удобную папку.
    3. Откройте терминал (не волнуйтесь, всего несколько простых команд).
      1. Если вы используете Ubuntu нужно установить git и libjpeg62: sudo apt-get install git libjpeg62
    4. перейдите в директорию с программой cd каталог_программы
    5. Запустите программуgit bisect start latest oldest
    6. Запустите офис ./opt/program/soffice
    7. Воспроизведите действия которые вызывают ошибку
      1. Если ошибка не воспроизводится: git bisect good
      2. Если ошибка присутствует: git bisect bad
    8. повторите шаги 6 & 7 пока не найдёте ту версию в которой эта ошибка появилась
    9. git bisect log
    10. Прикрепите вывод лога к отчету об ошибке

    Once set up, for each bug:

    1. Bibisect the bug
    2. Comment in the bug report with the results
    3. Replace the keyword 'bibisectRequest' with 'bibisected'
    4. If the precise commit causing the regression has been identified, also add the keyword 'bisected', add the developer as CC, and comment 'Adding Cc: to <developer's name>'

    Версии

    Commit ranges

    Репозиторий 43all должен включать все предыдущие и поэтому они могут считаться устаревшими[1].

    Платформа Версия Серия фиксаций (commit) от Серия фиксаций (commit) до Количество фиксаций (commit) Количество сборок Ссылка на загрузку Размер загрузки Bibisected bugs in range Коментарии
    Ubuntu 12.04 x64 43all d6cde02d c15927f2 60733 755 builds Canonical: репозиторий подпись 12Gb 542+[2] это заменяет старый репозиторий 42all[3]
    43only 22029c7e c15927f2 13951 220 builds Canonical: репозиторий подпись 3.6Gb только в диапазоне от точки ветвления 4.2 до 4.3[4]
    Ubuntu 14.04 x64 44alpha2only dea4a3b9 b800d0b6 9859 188 builds Canonical: репозиторий подпись 2.8 Gb только в диапазоне от разделения ветки 4.3 до тега alpha2 4.4
    macOS
    • lo-4.1_to_lo-4.2
    • 4.2_to_lo-4.3
    • и release_lo-3.3.0_to_lo-4.1
    ? ? ? ? TDF: репозиторий 6 GB, 3.9GB and 2GB пробная?
    WIN 2013-12-13_2013-12-19 ? ? ? ? TDF: репозиторий 3.5GB не активна, только для тестирования
    Linux dbgutil более поздняя точка ветвления libreoffice-x-y -> более поздний master TDF: репозиторий 2.6 GB dbgutil[5]

    git log c3f9dc54188b316a61dd871b63734d49b05f5d7f

    Now you can copy the source hashes of the first and previous displayed commits and separate them with .. to construct a range query like so:

    https://git.libreoffice.org/core/log/7c4d3ea6ba4d42b4dda5148a00c8c411b5d7703d..5b195fbcf7a441aeb193f6abd08b877e580938e0
    

    This will allow you to skim commit messages looking for related subjects. For deeper scrutiny, see the section on detective work.

    Finding the earliest version affected

    If you have a local copy of the core repository, you can update the Version field in the bug report thanks to some git commands:

    1. First, make sure you have all the tags:

    git fetch --tag

    2. Then, use `name-rev` to find the context (more precisely, by how many revisions it preceded the earliest tag that contains the commit):

    git name-rev <commit>

    3. If that didn't give a useful tag that matches a LibreOffice version, you can list all tags that contain the commit and have "libreoffice" in the name with:

    git tag --contains <commit> | grep libreoffice

    Limitations

    Performing a bibisect is only possible if we have a repository available for the correct OS, covering the correct range of LibreOffice commits. We have very good coverage on GNU/Linux, and are improving our coverage on Windows and macOS.

    Some regressions are difficult to reproduce, and may require multiple test runs for a bug to appear. As you may imagine, trying to bibisect such regressions is very difficult, and requires one to perform many test runs after each checkout of a new version of LibreOffice to give some security / statistics that the bug is indeed present or not present with the given version.

    We do not currently have bibisect support for

    Приготовления

    Ручная установка (скачивание архива tar)

    Во-первых, вы должны инсталлировать Linux 64-bit. Инсталляция в виртуальной машине тоже будет работать.

    Distro 43all 43only
    Ubuntu 13.10 (Saucy) необходимо установить libjpeg62 для включены версий старше 3.5 может работать установленный по умолчанию
    Ubuntu 12.04 LTS (Precise) необходимо установить libjpeg62 для включены версий старше 3.5 может работать установленный по умолчанию
    openSUSE 12.1 нет ?
    Fedora собрать libjpeg8 из исходного кода и установить LD_PRELOAD (для версий старше 3.5) ?

    Затем установите зависимости для вашего дистрибутива:

    > sudo apt-get install git libjpeg62 # ubuntu
    

    Затем, скачайте архив bibisect (выбрать здесь) и распакуйте его. Для 42all команда распаковки выглядит как:

    > tar -xf bibisect-42all.tar.xz
    

    Вы также можете проверить подлинность и целостность файлов. Для этого вам понадобится GPG-ключ с https://launchpad.net/~bjoern-michaelsen. Для примера,

    > gpg --keyserver keyserver.ubuntu.com --recv-keys XXXXXXXX # замените XXXXXXXX на OpenPGP ключ с веб-страницы
    > gpg --verify bibisect-42all.tar.xz.sig
    

    Первое скачивание будет занимать несколько гигабайт (12 гигабайт для 43all). Обновления занимают меньше места.

    Поиск места появления регрессии в LibreOffice

    Finding bugs needing bibisect

    The following bugs with keyword bibisectRequest are waiting for a bibisect:

    In addition all unresolved regressions in LibreOffice might benefit from bibisecting.

    После нескольких повторений, git сообщит вам что-то вроде этого:

     9625329ea5a7e3e8475cd21c07726beec20573bd is the first bad commit
     commit 9625329ea5a7e3e8475cd21c07726beec20573bd
     Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
     Date:   Thu Dec 8 12:29:59 2011 +0100
    
    <div class="mw-translate-fuzzy">
    source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
           
       commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4
       Author:     Jan Holesovsky <kendy@suse.cz>
       AuthorDate: Wed Nov 16 14:17:03 2011 +0100
       Commit:     Jan Holesovsky <kendy@suse.cz>
       CommitDate: Wed Nov 16 14:21:33 2011 +0100
           
         Kill one usage of chrel.sed to fix build.
    

    git log fb754a0df859e30255c25af8fa19bfaa75f257e7..2d19e9bb07ccff3134f855812dddfda5c07b1fe4

    Приложите это (линия source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 является очень важной тут) и сделайте вывод:

    > git bisect log
    

    Который должен выглядеть примерно так:

    git bisect start 'latest' 'oldest'
    # good: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
    git bisect good 2faf4bc12ab490370d2196dedbc8091f9b09d0a5
    # bad: [b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42
    git bisect bad b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4
    # good: [0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e
    git bisect good 0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e
    # bad: [9625329ea5a7e3e8475cd21c07726beec20573bd] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
    git bisect bad 9625329ea5a7e3e8475cd21c07726beec20573bd
    # good: [89d91bb6074026dc0894bcdc6aaf8f6124102da7] source-hash-fb754a0df859e30255c25af8fa19bfaa75f257e7
    git bisect good 89d91bb6074026dc0894bcdc6aaf8f6124102da7
    

    Для разработчиков это даст хорошее понимание, где начинается ошибка. Также, поставьте слово bibisected в поле статуса whiteboard, для того, чтобы ошибка больше не появлялась в списке с нуждающимися для поиска при помощи Bibisect.

    Теги в репозиториях bibisect

    Репозиторий 42all тэги типа last35onmaster, last36onmaster, которые маркируют последние сборки на ветке master до того как релиз был ответвлён. Если вы имеете ошибку, которую вы уже о которой знаете что она воспроизводится между 4.0 и 4.1, вы мжете сделать следующим образом:

    > git bisect start last41onmaster last40onmaster
    

    для того, чтобы искать в этом диапазоне. Обратите внимание, что ответвление крупного релиза происходит гораздо раньше, чем первая финальная версия (обычно между альфа и бета). Так что ошибка в первом крупном релизе может быть воспроизведена после ответвления. Она по-прежнему должны быть доступна для поиска в bibisect на ветке master по пути к следующей версии, так как почти все фиксации на ветке релиза идут в первую очередь на ветку master. Поэтому обращайтесь с осторожностью.

    особенности репозитория ежедневных сборок dbgutil

    Каждая версия имеет файл build-info.txt, и первая строка файла содержит source-hash который говорит о сборке. Это будет полезно, если вы включите исходные хэши последней хорошей версии и первый плохой в вашем докладе о результатах тестирования bibisect.

    Не доступно для поиска

    Некоторые ошибки не доступны для поиска при помощи Bibisect. Это включает:

    • Ошибки, которые не воспроизводятся на GNU/Linux
    • Ошибки, которые предшествуют покрытию в сборке Bibisect (Мы работаем над расширением покрытия)
    • Ошибки, которые зависят от параметров создания не включен в сборки TDF (например, ошибки в -kde)

    Еслиa ошибка с bibisectrequest в поле статуса whiteboard оказывается не пригодной для поиска при помощи Bibisect, оставьте комментарий на ошибки объясняя, почему мы не можем использовать Bibisect, и заменить bibisectrequest на NotBibisectable в поле статуса whiteboard.

    Выбор ошибки

    Выберите ошибку нуждающуюся в поиске при помощи Bibisect

    Следующие ошибки в поле whiteboard с записью bibisectrequest ожидают обработки:

    <rss>https://bugs.documentfoundation.org/buglist.cgi?list_id=145560&product=LibreOffice&query_format=advanced&status_whiteboard=bibisectrequest&status_whiteboard_type=allwordssubstr&title=Bug%20List&ctype=atom&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED</rss> Открыть этот лист в Bugzilla

    Кроме того, для всех нерешенных регрессий в LibreOffice можно попытаться использовать bibisecting.

    Поиск ошибок уже прошедших проверку на Bibisect

    Ссылки на запросы в Bugzilla смотрите тут.

    С учетом указанной выше информации добавленой к ошибке разработчик знает, что регрессия появилась между фиксациями fb754a0df859e30255c25af8fa19bfaa75f257e7 (good) and 2d19e9bb07ccff3134f855812dddfda5c07b1fe4 (bad) в мастере.

    > git log fb754a0df859e30255c25af8fa19bfaa75f257e7..2d19e9bb07ccff3134f855812dddfda5c07b1fe4
    

    В репозитории исходного кода будет показано 128 фиксаций в том числе та, которая спровоцировала ошибку. Это сильно облегчает поиск для разработчиков, и ускоряет исправление ошибки.

    ./opt/program/soffice -env:UserInstallation=file:///tmp/soffice-bisect

    Подробнее можно посмотреть:

    ./opt/program/soffice \
    -env:UserInstallation=file:///tmp/soffice-bisect-$(git rev-parse HEAD)

    Finding a fix

    Sometimes a bug is a collateral damage of another (possibly minor) bug, in a non obvious way. In such cases that other bug might be fixed on master, but was not backported to the release branch. To identify a problem-fixing commit you can use:

    git bisect start --term-new=fixed --term-old=unfixed
    git bisect fixed master
    git bisect unfixed <some-old-sha> # you can use "git log --reverse" to detect the first revision in the bibisected package

    As you test, say

    git bisect fixed
    or
    git bisect unfixed
    as appropriate.

    If the fix is small and important enough, it likely can be easily backported to the release branch.

    Checking out a specific commit based on source hash

    Sometimes you already know a specific source commit has/does not have the bug you are hunting.

    Copy the source hash from the LibreOffice git history and use it to grep in the bibisect repo log like so:

    git log --all --grep='29a9f433c268414747d8ec7343fc2b5987971738'

    Copy the commit hash of the bibisect repo and do a checkout for it to verify your assumption:

    git checkout 38758b70f5278d4d8292a2e857e80a9a1130f38e

    You can use the repo commit hash when determining the bad-good range to bisect:

    git bisect start 38758b70f5278d4d8292a2e857e80a9a1130f38e oldest

    Doing detective work inside a commit range

    In case your bibisect result is a range of commits and you have trouble locating the offending commit, you might make your life easier by searching with a keyword.

    An example for a case, where we know the problem is in Calc's Navigator view:

    git log --stat --pretty=short --graph 169bd7718264b0e312052757f9bbd2321e1399c2...ff8b873936aa72b17309da4bfc2775573a5b1f55 | grep -B 10 -A 10 --color=always "sc/source/ui/navipi" | less -R

    Adjust the -B and -A grep parameters to control how many lines before and after the hit you want to display. When piping to less, -R preserves the colouring of search results.

    Bisect skip hell

    Sometimes we get stuck in a miserable situation, where we have to use git bisect skip over and over again due to various reasons. There are ways of getting out of these infuriating messes and here we will show one of them.

    Example bug: tdf#123095

    Bug appeared in 4.0-4.1 range.

    There are lots of commits, where the autofilter is not shown at all, so have to skip those.

    We can use git bisect visualize to show us the remaining suspected commits:

    git bisect visualize --oneline > /some/path/bisect-viz-123095.txt

    The earliest bad results are at the top while the ones you have skipped are at the bottom. The commit below the bottom is the last known good one.

    The top results included

      b842ac1 source-hash-7b4d76772ef76a8de852ed647ed0cad368f70189
      40ef04e source-hash-dc173b7f2a550185404aacbc6da744cb6d1880fc
      8e697de source-hash-eb96e4325278f31b9e6fbc1d5c6a01543204ded6
    

    Doing git checkout b842ac1, test, continue with the next etc. it turns out the third one from the top was already a skippable commit.

    A range query with the source hashes in the style bottomcommit..firstbadcommit can be made.

    Searching for "filter" in the displayed results leads to a suspicious commit about sorting autofilter popup items.

    If soffice is failing with a non-zero exit code - this probably means a crash - a solution under QA/Bibisect/Automation#Tidbits for efficiency offers a script to ease the pain of repeatedly skipping failed probes.

    Finding source commits from bibisect

    If bibisect was done, but not likely to be correct or in a repository known to have large range of source commits, we can check the range by finding a previous build commit from the found one and then find the source range.

    $ git log -1 1f14665c5624bc7a502738aa8f4f2bd70a211e72^
    $ git log --oneline b6c016da23d309b4ac7d154bc33a22397974ed73..d85fd8a85501547d5bb87822d2589a07aed7f2d6

    Особые ситуации

    Работа в отдельном профиле пользователя

    Чтобы создать отдельный каталог пользователя в /tmp/ (который будет автоматически удалён при следующей перезагрузке системы):

    > ./opt/program/soffice -env:UserInstallation=file:///tmp/soffice-bisect
    

    Если вы хотите, чтобы каждый запуск программы создавал новый каталог с хэш-кодом фиксации git, вы можете добавить в конец имени каталога $(git rev-parse HEAD). Для примера:

    > ./opt/program/soffice \
    >     -env:UserInstallation=file:///tmp/soffice-bisect-$(git rev-parse HEAD)
    

    Finding a fix

    Problem / Messages:

       error: Your local changes to the following files would be overwritten by checkout:
         opt/program/pythonloader.pyc
         opt/program/uno.pyc
         opt/program/unohelper.pyc
       Please, commit your changes or stash them before you can switch branches.
       Aborting
    

    Иногда ошибка неочевидным путём является побочным эффектом другой (возможно маленькой) ошибки. В таких случаях ошибка может быть исправлена на ветке master, но не внесена в основную ветку. Вы можете найти исправление таким же способом как и ошибку, кроме того, что вам нужно вводить git bisect good за git bisect bad и наоборот. Если исправления небольшие и достаточно важные, это может легко быть перенесено в основную ветку.:

    git checkout .

    The above command will repair the problem. Afterwards you can start the next test run as usual with

    git bisect good # or git bisect bad

    If that does not solve the problem, you can try the following commands:

    git clean -fd
    git reset --hard

    The ultimate repair is to delete everything except one hidden .git/ folder, and do

    git checkout oldest

    Unable to start soffice

    Problem 1: Upon trying to run soffice within bibisect you receive the error "unexpected operator terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'

    Solution: Reset your libreoffice profile located in ~/.config/libreoffice. Make sure to backup the folder if you have any settings you'd like to preserve for use with your stable libreoffice release. After you're done with bibisect you can try to return your backed up profile to it's original location (ie. delete the new profile folder and replace it with the backed up one)

    Problem 2: Trying to run soffice within bibisect gives frequent errors such as "Application Error" and skipping via 'git bisect skip' is tedious.

    Solution: Upon an error, run one-line script to skip commit on error message and try the next one. Script will stop when soffice is successfully run and then you proceed with 'git bisect good' or 'git bisect bad'. If error is repeated, script can be run again.

    while (git clean -f -X && git bisect skip && ! instdir/program/soffice); do : ; done

    How to bisect RTL bugs

    In case you need to bisect a RTL ( Right-To-Left ) bug, please import this variable before calling LibreOffice:

    SAL_RTL_ENABLED=1

    How to bisect File Recovery bugs

    In case you need to bisect File Recovery bugs ( e.g. tdf#129210 ), comment out line OOO_DISABLE_RECOVERY=1 in file instdir/program/ooenv

    You may also use user control:

    soffice --norestore file-that-recovers.ext

    How to bisect file hanging / CPU or memory exhaustion bugs

    In case you need to bisect file hanging/memory exhaustion bugs, you may limit memory or CPU or time execution.

    In Linux, timeout utility can be used. To avoid confusion with built-in "timeout" command, here it's renamed to "tmt".

    For example, if LibreOffice 'good' commit opens a file with 1 GB of memory, you may set soffice memory limit to 1.500.000 kilobytes to avoid 'bad' commit hanging your computer.

    tmt -m 1500000 instdir/program/soffice

    Or, to limit CPU+SYS time (where normal time is seen with successful run):

    tmt -t 20 instdir/program/soffice

    More advanced option is to use benchexec utility. User needs to be added to the appropriate group (benchexec). Runexec can be used to execute a single command while measuring its resource consumption, similarly to the tool "time" but with more reliable time measurements and with measurement of memory usage.

    In Windows, process-governor utility can be used.

    Дополнительная информация

    Automation

    See the separate article on automating bisecting.

    Примечания

    • QA/Bibisect/Implementation - подробная информация о создании архивов для bibisect;
    • Bibisectzilla - информации о слиянии всех наших bibisect
    1. Могут быть до сих пор доступны на http://people.canonical.com/~j-lallement/libreoffice/binrepo/
    2. другие 250+ ошибок упоминаются в bibisect, но не имеют тегов. Возможно, просто забыли пометить
    3. сейчас хранится в http://people.canonical.com/~bjoern/bibisect/bibisect-42all.tar.xz , но скоро будут удалены как устаревшие
    4. он один заменяет оба следующие, более мелкие репозитории: в диапазоне от 4.2 до alpha1 и в диапазоне от alpha1 до точки ветвления 4.3 -- скорее всего, будет удален в ближайшее время
    5. Бьорн (Bjoern) создаёт постфактум репозиторий (после создания меток alpha или после ответвления) в автоматическом и понятным способом, с оптимизацией (например, отключением SDK). Миклош (Miklos) создаёт репозиторий на ежедневной основе (отсюда и название) из уже фрагментированной сборки. Поэтому его сборки в долгосрочной перспективе, вероятно, менее полезно (пока вы не охотитесь на проблемы dbgutil). Однако они очень полезны при отслеживании ошибок, которые произошли, например, на прошлой неделе, если меток в репозитории ещё не было. Это также значит, что если вы клонируете упоминаемый репозиторий через несколько дней после ответвления, он содержит только несколько фиксаций (commit). В этом случае вам может быть интересны старые версии. Это также причина, почему число в столбце размера постоянно изменяется.