bsdiff.exe を使用してソフトウェア パッチを作成し、それを bspatch.exe で適用していますが、これまでのところ 120 MB 未満のファイルで問題は発生していません。私が持っている 1 つのバイナリ ファイルは、以前は 21MB でしたが、現在は 77MB で、bsdiff が無期限にハングしているようです。
ドキュメントによると、「bsdiff はかなりメモリを消費します。最大 (17*n,9*n+m)+O(1) バイトのメモリが必要です。n は古いファイルのサイズ、m はサイズです。新しいファイルの。」これは大きなファイルの問題を説明していますが、デルタが大きくなると問題が発生するようです。
誰もこれに関する情報を持っていますか? 何でも役に立ちます、ありがとう！
また、2MB の DSP 実行可能コードを含むファイルを処理しようとすると、bsdiff がクラッシュするという問題もありました。
いくつかのデバッグの後、問題は「古い」ファイルに基づいてサフィックス配列を作成するために使用される qsufsort 関数内にあると判断しました。qsufsort は、自分自身を再帰的に呼び出す split という関数を呼び出します。クラッシュの場合、再帰呼び出しが何度も発生するため、プログラムはスタック領域を使い果たし、例外をスローします。
このスレッドで提案されているように: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409664 解決策は、qsufsort を別の解決策に置き換えてサフィックス配列を生成することです。サフィックス配列の Wikipedia エントリは SA-IS を参照しているため、ここからソースをダウンロードしました: https://sites.google.com/site/yuta256/sais
次に、bsdiff.c を sais.c および sais.h と一緒に再構築し、qsufsort の呼び出しを次のように置き換えました。
I[0] = オールドサイズ; sais(old, I+1, oldsize);
これで bsdiff は毎回動作し、さらに高速になりました!
ここにリストされている他のバイナリ差分プログラムのいずれかを試してください。
https://stackoverflow.com/questions/688504/binary-diff-tool-for-very-large-files
2 つのファイルの違いには、両方のファイルを表すために必要なメモリ以上のメモリが必要です。そのため、多くの違いがある 2 つのバイナリ ファイルを処理すると、2 つの同一ファイルよりも多くのメモリが必要になります。
ソフトウェアにバグがあるため、ファイルが小さいと問題があります。これを書いた Colin Percival はバグを認めており、修正する時間がないと述べています。