>>>>> Przemek Borys writes:
> EHLO!
> What can cause a segmentation fault? Things, which I'm aware of, are
> checked, and they are
> -incorrect malloc/realloc/free operations
This includes:
- Writing before or behind a malloced structure
- accessing a malloced area after free has been called
> -bad hardware
> -a bug in libc
> To make clear of what I'm talking about:
> I wrote a program (info viewer -- pinfo), and in two functions I get
> segmentation faults. I've checked it on few machines, running
> different operating systems, and the result was always the same.
> I also run the program compiled with -lefence, and after that I also
> tried with -lccmalloc. The result was that the segmentation faults
> didn't occur at all.
> I've also created wrappers for malloc/realloc/free, which logged what
> they werre doing. And nothing. The program sigsegv'ed on realloc() when
> reallocating block of (re)allocated previously memory (of certain size).
> Gdb said that all those faults came from libc_free...
Looks really like a malloc problem. Run your application with
MALLOC_CHECK_=1 or 2 in the environment to call some malloc self
checks (this works with glibc2 and AFAIK also with later libc5
versions).
> So? I'm really confused, I think I'll become grey because of this ;)
> And on my side, I'll take a closer look at the free() sources...
Better check your code first, the malloc source should be ok.
Andreas
P.S. From the glibc2 manual:
Another possibility to check for and guard against bugs in the use of
@code{malloc}, @code{realloc} and @code{free} is to set the environment
variable @code{MALLOC_CHECK_}. When @code{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 @code{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 @code{MALLOC_CHECK_} is set to @code{0}, any detected heap
corruption is silently ignored; if set to @code{1}, a diagnostic is
printed on @code{stderr}; if set to @code{2}, @code{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.
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
