Dear Roy, 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…
–Barna > On 1 Mar 2017, at 14:50, Barna Becsek <barnabec...@gmail.com> wrote: > > Alright, thank you for giving it a look. As far as I can see from libmesh’s > config.log the CXXFLAGS_DBG do include the option -O0. > > For the others I cannot really do much at the moment because I am in a > somewhat unfortunate situation, where: > I have a filesystem on the cluster that I can compile stuff on but to which > the compute nodes, i.e. also the debugger, have no access to. > I can use the framework compiled by the computational center that’s located > on a filesystem that is accessible but I cannot perform any changes on. > My local computer is a mac and gdb does not work with the dynamic library > version of macOS Sierra. (I am restricted to the GNU compilers) > > But I will try and figure something out where I can have access both to a > large enough filesystem that’s accessible and to a working debugger. > I will keep you posted. Thanks again! > > –Barna > >> On 28 Feb 2017, at 21:41, Roy Stogner <royst...@ices.utexas.edu >> <mailto:royst...@ices.utexas.edu>> wrote: >> >> >> On Tue, 28 Feb 2017, Barna Becsek wrote: >> >>> I actually attached the stack to the previous email but I am not >>> sure whether I can actually send attachments to this mailing list. >> >> Depends on attachment size, but I simply overlooked it. I use a text >> email reader 90% of the time and my eyes glaze over attachments unless >> I'm expecting one. >> >> I'm actually as baffled as you are here. Presumably cast_int isn't in >> your stack because it's been inlined... but the last non-inlined >> non-throw in your stack is that MaxQpsThread::operator(), which >> doesn't call cast_int. And looks like it doesn't call anything >> inlined that calls cast_int, etc... unless there's something corrupted >> in that element range? The parallel_reduce is being called on >> active_local_elements, which doesn't do any cast_int IIRC, except for >> the refinement_flag, which is an 8-bit-to-32-bit cast whereas what >> you're seeing is a failing 64-bit-to-32-bit cast. >> >> Can you recompile with -O0? Full-on dbg mode might be too slow for >> your problem but we really need a full stack trace to have any idea >> what's going on here. >> --- >> 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
