Re: Strangely modified variables

[Gerhard Niklasch <nikl@mathematik.tu-muenchen.de>]

In response to:
> Message-ID: <Pine.SOL.3.96.1010121121822.16892A-100000@elios>
> Date: Sun, 21 Jan 2001 12:27:05 +0000 (GMT)
> From: Mark Chimley <M.Chimley@bristol.ac.uk>
> 
> I have a program with a function as follows:
> 
> int func (GEN p, char **string)
> {
>    GEN n;
...
>    output (p);
>    n = stoi (1);
>    output (p);
> 
>    /*  rest of function */
>    ...
> }
> 
> This produces the following output when called with a GEN argument of 3:
> 
> 3
> 1073741827
> 
> So p appears to change its value because of stoi (1). I am at a loss as
> to what is going on. Incidentally, 1073741827 = 0x40000003.

This has probably nothing at all to do with the function, and
everything with the context in which you call it.

I suggest you insert a few strategic fprintf(stderr, "...", ...)
here, and have them display the pointers as addresses  (use the %p
format),  the words they point at, and also the global variable
avma.  I expect you'll find that p occupies an area of the stack
which is _already_ garbage  (in fact, collected garbage, i.e. below
avma)  at the time the function is called, and that the t_INT object
pushed onto the stack by the stoi overwrites whatever p is pointing
at.  The value of the variable p  (which is itself a GEN, i.e. pointer
to long)  does not in fact change here.  (There's no way it could
change unless you had done something extremely weird to the identifier
stoi, e.g. replaced it by a macro mentioning p, or the C compiler
you're using is broken.)  Only the area of memory which p points at
has been re-used by stoi() and overwritten.

The ultimate cause may be that the object at which p points was
itself created by a function which, before returning, had reset
avma to a value at the wrong end of the words occupied by this
object.  Or it may be over-aggressive garbage collecting in the
meantime, without taking care to preserve the p object across
the gc.

Hope this helps,
Gerhard

(and if it is any comfort -- the PARI developers are not immune
to this kind of coding accident.  Got my own fingers burned like
this...)