[BUG] TRIANGLE causes hard lockup
09-12-2014, 08:08 PM (This post was last modified: 09-15-2014 03:48 PM by Han.)
Post: #1
 Han Senior Member Posts: 1,810 Joined: Dec 2013
[BUG] TRIANGLE causes hard lockup
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)?

Graph 3D | QPI | SolveSys
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)