[Top][All Lists]

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

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

From: Doug Kaufman
Subject: Re: lynx-dev DOS binary of lynx2.8.4dev.9 crashing [PATCH]
Date: Fri, 15 Sep 2000 08:53:49 -0700 (PDT)

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

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.

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

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

reply via email to

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