Re: Possible heap problem on Windows, help sought

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@nospam.please> wrote in message
news:456dc966$0$31542$39db0f71@news.song.fi...
> Ludovic Brenta wrote:
...
> > 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.

I fought a problem like that in our spam filter for several months. I
introduced debug pools on virtually every access type, and only managed to
slow the filter down a lot. I'd pretty much given up on trying to find the
problem when I ran the program under a Windows debugger: and while tracing
it I got some bizarre messages about heap problems. I later found out that
Windows automatically uses a debug heap when a program is run under the
debugger. Anyway, tracing the messages led to a Free call in an DNS binding.
The Ada code for the allocator and deallocators were similar, while the
allocator used **DNS_Rec and the deallocator used *DNS_Rec. So I was passing
a pointer into the stack into the deallocator; no wonder things got
confused. Oddly, the binding in question had been in production use for more
than 3 years; apparently, it was never used in a program that was long
running enough to show the corruption.

Moral: for memory corruption bugs: they can be anywhere, even in code that's
supposedly well-tested. And a likely culprit is bindings to non-Ada code,
because the checking that Ada provides is lost there (the compiler can't
detect mistakes).

                             Randy.