[1.63][SSP]java.lang.ArrayIndexOutOfBoundsExeption

if I have a loop which waits until an click event witch startsedit another loop and break the first loop and afterwards break the second loop and start the first one again and do this multiple times and this Error appears:

window:277: vm error:
java.lang.ArrayIndexOutOfBoundsExeption: 256

here is my examplecode:
Program1:

term.clear()
term.setCursorPos(1,1)
print("X Click here")
print("Program 1")
while true do
local event, button, X, Y = os.pullEvent("mouse_click")
XY = X..","..Y
if XY == "1,1" and button == 1 then
shell.run("Program2")
break
end end

Program2:

term.setCursorPos(1,1)
print("X Click here")
print("Program 2")
while true do
local event, button, X, Y = os.pullEvent("mouse_click")
XY = X..","..Y
if XY == "1,1" and button == 1 then
shell.run("Program1")
break
end end

Every time you're starting a script via this code, the old one is still in memory, waiting for the new one to end so it can resume where it left off. The old script instances cannot end until the new ones finish - so your "break" lines are never executed.

Your code thus starts filling RAM with instance after instance of each script; there's a limit set on how many you can load up at a time, and you're hitting it via recursion. The only real improvement here ComputerCraft-side would be to throw a more informative error.

Some more details can be found here.

Sorry, I didn't know that this error is caused by memory overflow. But how do I provide the memory overflow?

Do you mean "how do I prevent the overflow"?

In this case, your two programs seem to have only one purpose - to trigger the stack overflow. I can't really comment on how to alter them to fix that, because if you take that purpose away from them then there isn't anything left… If there's a different script you're having trouble with, provide a link and you should be able to get assistance with it.

If you mean "how does this code cause the stack overflow", I'd hoped I'd explained that earlier… but if a function calls another function, the first then has to wait for that second function to end before it can continue. The Lua VM hence has to store both functions in RAM at the same time. If you devise a system where function after function gets called, but none of them ever end, then eventually you run out of RAM.

The solution in most cases is to implement "for", "while" or "repeat" loops - these allow you to run the same block of code over and over without additional function calls.

Ok, my example program was only to show whats happening in another program that i'm working on and i want to keep it as a secret as long as i can, so… but i have done some experiments and now it works without memory overflow. Heres my resault from my research:
in Program 1 the break is beeing removed
for Program 2:

function Back()
term.clear()
term.setCursorPos(1,1)
print("X Click here")
print("Program 1")
end
term.setCursorPos(1,1)
print("X Click here")
print("Program 2")
while true do
local event, button, X, Y = os.pullEvent("mouse_click")
XY = X..","..Y
if XY == "1,1" and button == 1 then
Back()
break
end end

I've tested it and it works totaly fine. (at least for me)
But thank you for your help. now i know a little bit more about computercraft. And now i know, that it was a problem caused by me. Could an admin move this to ask a pro?

Moved to Ask a Pro.

Can't you just add os.sleep(0.1) so it yields a little bit so it doesn't cause an overflow?

That's not the issue, the issue is that he's filling the call stack. He should be using an infinite loop in order to loop infinitely rather than having the function call itself again.

I assumed shell.run just waits until the other script is done. I guess not

It does do exactly that. Which means if you use that command a hundred times, you've made a hundred function calls. If none of those functions ever end - eg, because they each make more function calls, which sit there waiting for those to end, and so on - then Lua has to store them all in memory at the same time.

Creating an infinite loop out of function calls hence requires an infinite amount of RAM. You can probably see why that might trigger a crash.

The yielding matter is a bit different - in this case the scripts yield every time they sit and wait for a mouse click.

Oh, I didn't even notice the loop inside the functions…