Re: Wrong layout of the return value of gpow()?

[Ilya Zakharevich <ilya@math.ohio-state.edu>]

On Sun, Jul 16, 2000 at 03:01:03AM +0200, Gerhard Niklasch wrote:
> (i.e. the three-word t_INTMOD:  codeword, modulus pointer, and
> representative pointer;  followed by another unrelated word)
> 
> > As you can see, RETVAL[2] is less than RETVAL.  This causes a segfault
> > in Math::Pari.  Is it a bug?
> 
> That is the normal arrangement -- the parent object is created
> first, and its child object(s) is (are) created after it and
> thus below it on the stack.

This looks like my misunderstanding of the layout of objects on the
stack.  I thought that "taking a continuous chunk of the stack"
includes the object to be placed *after* the pointer to the object.
Let me try again:

  oavma = avma;
  RETVAL = pari_function(..);
  navma = avma;

The (part of the) return value which sits on the stack fills the chunk
between navma and oavma, but RETVAL can point anywhere between navma
and oavma-1, right?

> RETVAL[1] looks more suspect to me, but there's no way of telling
> from the information shown whether 0x6e23a0 is itself on the PARI
> stack or  (which would be likely for an INTMOD)  whether it points
> to a cloned t_INT on the heap.

In the situation in question I would expect it to be on the heap.

> What pointer is the perl module tripping over, then?  Where was
> gpow() called from, and what did the caller (attempt to) do with
> the return value?  Stacktrace at the time of the SIGSEGV?

Math::Pari uses a (superior?) memory management comparing to gp.  The
Perl objects which maps to GENs have the "on stack/heap" flag.  Those
objects which point to the stack are joined into the linked list.
When such an object is free()ed, then

  a) if the objects is the latest one, avma is corrected;
  b) if the object is deeper in the chain, then the later objects
     are first clone()ed to the heap, then the avma is corrected.

This allows substantially lower malloc()/free() overhead (or
gerepile() overhead).  [There is no memory overhead for the lists,
since Perl objects mapped to GENs happen to have a lot of unused
slots.]

[Of course, there are two variables which govern the avma correction:
the "level" related to GENs in the currently active subroutine, and
the "level" of "delayed-on-stack" objects.]

I now think that due to the misunderstanding above my avma-correction
logic is flawed.

Ilya