What is a `StackOverflowError`, what causes it, and how should I deal with them?

What is a StackOverflowError?

Take a look at the following two methods:

    public static void foo() {
        try {
            foo();
        } finally {
    	    foo();
        }
    }
    	
    public static void bar() {
        bar();
    }

---

Running `bar()` clearly results in a `StackOverflowError`, but running `foo()` does not (the program just seems to run indefinitely). *Why is that?*

Try-finally block prevents StackOverflowError

I have the following piece of code which fails with the following error:

&gt; RuntimeError: maximum recursion depth exceeded

I attempted to rewrite this to allow for tail recursion optimization (TCO). I believe that this code should have been successful if a TCO had taken place.

    def trisum(n, csum):
        if n == 0:
            return csum
        else:
            return trisum(n - 1, csum + n)
    
    print(trisum(1000, 0))

Should I conclude that Python does not do any type of TCO, or do I just need to define it differently?


Does Python optimize tail recursion?

I&#39;ve looked everywhere and can&#39;t find a solid answer. According to the documentation, Java throws a [java.lang.StackOverflowError][1] error under the following circumstance:

&gt; Thrown when a stack overflow occurs because an application recurses too deeply.

But this raises two questions:

 - Aren&#39;t there other ways for a stack overflow to occur, not only through recursion?
 - Does the StackOverflowError happen before the JVM actually overflows the stack or after?

To elaborate on the second question:

When Java throws the StackOverflowError, can you safely assume that the stack did not write into the heap? If you shrink the size of the stack or heap in a try/catch on a function that throws a stack overflow, can you continue working? Is this documented anywhere?

Answers I am not looking for:

 - A StackOverflow happens because of bad recursion.
 - A StackOverflow happens when the heap meets the stack.

  [1]: http://docs.oracle.com/javase/7/docs/api/java/lang/StackOverflowError.html &quot;java.lang.StackOverflowError&quot;

What actually causes a Stack Overflow error?

I asked this question to get to know how to increase the runtime call stack size in the JVM. I&#39;ve got an answer to this, and I&#39;ve also got many useful answers and comments relevant to how Java handles the situation where a large runtime stack is needed. I&#39;ve extended my question with the summary of the responses.

Originally I wanted to increase the JVM stack size so programs like runs without a `StackOverflowError`.

    public class TT {
      public static long fact(int n) {
        return n &lt; 2 ? 1 : n * fact(n - 1);
      }
      public static void main(String[] args) {
        System.out.println(fact(1 &lt;&lt; 15));
      }
    }

The corresponding configuration setting is the `java -Xss...` command-line flag with a large enough value. For the program `TT` above, it works like this with OpenJDK&#39;s JVM:

    $ javac TT.java
    $ java -Xss4m TT

One of the answers has also pointed out that the `-X...` flags are implementation dependent. I was using

    java version &quot;1.6.0_18&quot;
    OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1~8.04.3)
    OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)

It is also possible to specify a large stack only for one thread (see in one of the answers how). This is recommended over `java -Xss...` to avoid wasting memory for threads that don&#39;t need it.

I was curious how large a stack the program above exactly needs, so I&#39;ve run it `n` increased:

   * -Xss4m can be enough for `fact(1 &lt;&lt; 15)`
   * -Xss5m can be enough for `fact(1 &lt;&lt; 17)`
   * -Xss7m can be enough for `fact(1 &lt;&lt; 18)`
   * -Xss9m can be enough for `fact(1 &lt;&lt; 19)`
   * -Xss18m can be enough for `fact(1 &lt;&lt; 20)`
   * -Xss35m can be enough for `fact(1 &lt;&lt; 21)`
   * -Xss68m can be enough for `fact(1 &lt;&lt; 22)`
   * -Xss129m can be enough for `fact(1 &lt;&lt; 23)`
   * -Xss258m can be enough for `fact(1 &lt;&lt; 24)`
   * -Xss515m can be enough for `fact(1 &lt;&lt; 25)`

From the numbers above it seems that Java is using about 16 bytes per stack frame for the function above, which is reasonable.

The enumeration above contains *can be enough* instead of *is enough*, because the stack requirement is not deterministic: running it multiple times with the same source file and the same `-Xss...` sometimes succeeds and sometimes yields a `StackOverflowError`. E.g. for 1 &lt;&lt; 20, `-Xss18m` was enough in 7 runs out of 10, and `-Xss19m` wasn&#39;t always enough either, but `-Xss20m` was enough (in all 100 runs out of 100). Does garbage collection, the JIT kicking in, or something else cause this nondeterministic behavior?

The stack trace printed at a `StackOverflowError` (and possibly at other exceptions as well) shows only the most recent 1024 elements of the runtime stack. An answer below demonstrates how to count the exact depth reached (which might be a lot larger than 1024).

Many people who responded has pointed out that it is a good and safe coding practice to consider alternative, less stack-hungry implementations of the same algorithm. In general, it is possible to convert to a set of recursive functions to iterative functions (using a e.g. `Stack` object, which gets populated on the heap instead of on the runtime stack). For this particular `fact` function, it is quite easy to convert it. My iterative version would look like:

    public class TTIterative {
      public static long fact(int n) {
        if (n &lt; 2) return 1;
        if (n &gt; 65) return 0;  // Enough powers of 2 in the product to make it (long)0.
        long f = 2;
        for (int i = 3; i &lt;= n; ++i) {
          f *= i;
        }
        return f;
      }
      public static void main(String[] args) {
        System.out.println(fact(1 &lt;&lt; 15));
      }
    }

FYI, as the iterative solution above shows it, the `fact` function cannot compute the exact factorial of numbers above 65 (actually, even above 20), because the Java built-in type `long` would overflow. Refactoring `fact` so it would return a `BigInteger` instead of `long` would yield exact results for large inputs as well.

How to increase the Java stack size?

I have a recursive call to a method that throws a stack overflow exception. The first call is surrounded by a try catch block but the exception is not caught. 

Does the stack overflow exception behave in a special way? Can I catch/handle the exception properly?

Not sure if relevant, but additional information: 

 - the exception is not thrown in the main thread 
 
 - the object where the code is throwing the exception is manually loaded by Assembly.LoadFrom(...).CreateInstance(...)

C# catch a stack overflow exception

I am getting the error &quot;Uncaught RangeError: Maximum call stack size exceeded&quot; on chrome. here is my jQuery function

    $(&#39;td&#39;).click(function () {
            if ($(this).context.id != null &amp;&amp; $(this).context.id != &#39;&#39;) {
                foo($(&#39;#docId&#39;).val(), $(this).attr(&#39;id&#39;));
            }
            return false;
        });

Note that there are tens of thousands of cells in the page. However, I generally associate stack overflows with recursion and in this case as far as I can see there is none.

Does creating a lambda like this automatically generate a load of stuff on the stack? is there any way round it?

At the moment the only workaround I have is to generate the onclick events explicitly on each cell when rendering the HTML, which makes the HTML much larger.

Chrome/jQuery Uncaught RangeError: Maximum call stack size exceeded

This is my sample code:

    #include &lt;iostream&gt;
    #include &lt;string&gt;
    using namespace std;
    
    class MyClass
    {
    	string figName;
    public:
    	MyClass(const string&amp; s)
    	{
    		figName = s;
    	}
    
    	const string&amp; getName() const
    	{
    		return figName;
    	}
    };

    ostream&amp; operator&lt;&lt;(ostream&amp; ausgabe, const MyClass&amp; f)
    {
    	ausgabe &lt;&lt; f.getName();
    	return ausgabe;
    }
    
    int main()
    {
    	MyClass f1(&quot;Hello&quot;);
    	cout &lt;&lt; f1;
        return 0;
    }

If I comment out `#include &lt;string&gt;` I don&#39;t get any compiler error, I guess because it&#39;s kind of included through `#include &lt;iostream&gt;`. If I *&quot;right-click --&gt; Go to Definition&quot;* in Microsoft VS they both point to the same line in the `xstring` file:

    typedef basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
    	string;

But when I run my program, I get an exception error:

&gt; 0x77846B6E (ntdll.dll) in OperatorString.exe: 0xC00000FD: Stack overflow (Parameter: 0x00000001, 0x01202FC4)

Any idea why I get a runtime error when commenting out `#include &lt;string&gt;`? I&#39;m using VS 2013 Express.

Why is #include &lt;string&gt; preventing a stack overflow error here?

How does a stack overflow occur and what are the best ways to make sure it doesn&#39;t happen, or ways to prevent one, particularly on web servers, but other examples would be interesting as well?

How does a &quot;stack overflow&quot; occur and how do you prevent it?

I was wondering what happens when you try to catch an StackOverflowError and came up with the following method:

    class RandomNumberGenerator {

        static int cnt = 0;

        public static void main(String[] args) {
            try {
                main(args);
            } catch (StackOverflowError ignore) {
                System.out.println(cnt++);
            }
        }
    }

Now my question:

Why does this method print &#39;4&#39;?

I thought maybe it was because `System.out.println()` needs 3 segments on the call stack, but I don&#39;t know where the number 3 comes from. When you look at the source code (and bytecode) of `System.out.println()`, it normally would lead to far more method invocations than 3 (so 3 segments on the call stack would not be sufficient). If it&#39;s because of optimizations the Hotspot VM applies (method inlining), I wonder if the result would be different on another VM.


&lt;b&gt;Edit&lt;/b&gt;:

As the output seems to be highly JVM specific, I get the result 4 using&lt;br&gt;
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)&lt;br&gt;
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)

&lt;br&gt;

&lt;b&gt; Explanation why I think this question is different from https://stackoverflow.com/questions/15083318/understanding-java-stack: &lt;/b&gt;

My question is not about why there is a cnt &gt; 0 (obviously because `System.out.println()` requires stack size and throws another `StackOverflowError` before something gets printed), but why it has the particular value of 4, respectively 0,3,8,55 or something else on other systems.


