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-Thread: 103376,d139a44b4dd6bc63
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!kanaga.switch.ch!switch.ch!newsfeed3.funet.fi!newsfeeds.funet.fi!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail
Date: Wed, 29 Nov 2006 19:53:42 +0200
From: Niklas Holsti <niklas.holsti@nospam.please>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Possible heap problem on Windows, help sought
References: <456d72b1$0$31519$39db0f71@news.song.fi>
	<456d9441$0$24608$39db0f71@news.song.fi>
	<mailman.30.1164810040.4389.comp.lang.ada@ada-france.org>
	<4t5lq7F12jm1nU1@mid.individual.net>	<456db855$0$24618$39db0f71@news.song.fi>
 <873b82qi90.fsf@ludovic-brenta.org>
In-Reply-To: <873b82qi90.fsf@ludovic-brenta.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <456dc966$0$31542$39db0f71@news.song.fi>
Organization: TDC Song Internet Services
NNTP-Posting-Host: laku61.adsl.netsonic.fi
X-Trace: 1164822886 news.song.fi 31542 81.17.205.61:33065
X-Complaints-To: abuse@song.fi
Xref: g2news2.google.com comp.lang.ada:7747
Date: 2006-11-29T19:53:42+02:00
List-Id: <comp.lang.ada>

Ludovic Brenta wrote:
> Niklas Holsti writes:
> 
>>I'm grateful for your advice. Thanks to the Ada run-time checks it
>>has been a while since I had to fight with this kind of bug, but I
>>hope it will come back to me -- and then go away again :-)
> 
> 
> Same here; for the past coupld of months, I've been trying, on and
> off, to fight a nasty heap corruption bug in GPS 3.1.3, 4.0.0 and now
> 4.1.1.  I've documented the various symptoms in Debian bugs #393636,
> #400876 and #400883.  I realised that my skills are insufficient for
> such a large-scale undertaking; Valgrind detected more that 10 million
> errors during a short run of GPS, most of which in Python or GTK+
> libraries, and not all of which are necessarily serious.  Any advice?

Ouch. Makes me feel comforted, in a way, but sorry, no advice yet.

> Today I replaced one instance of Unchecked_Deallocation with a no-op
> and behold, GPS no longer crashes.  Obviously, it leaks, but that's
> not as bad as crashing or hanging.

My application is a batch computation, not interactive, so I 
deliberately avoid deallocation and cheerfully let all low-turnover 
allocations leak. (I know this will bite me if/when I try to build a GUI 
for this application.) So I have only a small number of access types 
where dangling pointers may occur (I think).

> I'm thinking maybe I should instrument access types to use debug
> pools, but there are too many of them.

What do you think of a GNAT option to make debug-pools the default? 
Would it make sense?

> That's obviously not on Windows; sorry for hijacking your thread,
> Niklas :)

Feel free, it seems my problem is not Windows-specific, either.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .