Keskustelu: Ohjelmointikysymykset: C++: SDL vuotaa muistia?

Valgrim antaa:

==7793== 18,536 (44 direct, 18,492 indirect) bytes in 1 blocks are definitely lost in loss record 60 of 74
==7793== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==7793== by 0x407907D: (within /usr/lib/libGL.so.1.2)
==7793== by 0x4057BA7: (within /usr/lib/libGL.so.1.2)
==7793== by 0x4057E3A: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2)
==7793== by 0x405814A: glXMakeCurrent (in /usr/lib/libGL.so.1.2)
==7793== by 0x40DF711: (within /usr/lib/libSDL-1.2.so.0.11.1)
==7793== by 0x40DF800: (within /usr/lib/libSDL-1.2.so.0.11.1)
==7793== by 0x40E5FCF: (within /usr/lib/libSDL-1.2.so.0.11.1)
==7793== by 0x40D28FF: SDL_SetVideoMode (in /usr/lib/libSDL-1.2.so.0.11.1)
==7793== by 0x804BA81: client::init() (clientBasic.cpp:65)
==7793== by 0x8054905: main (mainclient.cpp:10)

mainClient.cpp:10 kutsii client::init() funktiota. clientBasic.cpp:65 puolestaan on:

surface = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, videoFlags);

Miksei tuon varaamaa muistia vapauteta? Kun ohjelma suljetaan tuhoan luokan joka sisältää *surface osoittimen ja tuhoajassa löytyy tuolle oma SDL_FreeSurface(surface) kutsu. Myös SDL_Quit() kutsutaan ennen lopettamista.

Olenko unohtanut jonkin vaiheen vai missä vika? Tuo samainen rivi triggeröi pari muutakin muistivuoto varoitusta. Ei sinänsä iso ongelma kun näyttöä varten luon vain yhden surfacen joten muistinloppumisesta tuon takia tuskin on vaaraa mutta ärsyttävät moiset. Plus hankaloittaa omien muistivuotojen bongaamista kun tulos on rivikaupalla tälläisiä.

Samaten ftgl kirjaston suhteen tulee vuotoilmoituksia. Esmes:

==7852== 19,668 bytes in 37 blocks are still reachable in loss record 77 of 80
==7852== at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==7852== by 0x46DEE3C: (within /usr/lib/libfreetype.so.6.3.18)
==7852== by 0x46E303A: ft_mem_qalloc (in /usr/lib/libfreetype.so.6.3.18)
==7852== by 0x46E4D32: ft_mem_alloc (in /usr/lib/libfreetype.so.6.3.18)
==7852== by 0x46E50C2: FT_New_Library (in /usr/lib/libfreetype.so.6.3.18)
==7852== by 0x46DF1F8: FT_Init_FreeType (in /usr/lib/libfreetype.so.6.3.18)
==7852== by 0x41B9565: FTLibrary::Initialise() (FTLibrary.cpp:73)
==7852== by 0x41B95B9: FTLibrary::FTLibrary() (FTLibrary.cpp:62)
==7852== by 0x41B96E1: FTLibrary::Instance() (FTLibrary.cpp:33)
==7852== by 0x41B8B0E: FTFace::FTFace(char const*, bool) (FTFace.cpp:44)
==7852== by 0x41C14E7: FTFontImpl::FTFontImpl(FTFont*, char const*) (FTFont.cpp:220)
==7852== by 0x41C65EF: FTPixmapFontImpl::FTPixmapFontImpl(FTFont*, char const*) (FTPixmapFont.cpp:67)

Kiva kun ei edes tiedä missä vaiheessa koodiani tuo tulee tosin ei onneksi ole monessa kohtaa joten jäljittäminen ei ole mahdotonta(niinpitkälle kuin oma koodi on kyseessä) mutta onko näille mitään tehtävissä(jos ei oteta huomioon kirjaston koodin korjailua itse)? Ts. onko nämä oireita virheistä itse kirjastossa vai virhe niiden käytössä?

Jos OGL on käytössä, niin näyttöpintaan ei noin edes voi osoitinta luoda kun grafiikkapuolen asiat siirtyy täysin OGL:n vastuulle - eli riittää että vain kutsut funktiota SDL_SetVideoMode, sen palauttamaa arvoa ei tarvita.

