pose.GetSegmentEnergyScore for out-of-range segment crashes client
Case number: | 845829-2008878 |
Topic: | Crash/Hang |
Opened by: | LociOiling |
Status: | Open |
Type: | Bug |
Opened on: | Tuesday, February 18, 2020 - 16:45 |
Last modified: | Sunday, April 26, 2020 - 19:43 |
As Pikamander2 describes, functions like current.GetSegmentEnergyScore crash the client if the segment number specified is out of range. The poses recentbest, creditbest, and absolutebest seem to have the same issue, but I haven't exhaustively tested them.
For example:
current.GetSegmentEnergyScore ( 0 ) current.GetSegmentEnergyScore ( 999 )
both cause a crash.
The function should instead throw an error, terminating the recipe.
This happens on 20191029-32048a6a12-win_x86-devprev.
The recipe Safe Fun can be used to check various parameters errors. Right now, only the behavior functions can be tested without a crash.
The issue seems to extend beyond just segment ranges, it also affects checking atom numbers, as in this example
band.AddBetweenSegments ( 1, 24, 99, 99 )
The first two arguments are segment numbers, the next two are atom numbers on the corresponding segment. An atom number of 99 is not valid. This parameter error now crashes the client, instead of issuing an error message which can be trapped by pcall.
Curiously, this is OK:
band.AddBetweenSegments ( 1, 24, 0, 0 )
This statement actually produces a band.
Atom numbers of -1 crash the client.
Found another one:
band.Delete(0)
band.Delete(9001)
It looks like band.Delete will always crash the client if the specified band doesn't exist.
The correct behavior would be to either do nothing or throw a console error.
Another one:
print(band.AddToBandEndpoint(0, 1))
Another one:
print(band.AddBetweenSegments(0,0))
+1 from Susume: this line of lua crashes foldit reliably: band.Disable(band.GetCount()+1)
Argh. I can reproduce these bugs on the current build but not when debugging.
selection.Select()
structure.IsLocked()
structure.GetSecondaryStructure()
these crash too if the segment specified doesn't exist
band.SetStrength() crashes as well.
This issue appears to be a more general problem with parameter checking. Here are some additional examples which crash the client:
Calls like these used to produce errors, which could be trapped by the pcall function, allowing a recipe to log the error and perhaps continue. Now the same calls crash the client.
Thanks to Susume and robgee for moving the ball forward.