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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d29352214f90bc6f
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-01-20 02:05:07 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: petter.fryklund.konsult@dynamics.saab.se (Petter Fryklund)
Newsgroups: comp.lang.ada
Subject: Re: Stack Problem?
Date: 20 Jan 2003 02:05:06 -0800
Organization: http://groups.google.com/
Message-ID: <f74cb448.0301200205.5cab1bee@posting.google.com>
References: <f74cb448.0301160210.3fa1bd66@posting.google.com>
 <ba162549.0301161252.17eefbbe@posting.google.com>
NNTP-Posting-Host: 138.14.239.132
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1043057107 444 127.0.0.1 (20 Jan 2003 10:05:07
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 20 Jan 2003 10:05:07 GMT
Xref: archiver1.google.com comp.lang.ada:33229
Date: 2003-01-20T10:05:07+00:00
List-Id: <comp.lang.ada>

The problem was really an erronous free of an instance of a global
data array.

But for future ... what can we do about monitoring stack usage in
general. We're using several different GNAT's but this specific is
3.15 on Solaris 5.5, 5.6 or 5.8.


kcline17@hotmail.com (Kevin Cline) wrote in message news:<ba162549.0301161252.17eefbbe@posting.google.com>...
> petter.fryklund.konsult@dynamics.saab.se (Petter Fryklund) wrote in message news:<f74cb448.0301160210.3fa1bd66@posting.google.com>...
> > We are getting a SEGV out of realfree (/libc.so.1) call stack is
> > 
> > realfree
> > cleanfree
> > _malloc_unlocked
> > malloc
> > calloc
> > netconfig_dup
> > __rpc_getconfigip
> > gethostbyname_r
> > gnat__sockets__get_host_by_name
> > ....
> > 
> > Parameters sent from gnat__... seems to be alright. I've no idea about
> > the library, since it's not compiled with debug info.
> > 
> > I suspect that we've exceed the stack limit, but I can't find a way to
> > verify that. 
> 
> Crashes below malloc are almost always caused by heap
> corruption.  Your code or some library code has probably corrupted 
> the heap by freeing the same object twice, or by modifying an object
> after it was deallocated.