[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rogue Pointer
Re: Rogue Pointer
Mon, 14 May 2001 14:25:27 +0200 (MEST)
On Mon, 14 May 2001, Dale P. Smith wrote:
> I'm get a "Error in scm_gc_mark during GC: rogue pointer in heap" when
> the first gc happens in cvs guile. This is in an Apache module.
> What is a "rogue pointer"? I image it's a pointer into gc controlled
> memory from somewhere in the heap. Or is it the other way around, a
> pointer to memory that's not gc controlled?
It indicatest that the gc detected a pointer into non-gc controlled space
at a place where a pointer into gc controlled space was expected. It is a
severe error. Unfortunately, it is difficult to determine the place where
the actual error occurs - the gc only tells you that some time between now
and the previous gc something went wrong. Typically, it is some smob code
that is responsible for the problem.
If you have difficulties to figure out what goes wrong, the following may
make "CFLAGS=-g -DSCM_DEBUG_CELL_ACCESSES=1"
make "CFLAGS=-g -DSCM_DEBUG_CELL_ACCESSES=1" install
It will add debugging code to guile in a way that even non-gc code does
exhaustive pointer checking with every heap access. The effect will be,
that you get a coredump as soon as an illegal pointer is detected, which
is hopefully close to the point where the heap corruption occured.
Rebuilding the apache module in a similar way (i. e. with
SCM_DEBUG_CELL_ACCESSES set to 1) should also be done, but is not
necessary. It would only possibly help to get closer to the actual
error's source, because the code of the apache module itself would also be
instrumented with pointer checks.
Quoting from __scm.h:
If SCM_DEBUG_CELL_ACCESSES is set to 1, cell accesses will perform
exhaustive parameter checking: It will be verified that cell parameters
actually point to a valid heap cell. Note: If this option is enabled,
guile will run about ten times slower than normally.
In my local version of guile there is a patch that goes even further and
performs _additional_ garbage collections in a way that is scalable the
user. However, I have never for myself run across a "rogue
pointer" myself, and therefore am not sure whether this would really be
If you choose to give the SCM_DEBUG_CELL_ACCESSES macro approach a try,
could you please give some feedback if it helped you? If you still have
problems getting to the source of the error, I'd like to provide my local
patches for guile to you.