A crash means you have a programming error which you need to find and fix. This doesn't mean your approach is wrong. Maybe it ran out of stack.
If that's the case and you can't increase the stack, try an iterative solution instead. For example, first initialise an array as long as the number of rows in the table to -1 (represented as a 4th column):
101 | 102 | 103 | -1
102 | 104 | 105 | -1
103 | 106 | 0 | -1
104 | 107 | 108 | -1
105 | 109 | 0 | -1
106 | 0 | 0 | -1
107 | 110 | 0 | -1
108 | 0 | 0 | -1
109 | 0 | 0 | -1

Scan through the table and where number of children is known, fill it in.
So we don't know for 101, because rows 102 and 103 are -1.
Same for 102, 103, 104, 105.
106 has no children so set the -1 to 0.
Not sure about 107 because there isn't a 110 in the table.
108 has no children so set the -1 to 0, ditto 109 (and maybe 110 as I imagine at this stage you also have 110 | 0 | 0 [| -1]). So we now have:
101 | 102 | 103 | -1
102 | 104 | 105 | -1
103 | 106 | 0 | -1
104 | 107 | 108 | -1
105 | 109 | 0 | -1
106 | 0 | 0 | 0
107 | 110 | 0 | -1
108 | 0 | 0 | 0
109 | 0 | 0 | 0
110 | 0 | 0 | 0

We made changes so start again from the top of the table.
101: lookup the 4th column for 102,103, both are -1, can't tell, move onto the next.
102: lookup 104,105, ditto
103: aha, 106 has no children so we can tell now that 103 has precisely 1 child.
104: 108 is resolved but 107 isn't so we can't tell yet.
105: has child 109 which is resolved -> 1
107: skip this because column 4!=-1

(you can do the rest) At the end of this iteration we should have:
101 | 102 | 103 | -1
102 | 104 | 105 | -1
103 | 106 | 0 | 1
104 | 107 | 108 | -1
105 | 109 | 0 | 1
106 | 0 | 0 | 0
107 | 110 | 0 | 1
108 | 0 | 0 | 0
109 | 0 | 0 | 0
110 | 0 | 0 | 0

Only 3 -1's to resolve in the next iteration which should end:
101 | 102 | 103 | -1
102 | 104 | 105 | -1
103 | 106 | 0 | 1
104 | 107 | 108 | 3
105 | 109 | 0 | 1
106 | 0 | 0 | 0
107 | 110 | 0 | 1
108 | 0 | 0 | 0
109 | 0 | 0 | 0
110 | 0 | 0 | 0

and the final result should be:
101 | 102 | 103 | 9
102 | 104 | 105 | 6
103 | 106 | 0 | 1
104 | 107 | 108 | 3
105 | 109 | 0 | 1
106 | 0 | 0 | 0
107 | 110 | 0 | 1
108 | 0 | 0 | 0
109 | 0 | 0 | 0
110 | 0 | 0 | 0

So the pseudocode for this will be something like:
Code:
changes_made=1
while (changes_made)
{
  changes_made=0
  for each row
  {
    if col4==-1
    {
      lookup col4 in row corresponding to left node
      lookup col4 in row corresponding to right node
      if both are not -1
      {
        col4=1 if left node is !0 +
               1 if right node is !0 +
               col4 from left node's col4 +
               col4 from right node's col4
        changes_made=1
      }
    }
  }
}
If you store these intermediate results in the table then you would need to make sure that whenever a row was modified that the dependent rows were also updated. So let's add a node 111 to 108:
101 | 102 | 103 | 9 !!
102 | 104 | 105 | 6 !!
103 | 106 | 0 | 1
104 | 107 | 108 | 3 !!
105 | 109 | 0 | 1
106 | 0 | 0 | 0
107 | 110 | 0 | 1
108 | 111 | 0 | 0
109 | 0 | 0 | 0
110 | 0 | 0 | 0
111 | 0 | 0 | 0
So we could increase 108's col4 by 1 at this point but we need then to recalculate the results for any dependent rows. You could do this by working backwards: 104 contains a reference to 108 so set col4=-1. 102 refers to 104 so set that to -1, and 101 to 102:
101 | 102 | 103 | -1
102 | 104 | 105 | -1
103 | 106 | 0 | 1
104 | 107 | 108 | -1
105 | 109 | 0 | 1
106 | 0 | 0 | 0
107 | 110 | 0 | 1
108 | 111 | 0 | 0
109 | 0 | 0 | 0
110 | 0 | 0 | 0
111 | 0 | 0 | 0
then rerun the iteration to resolve the -1's. Or you could recalculate as you work backwards, whichever is easier.
sachinb like this