Re: [Libmesh-devel] Possible Valgrind issue

[John P. <jwp...@gm...>]

> On Jul 8, 2014, at 12:47 PM, Cody Permann <cod...@gm...> wrote:
> 
> John, just so you are up to speed Jason has reproduced this result on "rod", "cone" and "hpcbuild4" in addition to the original failure on "hpcbuild5", you just need to add that new flag so it's definitely popping up on multiple systems now.  Roy's theory is interesting but I'm surprised that we aren't seeing this error in other places in the library if that's the case.  It only shows up when you turn on periodic boundaries and might be related to the constraint function as it shows, but I just can't see it!

Ok... I think those are all GCC 4.6 installations?  I might try a 4.7.2 build on one of those Linux boxes and see if it has the same issue, depending on how fast the network connection from here is...


> 
> We're in the middle of a MOOSE workshop so it might be a few days before we can dig much deeper.
> 
> Cody
> 
> 
>> On Tue, Jul 8, 2014 at 11:37 AM, John Peterson <jwp...@gm...> wrote:
>> 
>> 
>> > On Jul 8, 2014, at 12:20 PM, Roy Stogner <roy...@ic...> wrote:
>> >
>> >
>> >> On Tue, 8 Jul 2014, John Peterson wrote:
>> >>
>> >> Wait, what?  --disable-cxx11 is the same behavior we've had since
>> >> forever, so it can't be causing a *new* valgrind error.
>> >
>> > No, sadly it's not what our behavior used to be, just what our
>> > behavior *should* have been.  I think I had a long-open issue about
>> > this - we'd been sticking -std=c++0x in our CXXFLAGS for g++ via
>> > compiler.m4
>> 
>> Oh yeah, I removed those manual flags in the patches adding automatic detection.  Good catch!
>> 
>> 
>> >
>> > Still *very* strange.  I wouldn't have been too shocked to see a
>> > compile-time error from turning off C++11 support, but I can't imagine
>> > what would have caused a runtime error.
>> >
>> > Googling... there are some libstdc++ ABI changes in STL containers.
>> > Are we inadvertently passing lists/pairs/sets/etc between C++98 and
>> > C++11 builds?
>> >
>> > Or... perhaps --disable-cxx11 is being strict enough to turn off
>> > unordered_foo, and we have some bug that only manifests in the case of
>> > an ordered set/map/multimap?
>> > ---
>> > Roy
>