[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address changes on function call
From: |
Pascal J. Bourguignon |
Subject: |
Re: address changes on function call |
Date: |
Wed, 29 Jul 2009 00:46:34 +0200 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) |
Evan <edrumwri@gmail.com> writes:
> Hi everyone,
>
> I am experiencing the following strange and fatal behavior. Given the
> function below:
>
> VectorN MatrixN::get_row1(unsigned i) const
> {
> VectorN v;
> get_row2(i, v);
> return v;
> }
>
> The variable 'v' has the address '0x7ffff8c4d988'. Stepping through
> gdb to get_row2(), where 'v' is passed in by reference, reports:
>
> MatrixN::get_row2 (this=0x7fff31c34940, i=0, result=@0x7fff31c34a50)
>
> The address of 'v' (called 'result' in get_row2) has suddenly
> changed! Even stranger, 'print v' while in get_row1() indicates:
>
> $4 = {
> _vptr.VectorN = 0x7fff31c34a50,
> ...
> }
>
> So, vptr (I assume this has to do with the fact that VectorN has
> virtual methods) actually points to the address that is passed to
> get_row2()! Regardless of this occurrence, any changes that I make to
> 'result' in get_row2() do not show up as they should in 'v' in get_row1
> ().
>
> Unfortunately, this behavior is not reproducible in a small test
> program, just in my library of 70k lines of code :)
>
> Any elucidation about what might be happening would be greatly
> appreciated.
You should show us the definition of VectorN and the signature of
get_row2.
This could occur if VectorN inherit from multiple superclasses, and
get_row2 takes one in parameter as reference. Other cases are
certainly possible.
--
__Pascal Bourguignon__