Program Terminates ...

Program Terminates ...

[Peter Richtmyer]

I hope someone can help. 

I am running a couple programs using
Gnat 3.15p on Win2000. One program has a number of tasks that
all have exception handlers. Virtually all my routines have 
exception handlers too. 

After running awhile (the two programs exchange 
messages) the one program terminates gracefully - for no 
apparent reason. Eventually all the tasks seem to terminate,
though I have not coded any normal way out of some of them
(endless loops).  And I have "Put_Line" statements in all 
exception handlers and at the end of the main program. 
But no error messages are printed. (Other "normal" messages
are printed during the run.)

Is there some resource that could be used up and yet not cause
an exception? Or what would cause this behavior? I have never
seen anything like this before, and I've been at it some years. 
Any ideas very welcome. It is deadline time!

Thanks,
Peter

Re: Program Terminates ...

[Steve]

You might try adding a delay after each of the Put_Line statements in the
exception handlers.  Maybe the program is getting killed before the message
makes its way out.

I have seen this type of termination before, usually not with Ada.  I have
been known resort to saving state information about each task in shared
memory so I could see where things were when the program died.

Steve
(The Duck)

"Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
news:1b585154.0312211634.6c414d2e@posting.google.com...
> I hope someone can help.
>
> I am running a couple programs using
> Gnat 3.15p on Win2000. One program has a number of tasks that
> all have exception handlers. Virtually all my routines have
> exception handlers too.
>
> After running awhile (the two programs exchange
> messages) the one program terminates gracefully - for no
> apparent reason. Eventually all the tasks seem to terminate,
> though I have not coded any normal way out of some of them
> (endless loops).  And I have "Put_Line" statements in all
> exception handlers and at the end of the main program.
> But no error messages are printed. (Other "normal" messages
> are printed during the run.)
>
> Is there some resource that could be used up and yet not cause
> an exception? Or what would cause this behavior? I have never
> seen anything like this before, and I've been at it some years.
> Any ideas very welcome. It is deadline time!
>
> Thanks,
> Peter

Re: Program Terminates ...

[Georg Bauhaus]

Steve <nospam_steved94@comcast.net> wrote:
: You might try adding a delay after each of the Put_Line statements in the
: exception handlers.  Maybe the program is getting killed before the message
: makes its way out.

Text_IO.flush?

-- Georg

Re: Program Terminates ...

[Randy Brukardt]

That sort of termination often happens when you run out of memory.
Storage_Error is raised, and when you handle the exception and try to print
out a message, Storage_Error gets raised again. Then the task silently ends.

I've debugged that sort of problem dozens of times. Some of them were "bug"
reports from customers of Janus/Ada.

Anyway, there isn't much you can do to guard against this problem. The best
defense is to find the memory leak and get rid of it. Doing that will
require using tools specific to your compiler; for instance MemAvail and
StackAvail in Janus/Ada, along with debugging storage pools.

                    Randy.

"Steve" <nospam_steved94@comcast.net> wrote in message
news:3lDFb.627904$Fm2.565052@attbi_s04...
> You might try adding a delay after each of the Put_Line statements in the
> exception handlers.  Maybe the program is getting killed before the
message
> makes its way out.
>
> I have seen this type of termination before, usually not with Ada.  I have
> been known resort to saving state information about each task in shared
> memory so I could see where things were when the program died.
>
> Steve
> (The Duck)
>
> "Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
> news:1b585154.0312211634.6c414d2e@posting.google.com...
> > I hope someone can help.
> >
> > I am running a couple programs using
> > Gnat 3.15p on Win2000. One program has a number of tasks that
> > all have exception handlers. Virtually all my routines have
> > exception handlers too.
> >
> > After running awhile (the two programs exchange
> > messages) the one program terminates gracefully - for no
> > apparent reason. Eventually all the tasks seem to terminate,
> > though I have not coded any normal way out of some of them
> > (endless loops).  And I have "Put_Line" statements in all
> > exception handlers and at the end of the main program.
> > But no error messages are printed. (Other "normal" messages
> > are printed during the run.)
> >
> > Is there some resource that could be used up and yet not cause
> > an exception? Or what would cause this behavior? I have never
> > seen anything like this before, and I've been at it some years.
> > Any ideas very welcome. It is deadline time!
> >
> > Thanks,
> > Peter
>
>

Re: Program Terminates ...

[Stephen Leake]

"Steve" <nospam_steved94@comcast.net> writes:

> You might try adding a delay after each of the Put_Line statements in the
> exception handlers.  Maybe the program is getting killed before the message
> makes its way out.

Better to use Ada.Text_IO.Flush; that's what it is for.

-- 
-- Stephe

Re: Program Terminates ...

[Stephen Leake]

prichtmyer@yahoo.com (Peter Richtmyer) writes:

> After running awhile (the two programs exchange 
> messages) the one program terminates gracefully - for no 
> apparent reason. Eventually all the tasks seem to terminate,
> though I have not coded any normal way out of some of them
> (endless loops).  And I have "Put_Line" statements in all 
> exception handlers and at the end of the main program. 
> But no error messages are printed. (Other "normal" messages
> are printed during the run.)

