mozillarrは、GDBリバースデバッグのより堅牢な代替手段です。
https://github.com/mozilla/rr
GDBの組み込みの記録と再生には厳しい制限があります。たとえば、AVX命令がサポートされていません。gdbの逆デバッグが「プロセスレコードはアドレスで命令0xf0dをサポートしていません」で失敗します。
rrの利点：
- 現在、はるかに信頼性があります。いくつかの複雑なソフトウェアを比較的長時間実行してテストしました。
- また、gdbserverプロトコルを備えたGDBインターフェースを提供し、優れた代替品になります
- ほとんどのプログラムでパフォーマンスがわずかに低下しますが、測定を行わないと自分で気づきませんでした
- 生成されたトレースは、非決定論的なイベントがほとんど記録されていないため、ディスク上で小さいです。これまでのところ、それらのサイズについて心配する必要はありませんでした。
rrは、スレッドスイッチなどのすべての非決定論的イベントで何が起こったかを記録する方法で最初にプログラムを実行することによってこれを実現します。
次に、2回目の再生実行中に、驚くほど小さいトレースファイルを使用して、元の非決定論的実行で発生したことを正確に再構築しますが、決定論的な方法で順方向または逆方向に再構築します。
rrはもともとMozillaによって開発され、翌日の夜間テストで発生したタイミングのバグを再現できるようにしています。ただし、実行中に数時間しか発生しないバグがある場合は、逆デバッグの側面も基本です。これは、前の状態が後の障害につながった原因を調べるために戻ることがよくあるためです。
次の例では、その機能の一部、特に展示reverse-next、reverse-stepおよびreverse-continueコマンドを。
Ubuntu 18.04にインストール：
sudo apt-get install rr linux-tools-common linux-tools-generic linux-cloud-tools-generic
sudo cpupower frequency-set -g performance
# Overcome "rr needs /proc/sys/kernel/perf_event_paranoid <= 1, but it is 3."
echo 'kernel.perf_event_paranoid=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
テストプログラム：
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int f() {
int i;
i = 0;
i = 1;
i = 2;
return i;
}
int main(void) {
int i;
i = 0;
i = 1;
i = 2;
/* Local call. */
f();
printf("i = %d\n", i);
/* Is randomness completely removed?
* Recently fixed: https://github.com/mozilla/rr/issues/2088 */
i = time(NULL);
printf("time(NULL) = %d\n", i);
return EXIT_SUCCESS;
}
コンパイルして実行します。
gcc -O0 -ggdb3 -o reverse.out -std=c89 -Wextra reverse.c
rr record ./reverse.out
rr replay
これで、GDBセッション内にとどまり、デバッグを適切に逆にすることができます。
(rr) break main
Breakpoint 1 at 0x55da250e96b0: file a.c, line 16.
(rr) continue
Continuing.
Breakpoint 1, main () at a.c:16
16 i = 0;
(rr) next
17 i = 1;
(rr) print i
$1 = 0
(rr) next
18 i = 2;
(rr) print i
$2 = 1
(rr) reverse-next
17 i = 1;
(rr) print i
$3 = 0
(rr) next
18 i = 2;
(rr) print i
$4 = 1
(rr) next
21 f();
(rr) step
f () at a.c:7
7 i = 0;
(rr) reverse-step
main () at a.c:21
21 f();
(rr) next
23 printf("i = %d\n", i);
(rr) next
i = 2
27 i = time(NULL);
(rr) reverse-next
23 printf("i = %d\n", i);
(rr) next
i = 2
27 i = time(NULL);
(rr) next
28 printf("time(NULL) = %d\n", i);
(rr) print i
$5 = 1509245372
(rr) reverse-next
27 i = time(NULL);
(rr) next
28 printf("time(NULL) = %d\n", i);
(rr) print i
$6 = 1509245372
(rr) reverse-continue
Continuing.
Breakpoint 1, main () at a.c:16
16 i = 0;
複雑なソフトウェアをデバッグする場合、クラッシュポイントに到達してから、深いフレームに陥る可能性があります。その場合、reverse-nextより高いフレームでは、最初に次のことを行う必要があることを忘れないでください。
reverse-finish
そのフレームまでupは、通常のことをするだけでは十分ではありません。
私の意見では、rrの最も深刻な制限は次のとおりです。
UndoDBはrrの商用代替手段です：https：//undo.ioどちらもトレース/リプレイベースですが、機能とパフォーマンスの点でどのように比較されるかはわかりません。