# 质控/二进制二分查找（Bibisect）

< QA
This page is a translated version of the page QA/Bibisect and the translation is 68% complete.
Outdated translations are marked like this.
Other languages:
Bahasa Indonesia • ‎English • ‎dansk • ‎español • ‎italiano • ‎русский • ‎中文（中国大陆）‎ • ‎日本語

## 一般性说明

“二进制二分查找”仅需要6个简单的步骤即可完成：

1. 搭建环境，包括安装必要的软件。
2. 下载 bibisect 仓库（其实质是集合了很多 LibreOffice 二进制包的 git 仓库，仓库中的每个commit对应的对 LibreOffice 源代码的一次编译）。
3. 使用该 bibisect 仓库对 bug 进行二分查找。
4. 获得二分查找的日志。
5. 将日志附加到 bug 报告中。
6. 更新 bug 报告的相应字段。
7. 移除 keyword 字段中的 'bibisectRequest' 关键词，并添加 'bibisected' 关键词。
8. 如果已经知道了究竟是哪个 commit 导致了问题，请同时添加 'bisected' 关键词，并将对应的开发者添加到 CC 列表中，并添加评论：'Adding Cc: to <开发者的名字>'

Some bibisect repositories have ranges of source commits folded into a single chunk. If after completing a bibisect you are presented with only a single one of these chunk commits, you can get the range by first copying the hash (note: not the source hash) and using it in a git log command like so:

git log c3f9dc54188b316a61dd871b63734d49b05f5d7f

## 限制

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.

## 版本

Bibisect 仓库的版本包含在了不同的操作系统相关的介绍里，请见上面的 #详情 部分。

### 无法进行 Bibisect 的 bug

• Bugs that don't show up on a supported platform (see #Limitations)
• Bugs that predate our bibisect builds (We're working on extending the range covered)
• Bugs that depend upon build options not enabled in the TDF builds (e.g. -kde)

If a bug with bibisectRequest Keyword is found to be not bibisectable, leave a comment on the bug explaining why we're not able to use bibisect to track down the introduction of this problem, and replace Keyword bibisectRequest with notBibisectable. If a bug predates bibisect builds, replace Keyword bibisectRequest with preBibisect.

## 找到 bug

### 找到已经完成了“二进制二分查找”的 bug

git log fb754a0df859e30255c25af8fa19bfaa75f257e7..2d19e9bb07ccff3134f855812dddfda5c07b1fe4

## 特殊情况

### 二分查找与特定语言（比如中日韩语言界面）相关的 bug

1. program/resource/<您的语言标记>
2. share/registry/Langpack-<您的语言标记>.xcd
3. share/registry/res/fcfg_langpack_<您的语言标记>.xcd
4. share/registry/res/registry_<您的语言标记>.xcd

### 以单独的“用户配置文件”运行程序

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

./opt/program/soffice \
-env:UserInstallation=file:///tmp/soffice-bisect-$(git rev-parse HEAD) ### 逆向 bibisect（找到修复了某个问题的提交） 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. ### 根据源代码的 hash 值检出某个特定的提交 有时候，您已经知道，在之前的某个特定的源代码 commit 中不存在您正在测试的 bug。 这种情况下，复制 LibreOffice 源代码 git 历史中的这个 source hash，并用它再 bibisecct 仓库的 log 中进行 grep： git log --all --grep='29a9f433c268414747d8ec7343fc2b5987971738' 然后复制 bibisect 中的 commit hash，检出这个 commit，然后验证您的假设： git checkout 38758b70f5278d4d8292a2e857e80a9a1130f38e 然后您可以使用 bibisect 仓库的 commit hash 来决定 bisect 过程中的 bad 和 good 的范围： git bisect start 38758b70f5278d4d8292a2e857e80a9a1130f38e oldest ### 在某个 commit 范围内进行侦察 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（跳过无法运行的 commit） 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. 示例 bug: tdf#123095 Bug 出现在 4.0-4.1 范围内。 这里有太多的与自动筛选（autofilter）无关的 commit 了，因此需要忽略这些。 我们可以使用 git bisect visualize 来显示剩下的有嫌疑的 commits: git bisect visualize --oneline > /some/path/bisect-viz-123095.txt 顶部显示的是最早的“坏”结果，底下显示的是您已经忽略的内容。再往下显示的是最近已知的“好”结果。 我的顶部结果包括：  b842ac1 source-hash-7b4d76772ef76a8de852ed647ed0cad368f70189 40ef04e source-hash-dc173b7f2a550185404aacbc6da744cb6d1880fc 8e697de source-hash-eb96e4325278f31b9e6fbc1d5c6a01543204ded6  因此，我进行 git checkout b842ac1，测试检出的程序，再继续下一个，重复这个步骤。看起来顶部的第三个是一个可以忽略的提交。 我使用 source hash 按照 bottomcommit..firstbadcommit 的方式构造了一个查询 打开查询界面后，我进而搜索 "filter"，然后找到了一个可疑的 commit，这个提交是关于对自动筛选的结果进行排序的。 如果在 bibisect 过程中 soffice 在某个或某几个 commit 下频繁崩溃，让您无法准确判断代码范围，那么 #Tidbits for efficiency 章节提供了解决办法。 ### 使用 bibisect 找到源代码 commit 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

## 故障排除

Please add your problems and how you solved them. This section covers issues that affect more than one OS. For OS-specific issues, please see the individual OS wiki pages.

### 无法提取文件

If you can't extract files (you should get an error message). Try to rename the file from *.tar.lzma to *.tar.xz.

### 已安装的 LibreOffice 被意外修改

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


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

### 无法启动 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

### 如果 bisect RTL（从右向左）类型的 bug

SAL_RTL_ENABLED=1

### 如何 bisect 文件恢复类型的 bug

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.

### 备注

Bibisect 仓库是如何生成的：