From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,518cb96553aa98c9,start
X-Google-Attributes: gid103376,public
From: Andreas Schulz <accot.schulz@nord-com.net>
Subject: Problem with VADS memory management - any way to tune
 fat_heap_global?
Date: 2000/08/01
Message-ID: <39873D67.C6522787@nord-com.net>#1/1
X-Deja-AN: 653361382
Content-Transfer-Encoding: 7bit
X-Accept-Language: de,en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@newsfeed.nordcom.net
X-Trace: newsfeed.nordcom.net 965164514 444 213.168.193.164 (1 Aug 2000
 21:15:14 GMT)
Organization: frei & daheim
Mime-Version: 1.0
NNTP-Posting-Date: 1 Aug 2000 21:15:14 GMT
Newsgroups: comp.lang.ada
Date: 2000-08-01T21:15:14+00:00
List-Id: <comp.lang.ada>

Maybe someone can enlighten me...
Up to now, I have encountered a few cases where different
programs, all built with VADS 6.3.4(c) (or was it 6.4.3?)
for Solaris 2.6 worked fine until confronted with larger 
amounts of data, where they either exit with an exception
(which is caught internally resp. has escaped my memory, 
so I can't tell exactly which) from, or, if this exception is
ignored, hangup inside some 'fat_heap_global' package
(judging from a core dump analysis).

I'm inclined to try some tweaking with v_usr_conf, since
the problem to me looks like a fragmentation problem
of some limited memory pool, but the VADS reference isn't
very helpful to me in this case...

TIA, A.Schulz