On Wed, Nov 30, 2016 at 3:50 PM, Harshad Sahasrabudhe
wrote:
> Hi all,
>
> The libmesh reference counter shows that there are fewer destructions that
> creations. Is there any easy way to find out which objects in my code are
> not destroyed?
>
You leaked ~140,000 Elems, I'd start by searching y
On Thu, Dec 1, 2016 at 6:50 AM, Harshad Sahasrabudhe
wrote:
> Hi all,
>
> The libmesh reference counter shows that there are fewer destructions that
> creations. Is there any easy way to find out which objects in my code are
> not destroyed?
>
> Thanks,
> Harshad
>
The reference count info shou
Hi all,
The libmesh reference counter shows that there are fewer destructions that
creations. Is there any easy way to find out which objects in my code are
not destroyed?
Thanks,
Harshad
| Reference count information
On Mon, Feb 8, 2016 at 8:55 AM, Harshad Sahasrabudhe
wrote:
> Hi John and Cody,
>
> Thanks for your responses. I ran the code with valgrind --leak-check=full
> --track-origins=yes, and then again with --keep-cout --redirect-stdout.
> Valgrind doesn't give me any leaks other than the MPI related.
Hi John and Cody,
Thanks for your responses. I ran the code with valgrind --leak-check=full
--track-origins=yes, and then again with --keep-cout --redirect-stdout.
Valgrind doesn't give me any leaks other than the MPI related. --keep-cout
--redirect-stdout prints reference counting for every proce
On Fri, Jan 15, 2016 at 9:45 AM, Harshad Sahasrabudhe
wrote:
> Hi,
>
> I'm trying to debug a memory leak message I get from LibMesh at the end of
> simulation. I get the following reference counter output from process 64 of
> 64:
>
>
>
> ---
Run you code through valgrind with "--leak-check=full --track-origins=yes".
Depending on your MPI implementation you'll probably see several warnings
about problems in the MPI stack. Just ignore those and find the pieces of
the report that point to your own application code.
On Fri, Jan 15, 2016 a
Hi,
I'm trying to debug a memory leak message I get from LibMesh at the end of
simulation. I get the following reference counter output from process 64 of
64:
| Reference count information
|
--
Thanks, I think that it is actually just MPI matter since I never use new
operator with non auto_ptr types...
Since the results are compatible with the ones obtained in other programs
that do not present memory leak I will let
the deep analysis to the end of my project. Thanks for the answers
On W
No, the memory leak won't damage the computer. Part of the issue in this
thread is that we're mixing two terminologies. Your Valgrind report
reported several memory issues but as John already pointed out, that's
normal for all known MPI stacks. You have a real memory leak in addition to
the MPI me
Forget the part about the results, I've figured out an error and now the
results are actually the same but with this memory leak persisting...
Anyone knows how much the memory leak could cause problems? It don't cause
permanent damage to the computer, right?
Thanks
On Tue, Oct 21, 2014 at 5:18 P
Let me rephrase my question: is there any constraint/limitations in
implementing classes that have members that handles MPI?
It seems that all my problem comes from the fact that I call the
"LibMeshInit init (argc, argv);" in the main while my mesh object is
actually inside an object declared in t
On Tue, Oct 21, 2014 at 9:01 AM, Rodrigo Broggi wrote:
> The leak seems to be related to parallelization, I've run the program with
> Valgrind and all "complains" derive from parallel statements both MPI and
> openmp. Is there any advice on how to handle classes that contains implicit
> MPI statem
The leak seems to be related to parallelization, I've run the program with
Valgrind and all "complains" derive from parallel statements both MPI and
openmp. Is there any advice on how to handle classes that contains implicit
MPI statements without causing problems...
Here goes the heavy complain f
You mean just invert :
EquationSystems equation_systems;
Mesh mesh;
with:
Mesh mesh;
EquationSystems equation_systems;
?
Cause the order of initialization is actually first mesh than
equation_system in the constructore... Anyway I tried but
Mesh should be declared first in your class, to match the order of
initialization... Other than that I don't see how there can be a memory leak,
because you don't allocate any memory...
> On Oct 18, 2014, at 3:15 AM, Rodrigo Broggi wrote:
>
> Hi guys,
>
> I'm trying to write a class that has
Hi guys,
I'm trying to write a class that has a Mesh and an EquationSystem members
between its internal members. For some reason just initializing these
members is sufficient to give me a big memory leak. I am sure that the
problem is there since commenting these members it works just fine.
here
Our latest ReferenceCountedObject class queried the command line via
GetPot to check if we should print out refcount info, and that query
wasn't cached.
The latest GetPot by default stuck every single query at the end of a
GetPot::_requested_* vector, as a simple but grossly
inefficient way of en
18 matches
Mail list logo
