Re: [Lynx-dev] Re: weird abortions

[Thomas Dickey]

On Tue, Jan 04, 2005 at 04:03:16PM +0000, Thorsten Glaser wrote:
> I don't exactly grok, then, why I have never had these problems
> with 2.6.6dev.7b in the same configuration?

But didn't you just recently start using ProPolice?
(Were you running 2.8.6dev.7b with ProPolice, that is).

> 
> The only diff which relates to free() is... uh, I don't find
> the one I had in mind at the moment.
> 
> There are also a bunch of diffs like
> @@ -8041,8 +8037,9 @@
>         if (!(stream->fp = LYOpenTemp(filename, HTML_SUFFIX, BIN_W))) {
>             CTRACE((tfp,
>                     "SourceCacheWriter: Cannot open source cache file for URL 
> %s\n",
> -                   HTAnchor_address((HTAnchor *) anchor)));
> +                   cp_freeme = HTAnchor_address((HTAnchor *) anchor)));
>             FREE(stream);
> +           FREE(cp_freeme);
>             return target;
>         }
>  
> but I don't suspect them that much.

Well, they could be.  Suppose that cp_freeme was set by an assignment to
a constant string.  Then the code would work if tracing was turned on, but
not otherwise.  (a grep of cp_freeme doesn't show me this is a problem).

The fixes that would prevent you from testing dev.9 to compare with dev.10
are relatively small (one is 1-line, the other is less than 10).  I'd test
dev.9 with those fixes (and then be more certain that none of the innocent
leak-fixes are responsible).

dev.8 also is different from dev.7b (though I don't recall what changed there).

When I have to retest an old lynx version, I start from the versions in
PRCS (for which I do have a local RCS archive with RCS-keywords stubbed
out), and construct a series of build trees between them.  Usually that's
not hard - things like the configure script and the ".po" files can be
dealt with rapidly, and once those are done, the difference is fairly
small.

That's generally what I do on the other programs anyway - I check-in
individual file-changes and mark the releases with a symbolic tag.
(Pulling by date is good enough to narrow things down for inspection).
 
> AND I still can't be sure it's a memory allocation problem...
> that's why I will now simply build lynx without ProPolice
> and look if I can debug it better afterwards.

ProPolice may be the only tool that notices the problem (that may be good ;-)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net