lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev 2-8-1 bug: print vs partial


From: Klaus Weide
Subject: Re: lynx-dev 2-8-1 bug: print vs partial
Date: Thu, 3 Dec 1998 05:29:48 -0600 (CST)

On Thu, 3 Dec 1998, Philip Webb wrote:

> thanx: i'll wait & see what others say, then test things.
> NB there's  strace  output which may nail the problem down more precisely:
> it's something to do with a `sigbus', which is beyond me.
> do you have any comment on that (a later message)?

Yes, if it is memory corruption (in this case, freeing memory that
another part of the program may still access later), then it is
unpredictable where a problem will occur (if at all).  A SIGSEGV or
SIGBUS may be generated in a place that looks totally unrelated.

Excerpt from a linux malloc(3) man page:

NOTES
       Crashes in malloc(), free() or realloc() are almost always
       related  to  heap corruption, such as overflowing an allo­
       cated chunk or freeing the same pointer twice.

       Recent versions of Linux libc (later than 5.4.23) and  GNU
       libc  (2.x)  include a malloc implementation which is tun­
       able via environment  variables.   When  MALLOC_CHECK_  is
       set,  a  special  (less  efficient) implementation is used
       which is designed to be tolerant  against  simple  errors,
       such  as double calls of free() with the same argument, or
       overruns of a single byte (off-by-one bugs).  Not all such
       errors  can be proteced against, however, and memory leaks
       can result.  If MALLOC_CHECK_ is set to  0,  any  detected
       heap  corruption is silently ignored; if set to 1, a diag­
       nostic is printed on stderr;  if  set  to  2,  abort()  is
       called  immediately.  This can be useful because otherwise
       a crash may happen much later, and the true cause for  the
       problem is then very hard to track down.


  Klaus


reply via email to

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