How to debug SystemStackError

[Tsukihime]

This is a common problem: you've got an infinite recursive loop going on somewhere.

Question is, how to deal with it as a developer. It's not always immediately obvious why it occurs.

After a few minutes of searching I came across this question

http://stackoverflow.com/questions/11544460/how-to-get-a-backtrace-from-a-systemstackerror-stack-level-too-deep

And one of the answers was to write something like

raise "crash me" if caller.length > 500caller is defined in Kernel, btw.This is very easy to do when you're debugging your scripts: figure out where the recursion is occurring, and then insert the line right before it.

For example, given the following code

def test1 test2enddef test2 test1endNow call `test1` or `test2` somewhere in your script.It is trivial, but you know there's a recursive loop and you're going to blow the stack eventually.

If you're printing the stacktrace to console using a script like cidiomar's full error backtrace, it will tell you which line basically blew the stack (I think), but it doesn't tell you anything else.

Ok so now we know line 2 was being visited frequently, so we use the trick above like this

def test1 raise "crash me" if caller.length > 20 test2 # this line was being called recursively repeatedly at some point # so let's interrupt it before ruby complainsenddef test2 test1endI set it to 20 because you shouldn't be calling test2 that many times anyways.Now when you run it, you'll see this in the console:

Now, whether you have any programming experience or not, you can look at the stacktrace and see that there's some repetition going on, and get a better idea where the problem is.

In my case, you can see that the two methods are just calling each other infinitely.

What kind of techniques do you use when it comes to SystemStackError debugging?

 

[Zeriab]

I haven't really formalized any particular strategy against infinite loops. I find them generally easy to solve as they usually are easy to reproduce and have a distinct flavor/smell to them.

Look at the stack trace is a good idea as it can contain valuable information.

For RMXP I typically just wrap a begin-rescue block around the $scene.main call in the Main loop.

  while $scene != nil    begin      $scene.main    rescue StandardError => err      printErrorMessage(err) # With backtrace and all      raise if $DEBUG    end  end
More annoying are the stack overflows not triggered by an infinite recursion. The stack btw. is used for your position in the program. When you call a method it puts the method on the stack and runs it. Once the method has been executed it pops off the method and continues from the previous method. (It probably does something more advanced, but you get the gist)

This stack has a limited size and each method in the call chain takes up some space. Should you exceed the limit, well you get a stack overflow error. To me it seems that the limit is very small in RMXP at least.

Recursive algorithms can sometimes be used to hide complexity in the call chain. You could for example imagine a pathfinding or tree searching algorithm you consider your current node and recursively considers other nodes. In this case the length of the path may differ depending on the situation, which as you can guess sometimes may lead to a stack overflow exception and other times not.

A solution could be to rewrite the algorithm to an iterative variant.

I guess you could also without any recursion hit the limit. I haven't encounter it myself, but I bet it would truly be annoying to fix.

*hugs*

 

[jamespedid]

I don't know if this is helpful, but here's an answer on stackoverflow:


http://stackoverflow.com/questions/2219461/how-do-i-log-every-method-thats-called-in-a-ruby-program.


Since the ruby stack cuts off after 5000 layers of recursion(more or less, I forget the exact number), you'll be able to see this in a text file. This might be overlogging, so you may want to have this occur only on certain method names. But I'm not sure if this was modified in the RGSS3 runner.

 

[GaryCXJk]

I use basically the same thing. Perhaps a bit differently though, and from a different source.


https://gist.github.com/jbgo/4493822


Anyway, I myself did a test once, and the stack was pretty high.


By the way, it's one of the things people blame on using aliases, while in reality stack overflows aren't caused by that. In most cases, even with fifty scripts aliasing the same method, there shouldn't be any problems for the first ten or twenty iterations.

 

[Shaz]

Giraki, please do not hijack other people's threads with your own unrelated questions. Please start a NEW thread in RGSSx Script Support asking for help - and provide more information - nobody can help you if they can't see what you've done.


Hiding off-topic posts.

 

[Giraki]

Sorry sir, I thought It was a system stack, Ill go start a new thread.

 

[Shaz]

System Stack errors actually SAY System Stack Error, as shown in the OP's screenshots. However, even if it was, this is not a thread for getting help finding your particular error. It is introducing a way (and asking for other ways in use) to help track one down when you have one.