Re: Possible heap problem on Windows, help sought

[Niklas Holsti <niklas.holsti@nospam.please>]

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
       .      @       .