Why does this method print 4?

What can cause a `java.lang.StackOverflowError`? The stack printout that I get is not very deep at all (only 5 methods).

What causes a java.lang.StackOverflowError

I&#39;m surprised at how it is possible to continue execution even after a [`StackOverflowError`](https://stackoverflow.com/questions/214741/what-is-a-stackoverflowerror) has occurred in Java.

I know that `StackOverflowError` is a sublass of the class Error.
The class Error is decumented as &quot;a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.&quot;

This sounds more like a recommendation than a rule, subtending that catching a Error like a StackOverflowError is in fact permitted and it&#39;s up to the programmer&#39;s reasonability not to do so. And see, I tested this code and it terminates normally.

    public class Test
    {
        public static void main(String[] args)
        {
            try {
                foo();
            } catch (StackOverflowError e) {
                bar();
            }
            System.out.println(&quot;normal termination&quot;);
        }
        
        private static void foo() {
            System.out.println(&quot;foo&quot;);
            foo();
        }
        
        private static void bar() {
            System.out.println(&quot;bar&quot;);
        }
    }

How can this be? I think by the time the StackOverflowError is thrown, the stack should be so full that there is no room for calling another function. Is the error handling block running in a different stack, or what is going on here?

Why is it possible to recover from a StackOverflowError?

I would like to generate a JSON String from my object:

	Gson gson = new Gson();
	String json = gson.toJson(item);

Everytime I try to do this, I get this error:

    14:46:40,236 ERROR [[BomItemToJSON]] Servlet.service() for servlet BomItemToJSON threw exception
    java.lang.StackOverflowError
    	at com.google.gson.stream.JsonWriter.string(JsonWriter.java:473)
    	at com.google.gson.stream.JsonWriter.writeDeferredName(JsonWriter.java:347)
    	at com.google.gson.stream.JsonWriter.value(JsonWriter.java:440)
    	at com.google.gson.internal.bind.TypeAdapters$7.write(TypeAdapters.java:235)
    	at com.google.gson.internal.bind.TypeAdapters$7.write(TypeAdapters.java:220)
    	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:68)
    	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:89)
    	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:200)
    	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:68)
    	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.write(CollectionTypeAdapterFactory.java:96)
    	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.write(CollectionTypeAdapterFactory.java:60)
    	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:843)

These are the attributes of my **BomItem** class:

	private int itemId;
	private Collection&lt;BomModule&gt; modules;
	private boolean deprecated;
	private String partNumber;
	private String description; //LOB
	private int quantity;
	private String unitPriceDollar;
	private String unitPriceEuro;
	private String discount; 
	private String totalDollar;
	private String totalEuro;
	private String itemClass;
	private String itemType;
	private String vendor;
	private Calendar listPriceDate;
	private String unitWeight;
	private String unitAveragePower;
	private String unitMaxHeatDissipation;
	private String unitRackSpace;

Attributes of my referenced **BomModule** class:

	private int moduleId;
	private String moduleName;
	private boolean isRootModule;
	private Collection&lt;BomModule&gt; parentModules;
	private Collection&lt;BomModule&gt; subModules;
	private Collection&lt;BomItem&gt; items;
	private int quantity;

Any idea what causes this error? How can I fix it?

gson.toJson() throws StackOverflowError

When I run my code, Node.js throws a `&quot;RangeError: Maximum call stack size exceeded&quot;` exception caused by too many recursive calls. I tried to increase Node.js stack size by `sudo node --stack-size=16000 app`, but Node.js crashes without any error message. When I run this again without sudo, then Node.js prints `&#39;Segmentation fault: 11&#39;`. Is there a possibility to solve this without removing my recursive calls?

Node.js - Maximum call stack size exceeded

Suppose we want to compute some Fibonacci numbers, modulo 997.

For `n=500` in C++ we can run
```cpp
#include &lt;iostream&gt;
#include &lt;array&gt;

std::array&lt;int, 2&gt; fib(unsigned n) {
	if (!n)
		return {1, 1};
	auto x = fib(n - 1);
	return {(x[0] + x[1]) % 997, (x[0] + 2 * x[1]) % 997};
}

int main() {
	std::cout &lt;&lt; fib(500)[0];
}
```
and in Python
```py
def fib(n):
    if n==1:
        return (1, 2)
    x=fib(n-1)
    return ((x[0]+x[1]) % 997, (x[0]+2*x[1]) % 997)

if __name__==&#39;__main__&#39;:
    print(fib(500)[0])
```

Both will find the answer 996 without issues. We are taking modulos to keep the output size reasonable and using pairs to avoid exponential branching.

For `n=5000`, the C++ code outputs 783, but Python will complain
```none
RecursionError: maximum recursion depth exceeded in comparison
```
If we add a couple of lines
```py
import sys

def fib(n):
    if n==1:
        return (1, 2)
    x=fib(n-1)
    return ((x[0]+x[1]) % 997, (x[0]+2*x[1]) % 997)

if __name__==&#39;__main__&#39;:
    sys.setrecursionlimit(5000)
    print(fib(5000)[0])
```
then Python too will give the right answer.

