Segmentation fault git read-tree

i pushed the branches necessary to reproduce this right
before it happened, so you should be able to pull them
and try it yourself.

thanks,
-Len

[lenb@t61 acpi (test)]$ git push lenb
lenb@master.kernel.org's password:
Counting objects: 723, done.
Compressing objects: 100% (237/237), done.
Writing objects: 100% (492/492), 82.22 KiB, done.
Total 492 (delta 389), reused 337 (delta 249)
To master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
   93d7446..dba92d3  linus -> linus
   93d7446..dba92d3  release -> release
   93d7446..c68a500  suspend -> suspend
   93d7446..5dceb6d  test -> test
[lenb@t61 acpi (test)]$ git merge test suspend
Already up-to-date with 5dceb6d3377c3cbd06f7b3282fec0e201273c302
Trying simple merge with c68a5009ab9938af22af668e0e2d646d2482c866
/home/lenb/bin/git-merge-octopus: line 52: 24287 Segmentation fault      git read-tree -u -m --aggressive $common $MRT $SHA1
Merge with strategy octopus failed.
[lenb@t61 acpi (test)]$ git merge test suspend
fatal: unable to create '.git/index.lock': File exists
Already up-to-date with 5dceb6d3377c3cbd06f7b3282fec0e201273c302
Trying simple merge with c68a5009ab9938af22af668e0e2d646d2482c866
fatal: unable to create '.git/index.lock': File exists
Merge with strategy octopus failed.
[lenb@t61 acpi (test)]$ git --version
git version 1.5.4.4.537.gb75aa
[lenb@t61 acpi (test)]$

On Thu, 13 Mar 2008, Len Brown wrote:

i pushed the branches necessary to reproduce this right
before it happened, so you should be able to pull them
and try it yourself.

Ok, I can reproduce this, I'm on it like a maggot on a two-week-dead baby 
donkey.

		Linus

On Thu, 13 Mar 2008, Linus Torvalds wrote:

Ok, I can reproduce this, I'm on it like a maggot on a two-week-dead baby 
donkey.

Ooh, interesting. Compiling with debugging makes the SIGSEGV go away, and 
replaces it with an endless loop.

The SIGSEGV when non-debugging seems to be due to a corrupt "info->prev" 
pointer chain, but this was less obvious than I hoped it would be.

Still looking.

		Linus

On Thu, 13 Mar 2008, Linus Torvalds wrote:

Ok, I can reproduce this, I'm on it like a maggot on a two-week-dead baby 
donkey.

Ok, that was embarrassing.

This should fix it. Spot the stupid stack corruption..

		Linus

---
 unpack-trees.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/unpack-trees.c b/unpack-trees.c
index be89d52..b62b054 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c

@@ -8,6 +8,8 @@
 #include "progress.h"
 #include "refs.h"
 
+#define MAX_UNPACK_TREES 4
+
 static void add_entry(struct unpack_trees_options *o, struct cache_entry *ce,
 	unsigned int set, unsigned int clear)
 {

@@ -123,7 +125,7 @@ static int unpack_index_entry(struct cache_entry *ce, struct unpack_trees_option
 int traverse_trees_recursive(int n, unsigned long dirmask, unsigned long df_conflicts, struct name_entry *names, struct traverse_info *info)
 {
 	int i;
-	struct tree_desc t[3];
+	struct tree_desc t[MAX_UNPACK_TREES];
 	struct traverse_info newinfo;
 	struct name_entry *p;
 

@@ -327,7 +329,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
 {
 	static struct cache_entry *dfc;
 
-	if (len > 4)
+	if (len > MAX_UNPACK_TREES)
 		die("unpack_trees takes at most four trees");
 	memset(&state, 0, sizeof(state));
 	state.base_dir = "";