xdelta3: : XD3_TOOFARBACK #188
Comments
Original comment by |
|
Original comment by
|
Original comment by |
|
Why did this bug get closed? |
|
Accidental close. Yes, please supply a pair of files, that's always helpful. |
|
Okay, so here's a demo pair of files: Basically I was trying to patch the .mp4 (which is the Big Buck Bunny 4k 60fps file I got from the linked site and tried to patch it to a .mkv (which was created by mkvmerge, though I didn't add subtitles or other streams to the .mkv in this example, just remuxed it with titles for the streams). It also happens with other .mp4 > .mkv files, but not with every file (I tested a 60MB file and it worked fine there). Launching xdelta via cmd the following way: Patching the same files the same way with an older version without increasing the block size (3.0.2), xdelta doesn't abort and the patch works as intended, though using an increased block size (1GiB) provided by one of the bug reporters from Google Code ( |
|
I faced a very similar issue, but the difference is that.. I cannot provide the files, but interesting to note is that the working diff here can be further compressed to 17% ratio. |
|
I forgot to mention in my comment earlier that I didn't test 3.0.8 or 3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass without XD3_TOOFARBACK in 3.0.8, I don't know for sure though. |
|
I mentioned 3.0.8 because the original issue was opened on 3.0.8.
|
|
Thank you. I will investigate this immediately. On Fri, Apr 24, 2015 at 3:25 PM, mykohsu notifications@github.com wrote:
|
|
I can provide screenshots or run a debug build but cannot provide any
|
|
It breaks at this line: It is easy to reproduce:
Restoring if statement, fixes it. Line 4699 in eb49cd2 I compiled it (source from Oct 12, 2014, if instead of assertion) and I can create a patch and use it without problems. |
|
OK, makes sense. That if statement smells--hides bugs elsewhere. |
|
Fix here: I'm going to work on a test and then a release. Thanks. |
|
Correction: |
|
I can confirm that the issue is fixed for me. |
|
#188 (comment), now works. |
|
Could we please get a 3.0.10 release that includes this fix? |
|
Yes. I'll do my best to have it done tomorrow night. On Sun, Jul 5, 2015 at 10:49 AM, Jan Alexander Steffens <
|
|
@jmacd What development environment are you using? Visual Studio 2010? Will try the new one, MinGW-w64 4 (GCC 5.1.0) |
|
@mgrinzPlayer I usually develop with llvm tools (on OS X), then update both I like your recommendation and have a mingw-w64-build running (on said On Mon, Jul 6, 2015 at 2:20 AM, mgrinzPlayer notifications@github.com
|
|
@jmacd Index: xdelta3-internal.h
===================================================================
--- xdelta3-internal.h
+++ xdelta3-internal.h
@@ -116,10 +116,8 @@
* absence of the '_' prefix) but they were initially buggy. So,
* always use the native '_'-prefixed version with Win32. */
#ifdef _WIN32
-#define vsnprintf_func(str,size,fmt,args) \
- _vsnprintf_s(str,size,size-1,fmt,args)
-#define snprintf_func(str,size,fmt,...) \
- _snprintf_s(str,size,size-1,fmt,__VA_ARGS__)
+#define vsnprintf_func _vsnprintf
+#define snprintf_func _snprintf
#else
#define vsnprintf_func vsnprintf
#define snprintf_func snprintfOtherwise, binaries won't work on WinXP. |
|
OK, I have managed to almost build for mingw. This will take a bit more work, but I like it. |
|
I wonder if the comment I removed in |
|
EDIT: There are so many “a portable (v)snprintf” implementations in the internet... Maybe write your own? and change c99_vsnprintf so it won't use _vsnprintf_s OR |
|
I've written one printf implementation (at work) and I refuse to do it I'm running into trouble with the mingw tools, I wonder if you could share On Thu, Jul 9, 2015 at 4:16 AM, mgrinzPlayer notifications@github.com
|
|
I'm using this MinGW-w64 installer: I installed it on pure Windows 10 Technical Preview (and that means: no other tools like MSYS, cygwin, etc) Build info: Make file: CC = GCC
SOURCES = xdelta3-blkcache.h \
xdelta3-cfgs.h \
xdelta3-decode.h \
xdelta3-djw.h \
xdelta3-fgk.h \
xdelta3-hash.h \
xdelta3-internal.h \
xdelta3-list.h \
xdelta3-lzma.h \
xdelta3-main.h \
xdelta3-merge.h \
xdelta3-second.h \
xdelta3-test.h \
xdelta3.h \
xdelta3.c
TARGETS = xdelta3-i686 \
xdelta3-x86_64
CFLAGS= -Wall -Wshadow -fno-builtin -O3
XDWINFLAGS:=-DXD3_STDIO=0 -DXD3_POSIX=0 -DXD3_WIN32=1 -DEXTERNAL_COMPRESSION=0 \
-DREGRESSION_TEST=1 -DSHELL_TESTS=0 -DXD3_DEBUG=0 \
-DSECONDARY_DJW=1 -DSECONDARY_FGK=1 -DSECONDARY_LZMA=0 \
-DXD3_MAIN=1 -DXD3_USE_LARGEFILE64=1
xdelta3-i686: $(SOURCES)
$(CC) $(CFLAGS) xdelta3.c -lm -o xdelta3-i686.exe \
$(XDWINFLAGS)
xdelta3-x86_64: $(SOURCES)
$(CC) $(CFLAGS) xdelta3.c -lm -o xdelta3-x86_64 \
$(XDWINFLAGS)
Compiled with this bat: set PATH=C:\MinGW-W64\mingw32\bin
cd /d "C:\xdelta3"
mingw32-make xdelta3-i686PS: I also have a question. Can you compile (Gentoo or OS X) with the newest XZ Utils from http://tukaani.org/xz , this package xz-5.2.1-windows.zip (1352 KiB) released on 2015-02-26 ? I tried without success: xdelta3: testing decompress_single_bit_error (XD3_SEC_LZMA)...xdelta3: non-failures 46; expected 54 failed: incorrect: XD3_INTERNAL xz-5.0.5-windows is the recent one which works. |
|
Sorry for late edit. I've internet connection problems (power failures due to recent strong wind) First for 32bit: |
|
PS: If you read messages via email, you may miss few updated/edited comments. Sorry about that. |
|
Same error with 3.0.9 on Linux x64 - pair of files + truncated (?) xdelta output are at https://mega.nz/#F!CgQiAQrT!Z1LKbCLBwRrRNyH_OFm5Vw |
|
@voltagex , It has already been solved. Try [this one win32bit](https://googledrive.com/host/0BwMAnE6mjogMfnk3Mk94Qlh6UVpENU5pQ2FRU2Z4NFZ5R0QtVlhFVzVadDRYQm9jWVVodWc/xdelta-devel commit ab5fac1/xdelta3 mingw-w64 gcc5.1.0 lzmaEnabled i686.exe). Or wait for next official version. |
|
I did succeed at building mingw binaries w/ my release script, but haven't On Sun, Jul 12, 2015 at 2:57 AM, mgrinzPlayer notifications@github.com
|
|
Mingw binaries are testing well. I may be able to make a release tomorrow. On Sun, Jul 12, 2015 at 8:01 AM, Josh MacDonald josh.macdonald@gmail.com
|
|
I tested your recent binaries. Looks like "XD3_TOOFARBACK" is now fixed. |
3.0.11:
Fixes and one major bug:
Decoder block cache poor cache performance (source buffer was effectively half-sized)
and a number of minor and non-critical bugs:
Number of decoder crashes discovered by American Fuzzy Lop
Lingering XD3_TOOFARBACK issues
Improved testing & portability
3.0.10
Primarily fixes jmacd/xdelta#188
Continuing work on portability, new release script runs build+test in more configurations.
Windows executable built with MinGW cross compiler.
3.0.9
Builds (more) cleanly on newer compilers.
Improvements in "printf" usage & portability Several minor bug fixes. Move to Github.
3.0.8
Windows build now includes support for liblzma secondary compression with "-S lzma". (Sorry for the delay.)
3.0.11:
Fixes and one major bug:
Decoder block cache poor cache performance (source buffer was effectively half-sized)
and a number of minor and non-critical bugs:
Number of decoder crashes discovered by American Fuzzy Lop
Lingering XD3_TOOFARBACK issues
Improved testing & portability
3.0.10
Primarily fixes jmacd/xdelta#188
Continuing work on portability, new release script runs build+test in more configurations.
Windows executable built with MinGW cross compiler.
3.0.9
Builds (more) cleanly on newer compilers.
Improvements in "printf" usage & portability Several minor bug fixes. Move to Github.
3.0.8
Windows build now includes support for liblzma secondary compression with "-S lzma". (Sorry for the delay.)
Original issue reported on code.google.com by
Qokelate@gmail.comon 28 Aug 2014 at 9:39The text was updated successfully, but these errors were encountered: