Re: [Lynx-dev] Re: weird abortions

[Thomas Dickey]

On Mon, Jan 03, 2005 at 08:26:56PM +0000, Thorsten Glaser wrote:
> Thomas Dickey dixit:
> 
> > 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.
> 
> Hm, strlcpy and truncation detection, or so?

something like that (but strlcpy isn't portable).
 
> What about having a buffer which grows as needed, but there is always
> exactly one allocated?

lynx has its own functions.  But with 170,000 lines of source code (50,000
statements), it's possible to overlook the bad usage of fixed buffers among the
good ones.  Bear in mind that lynx has been audited by several different people
(and old bugs are occasionally found - proving that auditing doesn't find all
of the bugs).

For instance the core dump from last week was misuse of a pointer - something
I should have seen if I'd been alert enough.
 
> > 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 ;-)
> 
> Sure, but I can't reproduce it.

:-(
 
> The last one happened when going from slashdot (light layout) to
> OSnews (in a slashbox), but there were at several other pages too,
> and never twice at the same, not even if reproducing the "surfing"
> behaviour.

I'll spend some time with valgrind, see if I can make dev.10 crash.
The nice thing about valgrind is that I don't have to recompile the
application to find problems (though for analysis, a debug-image is
needed).

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