For loop variable weirdness that should not happen, is this a bug of fuze or from me ?

JMM161437

When it comes to arrays you need to keep in mind that when you make one with 15 separate items they are indexed from 0-14 and not 1-15. so when you call out an array with 15 items like

MyArray[15]

you get an error because it'll try to index 15 which don't exist. Hopefully this helps

joyrider3774

@spikey thanks creating an init function indeed fixes the weird index 15 out of bounds error with the for loop variable so thats ok. but about the update() call i already have an update call and it still crashes after about 14000-15000 iterations with the stackoverflow error

@JMM161437 i'm aware arrays are zero based, the issue here was the for loop always goes to end value -1 so in theory it could have never reached index 15 in the main loop to make the array go out of bounds, that seemed to be an issue on reusing same for loop variable names in global and local scope and it gets fixed by placing the global scope for loops inside a seperate function.

@doumdoum, @PB____ i've tried placing var in front of those variables but it made no difference. i've placed the global scope for loops inside an init function so that has no influence anymore and even placed the main loop inside a seperate function but the program still crashes with a stackoverflow saying memory usage for variables has been used up after about 14000 iterations. So i started commenting things. If i only comment c = controls(0) it crashes with that same error after 28000 iterations so it seems it's not only the c=controls(0) call that leads up to this issue. So i started commenting more things and see how many iterations it can go. I also commented all the sum variable usage and it still crashes after about 28000 iterations so the sum variable is not the culprit. I'm still investigating to see what (which variable / line) is causing this.

The original program is now live also, so you guys can try experiment as well with it although i have now changed the program already to whats shown below. I can also share that if needed but the initial example program is easily changed to what i have below now

so even this program below crashes after 28000 iterations

Edit: prevc = c in the loop above seems to be a big culprit commented it and i'm nearing iteration 100000 and no crash yet with only that change compared to last screenshot's code. But i've still got to see what will happen if i uncomment c = controls(0) again so will slowly uncomment things to see how far it can go. If this is really the single culprit and we can not really do this how can i compare controls from previous frame with current frame ? i'm basically doing that to make sure some button was not pressed in previous frame while it is pressed in current frame (like to make sure a single button press happens and not keep reacting on it every frame if (!prevc.a) and c.a then ...)

I'll keep you guys posted

joyrider3774

ok i don't get it all ...

This crashes with the stackoverflow / max memory exceeded after about 28600 iterations

Put the for loop in comments and it happily goes to 100000 without crashing (i stopped it then did not let it run further, but i guess i could test it by letting it run overnight to see if it actually never crashes)

And this makes no sense at all to me whats up with the for loops causing this ? I have one more idea to try and thats doing 2 update() calls after each other

spikey

Quick note: enable the debug output of FUZE: if it grows, there is a memory leak, which will sooner or later crash. So, you dont have to let it run over night to see if it works.
Settings->Preferences->Show FPS + Memory Meter When Running Programs

Appendix: just saw that the memory does not change, or maybe very very slowly. Even after removing all sleeps and prints.

Kat

@joyrider3774 I've just tried running the 2nd most recent version you posted (the one with lines 35 and 40 uncommented) on the latest patch and I've passed iteration 100,000 with no errors :) So hopefully when it's out the patch will solve a lot of the problems you've been having.

spikey

I could reproduce a software crash, when running your latest version, after 2.5 min. Right now, you have the variable definition c = controls(0) inside main() this is a local scope. Now, its not clear for me, why this is still a problem, because, it looks like it could be "re-used" (my latest wild guess: its not re-used anyway, it allocates new memory and copies the content to it and replaces the old reference to the data with the new reference. Would be interesting to hear what you think nowadays) in your loop in 30-43. But it seems to be necessary (in FUZE version 2.15.0) to have c = controls(0) at the global scope (apology, for my cheeky proposition). So, if you take out c = controls(0)from your main()and put it between line 46 and 47, it will not crash anymore.

joyrider3774

@Kat thats good to hear will definatly retest it all when the patch comes out.
@spikey will test it. I just changed the code and started another run and hope it won't crash again (it already passed the 29000 mark so thats a good thing but will see how long it goes, i can leave it running for a few hours and hope it did not crash). Ps its exactly what i was thinking also that the variable is not reused and new memory (for variables) keeps being allocated up everytime it passes that line until it runs out of variable memory space

About the 1st version in my previous post (with the for loop commented) it happily goes to 1800000 without a problem (left it running during the day) while the second version (with the for loop uncommented) always crashed at iteration 28600 am running it now again with @spikey suggestion to make that line global scope and will see how it goes. But it is kinda weird that an empty for loop has an impact on it. I'll keep you guys posted

Oh on a side note i always run with the debugging enabled but don't see the memory going down during all of this not sure it shows / includes the variable memory space, maybe that memory is something else shown ? (like video memory for tiles / images and such)

joyrider3774

Hello guys,

So final testings. @spikey 's suggestion to place it a global scope indeed fixed the problem. Initially i only placed the initial call (var c = controls(0)) at global scope with the for loop enabled but not the contents. It went up to 1 million iterations without a problem. Next i added also var prevc = c below it and added the same statement inside the loop. I left it running fine til 100000 iterations without a problem. And in my final test i enabled the loop contents again and this also seemed to run fine up until 70000 iterations. Maybe tonight when i go to bed i let it run during the night as a real final test.

So what have we learned ?

Never use any for loops at global scope, place them inisde (init) functions or you will run into trouble if you use the same for variable from global scope in a local scope for loop after some time
Never place (define) var c= controls(0) at local scope place it in global scope or you will run into a stackoverflow eventually saying that variable space has been exhausted you can ofcourse in your main loop (at local scope) do c = controls(0)again to update the c value
you can remember the previous frame controller state (for comparing it with the state in the current frame) by doing first var c = controls(0) and right below it add var prevc = c at global scope then you can add in your loop (at local scope) the same statements without the var paremeter but place the prevc = c call before the c = controls(0) I did test using functions only did not retest it all without functions so best would be to use functions anyways to prevent problems just in case.

Here was the final version of the program i was testing and it's exactly what i need for my game. In case anyone is wondering that Z value calculation is to create the Z position value for infinite road (or any other repeating tile).

What started as seeing corruption in a game i was making ended up becomming one big investigation.

I will definatly restest this once the new patch is released as it seems by @Kat 's observations it did not crash with the new version at points where it did crash with me (on 2.15.0) during the testing. (for example when defining the var c = controls(0) at local scope (inside a function before using it in a loop)

i now have to change some code in my znax game also to prevent these problems from occuring.

I hope it helps someone and Thanks to all involved

PS. i will edit the post tommorow after i let it ran during the night to make sure it really did not crash the final program i only left going till iteration 70000 but i got a good feeling about it now

Edit: 500000+ iterations with last code posted (oh yeah seems i spelled iteration wrong ;))

Willpowered

I know @Kat already gave it a test, but I just want to confirm that this is a bug I worked on and indeed fixed for the upcoming patch.

joyrider3774

@Willpowered would that be both problems ? meaning the weird array index (for loop value) you can get after a while if you reuse the same name for a for loop variable in global and local scope and the stackoverflow with exhausted variable space when using c=controls(0) in local scope, or only the last one ? The test kat did, used a workaround for the 1st problem by not using for loops at global scope and placing them in an init function so i'm not sure that issue is also addressed (see very first post for example code that triggered this after about 5000 iterations)