What do you mean by "seem to terminate"?

I suggest you simplify your program to just two tasks, and test it
thoroughly. then add more tasks one by one, testing at each step.
You'll find it, and have a much better program for all the work.

-- 
-- Stephe

Re: Program Terminates ...

[Martin Krischik]

Georg Bauhaus wrote:

> Steve <nospam_steved94@comcast.net> wrote:
> : You might try adding a delay after each of the Put_Line statements in
> : the
> : exception handlers.  Maybe the program is getting killed before the
> : message makes its way out.
> 
> Text_IO.flush?

http://www.adaic.org/standards/95lrm/html/RM-A-10-1.html#I5689
http://www.adaic.org/standards/95lrm/html/RM-A-10-3.html

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Program Terminates ...

[Peter Richtmyer]

prichtmyer@yahoo.com (Peter Richtmyer) wrote in message news:<1b585154.0312211634.6c414d2e@posting.google.com>...

> Is there some resource that could be used up and yet not cause
> an exception? 

I don't like to point fingers when not absolutely certain, but 
it seems like Gnat may not be re-using memory from Unbounded_String's
that as their lengths change.


Below is part of gnatmem output:
----------------- snip ---------------
E:\>gnatmem -o temp2.out ut_wc_client.exe
y
gdb-internal-error: virtual memory exhausted: can't allocate 144
bytes.
C:\GNAT\bin\gdb.exe: *** mount version mismatch detected -
0x1A010A68/0x1B.
You have multiple copies of cygwin1.dll on your system.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version
*should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.
     24 [main] gdb 5240 sync_with_child: child 3348(0x230) died before
initialization with status code 0x1
    587 [main] gdb 5240 sync_with_child: *** child state waiting for
longjmp
  53862 [main] gdb 5240 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
  79130 [main] gdb 5240 open_stackdumpfile: Dumping stack trace to
gdb.exe.stackdump

### incorrect user program  termination detected.
    following data may not be meaningful

Global information
------------------
   Total number of allocations        :1666861
   Total number of deallocations      :   0
   Final Water Mark (non freed mem)   : 298.08 Megabytes
   High Water Mark                    : 298.08 Megabytes

Releasing deallocated memory at :
--------------------------------
   : ada__strings__unbounded__finalize$2

   : ada__strings__unbounded

   : system__file_io__close

   : ada__text_io__afcb_free$2

   ./UTT/lan_common/pragmarc.skip_list_unbounded.2.ada:183ut_macro_pkg.vardb_o.vardb_pkg.delete

Allocation Root # 1
-------------------
 Number of non freed allocations    :1415127
 Final Water Mark (non freed mem)   :  81.81 Megabytes
 High Water Mark                    :  81.81 Megabytes
 Backtrace                          :
   : ada__strings__unbounded__adjust$2

Allocation Root # 2
-------------------
 Number of non freed allocations    :159053
 Final Water Mark (non freed mem)   :   9.34 Megabytes
 High Water Mark                    :   9.34 Megabytes
 Backtrace                          :
   : ada__strings__unbounded__to_unbounded_string

Allocation Root # 3
-------------------
 Number of non freed allocations    :77215
 Final Water Mark (non freed mem)   : 149.88 Megabytes
 High Water Mark                    : 149.88 Megabytes
 Backtrace                          :
   : ada__strings__unbounded__append$2

Allocation Root # 4
-------------------
 Number of non freed allocations    :13393
 Final Water Mark (non freed mem)   :  54.49 Megabytes
 High Water Mark                    :  54.49 Megabytes
 Backtrace                          :
   : ada__strings__unbounded__replace_slice$2

--------------------- end snip -------------------

I started replacing Unbounded_strings and it seems to help.
Bu tthere are alot more.

The RM says:

   "Implementation Requirements 

   No storage associated with an Unbounded_String object shall 
   be lost upon assignment or scope exit. "

I seem to be losing storage though. And
is it OK to lose storage when the string changes length?
Would like to hear what folks know about this.

Thanks,
Peter

Re: Program Terminates ...

[Jeff C,]

"Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
news:1b585154.0312300730.459483cc@posting.google.com...
> prichtmyer@yahoo.com (Peter Richtmyer) wrote in message
news:<1b585154.0312211634.6c414d2e@posting.google.com>...
>
> > Is there some resource that could be used up and yet not cause
> > an exception?
>
> I don't like to point fingers when not absolutely certain, but
> it seems like Gnat may not be re-using memory from Unbounded_String's
> that as their lengths change.
>
>

I've never seen a problem with GNAT not reclaiming unbounded_string storage
but it certainly does
not mean that there are no bugs there.. I do notice all the cygwin errors
you are getting saying that
the data might not be meaningful

Do you get the same results if you are not using the cygwin environment
since GNAT is not officially
supported on Cygwin (it is a currently a mingw based win32 distribution).

