Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!svin02!eba!ebm!bloks
From: bloks@ebm.eb.ele.tue.nl (rudi_bloks)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problems with THINK pascal
Message-ID: <1048@eba.eb.ele.tue.nl>
Date: 23 Jan 91 09:33:32 GMT
Sender: news@eb.ele.tue.nl (The News system)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 80

About the following error with THINK pascal 3.0 (And also 3.01):

> I'm having a problem with Think Pascal that is wasting a lot of my time.
> Every so often when I select "Go" from the "Run" menu instead of my
> program executing, an alert with 3 lines of garbage text gets displayed.
> After hitting the OK button, a "Think Pascal has unexpectedly quit"
> alert appears.  I have no idea what's going wrong.  I don't think my
> programs are the cause.  Has anyone had similar problems or is it just
> me?

> I'm using a IIsi with 5 megs of ram.  System 6.0.7.  It's happened under
> Finder and Multifinder.

I have encountered exactly the same problem with THINK pascal 3.01.
Also, i have found a 95% guaranteed way of reproducing it. So for those
of you that never saw it, and Symantec in particular, here it is:

1) Run TP under MultiFinder and allocate x Kb of memory.
   Choose x yourself, i have allocated 2500 Kb to TP.

2) Open any project file, choose run options and set the amount of
   run time memory allocated to your project to any value larger
   than x. I set it to 3500 Kb.

3) Choose 'GO'. Result: TP crashes, by showing a large dialog box
   filled with a few lines of garbage (random) characters, where
   you are required to click 'OK'. After doing so, it crashes with
   ID = 3. (unexpectedly quit error message displayed by MF).

Apparently, TP doesn't check if it has enough memory to allocate to
your project. IT just goes ahead as if it *does* have anough.

Now that we're talking about TP anyway, here's some more strange
behavior:

* If you define a PACKED ARRAY[0..32767] OF BYTE, and also a pointer
  to it, then something goes wrong with computing the address of 
  any indexed location of the array, if the index is anything but a
  constant. The following program crashes with a bus error. 

       program test;

         type
           ByteArray = packed array[0..32767] of Byte;
           BArrPtr = ^ByteArray;
    
         var
           rom: BArrPtr;
           ind: Integer;

       begin
         rom := BArrPtr(NewPtr(100));
         for ind := 0 to 99 do
             rom^[ind] := 99 - ind;
         ind := 10;
         writeln(rom^[ind]);
       end.                                                

  This only happens with the debugging option ON. If either of the two
  index range values in the type definition is changed, the bug disappears, 
  even if the size of the array type stays the same. Checking out the 
  array addresses with the OBSERVE window reveals that the array locations
  are computed incorrectly.

* When your program is stopped in the debug mode, TP changes the updateRgn
  of your app's windows to something of its own, and sets them back when
  your app. resumes execution. However, if you try to examine this updateRgn
  using LightsBug, you get to see the values that TP put in there i.s.o. 
  your own. Only typing the corresponding expressions in the observe window 
  will reveal the real updateRgn for your application windows.

Rudi.

======================================================================
|  Rudi Bloks                       |   email  bloks@eb.ele.tue.nl   |
|  Eindhoven University             |          elebrb@urc.tue.nl     |
|  Of Technology                    ==================================
|  Dept. Of Electrical Engineering, EH 11.29                         |
|  POBox 513, 5600 MB Eindhoven, the Netherlands                     |
======================================================================