bsdiff.exe를 사용하여 소프트웨어 패치를 작성하고 bspatch.exe를 적용하여 120MB 미만의 파일에는 문제가 없었습니다. 내가 가지고있는 하나의 바이너리 파일은 이전에 21MB 였고 현재 77MB이고 bsdiff는 무기한으로 정지 된 것처럼 보입니다.bsdiff.exe가이 작은 파일에 문제가있는 이유는 무엇입니까?
documentation에 따르면 "bsdiff는 메모리가 많이 필요하며 max (17 * n, 9 * n + m) + O (1) 바이트의 메모리가 필요합니다. 여기서 n은 이전 파일의 크기이고 m은 새 파일의 크기입니다. " 큰 파일의 문제를 설명하는 있지만 델타 큰 경우 문제가 발생하는 것으로 보입니다.
누구와 관련하여이 정보가 있습니까? 아무거나는 도움이 될 것입니다, 감사합니다!
는 여기에 나열된 다른 바이너리 diffing의 프로그램 중 하나를 시도해보십시오 두 파일 사이
Binary diff tool for very large files?
의 차이는 위 두 파일을 표현하는 데 필요한 메모리를 넘어 메모리를 필요로한다. 따라서 많은 차이가있는 두 바이너리 파일을 처리하려면 두 개의 동일한 파일보다 많은 메모리가 필요합니다.
소프트웨어에 버그가있어서 파일 크기가 작아서 문제가 있습니다. 콜린 퍼시발 (Colin Percival)은이 글을 쓴 사람이 버그를 인정하고 그것을 고칠 시간이 없다고 말했다.
는 또한 DSP 실행 코드의 단지 2MB의 포함 된 파일을 처리 할 때 bsdiff가 충돌하는 문제가 있었다.
일부 디버깅 후 "이전"파일을 기반으로 접미사 배열을 만드는 데 사용되는 qsufsort 함수 내에 문제가 있음을 확인했습니다. qsufsort는 split이라는 함수를 호출하여 재귀 적으로 호출합니다. 충돌 사건에서 재귀 호출은 프로그램이 스택 공간을 다 써 버리고 예외를 던질 때까지 여러 번 발생합니다.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409664 해결책은 qsufsort를 다른 해결책으로 대체하여 접미사 배열을 생성하는 것입니다. 접미사 배열에 대한 위키 백과 항목은 SA-IS를 참조하고 그래서 나는 여기에서 소스 다운로드 : 다음 함께 sais.c 및 sais.h와 bsdiff.c을 다시 https://sites.google.com/site/yuta256/sais
과 함께 qsufsort에 대한 호출을 대체 :
I [0] = oldsize; sais (이전, I + 1, 이전 크기);
이제는 bsdiff가 매번 작동하며 더 빠릅니다!
나는 그 기능에서 bsdiff 크래시도했다. 당신이 말한대로 sais와 교환하고, 중대한 일하는 것을 보인다! 나는 알고리즘에 익숙하지 않다. 나는 당신의 전화 대체가 옳았기를 바랄뿐입니다. – Zorg
버그를 지적 할 수 있습니까? 이 포크에서 수정되었는지 조사하고 싶습니다 - https://github.com/mendsley/bsdiff –
정확히 어디서 버그인지는 모르겠지만 여기에 알고리즘 적으로 고정 될 수 있다고 Colin이 말한 곳이 있습니다 : http : //debian.2.n7.nabble.com/Bug-409664-bsdiff-is-extremely-slow-on-some-files-sometimes-hangs-td1738215.html –