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,5de108d9cf7f21e0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-22 01:52:58 PST From: "Dr. Michael Paus" Newsgroups: comp.lang.ada Subject: Re: Question concerning usage of gnatmem Date: Sun, 22 Sep 2002 10:52:57 +0200 Organization: 1&1 Internet AG Message-ID: References: NNTP-Posting-Host: p508302b0.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.online.de 1032684777 14166 80.131.2.176 (22 Sep 2002 08:52:58 GMT) X-Complaints-To: abuse@online.de NNTP-Posting-Date: 22 Sep 2002 08:52:58 GMT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!newspeer.clara.net!news.clara.net!newsfeed01.sul.t-online.de!t-online.de!news.belwue.de!news.uni-ulm.de!rz.uni-karlsruhe.de!schlund.de!news.online.de!not-for-mail Xref: archiver1.google.com comp.lang.ada:29245 Date: 2002-09-22T08:52:58+00:00 List-Id: Stephen Leake wrote: > "Dr. Michael Paus" writes: > > >>Stephen Leake wrote: >> >>>"Dr. Michael Paus" 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