Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!rice!sun-spots-request
From: als@roxanne.mlb.semi.harris.com (Alan Sparks)
Newsgroups: comp.sys.sun
Subject: Re: Compatibility problem?
Keywords: Miscellaneous
Message-ID: <1990Aug9.022500.7419@rice.edu>
Date: 7 Aug 90 17:52:35 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 40
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 296, message 8
X-Refs:  Original: v9n296

In article <1990Aug7.003432.1984@rice.edu> onders@taac.ipl.rpi.edu (Timothy E. Onders) writes:

> [program omitted]
> When run on the Sun 3, attempting to write to the array gives a
>SEGV.  Attempting to read the array from dbx gives a "bad address" error.
>by examining the addresses of the three variables, there seems to be
>enough space for everything allocated. There is 4 megs of space between
>the array starting address, and the address of r.  Any ideas what might be
>causing this problem, and how I can get around it?

I haven't taken much time to research this really well... but I suspect
you've blown out the stack on the 68xxx CPU (especially with such a mondo
array).  I duplicated your situation, then devised a couple of
workarounds.

One workaround is to make the array "testm" static:

	static int testm[1024][1024];

This moves it off the stack, into the static data area.  Another
workaround (especially if you want to reclaim storage) is to dynamically
allocate the array.  One way to do it is:

	int **testm, i;

        testm = (int **) calloc(1024,sizeof(int *));
        for (i = 0;  i < 1024;  ++i)
          testm[i] = (int *) calloc(1024,sizeof(int));

The remainder of the code stays the same.  To reclaim storage afterward:

	for (i = 0;  i < 1024;  ++i)
          cfree(testm[i]);
        cfree(testm);

Some variant of these workarounds will solve your problem.  They work on a
local Sun 3/60 here.

Hope this helps.
-Alan