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!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 30 Nov 2006 19:04:53 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <456d72b1$0$31519$39db0f71@news.song.fi> <456d9441$0$24608$39db0f71@news.song.fi> <4t5lq7F12jm1nU1@mid.individual.net> <456db855$0$24618$39db0f71@news.song.fi> <873b82qi90.fsf@ludovic-brenta.org> <456dc966$0$31542$39db0f71@news.song.fi> Subject: Re: Possible heap problem on Windows, help sought Date: Thu, 30 Nov 2006 19:05:28 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: <3IGdnfR2y-go4vLYnZ2dnUVZ_tqdnZ2d@megapath.net> NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-bHECPBA9JQRe3BfD+rwZABclMYw4ozAW4YCQuuPJgldFwvjxIYYLvBuQihZUiGCF9th6VIf3mbaCANu!LsPD2vW8n+/COsIcCEjk7lATauWOGA3M2JH6ftG0APsnEmYNWHN8jHyU57RtuyCKOFwL7Ue5uLQI!xs7XT/tGXLHztw== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:7764 Date: 2006-11-30T19:05:28-06:00 List-Id: "Niklas Holsti" 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.