[C++] Executable loopt vast

[Propuls1on]

Beste mede-Tweakers,

Ik heb een probleem waar ik niet echt uitkom. Voor mijn scriptie heb ik een simulatie geprogrammeerd, en die werkt vooralsnog prima. Deze simulatie wordt meerdere keren aangeroepen met verschillende initiële waarden in een optimalisatie, waarvoor ik een toolbox gebruik (PaGMO, ontwikkeld door de ESA). Het probleem is dat na een bepaald aantal runs van de simulator, het programma vast loopt op een bepaald punt. Er is niets vreemds (denk ik) aan dit punt, want erna zou gewoon weer een simulatierun gedaan moeten worden. Ook wordt er geen foutmelding gegeven. Ik weet dat het probleem niet in de optimalisatietoolbox zit, omdat ik dezelfde toolbox voor een ander probleem heb gebruikt waar het vastlopen niet in voorkwam.

Naast het runnen van de optimalisatie op mijn eigen laptop (Ubuntu), heb ik ook de mogelijkheid om de executable te compileren en runnen op een server (OpenSUSE). Op de server komt er hetzelfde probleem voor. Echter loopt de simulatie niet op het zelfde moment (i.e., na hetzelfde aantal runs van de simulator) vast als op mijn laptop.

Nu is het lastig om mijn volledige code te geven omdat dit tientallen bestanden zijn met vele regels code, en ik begrijp dat het lastig is om te zeggen waar het probleem zit zonder dat ik enige vorm van code laat zien. Ik hoop echter dat iemand met wat meer C++ ervaring misschien een suggestie kan doen in welke richting het probleem zit, en eventueel welke tools ik zou kunnen gebruiken om de oorzaak van het probleem op te sporen.


Propuls1on

[Vaan Banaan]

Wat je nodig hebt is een profiler, daarmee zou je wel iets wijzer moeten worden.
Jouw probleem klinkt als een geheugen probleem. Iets alloceert geheugen, maar wordt nooit meer vrijgegeven.

[DexterDee]

Ik denk dat je dan toch in de hoek van tools als gperftools, valgrind en gprof moet zoeken.

[Skyaero]

Wat bedoel je met "vastlopen"? Krijg je een foutmelding? Stopt het programma met het genereren van output? Is de CPU idle?

Weet je zeker dat het niet aan een configuratie van een run ligt? Heb je de volgorde van de runs wel eens omgedraaid?

[Propuls1on]

Met vastlopen bedoel ik dat de CPU nog wel op 100% draait, maar er verder niets gebeurt (geen output, geen analyse van de volgende individu in de populatie, etc.). Als ik een andere random seed gebruik voor het optimalisatie algoritme, wat dus resulteert in een andere set van runs, loopt de executable nog steeds vast, alleen op een ander moment.

Ik heb net valgrind geprobeert te draaien (zit blijkbaar in QT creator), maar ik weet niet zo goed hoe ik de output ervan moet interpreteren; sommige functies komen bekend voor, maar anderen totaal niet. Is er iets vreemds te zien op de screenshot?

[ Voor 6% gewijzigd door Propuls1on op 14-09-2015 14:57 ]

[Sir_Hendro]

Je hangt denk ik ergens vast in een loop. Wellicht ook even kijken of er spraken is van memory leakage door het geheugen gebruik te monitoren.

Een optie is misschien op bepaalde punt een debug message te plaatsen en kijken wanneer je programma stopt met het geven van debug messages. Dan weet je waar in de code een probleem zit.

[ Voor 40% gewijzigd door Sir_Hendro op 14-09-2015 15:01 ]

[Propuls1on]

Sir_Hendro schreef op maandag 14 september 2015 @ 14:57:
Je hangt denk ik ergens vast in een loop. Wellicht ook even kijken of er spraken is van memory leakage door het geheugen gebruik te monitoren.

