我正在使用bsdiff.exe构建一个软件补丁，并将其与bspatch.exe一起应用，到目前为止，对于小于120MB的文件没有任何问题。我有一个二进制文件以前是21MB，现在是77MB，而bsdiff似乎无限期地悬挂在它上面。
根据documentation，“bsdiff非常需要内存。它需要max（17 * n，9 * n + m）+ O（1）字节的内存，其中n是内存的大小旧文件和m是新文件的大小。“这解释了大文件的问题，但是当 delta 更大时，似乎会出现问题。
有没有人有任何相关信息？任何事都会有所帮助，谢谢！
答案 0 :(得分：5)
在尝试处理只包含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
然后我与sais.c和sais.h一起重建了bsdiff.c并将调用替换为qsufsort：
我[0] = oldsize; sais（old，I + 1，oldsize）;
现在bsdiff每次都有效，而且速度也快！
答案 1 :(得分：0)
尝试此处列出的其他二进制差异程序之一：
Binary diff tool for very large files?
两个文件之间的差异要求内存超出代表两个文件所需的内存。因此，处理两个具有许多差异的二进制文件将需要比两个相同文件更多的内存。
由于软件中存在错误，因此较小的文件存在问题。编写它的人科林·珀西瓦尔已经承认了这个漏洞，并说他没有时间修复它。