dplatt@coherent.com (Dave Platt) (05/16/89)
I'm stumped. I just can't figure this one out. HELP!
I've been working recently on the latest incarnation of my fractal-
drawing program MandelZot... adding better color support, and making it
compatible with the new 32-bit Color QuickDraw code. The current
version is crashing upon exit... usually with an ID=01, but sometimes
with different codes. A long series of change-one-thing-and-try-again
tests has narrowed down the conditions under which it crashes, and they
make no sense whatsoever to me!
Here's what I've found:
1) An older version of the application crashes in the same way. I've
been distributing this older version for the past three months or so,
and running it under 6.0.2 and 6.0.3 with nary a problem.
2) The program crashes only if 32-bit Color QuickDraw is installed.
[I'm using the 1.0 release version, courtesy of a local developer.
This is _not_ the 1.0a7 seed version].
If QD32 is not installed, the crash does not occur... exact same
System, Finder, video-card setup, etc.
3) Removing my 20-or-so nonstandard INITs, cdevs, and so forth has no
apparent effect on the problem.
4) The program crashes only if I've opened up a window with a custom
palette. I can open and close any series of such windows without
noting any problems, but opening any one such window will guarantee a
crash on exit.
5) TMON 2.8.1's strict trap discipline doesn't detect report any errors
in trap parameters. Both the application and system heaps appear to
be intact at the moment of the crash.
6) The crash occurs only when running a stand-alone application in the
single-Finder environment. Under MultiFinder, the crash does not
occur. Running the program from within the THINK C 3.02 development
environment, the crash does not occur.
7) The crash occurs even if I disable my higher-speed, construct-a-
PixMap-on-the-fly-and-CopyBits-it-to-the-screen "FlashUpdate"
subroutine, and do all of the drawing via one-pixel-at-a-time
QuickDraw calls.
8) Here's the really weird one: the crash occurs if, and only if, the
CODE segment in the application file that contains the THINK C
"MacTraps" glue is unlocked.
This is particularly odd because I _never_ do anything in my program
that would cause this segment to move or to be unloaded! As I
understand it, the Segment Loader will load the segment into memory
and lock it (if it wasn't already locked in the resource file) when I
first use any of the routines in the segment. The segment would
become eligible for being moved, or for being purged from memory,
if-and-only-if I ever issued an UnloadSeg() call for one of the entry
points in the segment.
I don't. I've tried putting this glue-file in a segment by itself,
or in the same segment as my main() entry point. No effect... the
crash occurs (100% of the time) if the segment containing this glue
is unlocked in the resource file, and does not occur (ever, as far as I
can tell) if the segment is locked in the resource file. Completely
disabling my "unload all external segments after each event" routine
has no effect whatsoever.
I am completely baffled. If anybody out there can suggest a cause for
this problem, and/or explain why the problem never showed up before
32-bit QuickDraw came on the scene, I'd REALLY appreciate the
information!
Yours in puzzlement,
--
Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805
UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com
INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303