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,8727a81126dc209a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-22 05:18:13 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeeds.sol.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!wn11feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F6EE824.8040401@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Problem with memory leaks in Glade and GLADE References: <2PN9b.1478$I9.42@newsfep4-winn.server.ntli.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1064232984 24.34.139.183 (Mon, 22 Sep 2003 12:16:24 GMT) NNTP-Posting-Date: Mon, 22 Sep 2003 12:16:24 GMT Organization: Comcast Online Date: Mon, 22 Sep 2003 12:16:24 GMT Xref: archiver1.google.com comp.lang.ada:42741 Date: 2003-09-22T12:16:24+00:00 List-Id: Dr. Adrian Wrigley wrote: > The Annex E server also consumes constantly rising memory. > > In this case, each time a client partition connects and terminates, > the server partition grabs roughly another 200kB of memory. > My server code only allocates with "new" in one place, and > calls "Unchecked_Deallocation" shortly after. > I am puzzled by this, and suspect that the PCS may be leaking. > Any suggestions for tracing and solving this problem? The 200kB size makes me suspect that a task is being created and the memory not freed. The issue may be that the task control block is not being freed after the task is terminated. This can happen either as a bug in the implementation, or because the task may still be named after it is terminated. I suspect a combination of the two. A task created of a task type in an outer scope. (When you exit the scope in which the task was created, it is still live, but you may not be able to name it. When it terminates, the TCB and the task stack can be cleaned up--but there is no way for the creator to clean up afterward. And the task itself may not know that it can no longer be named.) > Your thoughts? > -- > Dr Adrian Wrigley, Cambridge, UK. > -- Robert I. Eachus Ryan gunned down the last of his third white wine and told himself it would all be over in a few minutes. One thing he'd learned from Operation Beatrix: This field work wasn't for him. --from Red Rabbit by Tom Clancy.