On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
> On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
>
> Here is a workaround for one hash related GC bug.
^^^^^^^^^^
> + volatile Buffer *for_gc;
> /* hash->buffer.flags |= BUFFER_report_FLAG; */
>
> /* We rely on the fact that expand_hash() will be called before
> @@ -295,7 +296,12 @@
> hash->max_chain = (HashIndex) -1;
>
> hash->entries = 0;
> - hash->bucket_pool = new_buffer_header(interpreter);
> +
> + /* In order to keep the bucket_pool header from being
> + * collected from expand_hash(), a pointer to it is put on
> + * the system stack where the stack walking code can find it */
> + for_gc = hash->bucket_pool = new_buffer_header(interpreter);
> +
This is a case of a temporary allocated value being only in a CPU register?
If so, I believe that this is no solution of the cause, merely working round
a symptom. The stack walking code needs custom assembler to find all values in
the CPU registers that may not be on the stack.
We cannot control correct third party code that is linked against parrot.
So we cannot expect the solution to GC crashes to be "oh, you need to
get the source to libfoo and declare a variable volatile so that the stack
walking code can see it"
If I've misunderstood the cause of the above problem, oops, sorry.
But I believe that we still need to check for pointers in the CPU registers,
because on a register rich CPU is is not impossible that something has the
only pointer to an in use value still only in a CPU register.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
