[Trilinos-Users] Problems with Teuchos::XMLObject memory management?

Jonas Thies jonas at math.rug.nl
Mon Mar 3 12:39:13 MST 2008

Hi Kevin, Ross,

thanks for your replies, I guess it was my fault.
I stored some RCP's to XMLObjects within the tree so I could add more 
kids to them, and then
when the time comes for the whole tree to depart, there is trouble.
I now use standard pointers instead and it works

Kevin Long wrote:
> Hi Jonas,
> I'm not sure what could be causing the problem. If you still can't find the 
> problem after a clean rebuild and valgrind/purify, perhaps you could send me 
> a stripped-down example showing the problem and I could have a go at 
> debugging it. I'm the guy who originally wrote the class, and so would be 
> happy to try to fix it. It's been years since I wrote it so it's hardly fresh 
> in my mind, but I can probably figure out how it works :-).
> As Ross said, this class is used heavily without incident so I'd be surprised 
> if there's a problem; however, it may be you're using some not-often-used 
> feature in which a bug has lurked silently for years.  
> Let me know how it goes, and drop a line if you need me to help with the 
> debugging. 
> Kevin
> On Monday 03 March 2008 07:19, Bartlett, Roscoe A wrote:
>> Hello Jonas,
>> The class XMLObject is a handle class that does shallow copies of the
>> XMLObjectImplen data by default.  That is why where is no specifically
>> defined copy constructor or assignment operator, or destructor; the
>> compiler-generated versions should do exactly the right thing since only a
>> single Teuchos::RCP is being stored as private data.  When you use a
>> shallow-copy handle class you have to be very careful about sharing issues
>> and call deepCopy() when that is what you want.  I did not write this class
>> and there is just one simple unit test for it (see
>> teuchos/test/XML/cxx_main.cpp) but this class has seen very heavy use in
>> the last few years and we have need seen issues like what you describe.
>> Have you run valgrind or purify on your program?  The final segfault that
>> you are seeing might be a result of other code that is corrupting the data
>> of the XMLObject[Implem] objects.  The first that you should always do when
>> you get a segfault is to delete all of the *.o, *.a, and *.exe files and
>> rebuild everything from scratch.  That fixes about 50% of the segfaults
>> that I have seen in the past.
>> I hope some of these ideas help,
>> Ross
>> -----Original Message-----
>> From: trilinos-users-bounces at software.sandia.gov
>> [mailto:trilinos-users-bounces at software.sandia.gov] On Behalf Of Jonas
>> Thies Sent: Monday, March 03, 2008 2:14 AM
>> Cc: trilinos-users at software.sandia.gov
>> Subject: [Trilinos-Users] Problems with Teuchos::XMLObject memory
>> management?
>> Hi all,
>> I'm trying to put together a fairly complicated XML structure to be used as
>> the 'light-weight' part of an Xdmf output format. All goes well until the
>> end of the run, when the XMLObject is being deleted, whereupon I get a
>> coredump. It seems that there is an issue with the internal std::vector
>> destructor. When I put everything in one main program it works, I suspect
>> it has to do with the way new XMLObjects are copied into the vector. I
>> noticed that there is a method 'deepCopy', but no copy constructor, which
>> might explain the behaviour (std::vector push_back calls the copy
>> constructor). Am I doing something wrong? I'm surprised it works for the
>> XMLParameterListWriter class. Is there an example somewhere? By the way,
>> I'm working with Trilinos version 8.0.1
>> thanks for your help,
>> Jonas
>> _______________________________________________
>> Trilinos-Users mailing list
>> Trilinos-Users at software.sandia.gov
>> http://software.sandia.gov/mailman/listinfo/trilinos-users

More information about the Trilinos-Users mailing list