Path: utzoo!mnetor!uunet!husc6!bbn!metasoft!alan
From: alan@metasoft.UUCP (Alan Epstein)
Newsgroups: comp.sys.mac.programmer
Subject: PrintMgr Bug?
Message-ID: <371@metasoft.UUCP>
Date: 5 May 88 17:14:48 GMT
Organization: Meta Software Corporation, Cambridge MA
Lines: 54

i think i may have discovered an elusive bug in the print
manager, print glue or printer drivers (notably but not
restricted to the LW). all this relates to Design/2.0 which
is built using LightSpeed C (v2.15).

what i am doing is constructing an ordinary grafport which contains a
collection of boxes and polygons numbering less than 60. the polygons
are each about 38 bytes in size (about 6 vertices). when 'update' time
occurs, i write the objects to the device (screen or printer) using FrameRect
and FramePoly trap calls. all according to guidelines.

i have been able to construct cases where one or more of the polygons is
printed incorrectly -- part way thru the drawing, the polygon
is drawn to some incorrect position, indicating that the
points vector had been damaged. the next polygon is always fine.
on the other hand, using the same basic code, drawing the same set
of polygons to the screen never fails.

i have walked thru some of the print manager code and discovered that
when an offending polygon is being sent to the print driver (via
FramePoly), a call to PFDumpBuf() is invoked by PFOut() (both I assume
internal print manager or glue routines for which i have no documentation).
there appears to be a direct correlation between polygon failures
and calls to PFDumpBuf().

my hypothesis is that under certain circumstances, during a FramePoly
call, part of this polygon is written to the print port, the buffer
becomes full, requiring it to be flushed, and upon returning, PFOut
is no longer able to remember where it left off and writes some bogus
polygon segments for the remainder of the count.

this occurs on a Mac II (4Meg) or a Mac + (2Meg). it matters not whether
the polygons are locked prior to calling FramePoly (although i see that
FramePoly locks them anyway), nor is the presence of a printer
idle routine important.

although the problem manifests without any special debugging tools, it
is possible to exacerbate the failures (cause them where they were not
otherwise occurring), by using the TMON 'heap scramble' option. again,
the problem occurs without scramble.

i'm interested in learning from anyone who may have seen anything
remotely related to these bugs. i'd also like to hear from anyone
at apple who knows the internals of the printer manager & drivers
since i think that's where the problem lies.

feel free to call if you'd like further information.

	alan epstein
	meta software corp
	(617) 576.6920

	[ alan%metasoft@bbn.com	] or
	[ bbn!metasoft!alan		]