Stack Problem?

Stack Problem?

[Petter Fryklund]

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. How can I do that? How can I even find out the stack
size? For heap usage there is gmem is there any similar for stacks?

Any suggestions?

Re: Stack Problem?

[David C. Hoos, Sr.]

It is impossible to answer your question because the answer depends
on a number of factors of which you haven't informed us -- gnat version,
OS and version - shell and version, at least.

There is a wealth of information about the gnat-dependent part of your
question in both the GNAT User Guide, and the GNAT Reference Manual
included with GNAT distributions.

The shell environment in which you execute your programs may provide
control over how much stack and heap is available to a user program --
e.g., in the tcsh shell the limit and unlimit commands.

----- Original Message ----- 
From: "Petter Fryklund" <petter.fryklund.konsult@dynamics.saab.se>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: January 16, 2003 4:10 AM
Subject: Stack Problem?


> 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. How can I do that? How can I even find out the stack
> size? For heap usage there is gmem is there any similar for stacks?
> 
> Any suggestions?
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
>

Re: Stack Problem?

[Kevin Cline]

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.

Re: Stack Problem?

[Petter Fryklund]

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.

Re: Stack Problem?

[David C. Hoos, Sr.]

Have you followed the instructions in the GNAT User's Guide, section 3.2.6?

----- Original Message -----
From: "Petter Fryklund" <petter.fryklund.konsult@dynamics.saab.se>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: January 20, 2003 4:05 AM
Subject: Re: Stack Problem?


> 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.
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>
>

Re: Stack Problem?

[Kevin Cline]

petter.fryklund.konsult@dynamics.saab.se (Petter Fryklund) wrote in message news:<f74cb448.0301200205.5cab1bee@posting.google.com>...
> The problem was really an erronous free of an instance of a global
> data array.

Oh.  It's pretty unusual to end up freeing something that was
never allocated at all.  

> 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.

If you have a bit of money to spend, then I recommend Rational Purify.
See http://www.rational.com/products/purify_nt/index.jsp

Re: Stack Problem?

[Petter Fryklund]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.2.1043065003.12836.comp.lang.ada@ada.eu.org>...
> Have you followed the instructions in the GNAT User's Guide, section 3.2.6?

Yes, I feel that we have.

> 
> ----- Original Message -----
> From: "Petter Fryklund" <petter.fryklund.konsult@dynamics.saab.se>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: January 20, 2003 4:05 AM
> Subject: Re: Stack Problem?
> 
> 
> > 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.
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >
> >