[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] Re: weird abortions

From: Thomas Dickey
Subject: Re: [Lynx-dev] Re: weird abortions
Date: Mon, 3 Jan 2005 15:20:23 -0500 (EST)

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.,
  (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]