For `n=50000` C++ finds the answer 151 within milliseconds while Python crashes (at least on my machine).

Why are recursive calls so much cheaper in C++? Can we somehow modify the Python compiler to make it more receptive to recursion?

Of course, one solution is to replace recursion with iteration. For Fibonacci numbers, this is easy to do. However, this will swap the initial and the terminal conditions, and the latter is tricky for many problems (e.g. alpha–beta pruning). So generally, this will require a lot of hard work on the part of the programmer.

Why is Python recursion so expensive and what can we do about it?

I was trying to figure out hands-on how tail calls are handled by the C# compiler.

(Answer: [They&#39;re not.][1] But the *64bit JIT(s)* WILL do TCE (tail call elimination). [Restrictions apply][2].)

So I wrote a small test using a recursive call that prints how many times it gets called before the `StackOverflowException` kills the process.

    class Program
    {
        static void Main(string[] args)
        {
            Rec();
        }

        static int sz = 0;
        static Random r = new Random();
        static void Rec()
        {
            sz++;

            //uncomment for faster, more imprecise runs
            //if (sz % 100 == 0)
            {
                //some code to keep this method from being inlined
                var zz = r.Next();  
                Console.Write(&quot;{0} Random: {1}\r&quot;, sz, zz);
            }
            
            //uncommenting this stops TCE from happening
            //else
            //{
            //    Console.Write(&quot;{0}\r&quot;, sz);
            //}

            Rec();
        }

Right on cue, the program ends with SO Exception on any of:

- &#39;Optimize build&#39; OFF (either Debug or Release)
- Target: x86
- Target: AnyCPU + &quot;Prefer 32 bit&quot; (this is new in VS 2012 and the first time I saw it. [More here][3].) 
- Some seemingly innocuous branch in the code (see commented &#39;else&#39; branch).

Conversely, using &#39;Optimize build&#39; ON + (Target = x64 or AnyCPU with &#39;Prefer 32bit&#39; OFF (on a 64bit CPU)), TCE happens and the counter keeps spinning up forever (ok, it arguably spins *down* each time its value overflows).

**But I noticed a behaviour I can&#39;t explain** in the `StackOverflowException` case: it never (?) happens at *exactly* the same stack depth. Here are the outputs of a few 32-bit runs, Release build:

    51600 Random: 1778264579
    Process is terminated due to StackOverflowException.

    51599 Random: 1515673450
    Process is terminated due to StackOverflowException.

    51602 Random: 1567871768
    Process is terminated due to StackOverflowException.

    51535 Random: 2760045665
    Process is terminated due to StackOverflowException.

And Debug build:

    28641 Random: 4435795885
    Process is terminated due to StackOverflowException.

    28641 Random: 4873901326  //never say never
    Process is terminated due to StackOverflowException.

    28623 Random: 7255802746
    Process is terminated due to StackOverflowException.

    28669 Random: 1613806023
    Process is terminated due to StackOverflowException.

The stack size is constant ([defaults to 1 MB][4]). The stack frames&#39; sizes are constant. 

So then, what can account for the (sometimes non-trivial) variation of stack depth when the `StackOverflowException` hits? 


UPDATE
--
Hans Passant raises the issue of `Console.WriteLine` touching P/Invoke, interop and possibly non-deterministic locking. 

So I simplified the code to this: 

    class Program
    {
        static void Main(string[] args)
        {
            Rec();
        }
        static int sz = 0;
        static void Rec()
        {
            sz++;
            Rec();
        }
    }

I ran it in Release/32bit/Optimization ON without a debugger. When the program crashes, I attach the debugger and check the value of the counter. 

And it *still* isn&#39;t the same on several runs. (Or my test is flawed.)

UPDATE: Closure
---
As suggested by fejesjoco, I looked into ASLR (Address space layout randomization). 

It&#39;s a security technique that makes it hard for buffer overflow attacks to find the precise location of (e.g.) specific system calls, by randomizing various things in the process address space, including the stack position and, apparently, its size.

**The theory sounds good. Let&#39;s put it into practice!**

In order to test this, I used a Microsoft tool specific for the task: [EMET or The Enhanced Mitigation Experience Toolkit][5]. It allows setting the ASLR flag (and a lot more) on a system- or process-level.  
(There is also a [system-wide, registry hacking alternative][6] that I didn&#39;t try)

![EMET GUI][7]

In order to verify the effectiveness of the tool, I also discovered that [Process Explorer][8] duly reports the status of the ASLR flag in the &#39;Properties&#39; page of the process. Never saw that until today :)

![enter image description here][9]

Theoretically, EMET can (re)set the ASLR flag for a single process. In practice, it didn&#39;t seem to change anything (see above image).

However, I disabled ASLR for the entire system and (one reboot later) I could finally verify that indeed, the SO exception now always happens at the same stack depth.

BONUS
---
ASLR-related, in older news: [How Chrome got pwned][10]


  [1]: https://stackoverflow.com/questions/491376/why-doesnt-net-c-optimize-for-tail-call-recursion
  [2]: https://web.archive.org/web/20130321234831/http://blogs.msdn.com/b/davbr/archive/2007/06/20/tail-call-jit-conditions.aspx
  [3]: https://stackoverflow.com/questions/12066638/what-is-the-purpose-of-the-prefer-32-bit-setting-in-visual-studio-2012-and-how
  [4]: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774%28v=vs.85%29.aspx
  [5]: http://technet.microsoft.com/en-us/security/jj653751
  [6]: https://stackoverflow.com/questions/9560993/how-do-you-disable-aslr-address-space-layout-randomization-on-windows-7-x64
  [7]: http://i.stack.imgur.com/Uzf8i.png
  [8]: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
  [9]: http://i.stack.imgur.com/LcsBf.png
  [10]: http://9to5google.com/2012/03/07/vupen-conquers-chrome-at-pwn2own-security-conference-google-must-pay-cash-reward-for-french-teams-hack/

Why does a recursive call cause StackOverflow at different stack depths?

I just saw this *weird* piece of code in another question. I thought it would result in a `StackOverflowError` being thrown, but it doesn&#39;t...

    public class Node {
        private Object one;
        private Object two;
        public static Node NIL = new Node(Node.NIL, Node.NIL);
    
        public Node(Object one, Object two) {
            this.one = one;
            this.two = two;
        }
    }

I thought it was going to thow an exception, because of the `Node.NIL` referencing itself to build.

I can&#39;t figure it out why it does not.

Why doesn&#39;t this statement throw a StackOverflowError?

I would like to either prevent or handle a `StackOverflowException` that I am getting from a call to the `XslCompiledTransform.Transform` method within an `Xsl Editor` I am writing. The problem seems to be that the user can write an `Xsl script` that is infinitely recursive, and it just blows up on the call to the `Transform` method.  (That is, the problem is not just the typical programmatic error, which is usually the cause of such an exception.)

Is there a way to detect and/or limit how many recursions are allowed?  Or any other ideas to keep this code from just blowing up on me?

How do I prevent and/or handle a StackOverflowException?

What is the difference between a stack overflow and a buffer overflow in programming?

What is the difference between a stack overflow and buffer overflow?

It&#39;s my first question here on stack, so please be gentle :D

I&#39;m trying to create hibernate OneToMany relationship. When I try to fetch some data from my DB, I&#39;m getting StackOverflowError. But when i remove OneToMany part, everything goes normally. This is part of my REST Service, for now it runs on VMware vFabric Server and MySQL DB.

Fetch example:
&lt;!-- language: java --&gt;

    @Inject
    private EntityManager entityManager;
    ...
    entityManager.find(League.class, 1);
    ...
    entityManager.find(Team.class, 1);


MySQL script:
&lt;!-- language: sql --&gt;

    CREATE TABLE league (
    	id int(11) NOT NULL AUTO_INCREMENT,
    	name varchar(20) COLLATE utf8_unicode_ci NOT NULL,
    	PRIMARY KEY (id)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
    
    CREATE TABLE team (
    	team_id int(11) NOT NULL AUTO_INCREMENT,
    	name varchar(20) COLLATE utf8_unicode_ci NOT NULL,
    	fk_leagueId int(11) NOT NULL,
    	PRIMARY KEY (team_id),
    	FOREIGN KEY (fk_leagueId) REFERENCES league(id)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Classes:
&lt;!-- language: java --&gt;

    @XmlRootElement
    @Entity
    @Table(name = &quot;team&quot;)
    @Data
    public class Team {
        @Id
        @GeneratedValue(generator = &quot;increment&quot;)
        @GenericGenerator(name = &quot;increment&quot;, strategy = &quot;increment&quot;)
        @Column(name = &quot;team_id&quot;)
        private int id;
        @Column(name = &quot;name&quot;)
        private String name;
        @ManyToOne(fetch = FetchType.LAZY)
        @JoinColumn(name = &quot;fk_leagueId&quot;, nullable = false)
        private League league;
    }
    
    @XmlRootElement
    @Entity
    @Table(name = &quot;league&quot;)
    @Data
    public class League {
        @Id
        @GeneratedValue(generator = &quot;increment&quot;)
        @GenericGenerator(name = &quot;increment&quot;, strategy = &quot;increment&quot;)
        @Column(name = &quot;id&quot;)
        private int id;
        @Column(name = &quot;name&quot;)
        private String name;
        //if I comment 2 lines below, there is no error, and everything works fine
        @OneToMany(fetch = FetchType.LAZY, mappedBy = &quot;league&quot;)
        private Set&lt;Team&gt; teams;
    }


Error:

    Hibernate: select league0_.id as id1_1_0_, league0_.name as name2_1_0_ from league league0_ where league0_.id=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Hibernate: select teams0_.fk_leagueId as fk3_1_1_, teams0_.team_id as team1_4_1_, teams0_.team_id as team1_4_0_, teams0_.fk_leagueId as fk3_4_0_, teams0_.name as name2_4_0_ from team teams0_ where teams0_.fk_leagueId=?
    Exception in thread &quot;tomcat-http--3&quot; java.lang.StackOverflowError
    	at org.jboss.logging.JDKLogger.translate(JDKLogger.java:73)
    	at org.jboss.logging.JDKLogger.isEnabled(JDKLogger.java:85)
    	at org.jboss.logging.JDKLogger.doLog(JDKLogger.java:41)
    	at org.jboss.logging.Logger.debug(Logger.java:406)
    	at org.hibernate.internal.CoreMessageLogger_$logger.debug(CoreMessageLogger_$logger.java:525)
    	at org.hibernate.engine.jdbc.spi.SqlStatementLogger.logStatement(SqlStatementLogger.java:104)
    	at org.hibernate.engine.jdbc.spi.SqlStatementLogger.logStatement(SqlStatementLogger.java:95)
    	at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:180)
    	at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:159)
    	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1858)
    	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1835)
    	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1815)
    	at org.hibernate.loader.Loader.doQuery(Loader.java:899)
    	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:341)
    	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:311)
    	at org.hibernate.loader.Loader.loadCollection(Loader.java:2234)
    	at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:65)
    	at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:674)
    	at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:83)
    	at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1849)
    	at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:549)
    	at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:234)
    	at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:545)
    	at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:124)
    	at org.hibernate.collection.internal.PersistentSet.hashCode(PersistentSet.java:428)
    	at com.lukaszb.motspe.webapp.model.League.hashCode(League.java:21)
    	at com.lukaszb.motspe.webapp.model.Team.hashCode(Team.java:20)
    	at java.util.HashMap.hash(HashMap.java:351)
    	at java.util.HashMap.put(HashMap.java:471)
    	at java.util.HashSet.add(HashSet.java:217)
    ...


**Edit:**

I was able to solve this out thanks to @Thihara and @KarIP. I have overriden toString() for Team and League like this:

 

    @Override
    public String toString() {
    	return &quot;League [id=&quot; + id + &quot;, name=&quot; + name + &quot;]&quot;;
    }
    
    @Override
    public String toString() {
        return &quot;Team [id=&quot; + id + &quot;, name=&quot; + name + &quot;]&quot;;
    }
and was able to fetch data from DB as wanted. But then while parsing I got JAXB error with infinite cycles. So i annotated Team and League class with `@XmlAccessorType(XmlAccessType.FIELD)`, so it won&#39;t look at methods, and Team `league` field as `@XmlTransient`, so it won&#39;t be parsed.

Here I can even remove my toString() implementations, and it still works.
I&#39;m not completely sure why.
Problem is solved, but I would like to hear more precise explanation. I don&#39;t know why JAXB stopped data fetch, even if it&#39;s after whole DB communication process(or isn&#39;t?).
To be more specific, I&#39;m using Jersey for that:

    @GET
    @Path(&quot;search/id&quot;)
    @Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
    public List&lt;League&gt; searchById(@QueryParam(&quot;id&quot;) int id) {
    return Arrays.asList(leagueDAO.getById(id));
    }

Hibernate OneToMany java.lang.StackOverflowError

TL;TR&lt;br&gt;
When I asked the question I assumed a `StackOverflowException` is a
mechanism to prevent applications to run infinitely. This is not true.&lt;br&gt;
**A `StackOverflowException` is not being detected.&lt;br&gt;
It is thrown when
the stack does not have the capacity to allocate more memory.**

[Original question:]

This is a general question, which may has different answers per programming language.&lt;br&gt;
I am unsure how languages other than C# process a stack overflow.

I was going through exceptions today and kept thinking about how a `StackOverflowException` can be detected. I believe it is not possible to say f.e. if the stack is 1000 calls deep, then throw the exception. Because maybe in some cases the correct logic will be that deep.

**What is the logic behind the detection of an infinite loop in my program?**

`StackOverflowException` class:&lt;br&gt;
https://msdn.microsoft.com/de-de/library/system.stackoverflowexception%28v=vs.110%29.aspx&lt;br&gt;&lt;br&gt;
Cross reference mentioned in the `StackOverflowException` class documentation:&lt;br&gt;
https://msdn.microsoft.com/de-de/library/system.reflection.emit.opcodes.localloc(v=vs.110).aspx&lt;br&gt;

I just added the `stack-overflow` tag to this question, and the description says it is being thrown when the call stack consumes too much memory. Does that mean the call stack is some sort of path to the current executing position of my program and if it cannot store more *path information*, then the exception is thrown?


How is a StackOverflowException detected?

