Re: Question concerning usage of gnatmem

["Dr. Michael Paus" <paus@ib-paus.com>]

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