Een optie is misschien op bepaalde punt een debug message te plaatsen en kijken wanneer je programma stopt met het geven van debug messages. Dan weet je waar in de code een probleem zit.

Uiteraard heb ik dit al geprobeerd, alleen slaagde ik hiermee niet om de oorzaak van het probleem te vinden. Overigens wat misschien kan helpen om het probleem vast te stellen, ik ben in staat om de optimalisatie vanaf een bepaalde generatie te herstarten. Als ik de optimalisatie herstart, dan runt de executable voorbij het punt waar hij eerst vast liep, maar loopt op een later moment dan alsnog vast. Echter wil ik niet om de haverklap mijn optimalisatie herstarten omdat dit nogal tijdrovend zou zijn

[Skyaero]

Dit klinkt bij mij heel erg als een while-loop waarbij je tussen twee runs een variabele vergeet te resetten, waardoor je in de while loop vast komt te zitten.

[Sir_Hendro]

Het hoeft dan ook niet perse een debug bericht te zijn die steeds om een bevestiging vraagt. Een optie is om gewoon per stuk code een bepaalde variable 'executing_at' steeds een nieuwe string te plaatsen. Deze string zal dan mega snel steeds wijzigen maar wanneer je hangt kun je precies lezen welke string in deze variable staat. Dan weet je ook waar de code misloopt. Als je dan die code hier post kunnen we meehelpen zoeken.

[Janoz]

Waarom hang je er niet even een debugger aan op het moment dat hij vastgelopen lijkt te zijn. Dan kun je precies achterhalen waar hij mee bezig is.

[Propuls1on]

Wat ik probeerde was op verschillende plaatsen in de code de waarde van diverse variabelen te printen, zodat een NaN of een Inf opgespoord zou kunnen worden. Het vreemde was dat als ik een bepaald stuk code printte (een bepaalde matrix die ik gebruik), de run wel voorbij het punt ging waar de optimalisatie eerder vast liep.

Ik zou overigens graag mijn code posten zodat jullie mee kunnen helpen, maar ik gebruik een zeer uitgebreide astrodynamica toolbox en die optimalisatie toolbox van ESA, waardoor ik een gigantische hoeveelheid code zou moeten plaatsen.

P.S. Ik merk dat als ik een een multidimensionale interpolatie (gebruik om mijn aerodynamische databases te interpoleren) vervang door een simpele tweedegraads vergelijken (wat ik in eerste instantie gebruikte om de complexiteit te beperken), de optimalisatie niet stopt op dat punt en voorlopig door blijft runnen. Ik heb voorheen, met die tweedegraads vergelijkingen, optimalisaties gedaan van +500 generaties met zo'n 200 simulator runs per generatie zonder dat deze vast liep. Ik zou eventueel het stuk code van deze multidimensionale interpolatie (niet door mij zelf geschreven overigens), als de implementatie van deze interpolatie voor mijn probleem kunnen plaatsen mocht dit nodig zijn.

Edit: hierbij de code van de multilinear interpolator en mijn implementatie (rarefiedFlowCoefficients.h/cpp)
https://www.dropbox.com/s...tweakers_example.txt?dl=0

[ Voor 7% gewijzigd door Propuls1on op 14-09-2015 15:56 ]

[Sir_Hendro]

Aangezien je in een loop vasthangt en in de for loops niks raars staat waar hij op kan blijven hangen moeten we het zoeken in je while loops. Hij zal daar mogelijk het doel niet bereiken en dus eindeloos doorgaan. Dit is het stukje code waar het dan om zou moeten gaan:

code:

