GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung
Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Out of memory problem in EmcPoint - FairLink ?
icon8.gif  Out of memory problem in EmcPoint - FairLink ? [message #10897] Wed, 04 August 2010 00:15 Go to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *117-80-r.retail.telecomitalia.it
Dear all,
trying to run many DPM events we have realized that sometimes the simulation (run_sim_tpccombi_dpm.C) crashes, sometime with a "bad alloc" problem, sometime with a #include error, and without any helpful messages.

In order to check what is really going wrong, I have run the vsame macro under valgrind and finally, after waiting 15 hours, I have found the guilty guy, or at least one of them.

First of all, these are the dpm settings:

<I> PndDpmDirect initialization
<I> Momentum  = 15
<I> Seed      = 4357
<I> Mode      = 1
<I> Theta min = 0.001


At the beginning I have many valgrind messages, unitialized values in writing the parameter containers, maybe some expert (Mohammad) should take a look there:

Toggle Spoiler


However, this is not the problem. The problem appears at the 58th event:

Toggle Spoiler


The problem appears in PndEmcPoint.cxx at line +57:

SetLink(FairLink("MCTrack", trackID));


It is not so clear to me if this is a problem coming from the stuff inside fairlink, maybe set or allocator. Or maybe there is some "wrong" information from EmcPoint which is making FairLink crazy. The valgrind message 
new/new[] failed and should throw an exception
appears when a "new" is trying to allocate memory but memory is full... there is something eating up the memory.
If the same macro is run without valgring, it proceeds without crashing at the event, but the memory is slowly eaten and sooner or later the macro crashes definitely.

I would leave the work to experts, because I was not able to find what is the memory problem we have.

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10903 is a reply to message #10897] Thu, 05 August 2010 16:42 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *117-80-r.retail.telecomitalia.it
Trying to understand what is making our memory explode, under suggestion of Ralf I have run only one event by valgrind.

This is the final log message, with all the "problems":

Toggle Spoiler


Here you are the errors we have found, and the fix commited in the code:

PndTof.cxx line 200:
TList* nodeList = node->getTree();

This information is not used, I have commented out this part.

PndStack::UpdateTrackIndex(TRefArray*) (PndStack.cxx:332)
TIterator* detIter = detList->MakeIterator();
???

FairParRootFileIo::open(char const*, char const*, char const*, int) (FairParRootFileIo.cxx:103)
-> fstream *f = new fstream(fname);
???

PndDrc::Initialize() (PndDrc.cxx:146)
->PndDrcOptDevManager* manager = new PndDrcOptDevManager();

Added in PndDrcOptDevmanager contructor: fgInstance = this;

PndEmcStructure::crystal_name_analysis(TString, int&, int&, int&, int&) (PndEmcStructure.cxx:230)
-> TObjArray *subStrL = TPRegexp("^cave/Emc\\d+_(\\d+)/EmcLayer\\d_0/emc(\\d+)r(\\d+)c(\\d+)_0$ ").MatchS(node_path);

Is it possible to avoid to use TPRegexp? It seems very error prone, in particular for TObjArray.

FairModule::ExpandNode(TGeoNode*) (FairModule.cxx:293)
-> M->SetDefaultName();

This SetDefaultname is giving us a lot of troubles:

95,408 bytes in 16,006 blocks are definitely lost in loss record 373 of 401

in particular for the MVD geometry. Probably we should set each matrix name by hands, instead of using this default option.

---

These are just few of the messages in the log. Just doing the modifications in Dirc and Tof the simulation does not crash anymore at that event.. however also the other points should be checked and somehow fixed.

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10904 is a reply to message #10903] Fri, 06 August 2010 09:47 Go to previous messageGo to next message
Mohammad Al-Turany is currently offline  Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
first-grade participant
 From: *gsi.de
Hi Stefano,


Quote:

PndStack::UpdateTrackIndex(TRefArray*) (PndStack.cxx:332)
TIterator* detIter = detList->MakeIterator();



solved, delete detIter is added to the code.



Quote:

FairParRootFileIo::open(char const*, char const*, char const*, int) (FairParRootFileIo.cxx:103)
-> fstream *f = new fstream(fname);


solved, delete f is added at the right place.

Quote:

FairModule::ExpandNode(TGeoNode*) (FairModule.cxx:293)
-> M->SetDefaultName();



Here I am not sure! the method (M->SetDefaultName()) is doing much more than setting a name, it check the type of transformation, prepend a letter corresponding to the type and finally append the index of the transformation to the current GeoManager. and in any case we are speaking about 100 kB per session. So I do not believe that this is a big problem, I agree it has to be solved but we still have much worse problems.


regards

Mohammad

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10905 is a reply to message #10897] Fri, 06 August 2010 09:57 Go to previous messageGo to next message
Ralf Kliemt is currently offline  Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt
first-grade participant
From: *pool.mediaWays.net
Mohammad wrote

Quote:


FairModule::ExpandNode(TGeoNode*) (FairModule.cxx:293)
-> M->SetDefaultName();


Here I am not sure! the method (M->SetDefaultName()) is doing much more than setting a name, it check the type of transformation, prepend a letter corresponding to the type and finally append the index of the transformation to the current GeoManager. and in any case we are speaking about 100 kB per session. So I do not believe that this is a big problem, I agree it has to be solved but we still have much worse problems.



Hi,

I think we just could copy this function and change the way of setting the name. This would look like that:
void FairModule::SetDefaultMatrixName(TGeoMatrix* matrix)
{
  // Copied from root TGeoMatrix::SetDefaultName() and modified (memory leak)
  // If no name was supplied in the ctor, the type of transformation is checked.
  // A letter will be prepended to the name :
  //   t - translation
  //   r - rotation
  //   s - scale
  //   c - combi (translation + rotation)
  //   g - general (tr+rot+scale)
  // The index of the transformation in gGeoManager list of transformations will
  // be appended.
  if (!gGeoManager) return;
  if (strlen(matrix->GetName())) return;
  char type = 'n';
  if (matrix->IsTranslation()) type = 't'; 
  if (matrix->IsRotation()) type = 'r';
  if (matrix->IsScale()) type = 's';
  if (matrix->IsCombi()) type = 'c';
  if (matrix->IsGeneral()) type = 'g';
  TObjArray *matrices = gGeoManager->GetListOfMatrices();
  Int_t index = 0;
  if (matrices) index =matrices->GetEntriesFast() - 1;
  matrix->SetName(Form("%c%i", type, index));
}


Kind regards, Ralf.

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10906 is a reply to message #10897] Fri, 06 August 2010 12:23 Go to previous messageGo to next message
Mohammad Al-Turany is currently offline  Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
first-grade participant
 From: *gsi.de
Hi Ralf,

Ok, it is in SVN now!

Mohammad

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10907 is a reply to message #10906] Fri, 06 August 2010 13:02 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *117-80-r.retail.telecomitalia.it
Thanks Mohammad,
I have updated svn and run valrind one a single event.
Now, what is left is, in the initialization:

Toggle Spoiler


At the end:

Toggle Spoiler


In the init, I think they should not be so "heavy", even if maybe it would be better to fix them.

In the exec, after Mohammad changes I can see that PndEmcStructure is a quite huge guy, but I have no idea on how to fix it.
The other messages seem to come from root, apart FairMCApplication.cxx line 767, another iterator.

Now I try to run 10k DPM events, hoping that nothing will crash...
Any clue for the PndEmcStructure point?

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10911 is a reply to message #10897] Fri, 06 August 2010 14:57 Go to previous messageGo to next message
Dima Melnychuk is currently offline  Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
first-grade participant
 From: *fuw.edu.pl
Hi Stefano,

I tried to do something with PndEmcStructure, by adding at the end of PndEmcStructure::crystal_name_analysis()

delete subStrL;

where
TObjArray *subStrL = TPRegexp("^cave/Fsc_(\\d+)/emc(\\d+)r(\\d+)c(\\d+)_0$").MatchS(node_path);

But it somehow only increased memory consumption and calculation time. So I suspect this code should be rewriten somehow without regular expressions. But it will take some time and I can try to do it in two weeks after my vacations.

Best regards,
Dima

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10974 is a reply to message #10897] Mon, 13 September 2010 15:25 Go to previous messageGo to next message
Dima Melnychuk is currently offline  Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
first-grade participant
 From: *fuw.edu.pl
Hi all,

Since Stefano reported memory leaks caused by regular expressions - TPRegexp in PndEmcStructure, I have replaced it by sscanf (rev. 9846).

However I didn't manage to check how it affected memory leaks by myselfe.

Running

valgrind --tool=cachegrind root -b run_sim_tpccombi_dpm.C

I do not have such an informative output as reported by Stefano but just
 DIGI EXECUTION *********************
RealTime=247.386149 seconds, CpuTime=233.050000 seconds
(int)56
root [1] .q
==5031==
==5031== I   refs:      2,517,267
==5031== I1  misses:        2,578
==5031== L2i misses:        1,392
==5031== I1  miss rate:      0.10%
==5031== L2i miss rate:      0.05%
==5031==
==5031== D   refs:      1,291,254  (927,120 rd   + 364,134 wr)
==5031== D1  misses:       40,211  ( 37,743 rd   +   2,468 wr)
==5031== L2d misses:        6,443  (  5,450 rd   +     993 wr)
==5031== D1  miss rate:       3.1% (    4.0%     +     0.6%  )
==5031== L2d miss rate:       0.4% (    0.5%     +     0.2%  )
==5031==
==5031== L2 refs:          42,789  ( 40,321 rd   +   2,468 wr)
==5031== L2 misses:         7,835  (  6,842 rd   +     993 wr)
==5031== L2 miss rate:        0.2% (    0.1%     +     0.2%  )



I suspected that it was due to external packages compiled without debug info, but I recomplied it with debug info and it didn't help. Maybe I don't run valgrind with proper flag?

Dima

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10976 is a reply to message #10974] Mon, 13 September 2010 15:57 Go to previous messageGo to next message
Florian Uhlig is currently offline  Florian Uhlig
Messages: 424
Registered: May 2007
first-grade participant
 From: *gsi.de
Hi Dima

You have to do

valgrind root.exe run_sim_tpccombi_dpm.C

Yohave to call valgrind with root.exe which is an executable whereas root is only a wrapper script. So you tested only for
memory problems in the wrapper script.

Ciao

Florian

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10977 is a reply to message #10897] Mon, 13 September 2010 16:11 Go to previous messageGo to next message
Ralf Kliemt is currently offline  Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt
first-grade participant
From: *pool.mediaWays.net
Hi Dima.

I suggest to try the option --lek-check=full since you're hunting memory leaks.

Greetings, Ralf.

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #10980 is a reply to message #10977] Tue, 14 September 2010 12:48 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *to.infn.it
I am using the following:

valgrind --leak-check=full --suppressions=/home/spataro/jan10/tools/root/etc/valgrind-root.supp root.exe


In some versions you should use "suppression" instead of "suppressions", to disable the printout of all the well known root leakages.

Report message to a moderator

icon4.gif  Out of memory problem in EmcPoint - FairLink ! [message #10981 is a reply to message #10897] Tue, 14 September 2010 13:05 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *to.infn.it
Finally I have found who is making the analysis crash.
I would like to repeat, the problem occurs trying to run many dpm events, i.e. 10000.
You can find two kinds of crashes:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc


or

Error: Symbol #include is not defined in current scope  run_sim_tpccombi_dpm.C:141:
Error: Symbol exception is not defined in current scope  run_sim_tpccombi_dpm.C:141:
Syntax Error: #include <exception> run_sim_tpccombi_dpm.C:141:
Error: Symbol G__exception is not defined in current scope  run_sim_tpccombi_dpm.C:141:
Error: type G__exception not defined FILE:/d/panda02/spataro/pandaroot/macro/pid/64/2/./run_sim_tpccombi_dpm.C LINE:141
*** Interpreter error recovered ***
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc


After a lot of tests, disabling and enabling detectors, putting cout and using valgrind, I have find that the main reason of these leaks is explained by valgrind by the following message:

==18644== 10,028,992 bytes in 156,703 blocks are definitely lost in loss record 358 of 361
==18644==    at 0x4A20929: operator new(unsigned long) (vg_replace_malloc.c:230)
==18644==    by 0x12800BAB: __gnu_cxx::new_allocator<std::_Rb_tree_node<FairLink> >::allocate(unsigned long, void const*) (new_allocator.h:92)
==18644==    by 0x12800BCF: std::_Rb_tree<FairLink, FairLink, std::_Identity<FairLink>, std::less<FairLink>, std::allocator<FairLink> >::_M_get_node() (stl_
tree.h:357)
==18644==    by 0x12800C35: std::_Rb_tree<FairLink, FairLink, std::_Identity<FairLink>, std::less<FairLink>, std::allocator<FairLink> >::_M_create_node(Fair
Link const&) (stl_tree.h:366)
==18644==    by 0x12800D4E: std::_Rb_tree<FairLink, FairLink, std::_Identity<FairLink>, std::less<FairLink>, std::allocator<FairLink> >::_M_insert_(std::_Rb
_tree_node_base const*, std::_Rb_tree_node_base const*, FairLink const&) (stl_tree.h:852)
==18644==    by 0x12800EB3: std::_Rb_tree<FairLink, FairLink, std::_Identity<FairLink>, std::less<FairLink>, std::allocator<FairLink> >::_M_insert_unique(Fa
irLink const&) (stl_tree.h:1148)
==18644==    by 0x12800FDC: std::set<FairLink, std::less<FairLink>, std::allocator<FairLink> >::insert(FairLink const&) (stl_set.h:381)
==18644==    by 0x12801F34: FairMultiLinkedData::InsertLink(FairLink) (FairMultiLinkedData.cxx:137)
==18644==    by 0x128044D9: FairMultiLinkedData::AddLink(FairLink, bool, float) (FairMultiLinkedData.cxx:123)
==18644==    by 0x1280347A: FairMultiLinkedData::SetLink(FairLink, bool, float) (FairMultiLinkedData.cxx:58)
==18644==    by 0x1529D9B1: PndEmcPoint::SetTrackID(int) (PndEmcPoint.h:65)
==18644==    by 0x141BF945: PndStack::UpdateTrackIndex(TRefArray*) (PndStack.cxx:357)
==18644==


I have commented out the three calls to "SetLink" in emc classes, and after I am able to run 10k dpm events without any problems, instead of the old crashes starting from event #200.

For the moment, before the fix of all the problems with the STL code inside FairLink, I will commit these changes in EMC code, just commenting the FairLink lines. At least, the problem seems to appear only for EMC, maybe because the larger size of the data with respect to other detectors.

Of course, if we want to use links for EMC, we need that somebody tries to understand what is wrong with the Links.

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ! [message #10984 is a reply to message #10981] Tue, 14 September 2010 15:50 Go to previous messageGo to next message
Florian Uhlig is currently offline  Florian Uhlig
Messages: 424
Registered: May 2007
first-grade participant
 From: *gsi.de
Hi Stefano

I also fear that there is a problem with the FairLinks or the way of usage.
Whenruning one of the Cbm Macros on the GSI batch farm i end up with a segmentation violation always after around 350 Events. After the third crash i monitored the memory consumption and this was always increasing. When the memory consumption reached the limit of 4GB on the batch farm machines and terminates.

Checking the process with valgrind for some events I found exactly the same problem as you did. The number of lost bytes was increasing with increasing number of events. 


==20123== 7,844,864 bytes in 122,576 blocks are still reachable in loss record 511 of 514
==20123==    at 0x4A1C929: operator new(unsigned long) (vg_replace_malloc.c:230)
==20123==    by 0xE9F04F3: std::_Rb_tree<FairLink, FairLink, std::_Identity<FairLink>, std::less<FairLink>, std::allocator<FairLink> >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, FairLink const&) (new_allocator.h:88)
==20123==    by 0xE9F0638: std::_Rb_tree<FairLink, FairLink, std::_Identity<FairLink>, std::less<FairLink>, std::allocator<FairLink> >::insert_unique(FairLink const&) (stl_tree.h:931)
==20123==    by 0xE9F0D5A: FairMultiLinkedData::InsertLink(FairLink) (stl_set.h:321)
==20123==    by 0xE9F2BA6: FairMultiLinkedData::AddLink(FairLink, bool, float) (FairMultiLinkedData.cxx:123)
==20123==    by 0xEDB17EE: CbmStsDigi::CbmStsDigi(int, int, int, int, int, int, int) (CbmStsDigi.h:63)
==20123==    by 0xF8E92CD: CbmStsIdealDigitize::Exec(char const*) (CbmStsIdealDigitize.cxx:186)
==20123==    by 0x4D83402: TTask::ExecuteTasks(char const*) (TTask.cxx:312)
==20123==    by 0x4D83691: TTask::ExecuteTask(char const*) (TTask.cxx:275)
==20123==    by 0xEA06EAA: FairRunAna::Run(int, int) (FairRunAna.cxx:279)
==20123==    by 0xEA1CC1C: G__FairDict_792_0_5(G__value*, char const*, G__param*, int) (FairDict.cxx:11420)
==20123==    by 0x559C3D0: Cint::G__ExceptionWrapper(int (*)(G__value*, char const*, G__param*, int), G__value*, char*, G__param*, int) (Api.cxx:385)
==20123== 
==20123==


Unfortunately i was not able to find out what exactely is the problem. Maybe Tobias has an idea.

Ciao

Florian

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ! [message #10986 is a reply to message #10984] Tue, 14 September 2010 17:02 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
 From: *ikp.kfa-juelich.de
Hi all,

I try to figure out where the problem is. Unfortunately I do not see a potential problem in the code. I do not use pointers and I do not use any "new" in the code.

Maybe it is a problem with std::set I use as container to store the data. I will check if I can replace it with either std::vector or a root class.

Cheers,

Tobias

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ! [message #10987 is a reply to message #10986] Tue, 14 September 2010 17:34 Go to previous messageGo to next message
Florian Uhlig is currently offline  Florian Uhlig
Messages: 424
Registered: May 2007
first-grade participant
 From: *gsi.de
Hi Tobias

Quote:


I try to figure out where the problem is. Unfortunately I do not see a potential problem in the code. I do not use pointers and I do not use any "new" in the code.



This was exactely my problem when I looked in the code. I don't see any potential problem.

Quote:


Maybe it is a problem with std::set I use as container to store the data. I will check if I can replace it with either std::vector or a root class.



Why did you choose to use a set instead of a vector? What are the advantages of using a set?

Ciao

Florian

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ! [message #10989 is a reply to message #10987] Wed, 15 September 2010 08:58 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
 From: *ikp.kfa-juelich.de
Hi Florian,

a set is like a map where only the key is present. This means that you do not have twice the same entry and the data is sorted. This speeds up the find method quite a lot which is important for large link collections like in the TPC and EMC.

Ciao,

Tobias

Report message to a moderator

icon7.gif  Re: Out of memory problem in EmcPoint - FairLink ? [message #11042 is a reply to message #10897] Thu, 30 September 2010 12:45 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
 From: *ikp.kfa-juelich.de
Dear pandaRooters,

it seems that I have found the solution for the memory leak of FairMultiLinkedData.

The problem is coming from the TClonesArray. Whenever you call ->Clear() for a TClonesArray which contains FairMultiLinkedData you have to substitute it with ->Delete(). After this the memory leak is not visible anymore in Valgrind and Totalview.

Please test it and tell me your results.

Cheers,

Tobias

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #11043 is a reply to message #11042] Thu, 30 September 2010 14:24 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *13-87-r.retail.telecomitalia.it
Ehm,
please give me one week (quite busy at the moment, fighting against another crash) Smile

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #11161 is a reply to message #10897] Wed, 03 November 2010 13:45 Go to previous messageGo to next message
Dima Melnychuk is currently offline  Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
first-grade participant
 From: *fuw.edu.pl
Hi all,

Following the discussion started by Tobias today on EVO meeting concerning memory allocation by TClonesArray I want to propose an idea to use TClonesArray::Compress() (which remove empty slots) if TClonesArray::Capacity() (i.e. number of allocated slots) is above certain threshold, and this threshold can be subsystem and data level dependent. The threshold can be needed not to loose the performance by frequent TClonesArray compression.

I.e. for example it could look like in PndEmcMakeCluster::Exec()
fClusterArray->Delete();
if (fClusterArray->Capacity()>100)
fClusterArray->Compress();


However in case of EMC FairLinks created most problems at the simulation stage and here I do not know precisely where to compress TClonesArray.

In PndEmc there is a method Reset() and I can guess it clear the memory at each event, but I am not 100% sure.

void PndEmc::Reset() {
   fEmcCollection->Clear();
   fPosIndex = 0;
}


So it could be modified like
void PndEmc::Reset() {
   fEmcCollection->Clear();
   if (fEmcCollection->Capacity()>100)
   fEmcCollection->Compress();
   fPosIndex = 0;
}

Here I put for check of capacity 100 as an arbitrary number which should be optimized.

I have complication to check it by myself since search for memory leaks requires rather powerful computer and mine is not.

May be this will not help to solve the problem with FairLink but it can be checked.

Dima

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #11162 is a reply to message #11161] Wed, 03 November 2010 14:17 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
 From: *ikp.kfa-juelich.de
Dear Dima,

I think this is a good idea. I will try to test it.

You can only see the problem if you look at the memory consumption of pandaRoot during runtime. The problems are no memory leaks.

Cheers,

Tobias

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #11285 is a reply to message #10897] Wed, 08 December 2010 14:03 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
 From: *ikp.kfa-juelich.de
Dear pandaRooters,

I have activated the FairLinks in the code again and replaced all the TClonesArray::Clear() with TClonesArray::Delete().

Please test if you encounter any problems or losses in performance.

Cheers,

Tobias

Report message to a moderator

Re: Out of memory problem in EmcPoint - FairLink ? [message #11359 is a reply to message #11285] Mon, 20 December 2010 17:15 Go to previous message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant
From: *to.infn.it
Hi,
it seems the fix solves the problem for EMC.
Unfortunately it does not solve all the other crashes connected to TPC digitization and so on.

Report message to a moderator

Previous Topic: Compilation problem of trunk
Next Topic: Error during PndTpcElectronicsTask
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Nov 22 13:30:18 CET 2024

Total time taken to generate the page: 0.00659 seconds
.:: Contact :: Home :: Legal Notice :: Data Protection Policy ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software