I recently found a presentation about [F# for Python programmers][1], and after watching it, I decided to implement a solution to the &quot;ant puzzle&quot; on my own.

*There is an ant that can walk around on a planar grid. The ant can move one space at a time left, right, up or down.  That is, from the cell (x, y) the ant can go to cells (x+1, y), (x-1, y), (x, y+1), and (x, y-1). Points where the sum of the digits of the x and y coordinates are greater than 25 are inaccessible to the ant. For example, the point (59,79) is inaccessible because 5 + 9 + 7 + 9 = 30, which is greater than 25. The question is: How many points can the ant access if it starts at (1000, 1000), including (1000, 1000) itself?*

I implemented my solution in 30 lines of [OCaml first][2], and tried it out:

    $ ocamlopt -unsafe -rectypes -inline 1000 -o puzzle ant.ml
    $ time ./puzzle
    Points: 148848

    real    0m0.143s
    user    0m0.127s
    sys     0m0.013s

Neat, my result is the same as that of [leonardo&#39;s implementation, in D and C++][3]. Comparing to Leonardo&#39;s C++ implementation, the OCaml version runs approx 2 times slower than C++. Which is OK, given that Leonardo used a queue to remove recursion.

I then [translated the code to F#][4] ... and here&#39;s what I got:

    Thanassis@HOME /g/Tmp/ant.fsharp
    $ /g/Program\ Files/FSharp-2.0.0.0/bin/fsc.exe ant.fs
    Microsoft (R) F# 2.0 Compiler build 2.0.0.0
    Copyright (c) Microsoft Corporation. All Rights Reserved.
    
    Thanassis@HOME /g/Tmp/ant.fsharp
    $ ./ant.exe
    
    Process is terminated due to StackOverflowException.
    Quit
    
    Thanassis@HOME /g/Tmp/ant.fsharp
    $ /g/Program\ Files/Microsoft\ F#/v4.0/Fsc.exe ant.fs
    Microsoft (R) F# 2.0 Compiler build 4.0.30319.1
    Copyright (c) Microsoft Corporation. All Rights Reserved.
    
    Thanassis@HOME /g/Tmp/ant.fsharp
    $ ./ant.exe
    
    Process is terminated due to StackOverflowException

Stack overflow... with both versions of F# I have in my machine...
Out of curiosity, I then took the generated binary (ant.exe) and run it under Arch Linux/Mono:

    $ mono -V | head -1
    Mono JIT compiler version 2.10.5 (tarball Fri Sep  9 06:34:36 UTC 2011)
    
    $ time mono ./ant.exe
    Points: 148848
    
    real    1m24.298s
    user    0m0.567s
    sys     0m0.027s

Surprisingly, it runs under Mono 2.10.5 (i.e. no stack overflow) - but it takes 84 seconds, i.e. 587 times slower than OCaml - oops. 

So this program...

- runs fine under OCaml
- doesn&#39;t work at all under .NET/F#
- works, but is very slow, under Mono/F#.

Why?

**EDIT:** Weirdness continues - Using &quot;--optimize+ --checked-&quot; makes the problem disappear,  **but only under ArchLinux/Mono** ; under Windows XP and Windows 7/64bit, even the optimized version of the binary stack overflows.

**Final EDIT**: I found out the answer myself - see below.

  [1]: http://combiol.org/fs/FSUG_FS4PPv2.pptx
  [2]: http://pastebin.com/EzMt466b
  [3]: http://leonardo-m.livejournal.com/
  [4]: http://pastebin.com/0Vx5GTBQ



F# vs OCaml: Stack overflow

One of my coworkers came to me with a question about this method that results in an infinite loop. The actual code is a bit too involved to post here, but essentially the problem boils down to this:

    private IEnumerable&lt;int&gt; GoNuts(IEnumerable&lt;int&gt; items)
    {
        items = items.Select(item =&gt; items.First(i =&gt; i == item));
        return items;
    }

This *should* (you would think) just be a very inefficient way to create a copy of a list. I called it with:

    var foo = GoNuts(new[]{1,2,3,4,5,6});

The result is an infinite loop. Strange.

I think that modifying the parameter is, stylistically a bad thing, so I changed the code slightly:

    var foo = items.Select(item =&gt; items.First(i =&gt; i == item));
    return foo;

That worked. That is, the program completed; no exception.

More experiments showed that this works, too:

    items = items.Select(item =&gt; items.First(i =&gt; i == item)).ToList();
    return items;

As does a simple

    return items.Select(item =&gt; .....);

Curious.

It&#39;s clear that the problem has to do with reassigning the parameter, but only if evaluation is deferred beyond that statement. If I add the `ToList()` it works.

I have a general, vague, idea of what&#39;s going wrong. It looks like the `Select` is iterating over its own output. That&#39;s a little bit strange in itself, because typically an `IEnumerable` will throw if the collection it&#39;s iterating changes. 

What I don&#39;t understand, because I&#39;m not intimately familiar with the internals of how this stuff works, is why re-assigning the parameter causes this infinite loop.

Is there somebody with more knowledge of the internals who would be willing to explain why the infinite loop occurs here?

Why does this method result in an infinite loop?

I am running a program that I&#39;ve written in Java in Eclipse. The program has a very deep level of recursion for very large inputs. For smaller inputs the program runs fine however when large inputs are given, I get the following error:

    Exception in thread &quot;main&quot; java.lang.StackOverflowError

Can this be solved by increasing the Java stack size and if so, how do I do this in Eclipse?

&lt;b&gt;Update:&lt;/b&gt;

@Jon Skeet

The code is traversing a parse tree recursively in order to build up a datastructure. So, for example the code will do some work using a node in the parse tree and call itself on the node&#39;s two children, combining their results to give the overall result for the tree.

The total depth of the recursion depends on the size of the parse tree but the code seems to fail (without a larger stack) when the number of recursive calls gets into the 1000s.

Also I&#39;m pretty sure the code isn&#39;t failing because of a bug as it works for small inputs.

Java stack overflow error - how to increase the stack size in Eclipse?

This is different to other questions regarding an error message in Node that reads **RangeError: Maximum call stack size exceeded** in that I know exactly why I&#39;m getting this error message. It&#39;s happening because I&#39;m recursing, recursing quite a lot in fact.

Thanks.

How can I increase the maximum call stack size in Node.js

I&#39;m aware that StackOverflowExceptions in .NET can&#39;t be caught, take down their process, and have no stack trace. This is officially documented [on MSDN][1]. However, I&#39;m wondering what the technical (or other) reasons are behind the behavior. All MSDN says is:

&gt; In prior versions of the .NET Framework, your application could catch
&gt; a StackOverflowException object (for example, to recover from
&gt; unbounded recursion). However, that practice is currently discouraged
&gt; because significant additional code is required to reliably catch a
&gt; stack overflow exception and continue program execution.

What is this &quot;significant additional code&quot;? Are there other documented reasons for this behavior? Even if we can&#39;t catch SOE, why can&#39;t we at least get a stack trace? Several co-workers and I just sunk several hours into debugging a production StackOverflowException that would have taken minutes with a stack trace, so I&#39;m wondering if there is a good reason for my suffering.

  [1]: http://msdn.microsoft.com/en-us/library/system.stackoverflowexception%28v=vs.110%29.aspx

Why does .NET behave so poorly when StackOverflowException is thrown?

Having read [Dr Rauschmayer&#39;s description][1] of recursive tail call optimisation in es6, I&#39;ve since been trying to recreate the &#39;zero-stack&#39; execution of the recursive factorial function he details.&lt;br/&gt;&lt;br/&gt;
Using the Chrome debugger to step between stack frames, I&#39;m seeing that the tail optimisation is not occurring and a stack frame is being created for each recursion.&lt;br/&gt;&lt;br/&gt;
I&#39;ve also tried to test the optimisation by calling the function without the debugger, but instead passing &lt;code&gt;100000&lt;/code&gt; to the factorial function. This throws a &#39;maximum stack&#39; error, which implies that it is, in fact, not optimised.

Here is my code:

    const factorial = (n, acc = 1) =&gt; n &lt;= 1 ? acc : factorial(n - 1, n * acc)
    console.log( factorial(100000) )

Result:

    Uncaught RangeError: Maximum call stack size exceeded





  [1]: http://www.2ality.com/2015/06/tail-call-optimization.html

ES6 Tail Recursion Optimisation Stack Overflow

Consider the following code.

&lt;!-- language-all: lang-java --&gt;


    public class Action {
    private static int i=1;
    public static void main(String[] args) {
        try{
            System.out.println(i);
            i++;
            main(args);
        }catch (StackOverflowError e){
            System.out.println(i);
            i++;
            main(args);
        }
     }

    }

I am getting i value up to `4338` correctly. After catching the `StackOverflowError` output getting wired as follows.

    4336
    4337
    4338 // up to this point out put can understand 
    433943394339 // 4339 repeating thrice  
    434043404340
    4341
    434243424342
    434343434343
    4344
    4345
    434643464346
    434743474347
    4348
    434943494349
    435043504350

Consider [Live][1] demo here. It is working correctly up to `i=4330`. Actually how this happen?  


***FYI:***

I did following code to realize what is happening here.


    public class Action {
    
        private static int i = 1;
        private static BufferedWriter bw;
    
        static {
            try {
                bw = new BufferedWriter(new FileWriter(&quot;D:\\sample.txt&quot;));
            } catch (IOException e) {
               e.printStackTrace();
            }
        }
    
        public static void main(String[] args) throws IOException {
            bw.append(String.valueOf(i)+&quot; &quot;);
            try {
                i++;
                main(args);
            } catch (StackOverflowError e) {
                bw.append(String.valueOf(i)+&quot; &quot;);
                i++;
                main(args);
            }
        }
    
    }

Now previous issue not there. now value of `i` up to `16824744` correct and and runs further. I am hopping this may runs up to value of `i=2,147,483,647`(max value of int) without an issue.

There is some issue with `println()`. There are similar answers bellow too. But why? 

What will be the actual reason?
 

  [1]: http://ideone.com/rqX0jv


All Stack Overflow Solutions on Gang of Coders

Total of 28 Stack Overflow Solutions