Question concerning usage of gnatmem

Question concerning usage of gnatmem

[Dr. Michael Paus]

Hi,

I am just analyzing a program on Linux with GNAT 3.14p using gnatmem.

When I run gnatmem on the output file generated by a previous run of
the main program I get the following result:

mpaus@ip4:>gnatmem -i gmem.out ../bin/i386-Linux/main_single_board
Global information
------------------
    Total number of allocations        :1079
    Total number of deallocations      :  51
    Final Water Mark (non freed mem)   : 242.08 Kilobytes
    High Water Mark                    : 242.08 Kilobytes

Allocation Root # 1
-------------------
  Number of non freed allocations    :1028
  Final Water Mark (non freed mem)   : 242.08 Kilobytes
  High Water Mark                    : 242.08 Kilobytes
  Backtrace                          :
    ??:0 ??

This looks strange to me because I actually expected more allocation roots
than just one.

I'd be happy if someone could answer me the following questions:

When I run the program I have to stop it via Cntrl-C because this software
was designed to run forever and there is no other way to stop it. Does this
lead to a corrupt output file?

If the output is likely to be corrupt is there any other way to get the
memory usage until the time when the program is stopped?

Many thanks in advance

Michael

Re: Question concerning usage of gnatmem

[Stephen Leake]

"Dr. Michael Paus" <paus@ib-paus.com> writes:

> When I run the program I have to stop it via Cntrl-C because this software
> was designed to run forever and there is no other way to stop it. Does this
> lead to a corrupt output file?

In general, I suspect the answer is "yes".

> If the output is likely to be corrupt is there any other way to get
> the memory usage until the time when the program is stopped?

Probably not. 

Modify your code; it probably has a top-level forever loop. Change it
to run 1000 times, or whatever produces useful results.

-- 
-- Stephe

Re: Question concerning usage of gnatmem

[Dr. Michael Paus]

Stephen Leake wrote:
> "Dr. Michael Paus" <paus@ib-paus.com> writes:
> 
> 
>>When I run the program I have to stop it via Cntrl-C because this software
>>was designed to run forever and there is no other way to stop it. Does this
>>lead to a corrupt output file?
> 
> 
> In general, I suspect the answer is "yes".
> 
> 
>>If the output is likely to be corrupt is there any other way to get
>>the memory usage until the time when the program is stopped?
> 
> 
> Probably not. 
> 
> Modify your code; it probably has a top-level forever loop. Change it
> to run 1000 times, or whatever produces useful results.

Well, if it were so easy I would have done that already :-) The program
consists of about 30 tasks all waiting for some input to process and
some of them listening on sockets to receive some data from external
sources. It is not so easy to force this program to terminate without
major changes to the code. If I remember correctly there was a discussion
here recently on how to stop an Ada program. The solution, if there was
any, would be handy here now.

Michael

Re: Question concerning usage of gnatmem

[Stephen Leake]

"Dr. Michael Paus" <paus@ib-paus.com> writes:

> Stephen Leake wrote:
> > "Dr. Michael Paus" <paus@ib-paus.com> writes:
> >
> >>When I run the program I have to stop it via Cntrl-C because this software
> >>was designed to run forever and there is no other way to stop it. Does this
> >>lead to a corrupt output file?
> > In general, I suspect the answer is "yes".
> >
> >>If the output is likely to be corrupt is there any other way to get
> >>the memory usage until the time when the program is stopped?
> > Probably not. Modify your code; it probably has a top-level forever
> > loop. Change it
> > to run 1000 times, or whatever produces useful results.
> 
> Well, if it were so easy I would have done that already :-) The program
> consists of about 30 tasks all waiting for some input to process and
> some of them listening on sockets to receive some data from external
> sources. It is not so easy to force this program to terminate without
> major changes to the code. 

As I recall, what you are doing is trying to find out if there is a
memory leak. That can be done by running each piece of the program
separately, in a unit test. If each unit does not leak, the program as
a whole does not leak.

Hmm, maybe you were trying to find out the max memory usage of the
program. That's harder to do in pieces, since it depends on the
pattern of use. If you really need to know that, you'll need to define
your own storage pools, that allow you to query their current usage.
Then add a command to one of the tasks to dump that information.

> If I remember correctly there was a discussion here recently on how
> to stop an Ada program. The solution, if there was any, would be
> handy here now.

Abort the environment task. That's supposed to also abort all
dependent tasks, but it may not work if they are waiting on sockets
(since that's an OS issue, not an Ada issue). Give it a try.


Perhaps you can add a "please terminate" message to each task? Maybe
that's what you meant by "major changes to the code".

-- 
-- Stephe

Re: Question concerning usage of gnatmem

[Dr. Michael Paus]

Stephen Leake wrote:
> "Dr. Michael Paus" <paus@ib-paus.com> writes:
> 
> 
>>Stephen Leake wrote:
>>
>>>"Dr. Michael Paus" <paus@ib-paus.com> writes:
>>>
>>>
>>>>When I run the program I have to stop it via Cntrl-C because this software
>>>>was designed to run forever and there is no other way to stop it. Does this
>>>>lead to a corrupt output file?
>>>
>>>In general, I suspect the answer is "yes".

I looked at this issue a little bit closer and I am sure now that this is no
problem. The file is written sequentielly and the processing can stop when there
is no more valid input.

>>>
>>>
>>>>If the output is likely to be corrupt is there any other way to get
>>>>the memory usage until the time when the program is stopped?
>>>
>>>Probably not. Modify your code; it probably has a top-level forever
>>>loop. Change it
>>>to run 1000 times, or whatever produces useful results.
>>
>>Well, if it were so easy I would have done that already :-) The program
>>consists of about 30 tasks all waiting for some input to process and
>>some of them listening on sockets to receive some data from external
>>sources. It is not so easy to force this program to terminate without
>>major changes to the code. 
> 
> 
> As I recall, what you are doing is trying to find out if there is a
> memory leak. That can be done by running each piece of the program
> separately, in a unit test. If each unit does not leak, the program as
> a whole does not leak.

No, I am not trying to find memory leaks. I am just trying to find the
maximum storage used and where it is used. That's exactly what gnatmem
is designed for.

> Hmm, maybe you were trying to find out the max memory usage of the
> program. That's harder to do in pieces, since it depends on the
> pattern of use. If you really need to know that, you'll need to define
> your own storage pools, that allow you to query their current usage.
> Then add a command to one of the tasks to dump that information.

Gnatmem is doing that in a much simpler way.

>>If I remember correctly there was a discussion here recently on how
>>to stop an Ada program. The solution, if there was any, would be
>>handy here now.
> 
> 
> Abort the environment task. That's supposed to also abort all
> dependent tasks, but it may not work if they are waiting on sockets
> (since that's an OS issue, not an Ada issue). Give it a try.
> 
> 
> Perhaps you can add a "please terminate" message to each task? Maybe
> that's what you meant by "major changes to the code".
> 

This is all not so easy if the tasks are involved in blocking IO calls.

Actually I have solved my problem already with the help of gnatmem. The
problem seems to be that gnatmem on Linux is broken. I have written a
simple test program which terminates correctly by itself and even for
that I do not get a proper backtrace. The global allocation information
though seems to be correct and that's the most important information for
me.

Michael