invalid object bug.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. uncommenting the "orientation box fill" in testdraw.ps
2. Triggers an invalid object error 2 pages later in the fat curves.
3.

What is the expected output? What do you see instead?

It should execute all of this code with no difficulty. Mysterious bug. I 
strongly suspect the save/restore mechanism and/or garbage collection.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by luser.droog on 2 Dec 2013 at 11:39

[GoogleCodeExporter]

Hm. I can't trigger the bug at the moment.
Attached is full text output for the 'runtest' sequence. It shows perfect 
handling of degenerate polygons. And no invalid objects. :/ 

Original comment by luser.droog on 3 Dec 2013 at 1:14

Attachments:

• buglog

[GoogleCodeExporter]

The suspicious area in the buglog begins with the first "break>" It then fills 
each segment of a brown fat curve with a sharp cusp. The bug was happening at 
the end of the curve. After it got into the next curve, I typed "clearhook" at 
"break>" and let it continue. It ran to the end.

Original comment by luser.droog on 3 Dec 2013 at 1:34

[GoogleCodeExporter]

invalid objects are returned as error indications by object-returning internal 
functions. These really should not show up at the ps level. Enough support has 
been added at the ps level that an invalid object yields the name invalidtype 
as its type, and converts to the string "@INVALID@" in cvs. So if it shows up 
again, it's a bug in internal error handling. If you still have a prompt after 
the error report, then the output from '$error /estack get ==' may be useful in 
tracking down the exact operator producing the invalid object.

Original comment by luser.droog on 16 Dec 2013 at 9:48

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by luser.droog on 5 Jan 2014 at 9:37

• Changed state: Fixed