On Wed, 1 Mar 2017, Barna Becsek wrote:
I found the place the assertion is tripped. In the attachment you
can see the stack and location of the casting. Haven’t dug into why
this happens yet…
Well, at least we know the cast is a red herring now! That's not a
64-bit invalid_something_or_other constant being cast into too small a
target, that's just garbage being read out of an invalid memory
pointer.
Except...
How could that *possibly* be garbage? The quadrature rule there is
getting initialized properly at MaxQpsThread.C:69, and it goes
straight from there into some of the most heavily tested code in
libMesh, so I can't imagine the stack getting smashed in there.
Is it possible that we're trying to use a garbage elem there?
getActiveLocalElemRange looks correctly implemented, so we're not
hitting an inadvertently cached pointer to a removed element or
anything crazy like that.
I really wish you could boil this down to a test code I could
replicate... I'm now at the point where I can't think of what to do
other than poke at elem, etc. in memory and see if I can find earlier
evidence of corruption.
Is it safe to assume that the crash happens mid-range, not at the
first element hit?
---
Roy
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