while (!databaseStream.eof() )
    {
        std::string line;
        std::getline( databaseStream, line );

        if ( line == "" )
        {
            break;
        }

        line = line.substr(0, line.size()-1);


        if ( !machSet )
        {
            int machStart = line.find( ":" );
            unsigned int nextSpace = 0;
            std::string subString = line.substr( machStart + 1 );

            while ( nextSpace < ( subString.size() - 1 ) )
            {
                subString = subString.substr( nextSpace + 1 );
                nextSpace = subString.find(" ");
                independentVariables[ 0 ].push_back( atof( ( subString.substr( 0, nextSpace ) ).c_str() ));
            }

            machSet = true;
        }
        else if ( !aoaSet )
        {
            int aoaStart = line.find( ":" );
            unsigned int nextSpace = 0;
            std::string subString = line.substr( aoaStart + 1);

            while ( nextSpace < (subString.size() - 1 ))
            {
                subString = subString.substr( nextSpace + 1);
                nextSpace = subString.find(" ");
                independentVariables[ 1 ].push_back( atof( ( subString.substr( 0, nextSpace ) ).c_str() ));
            }

            aoaSet = true;
        }
        else if (!aosSet )
        {
            int aosStart = line.find( ":" );
            unsigned int nextSpace = 0;
            std::string subString = line.substr( aosStart + 1);

            while ( nextSpace < (subString.size() - 1 ))
            {
                subString = subString.substr( nextSpace + 1);
                nextSpace = subString.find(" ");
                independentVariables[ 2 ].push_back( atof( ( subString.substr( 0, nextSpace ) ).c_str() ));
            }

            aosSet = true;

            coefficientsPtr = boost::make_shared< boost::multi_array<
                    boost::shared_ptr< Eigen::VectorXd >, 3 > > ( );

            coefficientsPtr->resize(
                        boost::extents[ independentVariables[0].size() ]
                        [ independentVariables[1].size() ]
                        [ independentVariables[2].size() ]);
        }
        else
        {
            ParsedDataVectorPtr parseResult = databaseParser.parse( line );

            ParsedDataLineMapPtr lineData = parseResult->at( 0 );

            boost::shared_ptr< Eigen::VectorXd > lineCoefficients =
                    boost::make_shared< Eigen::VectorXd >(3);

            (*lineCoefficients)(0) = atof( lineData->find( coefficientX )->second->getRaw( ).c_str() ) ;

            (*lineCoefficients)(1) = atof( lineData->find( coefficientY )->second->getRaw( ).c_str() ) ;

            (*lineCoefficients)(2) = atof( lineData->find( coefficientZ )->second->getRaw( ).c_str() ) ;


//            (*lineCoefficients)(3) = atof( lineData->find( coefficientMX )->second->getRaw( ).c_str() ) ;

//            (*lineCoefficients)(4) = atof( lineData->find( coefficientMY )->second->getRaw( ).c_str() ) ;

//            (*lineCoefficients)(5) = atof( lineData->find( coefficientMZ )->second->getRaw( ).c_str() ) ;


            (*coefficientsPtr)[machIt][aoaIt][aosIt] = lineCoefficients;

            aosIt++;
            if ( aosIt == independentVariables[2].size() )
            {
                aosIt = 0;
                aoaIt++;
            }

            if (aoaIt == independentVariables[1].size() )
            {
                aoaIt = 0;
                machIt++;
            }

        }
    }

Kun je databaseStream toelichten (regel 1)? Hoe wordt deze zeg maar aangemaakt? De volgende 3 while zijn gebaseerd op een string length. Mogelijk wordt hier gedurende de while loop het doel niet bereikt voor nextSpace / subString combinatie.

Verder zie ik zover iets waar het verder aan kan liggen.

[ Voor 4% gewijzigd door Sir_Hendro op 14-09-2015 16:29 ]

[leuk_he]

Waarschijnlijk zo voor de hand liggend dat ik ik mis.

Je attached een debugger aan het lopende proces, "breakt"hem, en inspecteerd variablen , of stept door de loop en kijkt waar hij iets anders doet dan jij verwacht.

[Propuls1on]

Sir_Hendro schreef op maandag 14 september 2015 @ 16:10:
Aangezien je in een loop vasthangt en in de for loops niks raars staat waar hij op kan blijven hangen moeten we het zoeken in je while loops. Hij zal daar mogelijk het doel niet bereiken en dus eindeloos doorgaan. Dit is het stukje code waar het dan om zou moeten gaan:

