Re: [ROOT] Objects containing STL map of vectors?

From: Aaron Chou (achou@fnal.gov)
Date: Thu Jan 16 2003 - 01:08:48 MET


Hi Philippe,

Wow, thanks for your quick reply!

If I change in my STLClass.h file the vector<int,__malloc_alloc_template<0> > 
to just vector<int> in order to use the default STL allocator, then the 
rootcint generated STLClassdict.cc file fails to compile with a complaint 
that the allocators are mismatched.  For example:

In file included from STLClassdict.cc:111:
/usr/include/g++-3/stl_pair.h: In method `pair<_T1, _T2>::pair (const
pair<_U1, _U2> &) [with _U1 = int, _U2 = vector<int,
__malloc_alloc_template<0> >, _T1 = const int, _T2 = VecInt]':
/usr/include/g++-3/stl_map.h:162:   instantiated from here
/usr/include/g++-3/stl_pair.h:48: no matching function for call to
`vector<int, allocator<int> >::vector (const vector<int,
__malloc_alloc_template<0> > &)'

Apparently the dictionary generator likes to use the 
__malloc_alloc_template<0> allocator, at least in my build of ROOT.   Is this 
the problem that you just fixed?  I had assumed that you guys were using the 
slower __malloc_alloc_template allocator for thread-safety.

Thanks,

Aaron


