[OpenWalnut-Dev] mystisches Speicherproblem

[Patrick Oesterling]

Hi guys,

thanks for your answers. As Christian/Scott Meyers already explained I 
also considered the swap-idiom to be the only "real" way to reduce 
capacity ( and also the destructor-call during the re-assignment). I 
just added clear/resize to apply the whole reduce/free arsenal for 
demonstration purposes. I also read somewhere that calling 
vector.reserve( 0 ) (or a value smaller than the actual capactity) does 
nothing at all (most notably not reducing the capacity).

Still, I wonder why the whole thing works in the helloWorld programm and 
why memory is reserved more than once after several allocation calls and 
assignmentd to the very same variable.

Btw: the problem seems not to occur for "std::vector< double >" for some 
reason. If this has to do with reserved capacity of "inner vectors" I 
still wonder why it works in the helloWorld programm.


@christian: std::cout << m_matrix.capacity(); indeed notifies zero.

Thanks anyways, I guess for now I will use a one-dimensional "matrix" 
plus additional index-complexity.


On 06/22/2012 04:40 PM, Alexander Wiebel wrote:
> Dear Patrick,
> unfortunately I do not have a solution at this time. However, I had
> similar problems with my glyph module and the isosurface module in the
> past (#425 in the old issue track in the trac system).
>
>> #425	Memory leak in isosurface and Teem Glyphs
>>
>> Description	
>> It is believed that the memory leak does not come from inside the
>> modules but more from the WGEGroupNode or somewher else.
>> At least for Teem Glyphs this is very sure. ebaum also had the idea
> that it might com from Qt.
>
> I just checked the isosurface and I (still) can find the memory growing
> when adding and removing the module and playing with the "isovalue"
> slider in between.
>
> Cheers,
> Alex
>
> On 06/22/2012 04:03 PM, Patrick Oesterling wrote:
>> Hallo OW-Developer,
>>
>> da es meine erste Nachricht ist, zunächst ein großes Lob an alle
>> Verantwortlichen, die OW in seinen heutigen Zustand gebracht haben. Es
>> macht mir gewissermaßen "Spaß", meine bisherige Arbeit damit zu
>> implementieren.
>>
>> Ich bin leider auf ein ziemlich merkwürdiges Speicherproblem im OW
>> gestoßen, welches dazu führt, dass der RAM überläuft (auf allen Rechnern
>> die ich getestet habe). Da ich mit Sebastian bereits vergeblich eine
>> ganze Menge Zeit investiert habe, hoffe ich nun, dass evtl von euch
>> jemand eine Ahnung/Idee hat, was genau hier (theoretisch) "schief" läuft.
>>
>>
>> Auf folgende Weise kann das Szenario schnell und einfach reproduziert
>> werden:
>>
>>
>> [ 1) OW auschecken ]
>>
>> 2) als private member im Template-Modul in der WMTemplate.h folgendes
>> deklarieren
>>
>> std::vector<  std::vector<  double>  >  m_matrix;
>>
>> 3) in der moduleMain() in der WMTemplate.cpp beim m_aTrigger event (ca.
>> line: 629) folgendes einfügen
>>
>> int size = 0;
>> std::cin>>  size;
>>
>> // free old matrix ( just to be sure )
>> m_matrix.clear();
>> m_matrix.resize( 0 );
>> std::vector<  std::vector<  double>  >().swap( m_matrix );
>> m_matrix = std::vector<  std::vector<  double>  >();
>>
>> // allocate new (triangle) matrix
>> for( int i = 0; i<  size; ++i )
>>      m_matrix.push_back( std::vector<  double>( i + 1, 0.0 ) );
>>
>> 4) OW starten - trigger auslösen - 30000 eingeben
>>
>> 5) mit "top" (linux command) oder "gnome-system-monitor" beobachten, wie
>> der RAM um ca. 4 GB steigt
>>
>> jetzt zum Problem:
>>
>> 6) trigger erneut auslösen - 30 (oder irgendwas<<  30000) eingeben und
>> beobachten, wie der Speicher der member variablen -NICHT- komplett
>> wieder freigegeben wird.
>>
>> Scheinbar willkürlich wird von den 4GB mal mehr oder weniger (laut
>> "top") wieder freigegeben, oder leider auch mal gar nichts. Richtig
>> unangenehm wird die Geschichte, weil nach mehrmaligen Auslösen des
>> Triggers sogar ein Vielfaches des Speichers belegt wird (bis der RAM
>> halt voll ist) ( ->  einfach zweimal mit halber RAM-Größe auslösen, um es
>> zu beschleunigen).
>>
>> Dass "top" etwas falsches anzeigt, scheidet meiner Meinung nach aus,
>> weil a.) letztendlich tatsächlich geswapt wird (obwohl es nur eine
>> Instanz geben sollte) und weil b.) folgender "helloWorld" Ansatz
>> einwandfrei funktioniert (laut "top"):
>>
>> ---------------------------
>>
>> #include<iostream>
>> #include<vector>
>>
>> int main()
>> {
>>    std::vector<  std::vector<  double>  >  matrix;
>>
>>    int size = 0;
>>    while( true)
>>    {
>>      std::cin>>  size;
>>
>>      if( size == 0)
>>          break;
>>
>>      // free matrix
>>      std::vector<  std::vector<  double>  >().swap( matrix );
>>
>>      // allocate matrix
>>      for( int i = 0; i<  size; ++i )
>>          matrix.push_back( std::vector<  double>( i+1, 0.0 ) );
>>    }
>> }
>>
>> ---------------------------
>>
>> Falls einer von euch eine Ahnung hat, was im OW (threading, libraries,
>> etc) dafür verantwortlich sein könnte, oder ob hier prinzipielle Dinge
>> verantwortlich sind, wäre ich sehr dankbar. Angeblich existiert auch nur
>> immer eine Instanz eines Moduls (hier: des Template Moduls).
>>
>>
>> Folgendes habe ich außerdem probiert:
>>
>> 1.) alle Einzelfälle bei "free memory" (siehe oben)
>> 2.) boost::shared_ptr<  std::vector<  std::vector<  double>  >  >  m_matrix
>> 3.) helloWorld Ansatz mit Klassen-member und boost::threads ( "top"
>> zeigt weiterhin korrekt an)
>> 4.) helloWorld Ansatz mit Klassen-member und Funktionalität in extra
>> library ( "top" zeigt weiterhin korrekt an)
>>
>>
>> Vielen Dank schonmal.
>> Patrick
>> _______________________________________________
>> OpenWalnut-Dev mailing list
>> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
>> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
>>
>> Archive: http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
> _______________________________________________
> OpenWalnut-Dev mailing list
> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
>
> Archive: http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
>