Re: lynx-dev DOS binary of lynx2.8.4dev.9 crashing [PATCH]

[Doug Kaufman]

On Tue, 12 Sep 2000, Doug Kaufman wrote:

> > The DOS binary of lynx2.8.4dev.9 is crashing when accessing some local
> > directories. This seems to occur most when going to "file:///./". I
> > built a debugging version and got the following call frame traceback.

I finally found the code that was causing the crash. This was added in
2.8.4dev.5. As you know, I am not a programmer, but this appears to
be freeing memory that was never allocated in the first place. DJGPP
code almost always crashes when free is called on unallocated memory.
Removing this code prevents the crashes that I previously reported.
>From the DJGPP FAQ:

9.2 Programs that crash in `malloc' or `free'.
==============================================

_*Q*: Since I upgraded to DJGPP v2.02, my program started to crash, and the
traceback points to library function `free'.  This program worked flawlessly
with v2.01, so I guess there's a bug in the new version of `free', right?_


*A*: Such problems are a tell-tale sign of programs that overwrite buffers
allocated by `malloc' or `calloc', or call `free' more than once with the
same pointer, or pass to `free' a pointer that didn't originate from a call
to `malloc' or `calloc'.  If the program that crashes is a C++ program, you
might have several objects that share the same data, and the object
destructor crashes when it calls `free' several time with the same memory
chunk.

These crashes happen inside the memory-allocation functions because these
functions maintain some crucial information about the allocated and free
memory blocks right before the beginning and beyond the end of the allocated
buffers.  For speed considerations, this information is not protected by any
means like CRC or parity, so if you overwrite this information, `malloc' and
`free' will become confused and eventually will blow up.

The version of `malloc' in DJGPP library before v2.02 left some slack space
beyond the end of the allocated buffer (this was a side-effect of the
algorithm it used, which was optimized for speed, but wasted some memory).
Thus, a program could overrun the allocated buffer and still get away
uncaught.  The new version of `malloc' introduced with v2.02 doesn't waste
memory, and because of this is much less tolerant to such bugs.
                            Doug

--- lynx2-8-4/src/LYUtils.c     Thu Aug 24 18:30:12 2000
+++ lynx2-8-4/src/LYUtils.c.new Fri Sep 15 08:20:58 2000
@@ -7266,8 +7266,6 @@
     if (!LYIsHtmlSep(*leaf))
        LYAddHtmlSep(target);
     StrAllocCat(*target, leaf);
-    if (leaf != source)
-       FREE(leaf);
 }
 
 #ifdef NOTDEFINED
__ 
Doug Kaufman
Internet: address@hidden



; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden