NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/mac/programm/18627

Text File | 1992-11-18 | 5.3 KB | 124 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!news.udel.edu!chopin.udel.edu!kurisuto
From: [e-mail] (Sean J. Crist)
Subject: Summary: THINK Pascal and stand-alone crashes
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: chopin.udel.edu
Organization: University of Delaware
Date: Thu, 19 Nov 1992 03:47:23 GMT
Lines: 112

In a recent posting, I described a crash which is happening in a
stand-alone application but which isn't happening in the THINK
Pascal run environment.  I've had several requests for the
responses that I've gotten; since this topic seems to be of
general interest, I'm summarizing what I've gotten here.

Some have suggested that my problem is that I'm not initializing
the Toolbox:

(Person A wrote)
> Is your program doing all of the Mac initialization stuff at the start?
> When running in ThinkP these calls are done for you, but when you build the
> standalone they aren't.  I mean stuff like:  InitGraf, InitWindows,
> InitDialogs... etc.  Look up these calls in InsideMac or in any listing of
> a complete Mac program!

However, others have correctly pointed out that you should NOT
initialize the Toolbox, since this is done for you both in the
Pascal environment and in the stand-alone application:

(Person B wrote)
> Let me guess--your program explictly calls InitGraf, InitFonts, InitWindows,
> etc.
>
> If so, this is the cause of your crash.  THINK Pascal automatically adds
> glue initializing a whole bunch of Toolbox managers.  Any explicit calls
> from within your program are ignored when executed in the TP environment,
> but cause crashes when you run in standalone mode.  (See pp. 150 and
> pp. 211 of the TP User Manual.)
>
> Basically, you have two choices: 1) you can remove the explicit
> initializations from your program, or 2) you can compile with the {$I-}
> compiler directive (which suppresses the automatic initialization).
>
> If this is not your problem, then it beats me...

Several people have suggested that I'm not managing my grafPorts
properly:

(Person C wrote)
> QuickDraw dies horribly if there is no valid port set when it's called.
> Inside TP, if you haven't changed the port explicitly, one of TP's windows
> will be a valid port; outside TP, it's a problem. Do a SetPort to your
> window after you create it and every time you receive an activate event
> for that window.

Some have spoken about things not being initialized, but I would like
to hear more specifics:

(Person D wrote)
> It might be some pointer or other variable that is not initialised. The
> debugger does this automatically.

(Person E wrote)
> TP does several things for you in the runtime environment: local (stack)
> vars are initialized to zero; your explicit stack and memory allocations
> get set up; there are lots of subtle differences having to do with TP
> sitting between you and the system; your code executes in a heap zone
> in TP's heap zone; etc.
>
> You won't know the real answer until you track down the bug and see how
> it could slip through in one environment and not in the other. Sorry.

(Person F wrote)
> The THINK Environment is a bit kinder regarding nil pointers, dereferenced
> handles and initial values. Check that you aren't using any variables before
> setting them and that all your handles are locked before dereferencing.

Other miscellaneous suggestions:

(Person G wrote)
> I've experienced this twice: once a memory leak, once a NewHandle
> call with a bad parameter to the SizeOf function.
>
> These are frustrating bugs to track down. If it's not apparent from
> inspecting the code, you may have to run the built app under MacsBug
> (with Names on in the compiled app). You'll have to do this eventually
> to make sure your app survives heap scrambling.
>
> Check your SIZE -1 resource to be sure your built app has as much memory
> as you've allocated in TP's compiler option dialog.

(Person H wrote)
> It is probably something not properly initialized. I've had to resort to
> rewriting the application. I've corrected three problems in the new version:
> - proper handling of update events. I think I might have been trying to write
> to windows which weren't mine. At least my application crashed whenever I
> tried to resize my window (stand-alone, not in the Think environment).
> - opening a open-file-dialog with 0 as the number of types specified in the
> type-list. In system 7 this worked ok (showed all files), but in system 6 it
> showed zero files, only folders.
> - pointer arithmetic. I am used to programming on a PC with Turbo Pascal,
> which doesn't make a difference between PACKED and UNPACKED ARRAY's. Well,
> Think most certainly does :-(.

(Person I wrote)
> Welcome to the real world. The odds are that your problem is caused by
> improper management of GrafPorts, but that aside, you should become
> proficient in the use of Macsbug to debug your code. It's a requirement
> for doing any sort of Mac programming.

Several people have recommended that I obtain Macsbug to determine
exactly where the crash is happening.  I have done this, and I'm
learning to use it (and I like it very much).  I have succeeded
in isolating the code where this particular crash is occuring, but
I don't know *why* it's happening.  I'm going to post that problem
separately.

Thanks to all who responded!

--Kurisuto