> On 3 Mar 2017, at 22:30, Roy Stogner <royst...@ices.utexas.edu> wrote: > > > On Fri, 3 Mar 2017, Barna Becsek wrote: > >>> On 3 Mar 2017, at 17:47, Roy Stogner <royst...@ices.utexas.edu> wrote: >>> >>> On Fri, 3 Mar 2017, Barna Becsek wrote: >>> >>>>> On 3 Mar 2017, at 17:28, Roy Stogner <royst...@ices.utexas.edu> wrote: >>>>> >>>>> What is &qw and how does it compare to &(this->qrule->_weights) a >>>>> level up? It could be that the pointer underlying that reference got >>>>> scribbled on. >>>> >>>> &qw is 0x11c20a8 and >>>> &(this->qrule->_weights) is 0x11c20c8 >>>> >>>> I guess you were right, they are not the same address. >>> >>> What does elem->have_affine_map() return? true, I assume? It looks >>> as if compute_affine_map() and dependencies are the only places we >>> could be trashing the stack? >> >> Yes, elem->has_affine_map() always returns true in any point in the stack >> after where there is an elem instance. >> Is there anywhere else I can dig around? > > If it really is the first element that's triggering the corruption, > then this might not be impossible to debug. > > You could set a break point in FEProblemBase.C:3124, then after that > at FE.C:263, and if that's at the broken element then you'll be there > *pre*-breakage. Start stepping into functions, keep checking &qw and > &(this->qrule->_weights), and as soon as the former changes you'll > know you hit your stack-smashing line of code.
Not sure if this helps but it seems the iterator for the active semilocal elements lacks information on _begin and _end values. There are values for _first (=0 on each process) and _last but I don’t know whether they are used for iteration. (see attachment) This might explain a problem where the wrong element is referenced maybe(?). That iterator “range” gets passed on to MaxQpsThread::operator(). But if I check in the loop over elements it seems like the elements on the respective processes have distinct _id’s and _unique_id’s, i.e. the local ones. Anyway, &qw never actually changes. The first time it is used is in FEMap::compute_map() (invoked at FE::reinit() (fe.C:263)) where it gets obtained as this->qrule->get_weights(). This somehow goes bad. The received address in &qw is different from the passed one in &(this->qrule->_weights). I don’t know if this helps but the addresses’ difference between the passed &(this->qrule->_weights) and the accepted &qw is always 0x000000000020 (32 bit?) on every process. This is what I was able to find. I hope this helps somehow. –Barna > > I hope... elem->has_affine_map() is the only obvious hunk of tricky > code in between putting qw on the stack and using it in corrupted > form. But that's a *const* method, with no "mutable" tricks under the > hood, so it really shouldn't be possible for it to corrupt anything > else in memory. > — > Roy ------------------------------------------------------------------------------ Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