[..]

Kun je databaseStream toelichten (regel 1)? Hoe wordt deze zeg maar aangemaakt? De volgende 3 while zijn gebaseerd op een string length. Mogelijk wordt hier gedurende de while loop het doel niet bereikt voor nextSpace / subString combinatie.

Verder zie ik zover iets waar het verder aan kan liggen.

databaseStream is een ifstream uit de standard library om een bestand in te lezen dat de database bevat. Dit wordt echt slechts één keer gedaan aan het begin van de optimalisatie, en dit gaat volgens mij zoals het moet.

leuk_he schreef op maandag 14 september 2015 @ 16:24:
Waarschijnlijk zo voor de hand liggend dat ik ik mis.

Je attached een debugger aan het lopende proces, "breakt"hem, en inspecteerd variablen , of stept door de loop en kijkt waar hij iets anders doet dan jij verwacht.

Ik ga dit morgen proberen. De debugger in Qt Creator is mij nog niet helemaal duidelijk, maar dat wordt dan maar even inlezen (tenzij iemand een suggestie heeft voor een goede debugger voor Linux).

[Matis]

gdb is de debuggger voor Linux.

Er zijn zelfs mogelijkheden om op een remote-server te debuggen middels gdbserver, die installeer je op de CentOS-distributie.
Je kunt desgewenst Qt Creator de gdbserver laten opzetten en automatisch connecten.

De enige voorwaarde is dat je een cross-compiler en bijbehorende debugger nodig hebt om je CentOS te kunnen debuggen.

Op die manier werk ik al geruime tijd. Ik gebruik Qt creator als IDE, cross-compile te code voor een ARM-processor, deploy te executable naar het target en debug dan remote. Werkt heel erg prettig en Qt Creator zit boordevol handigheden om remote-debugging een aangename aangelegenheid te maken.

De functies / bestanden die voor jou onbekend overkomen, zijn systeem libraries welke Linux gebruikt om jouw applicatie te bouwen / uit te voeren.

Ik verwacht niet dat het memory-leaks zijn, die sigsegven normaliter je applicatie waardoor deze crasht. Ik verwacht eerder dat er een race-conditie zit in je code, waardoor je niet meer uit een loop komt.

Mocht je toch graag op zoek willen gaan naar memory-leaks, dan ben je het meest geïnteresseerd in Valgrinds definitely lost: aantal.

Maar de uitkomst kan soms erg verneukeratief zijn, want sommige systeem libraries lijken memory te leaken, maar doen dat feitelijk niet. Soms vergist Valgrind zich daar wel eens in.

Als laatste wil ik je nog de volgende raad meegeven; op verschillende Linux-distributies kunnen sommige functies anders reageren dan je verwacht.

[ Voor 39% gewijzigd door Matis op 14-09-2015 18:40 ]

[Propuls1on]

Matis schreef op maandag 14 september 2015 @ 18:29:
..

Bedankt voor de tips! Ik ben niet nieuw in het programmeren, maar wel enigszins nieuw in C++. Omdat ik van medestudenten altijd wilde verhalen hoorde over verkeerde pointers en memory leaks, was ik bang dat dit ook het geval zou zijn, vooral omdat ik op de "handmatige" manier van debuggen niets kon vinden. Ik ga morgen verder met het speuren naar de bug, en mocht ik de oorzaak vinden dat laat ik dit uiteraard weten .

Update: Ik heb valgrind gebruikt om m'n programma te controleren op memory leaks, en het blijkt dus dat deze er inderdaad in zaten. Met behulp van de logs die valgrind produceerde heb ik de problemen kunnen verhelpen, en vooralsnog lijkt de optimalisatie niet te stoppen. Hopelijk blijft dit ook zo

In ieder geval, iedereen die heeft meegedacht, heel erg bedankt!

