Re: [Lynx-dev] Re: weird abortions

[Thomas Dickey]

On Mon, 3 Jan 2005, Thorsten Glaser wrote:

> The ?? orgy continues...
>
> [...]
> #164 0x00000000 in ?? ()
> #165 0xcfbf26d8 in ?? ()
> #166 0x1c0e4f42 in valloc ()
> Previous frame inner to this frame (corrupt stack?)
>
>
> Do you still suggest to re-try with valgrind or recompiling
> lynx with find-leaks?

Perhaps.  As you see, memory corruption problems can be tedious to
resolve.  I recall troubleshooting something like this by running
lynx with the trace option turned on, and seeing how far it got.
(This, of course, for a case which I could reproduce).  Then I added
more CTRACE's in the general area where the code appeared to die.
Some of the CTRACE's are for very low-level calls, and it's hard to
see where they are, so adding calls such as

        CTRACE((tfp, "%s @%d\n", __FILE__, __LINE__));

to the source above those calls can give some hints.  Mostly I rely on
traces to give information (it's rare for me to use more than a half-dozen
gdb commands in a session - walkback, run, print (2-3 different 
variables).

The one I have in mind was this:

* replace fixed-buffer Style_className[] with a dynamically-allocated buffer,
  needed for large pages which lack correctly-nested tags, e.g.,
    http://www.aspas-nature.org/petitions/petition2.html
  (reported by Frederic L W Meunier) -TD

The problem was that a fixed-buffer (under src) was used for storing a 
stack of names.  When it ran past the end of the buffer, adjacent data was 
overwritten, causing a secondary problem down in the WWW logic, and 
finally a core dump.

Narrowing the problem down to see where the first problem can be observed 
is the first step.  The cause may be far removed from the symptom - which 
is why it's nice to have a case that can be repeated (in debugging, I 
repeat those cases many times ;-)

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