On Wed, Feb 3, 2010 at 3:32 PM, Derek Gaston wrote:
> On Feb 3, 2010, at 2:29 PM, John Peterson wrote:
>
>> class MyClass
>> #ifdef LIBMESH_ENABLE_REFERENCE_COUNTING
>> : public ReferenceCountedObject
>> #endif
>> {
>> };...
>
> Since we have a two class hierarchy of ReferenceCountedObject and
>
On Wed, Feb 3, 2010 at 2:26 PM, Derek Gaston wrote:
> Yo.
>
> So... I'm trying to turn off reference counting with
> --disable-reference-counting... but I'm still getting "Memory Leak Detected!"
> errors at the end of my run.
>
> Besides the obvious "Fix the memory leak!"... is there something e
On Feb 3, 2010, at 2:29 PM, John Peterson wrote:
> class MyClass
> #ifdef LIBMESH_ENABLE_REFERENCE_COUNTING
> : public ReferenceCountedObject
> #endif
> {
> };...
Since we have a two class hierarchy of ReferenceCountedObject and
ReferenceCounter... we could just do this to ReferenceCountedObject
On Wed, Feb 3, 2010 at 2:51 PM, Roy Stogner wrote:
>
> On Wed, 3 Feb 2010, Derek Gaston wrote:
>
>> On Feb 3, 2010, at 1:39 PM, Roy Stogner wrote:
>>
>>> Surprised me too, actually. I think it would be better to turn off
>>> counting entirely when asked via configure (especially since it
>>> requ
Never mind... I see it. It's the _n_objects++ in the constructor of
ReferenceCounter. This happens despite using --disable-reference-counting...
So now my question is... should it? Should we turn off doing that ++ and -- in
Reference counter if you specifically disable reference counting? Or
On Wed, 3 Feb 2010, Derek Gaston wrote:
> On Feb 3, 2010, at 1:39 PM, Roy Stogner wrote:
>
>> Surprised me too, actually. I think it would be better to turn off
>> counting entirely when asked via configure (especially since it
>> requires an atomic unsigned int when threading is on), do the "on
On Feb 3, 2010, at 2:07 PM, Kirk, Benjamin (JSC-EG311) wrote:
> My thought was that the global ++/-- reference count was a cheap, good thing
> to check for leaks at the grossest level. Not sure how many threads you are
> on, or the actual overhead of the atomic operation...
We're running upwards
On Wed, Feb 3, 2010 at 3:07 PM, Kirk, Benjamin (JSC-EG311)
wrote:
>> Surprised me too, actually. I think it would be better to turn off
>> counting entirely when asked via configure (especially since it
>> requires an atomic unsigned int when threading is on), do the "one
>> total count" stuff in
> Surprised me too, actually. I think it would be better to turn off
> counting entirely when asked via configure (especially since it
> requires an atomic unsigned int when threading is on), do the "one
> total count" stuff in opt mode with counting on, then do the detailed
> stuff in dbg/devel m
On Feb 3, 2010, at 1:36 PM, John Peterson wrote:
> Looks like even if LIBMESH_ENABLE_REFERENCE_COUNTING is not defined,
> it still keeps a rough count of all reference-counted objects
> created...
Yep - just saw that myself.
> Check out the constructors in reference_counter.h. The easiest 'fix'
On Wed, 3 Feb 2010, Derek Gaston wrote:
> So... I'm trying to turn off reference counting with
> --disable-reference-counting... but I'm still getting "Memory Leak
> Detected!" errors at the end of my run.
>
> Besides the obvious "Fix the memory leak!"... is there something
> else I need to do to
On Feb 3, 2010, at 1:39 PM, Roy Stogner wrote:
> Surprised me too, actually. I think it would be better to turn off
> counting entirely when asked via configure (especially since it
> requires an atomic unsigned int when threading is on), do the "one
> total count" stuff in opt mode with counting
Yo.
So... I'm trying to turn off reference counting with
--disable-reference-counting... but I'm still getting "Memory Leak Detected!"
errors at the end of my run.
Besides the obvious "Fix the memory leak!"... is there something else I need to
do to make this message go away? I really don't u
13 matches
Mail list logo
