[OpenWalnut-Dev] mystisches Speicherproblem

Mon Jul 2 14:57:49 CEST 2012

It turns out there are multiple malloc debuggers available, not only valgrind:
http://www.linuxjournal.com/article/6556 maybe one of them can tell you more.

On 02.07.2012 14:37, Patrick Oesterling wrote:
> 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/
>>
> 
> _______________________________________________
> 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/

-- 
Institut für Informatik
Universität Leipzig
Johannisgasse 26, 04103 Leipzig
Phone: +493419732283