Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!uw-beaver!tektronix!tekcrl!tekgvs!larryh
From: larryh@tekgvs.TEK.COM (Larry Hutchinson)
Newsgroups: comp.sys.mac.programmer
Subject: Help! 'Monitors' cdev related bug.
Message-ID: <3189@tekgvs.TEK.COM>
Date: 7 Mar 88 18:43:24 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 59
Keywords: bug MacII cdev offscreen bitmap


Is anyone aware of problems with the 'Monitors' cdev in the current
system release?

I have a very nasty bug in an application I am working on (or in the
'Monitors' cdev).  The bug is very difficult to reproduce.  
It manifests itself as a bus error when changing the number
of colors using the control panel.  I am 80% sure the problem is with
my code but would like to check with you folks first.

Additional info for those who like this sort of thing:

The bus error occurs deep within the cdev -- after it has done an
InitGDevice and appears to be walking the window list. I suspect that
it bombs when it hits one of my windows that uses an offscreen bitmap.
This window destroys and recreates the offscreen bitmap whenever the
number of bits per pixel changes.  Thus a lot of heap activity takes place
when the # of colors is changed in the control panel.  One thing in
this mess of code that I am unsure about is the fact that I steal the
pixMapHandle from a freshly created color graf port and keep it around
for when the screen needs updating.  Since the graf port is transient,
I install a sacrificial fake pixMapHandle (via NewHandle(0L)) before
disposing of the color graf port.  Is this ok?  Should I clone the
pixMapHandle rather than using a fake one for disposal?  Otherwise,
I am pretty much using the technique described in TN120 (or whatever
-- this is from memory).

The problem does NOT appear to occur more frequently under TMON's heap
scramble and check.

Discipline reveals a questionable _RecoverHandle in the cdev code that
is using an address below the application heap.  Perhaps this is just the
system heap and TMON does not recognize it.  (It occurs continuously while
the control panel is running ( and not just the Monitors cdev).  This is
the only thing revealed by Discipline.

There is plenty of memory available.

There are around 300 objects in the heap.  The heap "looks" ok.

Multifinder is not running.

The bus error occurs BEFORE my windows are updated.  Perhaps something
becomes foobar from a previous change -- I have to change the '# of colors'
several times before the bomb occurs.

I have finally found a sequence of events that will always produce
the problem and will be spending time single stepping thru the cdev
unless I get an indication from you folks that it may not be my
problem.

Thanks for any info,



Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 50-383, Beaverton, OR 97077
UUCP:   [uunet|ucbvax|decvax|ihnp4|hplabs]!tektronix!tekgvs!larryh
ARPA:   larryh%tekgvs.TEK.COM@RELAY.CS.NET
CSNet:  larryh@tekgvs.TEK.COM