On Wednesday 15 January 2003 05:38 pm, Philippe Canal wrote:
> > (I have to use the malloc_alloc allocator here in order to get the Cint
> > dictionary to compile.  Is there some way to force the dictionary
>
> generator
>
> > to use the standard STL allocator by default?  Or to force gcc 2.96 to
> > use malloc_alloc by default?)
>
> Yes.  Just use __tomorrow__'s CVS repository.  (as it happens I just fixed
> this problem a few minutes ago).
>
> > Are STL containers of containers not yet supported in ROOT or am I doing
> > something wrong?
>
> Using __malloc_alloc_template instead of the default allocator, just serves
> to confuse the STL library and/or the ROOT stl streamers.
>
> Cheers,
> Philippe
>
> -----Original Message-----
> From: owner-roottalk@pcroot.cern.ch
> [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Aaron Chou
> Sent: Wednesday, January 15, 2003 4:42 PM
> To: roottalk@pcroot.cern.ch
> Subject: [ROOT] Objects containing STL map of vectors?
>
>
> Hi,
>
> (Using Root 3.04.02 on RedHat Linux 7.3 with gcc 2.96).
>
> I'm having trouble filling a tree in which one of the branches is an
> user-defined object containing a STL map like this:
>
> STLClass.h:
>
> #include <vector>
> #include <map>
> #include "TObject.h"
>
> typedef vector<int,__malloc_alloc_template<0> > VecInt;
>
> class STLClass : public TObject
> {
> private:
>   map<int, VecInt > A;
>
> public:
>   STLClass();
>   ~STLClass() ;
>   void AddInt(int a,int b);
>
>   friend ostream& operator<<(ostream&, const STLClass&);
>   ClassDef(STLClass,1)
> };
>
>
> (I have to use the malloc_alloc allocator here in order to get the Cint
> dictionary to compile.  Is there some way to force the dictionary generator
> to use the standard STL allocator by default?  Or to force gcc 2.96 to use
> malloc_alloc by default?)
>
> I use a Makefile to build the STLClass.so library and then use AClic to
> compile and run a program called WriteSTL.cc to test it.
>
> WriteSTL.cc:
> #include <iostream>
> #include "STLClass.h"
> #include "TROOT.h"
> #include "TClassTable.h"
> #include "TFile.h"
> #include "TTree.h"
> void WriteSTL() {
>   TFile tf("STLTest.root","recreate");
>   TTree MyTree("STLTest","STL Test");
>
>   STLClass *MyClass = new STLClass();
>   MyTree.Branch("STL_branch","STLClass",&MyClass);
>   for (int j=0;j<5;++j) {
>     for (int i=0;i<10;++i) {
>       MyClass->AddInt(i,i*j);
>     }
>     cout << "filling" << endl;
>     MyTree.Fill();
>     cout << "filled" << endl;
>   }
>   cout << "writing" << endl;
>   tf.Write();
>   tf.Close();
> }
>
>
> Here is my ROOT command line input, and the segmentation fault that
> results:
>
> root [0] .L STLClass.so
> root [1] .x WriteSTL.cc++
> Info in <TUnixSystem::ACLiC>: creating shared library
> /home/users/achou/programs/rootstuff/roottalk/./WriteSTL_cc.so
> filling
>
>  *** Break *** segmentation violation
>  Generating stack trace...
>  0x401bc0af in TUnixSystem::StackTrace(void) + 0x25b from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x401bad2e in TUnixSystem::DispatchSignals(ESignals) + 0xb2 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x401b9ed7 in <unknown> from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x401bd971 in <unknown> from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x40ccd307 in <unknown> from /lib/libpthread.so.0
>  0x40d65ef8 in <unknown> from /lib/libc.so.6
>  0x40184c81 in TClass::Streamer(void *, TBuffer &) + 0x21 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x4010ad00 in TBuffer::StreamObject(void *, TClass *) + 0x24 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x4149433d in R__STLClass_A__FR7TBufferPvi + 0x3b5 from
> /home/users/achou/programs/rootstuff/roottalk/./STLClass.so
>  0x401a60e9 in TStreamerInfo::WriteBuffer(TBuffer &, char *, int) + 0x1bc5
> from /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x40b5c54b in TBranchElement::FillLeaves(TBuffer &) + 0x34b from
> /home/users/programs/root3_04_02/root/lib/libTree.so
>  0x40b56b40 in TBranch::Fill(void) + 0x214 from
> /home/users/programs/root3_04_02/root/lib/libTree.so
>  0x40b5c18b in TBranchElement::Fill(void) + 0x117 from
> /home/users/programs/root3_04_02/root/lib/libTree.so
>  0x40b5c16d in TBranchElement::Fill(void) + 0xf9 from
> /home/users/programs/root3_04_02/root/lib/libTree.so
>  0x40b72794 in TTree::Fill(void) + 0x80 from
> /home/users/programs/root3_04_02/root/lib/libTree.so
>  0x40cbd828 in WriteSTL(void) + 0x108 from
> /home/users/achou/programs/rootstuff/roottalk/./WriteSTL_cc.so
>  0x40cbda57 in <unknown> from
> /home/users/achou/programs/rootstuff/roottalk/./WriteSTL_cc.so
>  0x405c35ab in G__call_cppfunc + 0x237 from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x405b2e3d in G__interpret_func + 0x895 from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x405995ec in G__getfunction + 0x1bb4 from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x40590f71 in G__getitem + 0x509 from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x4058f6ff in G__getexpr + 0x8c3f from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x405867a2 in G__calc_internal + 0x38e from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x405e718f in G__process_cmd + 0x23eb from
> /home/users/programs/root3_04_02/root/lib/libCint.so
>  0x4017a33a in TCint::ProcessLine(char const *, TInterpreter::EErrorCode *)
> +
> 0x9a from /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x4017a428 in TCint::ProcessLineSynch(char const *,
> TInterpreter::EErrorCode
> *) + 0x48 from /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x40102166 in TApplication::ProcessFile(char const *, int *) + 0x6e2 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x401018d0 in TApplication::ProcessLine(char const *, bool, int *) + 0x4ec
> from /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x40c9921b in TRint::HandleTermInput(void) + 0x127 from
> /home/users/programs/root3_04_02/root/lib/libRint.so
>  0x40c98540 in TTermInputHandler::Notify(void) + 0x28 from
> /home/users/programs/root3_04_02/root/lib/libRint.so
>  0x40c9987b in TTermInputHandler::ReadNotify(void) + 0x13 from
> /home/users/programs/root3_04_02/root/lib/libRint.so
>  0x401bb123 in TUnixSystem::CheckDescriptors(void) + 0x113 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x401ba836 in TUnixSystem::DispatchOneEvent(bool) + 0x112 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x4014cf8d in TSystem::InnerLoop(void) + 0x1d from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x4014cf22 in TSystem::Run(void) + 0x7e from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x401024dd in TApplication::Run(bool) + 0x31 from
> /home/users/programs/root3_04_02/root/lib/libCore.so
>  0x40c98d56 in TRint::Run(bool) + 0x2ba from
> /home/users/programs/root3_04_02/root/lib/libRint.so
>  0x08048792 in main + 0x52 from
> /home/users/programs/root3_04_02/root/bin/root.exe
>  0x40d551c4 in __libc_start_main + 0x90 from /lib/libc.so.6
>  0x08048661 in __register_frame_info + 0x35 from
> /home/users/programs/root3_04_02/root/bin/root.exe
>
> As you can see, the segmentation violation occurs when I try to fill the
> tree.
> The same code works if I replace the map with:
>
> map<int, VectorWrapper>
>
> where VectorWrapper is just a wrapper class which stores the
> vector<int,__malloc_alloc_template<0> > and does nothing else.
>
> Are STL containers of containers not yet supported in ROOT or am I doing
> something wrong?  I've included all code in an attached .tgz file.
>
> Many thanks,
>
> Aaron



This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:08 MET