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

Jonas Thies jonas at math.rug.nl
Mon Mar 3 14:05:31 MST 2008


Kevin & Ross,

Yes, I guess I broke one of the RCP commandments, though I didn't look 
at them yet.
I resolved the problem by going through the code and cleaning up the 
order in which the
list is constructed, it's hard to reconstruct what exactly went wrong, 
but I suspect that it is
something along these lines:

RCP<XMLObject> xml1 = rcp(new XMLObject("xml1");
RCP<XMLObject> xml2 = rcp(new XMLObject("xml2");

(add children to both objects)

xml1->addChild(*xml2);

The last call adds the xml2 object (not the RCP) to xml1,
and if I'm not mistaken this involves putting it in a std::vector 
'children' in
the underlying class (XMLObjectImplem or something)
Putting it in the STL vector means (according to that class' documentation)
calling the copy constructor and deleting the original object (!).
Since the copy constructor is not functional I guess this messes up the RCP.
 (but I'm not at all sure this is the problem)

anyway, valgrind is not complaining about XMLObjects now, so I'm happy
/Jonas

Kevin Long wrote:
> Hi Jonas,
>
> I'm curious about exactly what the problem was so we can avoid it in the 
> future. Did you do something like put a stack-based object into an RCP? I.e., 
>
> XMLObject x;
> RCP<XMLObject> p(&x);
>
> That would fail. Is that what happened? 
>
> Thanks,
>
> Kevin
>
> On Monday 03 March 2008 13:39, Jonas Thies wrote:
>   
>> 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
>> regards,
>> Jonas
>>
>> 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
>>>>         
>> _______________________________________________
>> 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