[BUG] TRIANGLE causes hard lockup

[Han]

This bug drove me nuts. I think I have found the heart of the problem, though. The new version of TRIANGLE and TRIANGLE_P commands return a list of points that can be used by later calls to these commands or the LINE_P command. However, the current state REQUIRES that the returned list of points MUST be saved, or else (and this is a guess) a memory overrun occurs.

For example, repeatedly calling the following code (presumably inside a subroutine) causes no issues.

Code:

dimgrob_p(G1,320,240);
  zs:= TRIANGLE(); // Get z clipping
  local rotated= triangle_p(G1, points, triangles, { Rot, "N", { -160, -120, mind*zoom3D }, xmin3D, xmax3D, ymin3D, ymax3D, zmin3D, zmax3D }});
  line_p(G1, rotated, lines, zs);

On the other hand, the code:

Code:

dimgrob_p(G1,320,240);
  zs:= TRIANGLE(); // Get z clipping
  triangle_p(G1, points, triangles, { Rot, "N", { -160, -120, mind*zoom3D }, xmin3D, xmax3D, ymin3D, ymax3D, zmin3D, zmax3D }});
  line_p(G1, rotated, lines, zs);

will eventually lock up the entire calculator and a paperclip reset is required. I can pinpoint that the lockup occurs exactly at some future instance of zs:=TRIANGLE(); -- not sure if that is significant. Perhaps this is a garbage collection issue? Cyrille or Tim?

EDIT: This raises the question: Does the current firmware properly handle values returned but not saved (a case of unreferenced pointers, for example)?