Don't confuse stack limits with recursive trigger limits. The 16 limit refers to a DML operation that causes another DML operation (via triggers); you can only go 16 DML calls deep before your code will bail out. The stack, on the other hand, is a memory structure that keeps track of your function calls. This has a separate limit (much higher), and is reached through recursive function calls. Consider the following implementation of n! (factorial numbers):

public integer fn(integer x) {
  if(x==1) {
    return 1;
  }
  return x * fn(x-1);
}

If you call fn(1), the result is 1; the maximum stack depth reached is 1. If you call fn(3), the result is 3 * 2 * 1, or 6, and the total stack depth here is 3 (fn, once called, calls itself two more times to derive the final answer). Calling fn(1001) would result in a mathematical overflow, but if it didn't, the stack would reach a depth of 1001.

Each time you call a function, the "instruction pointer" for where that function was called is placed on the stack. When the called function returns, the instruction pointer reloads that stored location and continues from that point. Most modern developers are unaware of this feature of programming because it has been abstracted away by the language. In traditional 80x86 machine code, it was important to know how much stack space remained, because the system could only have up to 32767 recursive function calls ("local variables" also resided on the stack, and would reduce the total maximum recursive function calls one could make). In modern languages, the stack is managed for you, and you have no way to avoid this limitation short of creating your own stack structure and some fairly complex logic (plus, object-oriented programming makes this virtually impossible).

In Apex Code, you are limited to a maximum depth of 1000 recursive function calls. The usual way one would reach this limit is by either by calling a function that calls itself recursively, or, more likely, calling a function ("A") that calls a second function ("B") that in return calls function A again (thus, a possibly infinite loop).

You should analyze the functions involved in your code and see if there's a function that calls itself recursively, or calls another function that could call the first one again (or, it may even be 3 or more functions). The most usual cause I've observed with this limit is when implementing custom getter functions, where a getter for A calls the getter for B, which calls the getter for A. It is easy to track down once you know what you are looking for, but there are very few good examples of how this occurs and/or how to fix it out there on the forums or the Internet. Here's an (obvious) example:

public integer a { get { return b == null ? 1 : b + 1; } set; }
public integer b { get { return a == null ? 1 : a + 1; } set; }

What will happen if you try to access A or B? If you access, for example, A, it will call the getter for B (to check b == null), which in turn will call the getter for A (to check a == null), which will call the getter for B (to check b == null)... and so on recursively until the stack is exhausted. The solution to such a problem is typically to include a backing variable:

integer a1, b1;
public integer a { get { return b1 == null ? 1 : b1 + 1; } set { a1 = value; } }
public integer b { get { return a1 == null ? 1 : a1 + 1; } set { b1 = value; } }

This eliminates the possibility that the getters will be called recursively. Note that the value of a or b still depends on which one is accessed first, etc, but that's an exercise for another day.