Nontrivial assignment can corrupt variables in outer scope

Z-Mann

The following, a bit similar to one of the last bugs faults with a seemingly nonsensical error:

struct mem
  int a[0]
endStruct

function stress(ref m)
  int b[100]
  m.a = b
endStruct

function crash()
  mem m
  int i
  for i = 0 to 5000 loop
    stress(m)
  repeat
return void()

crash()

The error is

---Error---
LINE: 8
FUNCTION: crash
----
Invalid type for loop variable.
(Expected a number)

The line number is wrong, nothing unusual; the text must be referring to the loop variable i.
For a loop limit of 4000, it runs through fine.
Very occasionally, after random change experiments and repeated runs, it would also crash F4NS to the system UI.

It's not a memory exhaustion problem this time; adding a huge array to crash's outer scope, like int x[100000], does not make it fault sooner. In fact, it makes it run through with loop limit 500000, probably by random chance avoiding the corruption.
But: here, too, if you decrease the size of the allocated array in stress(), you can increase the loop limit in crash() before it faults, and vice versa.

All sensible workaround attempts failed (like stuffing mem inside another struct to avoid direct array assignment). The only one that worked was to rewrite stress() to assign individual array elements:

function stress(ref m)
  int j
  for j = 0 to 100 loop
    m.a[j] = 0
  repeat
return void

even if that working is not a random fluke, it's still no good: you can't shrink the array that way.

The real issue I encountered (too complex for filing a report on) and tried to reproduce here had a slightly different effect; the main loop looked something like this

function main()
  float z = 0
  while... loop
    stress(...)
  repeat
  print(z)
return void

and if the system got stressed too much (under regular gameplay conditions, that would be after 10 or 20 minutes), print(z) would fail because it thought at that point z was not defined. I hope it's the same bug. Mysterious type change and mysterious disappearance sound similar enough.

This one... is quite the blocker for me. I like my nontrivial data manipulation :(

DomDom

This post is deleted!

Z-Mann

Thanks. In my day job, I'm at the receiving end of these things, so I know how valuable minimal test cases and how annoying bad reports can be. Also I know which ones I fix first, so it's not pure compassion with the devs if I make an effort :)

pianofire

Thanks for reporting an issue has been raised

Willpowered

@Z-Mann Just want to update and let you know that this is being worked on for the next patch!

Z-Mann

Wee! And no worries, I did find a workaround for the real problem I was having. Everything works if I just restructure the code so the outer scope variable doesn't have to be used any more after the loop exits.