On Thu, Jul 17, 2014 at 10:54 AM, Derek Gaston wrote:
> I vote for suppression as well.
Cool, do you mind merging my MOOSE PR #3546 that does this?
--
John
--
Want fast and easy access to all the code in your enterpris
I vote for suppression as well.
On Wed, Jul 16, 2014 at 3:52 PM, John Peterson wrote:
> On Wed, Jul 16, 2014 at 3:02 PM, John Peterson
> wrote:
> > On Wed, Jul 16, 2014 at 2:58 PM, John Peterson
> wrote:
> >> On Wed, Jul 16, 2014 at 2:31 PM, John Peterson
> wrote:
> >>> On Wed, Jul 16, 2014
On Wed, Jul 16, 2014 at 3:02 PM, John Peterson wrote:
> On Wed, Jul 16, 2014 at 2:58 PM, John Peterson wrote:
>> On Wed, Jul 16, 2014 at 2:31 PM, John Peterson wrote:
>>> On Wed, Jul 16, 2014 at 1:39 PM, John Peterson wrote:
On Wed, Jul 16, 2014 at 1:33 PM, Kirk, Benjamin (JSC-EG311)
On Wed, Jul 16, 2014 at 2:58 PM, John Peterson wrote:
> On Wed, Jul 16, 2014 at 2:31 PM, John Peterson wrote:
>> On Wed, Jul 16, 2014 at 1:39 PM, John Peterson wrote:
>>> On Wed, Jul 16, 2014 at 1:33 PM, Kirk, Benjamin (JSC-EG311)
>>> wrote:
should be fixed in valgrind 3.9.0. What ve
On Wed, Jul 16, 2014 at 2:31 PM, John Peterson wrote:
> On Wed, Jul 16, 2014 at 1:39 PM, John Peterson wrote:
>> On Wed, Jul 16, 2014 at 1:33 PM, Kirk, Benjamin (JSC-EG311)
>> wrote:
>>>
>>> should be fixed in valgrind 3.9.0. What version are you running?
>>
>> 3.7.0, I could try and see if the
On Wed, Jul 16, 2014 at 1:39 PM, John Peterson wrote:
> On Wed, Jul 16, 2014 at 1:33 PM, Kirk, Benjamin (JSC-EG311)
> wrote:
>>
>> should be fixed in valgrind 3.9.0. What version are you running?
>
> 3.7.0, I could try and see if there is a newer binary available for
> the system I'm on.
FYI, b
On Wed, Jul 16, 2014 at 1:33 PM, Kirk, Benjamin (JSC-EG311)
wrote:
> On Jul 16, 2014, at 2:25 PM, John Peterson wrote:
>
>> The next thing I'll try is re-enabling tbb, but removing the
>> scalable_allocator template parameters from dof_map.h and
>> sparsity_pattern.h, and making sure we're still
On Jul 16, 2014, at 2:25 PM, John Peterson wrote:
> The next thing I'll try is re-enabling tbb, but removing the
> scalable_allocator template parameters from dof_map.h and
> sparsity_pattern.h, and making sure we're still valgrind-clean.
> Assuming this works, what is the correct long-term fix?
On Tue, Jul 8, 2014 at 6:32 PM, Derek Gaston wrote:
> Have you tried disabling TBB? That might show something interesting.
So, I can confirm that configuring libmesh with --disable-tbb
--disable-cxx11 gets rid of the valgrind error.
Since all the valgrind errors seem to have this "scalable_free
Have you tried disabling TBB? That might show something interesting.
Could it be that TBB is compiled with C++11 support... so passing an object
from it down into a C++98 compiled STL might not work out?
I don't remember how we get TBB... Jason: did _we_ compile TBB ourselves?
Derek
On Tue, J
On Tue, Jul 8, 2014 at 12:45 PM, John Peterson wrote:
> On Tue, Jul 8, 2014 at 11:52 AM, John Peterson wrote:
>>
>>
>> On Jul 8, 2014, at 12:47 PM, Cody Permann wrote:
>>
>> John, just so you are up to speed Jason has reproduced this result on "rod",
>> "cone" and "hpcbuild4" in addition to the
On Tue, Jul 8, 2014 at 11:52 AM, John Peterson wrote:
>
>
> On Jul 8, 2014, at 12:47 PM, Cody Permann 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 ne
> On Jul 8, 2014, at 12:47 PM, Cody Permann 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
> sy
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 ar
> On Jul 8, 2014, at 12:20 PM, Roy Stogner 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
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 abou
On Tue, Jul 8, 2014 at 10:20 AM, Cody Permann wrote:
> UPDATE: With our testing we have determined that the culprit is
> --disable-cxx11
>
> If you take a clean Linux box, configure libMesh with that option and run
> adaptivity example 5 with Valgrind you will see an error similar to the
> first
> On Jul 8, 2014, at 11:21 AM, "Cody Permann" wrote:
>
> ilar to the first message in this thread. I suppose that it really could be
> a compiler bug since I still can't see what is wrong with that method.
Thanks for the update. I wonder if that's the case and of so maybe it could be
replica
UPDATE: With our testing we have determined that the culprit is
--disable-cxx11
If you take a clean Linux box, configure libMesh with that option and run
adaptivity example 5 with Valgrind you will see an error similar to the
first message in this thread. I suppose that it really could be a comp
UPDATE: I cleaned up my configure, the error still exists on at least two
of our build boxes in opt, oprof and dbg modes. (that's a good sign -
repeatable). Jason, is going to rebuild one of the build boxes itself with
a clean software stack and try once more, we are still not able to make it
fail
20 matches
Mail list logo