Re: Program Terminates ...

[Peter Richtmyer]

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message news:<tphIb.15634$xX.39631@attbi_s02>...

> I do notice all the cygwin errors
> you are getting saying that
> the data might not be meaningful
> 
> Do you get the same results if you are not using the cygwin environment
> since GNAT is not officially
> supported on Cygwin (it is a currently a mingw based win32 distribution).

I am not using Cygwin - could not even find that DLL on my computer.
I think gnatmem is confused there. Also, the gnatmem output did show alot
of DEALLOC messages for unbounded_string's (along with the ALLOC's).

There are 3 major areas where I use unbounded_string's in the pgm. I 
changed to fixed strings in one area, and have not seen memory 
problems there any more. I really like the unbounded variety, but 
can not have the program crashing all the time. 

I used to run it more on Unix (Rational Ada) and only on Gnat for 
development. And did not have these problems. But this version is Gnat only. 
(Using Gnat Sockets). I have made other changes too. But the messaging
means more exercising of the Unbounded_String objects I have, and it 
seems to be the cause of the memory problems.

From the RM, it sounds like Bounded_String's would be as bad. It said
they should not be dynamically allocated. 

Hey. Could it be that the Unbounded_String's are not the problem per se, 
but the fact that they are within record objects being dynamically
allocated is the problem?  Or one of the problems?

thanks,
Peter

Re: Program Terminates ...

[Jeff C,]

"Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
news:1b585154.0312301431.6816874d@posting.google.com...
> "Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message
news:<tphIb.15634$xX.39631@attbi_s02>...
>
> > I do notice all the cygwin errors
> > you are getting saying that
> > the data might not be meaningful
> >
> > Do you get the same results if you are not using the cygwin environment
> > since GNAT is not officially
> > supported on Cygwin (it is a currently a mingw based win32
distribution).
>
> I am not using Cygwin - could not even find that DLL on my computer.
> I think gnatmem is confused there. Also, the gnatmem output did show alot
> of DEALLOC messages for unbounded_string's (along with the ALLOC's).
>

Hmm..Interesting. I have not seen a cygwin error message come of out. What
version
of GNAT are you running?

> >
> Hey. Could it be that the Unbounded_String's are not the problem per se,
> but the fact that they are within record objects being dynamically
> allocated is the problem?  Or one of the problems?
>

Well, if these record are either not controlled types or are never
explicitly free'd then yes this could be the problem.

Re: Program Terminates ...

[Simon Wright]

prichtmyer@yahoo.com (Peter Richtmyer) writes:

> I am not using Cygwin - could not even find that DLL on my computer.
> I think gnatmem is confused there. Also, the gnatmem output did show
> alot of DEALLOC messages for unbounded_string's (along with the
> ALLOC's).

The gdb packaged on Windows for (recent?) GNATs needs cygwin; the
normal cygwin1.dll has been copied to cyggnat.dll (in eg
c:\GNATPRO\3.16a1\bin).

-- 
Simon Wright                               100% Ada, no bugs.

Re: Program Terminates ...

[Peter Richtmyer]

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message news:<CxnIb.79460$VB2.161212@attbi_s51>...

> Hmm..Interesting. I have not seen a cygwin error message come of out. What
> version
> of GNAT are you running?
> 

I am running Gnat 3.15p on Win2K. That includes C:\GNAT\bin\cyggnat.dll

Re: Program Terminates ...

[Frank J. Lhota]

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message
news:tphIb.15634$xX.39631@attbi_s02...
> Do you get the same results if you are not using the cygwin environment
> since GNAT is not officially
> supported on Cygwin (it is a currently a mingw based win32 distribution).

I don't see how this could be an issue. Cygwin is an extension of MING
technology that provides much better POSIX compatability. If your
application is developed with MING and avoids the Cygwin stuff, then the
CYGWIN1.DLL should have no effect on the running of your application.

Re: Program Terminates ...

[Robert I. Eachus]

Jeff C, wrote:

>>Hey. Could it be that the Unbounded_String's are not the problem per se,
>>but the fact that they are within record objects being dynamically
>>allocated is the problem?  Or one of the problems?

> Well, if these record are either not controlled types or are never
> explicitly free'd then yes this could be the problem.

Definitely true.  If you allocate an object on the heap, then don't free 
it, any Unbounded_Strings within the object won't be deallocated unless 
you leave the scope of the object type.  (In the normal case of the type 
being declared in a library package or the main program, read never.)

The other potential problem is that your Unbounded_String use could be 
fragmenting the heap.  Unfortunately the way to fix/test this is to 
allocate everything else from some non-default heap.  If you have only a 
few such types it should be easy enough to give each its own heap with a 
specified size, but if you have lots of dynamically allocated types 
using non-default heaps can get old fast.

Incidently, it sounds like Bounded_String is probably the right solution 
for your problem.  If it is possible to put a reasonable limit on the 
size of the strings nested inside other dynamic types, this should solve 
your problem--and result in faster code.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush