On Thu, Oct 16, 2008 at 4:59 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
> (gdb) p elem_subsolutions[0]
> $2 = (DenseSubVector<double> *&) @0x750ed0: 0x74d9f0
> (gdb) p *elem_subsolutions[0]
> $4 = {<DenseVectorBase<double>> = {_vptr.DenseVectorBase =
> 0x2ae6f8e271d0}, _parent_vector = @0x74a568, _n = 2, _i_off = 0}
> (gdb) p (*elem_subsolutions[0]).size()
> $6 = 4167516032
> (gdb) p (*elem_subsolutions[0])._n
> $7 = 2
>
> Double checking our dense_subvector.h:
>
> /**
> * @returns the size of the subvector.
> */
> virtual unsigned int size() const { return _n; }
Assuming everything that's relevant has been recompiled, linked
etc...could it have anything to do with not initializing _n in the
constructor's initialization list? I don't see how that could be a
problem, since _n is set during the call to reposition, unless you are
at a breakpoint just before the call to reposition :-)
template<typename T>
inline
DenseSubVector<T>::DenseSubVector(DenseVector<T>& parent,
const unsigned int ioff,
const unsigned int n) :
_parent_vector(parent)
{
reposition (ioff, n);
}
--
John
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