[ Voor 84% gewijzigd door Propuls1on op 15-09-2015 14:05 ]

[koli-man]

Propuls1on schreef op maandag 14 september 2015 @ 19:04:
[...]


Bedankt voor de tips! Ik ben niet nieuw in het programmeren, maar wel enigszins nieuw in C++. Omdat ik van medestudenten altijd wilde verhalen hoorde over verkeerde pointers en memory leaks, was ik bang dat dit ook het geval zou zijn, v......

Misschien een tip voor jou en je mede studenten. Voor C++ development hoef je alles behalve bang voor te zijn.

Mocht jij of jouw mede studenten nog eens iets met C++ gaan doen, als je vanaf moment 1 je system under test (SUT), of dat nou een stuk code in een unit test is, of de complete applicatie met valgrind runt, en de resultaten bekijkt en monitored is er niets om bang te zijn.

Zeker met de huidige C++11/14 features, waarbij built-in std::unique en std::shared_ptr gebruikt kunnen worden als je geen zin hebt om zelf geheugen te managen is het imo een prachtige taal om iets te ontwikkelen.

[Propuls1on]

Ik vind C++ ook best een prettige taal om in te werken, alleen is het als je als je er nog niet heel ervaren in bent soms onduidelijk waardoor iets niet werkt (zoals bijvoorbeeld een memory leak). Overigens gebruiken we hier Boost (shared_ptr, make_shared), wat volgens mij vergelijkbaar is met std::shared_ptr.

[igmar]

Wat meestal helpt :

1) Start een nieuwe shell, en doe ulimit -c unlimited
2) Start het programma vanaf een dir waarin je schrijfrechten hebt
3) Wacht totdat het programma in een loop zit, en doe een kill -11 <pid>. Hierdoor zou het programma een coredump moeten geven.
4) Start gdb : gdb /path/naar/binary corefile
5) Vanuit gdb geeft een bt

Dat zou je redelijk moeten vertellen waar de loop zit.

[Propuls1on]

igmar schreef op donderdag 17 september 2015 @ 10:40:
Wat meestal helpt :

1) Start een nieuwe shell, en doe ulimit -c unlimited
2) Start het programma vanaf een dir waarin je schrijfrechten hebt
3) Wacht totdat het programma in een loop zit, en doe een kill -11 <pid>. Hierdoor zou het programma een coredump moeten geven.
4) Start gdb : gdb /path/naar/binary corefile
5) Vanuit gdb geeft een bt

Dat zou je redelijk moeten vertellen waar de loop zit.

Ik had zonder jouw suggestie ook al gevonden waar in de loop de executable vast liep. Echter, als ik bepaalde output erbij printte ging hij soms wel verder (om vervolgens op een later moment alsnog vast te lopen), en ik kon geen oorzaak ontdekken waarom de loop stopte. Zoals ik zei in een eerdere post was de oorzaak dus een memory leak die ik met valgrind heb opgespoord en opgelost. Desalniettemin, bedankt voor je suggestie!

[MSalters]

Ik snap dat een heleboel mensen memory leak roepen. Dat is niet ongebruikelijk in antieke C++ code.

In numerieke code is er echter veel vaker sprake van een ander probleem, en dat is een algoritme wat geen voortgang meer maakt. Simpel gezegd, denk aan het volgende loopje

C++:

double stepsize = bestStep(Input);
for (double x = 0.0; x < 1.0; x += stepsize)
{
   // ....
}

Mocht om welke reden dan ook de stepsize ooit 0.0 zijn, dan hangt je code even goed.

[Propuls1on]

Ik maak inderdaad gebruik van een variable stepsize integrator, waar de minimale stepsize 1e-7 is. Mocht de variatie zo groot zijn dat de integrator het nodig acht te vinden om op die stepsize te integreren, dan lijkt het inderdaad dat het algoritme hangt. Echter heb ik dit gecontroleerd voordat ik de post hier plaatste, en dit was niet het geval.