Stack overflow while merging the given VCDIFF files

[GoogleCodeExporter]

What steps will reproduce the problem?

#1. Unzip the attached deltatest1.zip file to a directory, say c:\deltatest1

#2. Open command prompt (Start->Run->cmd.exe)

#3. Change directory to extracted folder, say "cd c:\deltatest1"

#3. Run test.bat

What is the expected output? What do you see instead?
* Merged DIFF file.
* xdelta3.exe crashes with stack overflow error.

What version of the product are you using? On what operating system?
xdelta version: 3.0.6
OS: Windows 2008 x64 R2 SP1, Windows 2003 R2 x64 SP2

Please provide any additional information below.
Issue reproducible also using xdelta version: 3.0z

Thanks in advance for looking into this issue.

Regards,
Thanga

Original issue reported on code.google.com by thanga...@gmail.com on 5 Aug 2013 at 11:47

Attachments:

• deltatest1.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue reproducible even with following latest Xdelta versions as well:

xdelta3-3.0.7.x86-32.exe
xdelta3-3.0.7.x86-64.exe

Original comment by thanga...@gmail.com on 6 Aug 2013 at 12:10

[GoogleCodeExporter]

Just to clarify - the given sample VCDIFF files are forward deltas in 
incremental order, and merge command preserves this order.

Original comment by thanga...@gmail.com on 6 Aug 2013 at 12:50

[GoogleCodeExporter]

Note to developer: this issue happens because of recursion in 
xd3_merge_source_copy. The code already has comments that this logic needs to 
be re-worked because of inefficiency.

Original comment by jace...@gmail.com on 19 Sep 2013 at 10:31

[suryagutta]

Hi, We are also seeing the same issue. xdelta "merge" fails when delta size increases. What's the expected release of this fix? Thanks in advance for your help.

[jmacd]

Admittedly, the algorithm used in the "merge" command is not a fast one--and it can be improved to avoid recursion--but I have to place a higher priority on finishing the 64bithash improvements (issue 127). Until then, I'd like to recommend increasing the stack size of the program.

I tested this with my latest build using the MinGW toolchain and do not see a stack overflow, which means by default the MinGW stacksize is large enough for your test. Presumably the default stacksize of the MS VC++ toolchain used through release 3.0.9 was too small.

The version 3.0.10 release was also built with MinGW, so should address this specific test. I can raise the default used in the next release, if that will help. http://stackoverflow.com/questions/3557691/increase-stack-size-when-compiling-with-mingw

[jmacd]

New releases 3.0.11 and 3.1.0 address this with a larger stack. Please update this bug if a still-larger stack is needed; eventually, the recursive algorithm should be replaced with something less stack-intensive.