| Description |
nize kopie vzajemne komunikace pro pripomenuti, o co slo a kde to uvizlo. zbyval maly krucek. krom toho teda jeste ujisteni, ze ty zmeny/seskrtani se povedly a knihovna je ve stabilnim stavu.
Subject: Re: memory leaks v majce
Date: Wed, 27 Apr 2011 16:35:11 +0200
From: Pavel Smerk <xsmerk@…>
To: Palenicek, Tomas <Tomas.Palenicek@…>
Dobry den,
On Wed, Apr 20, 2011 at 10:51:07AM +0200, Tomas Palenicek wrote:
Dobry den,
jak prosim pokrocila tato asi ne prilis narocna uprava? Ve svetle novych
informaci vyplynuvsich z Vaseho mailu ohledne generovani vlastniho
slovniku by myslim mohly v majce zustat obe metody s tim, ze pokud se
nepreda vysledkovy buffer, zinicializuje se automaticky podle hodnot v
hlavicce datoveho souboru?
ja se hrozne omlouvam, ja ted nestiham protoze se sesly deadliny na podavani
grantovych zadosti a naopak zadavani vysledku do celostatni databaze RIV
plus jeste ruzne dalsi akutni veci. Doufam, ze zitra uz tohle poslu.
Cele to vzniklo tak, ze kolega z vyvojoveho tymu Informacniho systemu MU,
kde to pouzivaji na vyhledavani a detekci plagiatu ap., me presvedcil, ze
knihovna nema takto alokovat pamet, ale ze ma volajicimu programu rict,
kolik si ma naalokovat pameti, tak jsem to takto zmenil.
Cilize ted tam udelam nejaky podmineny preklad, aby tam zustalo i to puvodni
rozhrani pro vas (pripadne to nejak zkombinuju, jak pisete nize), akorat
jsem ted v hroznem frmolu, ze jsem na to jeste nenasel cas --- a nechci to
zase delat uplne v rychlosti, aby to pak nekde nepadalo.
(Ve skutecnosti jsem teda ten kod mezitim taky dost zasadne zmenil/seskrtal,
ale asi Vam to ted poslu jeste ve "starem", abych to uz nezdrzoval.)
S pozdravem, P.
Tedy puvodni
void najdi(const char *hledane)
by mohlo jen volat nove
void najdi(const char *hledane, char *vysledky_buf)
kde by jako vysledkovy buffer pouzila prave ten zinicializovany interni.
Dekuji za brzkou odpoved,
Tomas Palenicek
On 04/12/2011 04:33 PM, Tomas Palenicek wrote:
Dobry den,
gratuluji k narozeni ditete.
Dekuji za zdrojaky a data, mel bych k tomu ovsem jeste prosbu o upravu.
Z nejakeho duvodu tam pribyly dve metody, ktere si na rozdil od
puvodnich s sebou prinaseji misto pro vysledky:
+ void najdi(const char *hledane, char *vysledky_buf);
+ void ohackuj(const char *hledane, char *vysledky_buf);
Puvodni, nami pouzivane, metody pocitaji s predalokovanym mistem, jehoz
zajisteni bylo z kodu odstraneno:
- vysledky = new char [maxvysledky * 10];
Opravou u nas by vznikla nekonzistence v kodu u vas a nasem, predevsim
ale si nejsem jisty, jakou hodnotu pro inicializaci pouzit. Zda puvodni
(maxvysledky * 10) nebo soucasne pouzitou (maxvysledku). Pochopil jsem
spravne, ze obe a vsechny dalsi ze struct signature z fsa.h jsou ulozeny
primo v datovem souboru jako nejaka hlavicka? Inicializace na jednicku v
common.cc je jen pro pripad, ze se datovy soubor nepodari najit nebo
otevrit?
Pokud se ty hodnoty opravdu odvijeji od datoveho souboru, bylo by fajn
jejich inicializaci vne majky nemuset resit, jako to bylo u predchozi
verze.
Diky a tesim se na upravenou verzi :)
Tomas Palenicek
On 04/05/2011 12:13 PM, Pavel Smerk wrote:
On Tue, Mar 08, 2011 at 02:15:44PM +0100, Tomas Palenicek wrote:
Dobry den nazpet, v priloze najdete zdrojaky (vcetne z nich vznikleho
majka_testu s popisovanym chovanim) a data, se kterymi pracujeme.
Promlem je patrny uz pri spusteni valgrindu bez zvlastni konfigurace a s
libovolnym datovym souborem - je to zrejme uz z predchoziho zaslaneho
reportu, ve fsa::read_fsa(char const*) se predpokladam naalokuje pamet
pro nacteni automatu z datoveho souboru, ale uz nedochazi k jeji
uvolneni. Nicmene pro poradek, zde je mnou spoustena prikazova radka,
neni ani potreba zadavat nejaka slova k analyze:
$ valgrind --leak-check=full ./majka_test -f ../../data/lt-w.fsa
Podle SVN mame posledni update zdrojaku z 06.11.2009 a data z 02.03.2010.
Tesim se tedy na brzke opravy, diky,
Echm, dobry den po case a velka omluva, narodilo se mi mezitim dite a ta
doba okolo bylo jaksi vyrazne narocnejsi nez drive okolo narozeni prvniho
ditete.
Prikladam soubor majka.tgz, kde je aktualni kod majky. Valgrind si nad nim
pri normalnim spusteni a analyzach nestezuje.
Dale v data.tgz prikladam nova data, kde jsou vsechny znacky a doplnene
tvary typu neplacení jako podstatne jmeno. (Jeste tam nejsou ti duchove,
to
mi ted nakonec omylem vypadlo, ale pregenerovavani trva, takze to poslu v
dalsi varce s dalsimi upravami.)
A konecne ve fsa_build.tgz posilam program pro tvorbu slovniku. Funguje to
tak, ze na vstupu ocekava radky ve tvaru typu
krtka:Cek:k1gMnSc2
kde krtka je tvar, Cek koduje operaci pro ziskani zakladniho tvaru, kdy
velke
pismeno udava, kolik pismen od konce se ma smazat (A == 0, B == 1, ...) a
co
se ma pripojit, za druhou dvouteckou nasleduje znacka. Pouziti pak je
LC_ALL=C LANG=POSIX sort -u data | ./fsa_build -t w-lt_is> w-lt.fsa
Pokud byste chteli jiny typ dat, -t w_is je prosty seznam slov, -t w-l_is
jsou radky tvaru krtka:Cek, l-w_is naopak krtek:Cka, lt-w
krtek:k1gMnSc2:Cek a konecne l-wt krtek:Cka:k1gMnSc2
Jeste jednou se omlouvam a zdravim, P.
On 03/08/2011 01:11 PM, Pavel Smerk wrote:
Dobry den,
On Tue, Mar 08, 2011 at 11:23:03AM +0100, Tomas Palenicek wrote:
narazili jsme na pomerne neprijemnou vec, majka neuvolnuje vsechnu
alokovanou pamet. Markantni je to u datovych souboru s automaty, kde se
jedna o megabajty, ale tyka se to i dalsich pouzivanych datovych
struktur.
Dobre je to videt uz pri spusteni Vaseho majka_test s valgrindem:
muzete prosim poslat konkretni prikazovou radku (prepinace valgrindu,
data
a
pripadny testovaci vstup), ktera k tomu vedla?
Znepokojil me i letmy pohled do kodu, kde je videt zjevne nedoreseny
problem a pricinu jednoho neuvolnovaneho bloku - v deklaraci tridy fsa
v
souboru common.h:
Tohle pada pri vadnem vstupnim souboru... Proc? Prece se to new vzdy
provede, ne?
virtual ~fsa(void) { delete [] word_syntax; delete [] candidate; }
Hmm, tohle je totiz asi nejaky starsi kod, v aktualnim toto uz nejakou
dobu
nemam. Priznam se, ze nevim uplne presne, co jsem vam naposledy posilal
za
kod a data (mam neco schovaneho, ale mam pocit, ze to neni posledni),
mohli
byste mi prosim vase "aktualni" zdrojaky i data pro srovnani "vratit"?
Otestuju pak svou aktualni verzi s Vami pouzitymi prepinaci valgrindu a
bude-li vse OK, poslu.
Co jsem ted zkousel valgrind --leak-check=full --show-reachable=yes -v,
hlasil mi dva leaky zpusobene chybejicimi delete na konci majka_test
(coz
ovsem predpokladam zajistuje i OS s koncem programu, nicmene pro poradek
jsem doplnil) a jedno Mismatched free() / delete / delete [], ktere jsem
opravil. Takze toto by snad mohlo byt vyresene velmi rychle.
Prosim o napravu, vcetne zapracovani pozadavku, ktere uz pred casem
posilal Michel Samia. Bylo by mozna fajn se domluvit na nejakem
konkretnim terminu.
A jeje, to jsem mirnym nedorozumenim (ktere ovsem pada zcela na mou
hlavu)
zasklil. Prosim, ozyvejte se v takovych pripadech rozhodne mnohem drive!
:-)
Omlouvam se, podivam se na to a dam vedet.
S pozdravem, Pavel Smerk
|