Muistivuodot melko varmasti tulevat siitä että diagnoosikalu ei pysty seuraamaan muistin vapautusta kun se hoidetaan jossakin ihan toisaalla eri aikaan ja eri paikassa.

SDL_SetVideoModen palauttamaa pintaa ei kuulu erikseen vapauttaa, vaan SDL_Quit huolehtii tästä. Lisäksi näet (näethän?) viesteistä, että itse malloc-kutsu tapahtui libGL:n puolella (glXMakeContextCurrent), joten se ei mitenkään liity SDL:ään. Lisäksi tuo tapahtuu luultavasti vain kerran eikä siksi ole ongelma ohjelman kannalta.

Jälkimmäinen huomautus taas ei usein ole ongelma laisinkaan (ks. FAQ).

Nyt on tärkeää selvittää, kasvaako muistivuoto ohjelman ollessa päällä (ajan myötä) vai pysyykö vuoto suunnilleen vakiona.

Moni kirjasto saattaa vuotaa noin vakion verran muistia (hyvin pieni määrä), kuten esimerkiksi ClanLib. 'Vakio'muistivuotojen olemassaolo on siis riippuvainen kirjaston laadusta.

Muistivuotoja on kahdenlaisia: ajasta riippuva ja ajasta riippumaton vuoto. Näistä ensimmäinen, ajasta riippuva vuoto on vakava vuoto, joka on korjattava.

Jtm kirjoitti:

Nyt on tärkeää selvittää, kasvaako muistivuoto ohjelman ollessa päällä (ajan myötä) vai pysyykö vuoto suunnilleen vakiona.

Noh tällä hetkellä ei tule tarpeeksi käyttöä noille että voisi testata tarkemmin(myös valgrindin järjetön HITAUS openGL sovellusta ajaen hankaloittaa. Yritä siinä sitten testata ku julmetun tehokas kone uudella näytönohjaimellakin alkaa tökkiä valgrindilla suorittaessa...). Kuha ny keksisin miten toteuttaa hahmot että voisi tehdä muutakin kuin ihastella maisemaa voisi tuota testata.

Toinen ongelma on että noita ilmoituksia tulee niinpaljon ettei kaikki jää edes konsoliin muistiin...Alkupään ilmoituksia en siis edes pääse näkemään.

tneva82 kirjoitti:

Toinen ongelma on että noita ilmoituksia tulee niinpaljon ettei kaikki jää edes konsoliin muistiin...Alkupään ilmoituksia en siis edes pääse näkemään.

Voit ohjata ne tiedostoon (komento > tiedosto), poimia vain alun tulosteet (komento | head -n rivimaara) tms. Voit myös ohjata ne omatekoiselle ohjelmalle, joka osaa poimia oikeat ilmoitukset, tai käyttää grep-komentoa ja vaikkapa säännöllisiä lausekkeita vastaavaan tarkoitukseen.

Metabolix kirjoitti:

tneva82 kirjoitti:

Toinen ongelma on että noita ilmoituksia tulee niinpaljon ettei kaikki jää edes konsoliin muistiin...Alkupään ilmoituksia en siis edes pääse näkemään.

Voit ohjata ne tiedostoon (komento > tiedosto), poimia vain alun tulosteet (komento | head -n rivimaara) tms. Voit myös ohjata ne omatekoiselle ohjelmalle, joka osaa poimia oikeat ilmoitukset, tai käyttää grep-komentoa ja vaikkapa säännöllisiä lausekkeita vastaavaan tarkoitukseen.

Henk.koht. inhoan säännöllisiä lausekkeita, mutta kyllä tuo grep on silti erittäin hyödyllinen komento moneen tilanteeseen. :)

Lisään tuohon listaan vielä että useimmisssa konsoleissa on mahdollisuus kasvattaa sen muistipuskurin kokoa. Esim. Windowsin oman command consolen puskurin voi kasvattaa vakiosta 50 rivistä 999 riviin saakka (ainakin XP). Avaat vain command consolen properties ikkunan ja sieltä se asetus löytyy.