[OpenWalnut-Dev] mystisches Speicherproblem

Mon Jul 2 14:37:13 CEST 2012

Hey guys,

following Christian's hint regarding possible Qt-issues, I made some 
progress:

Changing the helloWorld program to use simple QMainWindow/QPushButton to 
free/allocate the matrix causes almost the same memory problems. 
However, just defining "QApplication app(argc, argv);" without calling 
"app.exec();" does not seem to be enough.

Christian assumes that Qt globally overrides new/delete operators for 
optimization purposes, but seemingly causes memory fragmentation at the 
same time.

If this is true at all, the question remains how we could handle this?! 
It sounds ridiculous to prohibit usage of certain data types -> the 
problem seems not to appear with "vector< T >" ( although Alex also has 
memory problems but does not use "vector< vector< T > >")

Can we rule out that OW prototyping mechanisms do influence/amplify 
these effects? At least in the helloWorld program the effects aren't 
that tragic: From 4GB 3GB are freed and several allocations do not seem 
to stack memory usage.

Maybe these new information can stimulate/remind one or two.

Patrick

On 06/22/2012 05:39 PM, Patrick Oesterling wrote:
> 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/
>>
>
> _______________________________________________
> 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/
>