John Peterson wrote:
> 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 :-)
_n did end up getting set correctly; for that .in file it was supposed
to be 2. The _n and _i_off on the other subsolution got set correctly
as well.
I ended up finding the bug I was looking for, but without nearly as much
gdb help as I would have liked. Nobody should have to find bugs by
actually reading their own code and thinking about what it's doing;
that's just barbaric.
---
Roy
-------------------------------------------------------------------------
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
