czyli w skrocie -> ZAPCHANIE sobie tablicy (przez bledy w poodznaczaniu
flag) to nie WYCIEKI (z tego jak to widze leaki raczej nieodzownie lacza
sie z utraconymi referencjami czyli nieodzownie zagubionym ramem)

nie widze tego zbyt dokladnie bo np wydawaloby sie ze o ile proces nie
to mallok machina powinna moc widziec wszystkie zaalokowane przez
proces bloki czyli te odlaczone tez - (wiec mozna by niby poprosic
ja nawet o dumpnie cie do loga albo cos takiego) - ale jak tu cos
(czyli roznice zbiorow ram zamalokowany minus ram aktualnie
referencjonowany) z tym zrobic skoro te referencje z programu
sa zwykle tak rozproszone)

absolutnie co innego program w c (statycznym) <<tu caly ram lezy
jak moje dawne notatki w brulionie na tapczanie>>

--
said 'no problemo', a to dopiero demo [stylowa spolka spolem]

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

>Jedna istotna różnica jest taka, że przy statycznych tablicach to trochę
>szybko wychodzi, ale wystarczy wypisywać przy każdym malloc/free
>komunikat, żeby prosto znaleźć co nei zostało zwolnione. Albo użyć
>przeznaczonych do tego narzędzi jak np valgrind.


>> o ile pamietam to z niektorymi powinienem nie rozmawiac (poki nie
>> przywala glowami ze trzy razy w sciane)
>Ja z Tobą też miałem nie gadać póki nie zaczniesz leczyć depresji, ale
>że piszesz w okolicy sensu to toczę tę pogawędkę, więc 1:1.

mozesz sobie pogadac; mnie gadki polegajace na tym ze mialbym
tlumaczyc komus cos czego ten nie rozumie (i widac jest nie w pelni
rozumu skoro gada do wlasnego mozgu fantastyczne i zenujace glupoty
jakie powymyslal na moj temat) niezbyt interesuja, interesuje mnie
moje wlasne skupienie na temacie (i czasem grupa jest do tego b dobra
a czasem nie)


co do leakow - przypadek z niepoodznaczaniem rekordow w tablicy mz
nie odpowiada pojeciu lika - to by bardziej odpowiadalo ewentualnie
przypadkowi gdy mnozysz malloki i odpowiadajace im referencje-wskazniki
i nie zwlaniasz tego wszystkiego, np az do momentu
kiedy skonczy sie ram - mozna tak zapchac pamiec, ale to nie beda
wycieki - leak jest wtedy gdy _stracisz_ referencje do kawalka
ramu np przypisujac do uzywanego wskaznika nowy kawalek - to jest leak
- i to niema odpowiednika w alokatorach na statycznych tablicach w c
(bo tam nie mozna zgubic rekordu w pozaprzestrzeni)

zas z samym szukaniem leakow to nie jest taka prosta sprawa,
sam zlokalizowalem odpowiedzialna linijke (choc i to bylo
dosyc nurzace)

uiImageView.image = mImage
// opis problemu:
// przed przypisaniem mImage ma retain count 1
// po przypisaniu 2, nie moge zwolnic mImage wiecej niz raz bo drugi
// ownership ma uiImageView nie ja i to ono powinno to zwolnic - ale jak?
// przypisanie nila linijke wczesniej z tego co wiem powinno zwolnic
// stary image ale Instruments ciagle pokacuje leaki

ale nie wiele mi to daje - podobno w iphonowym i wogole macowym
objective-c polowa problemow (pytan na forach itp) jakie maja ludzie
dotyczy problemow z gospodarka pamiecia a sa tego grube tysiace :/

pojedyncze leaki zdarzaly mi sie gdy pisalem troche w c++ i gdy pisalem
troche w c# i gdy pisalem troche o obj-c (i kazdy z tych glupich bugow
zajmowal mi ponad dobe czyli okropnie dlugo) natomiast w c nigdy
(bo w oczywisty sposob nie moze byc leakow przy braku allokow)


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 02/05/2011 22:06, f...@W...gazeta.pl wrote:
> czyli w skrocie -> ZAPCHANIE sobie tablicy (przez bledy w poodznaczaniu
> flag) to nie WYCIEKI

To są wycieki.

> (z tego jak to widze leaki raczej nieodzownie lacza
> sie z utraconymi referencjami czyli nieodzownie zagubionym ramem)

To jest tylko kwestia implementacyjna. Logicznie masz ten sam problem:
jeśli element w tablicy nie może być już do niczego użyty (nie ma i
logicznie nie mogą pojawić się indeksy tego elementu), a nie został
oznaczony jako wolny czy wpisany do puli wolnych elementów, to RAM
zajmowany przez ten element jest "nieodzownie zagubiony".

do góry

On 02/05/2011 21:26, f...@W...gazeta.pl wrote:
> Michoo<m...@v...pl> napisał(a):
>
> co do alokatorow to alokatory czesto nie sa potrzebne bo wiele
> zjawisk w programowaniu dotyczy dzialan na stalej liczbie obiektow

Ogólnie to jest jednak nieprawda: większość rzeczywistych problemów jak
najbardziej wymaga takiej czy innej formy dynamicznego przydzielania
pamięci na dane: po pierwsze dlatego, że programy często przyjmują
jakieś dane z zewnątrz, które muszą przetwarzać, trzymając jednocześnie
informacje o danych wcześniej wprowadzonych, ale też dlatego, że wiele
struktur danych wymaga dodatkowych alokacji dla swoich "wnętrzności",
przykładem choćby implementacje konteneró asocjacyjnych jak hash-table
czy self-balancing tree. Można oczywiście zaimplementować to tak, żeby
nie używać malloc/free czy odpowiedników, ale to nie likwiduje problemu
wycieku, czyli sytuacji kiedy błąd w programie powoduje, że śmieci
zapychają dostępne miejsce na nowe dane - niezależnie od tego, czy tym
miejscem będzie statyczna tablica, czy sterta.

> zas jesli mam wewnetrzny alokator na statycznej tablicy to jesli nie
> zaznacze (np po zestrzeleniu samolotu) ze dany rekord z danymi
> jest nieuzywany i gotowy do nadpisania, to nie jest to leak tylko
> wewnwtrzny blad w programie (pamiec sie nie urywa tylko jest
> blednie pooznaczana jako zajeta)

Leak z malloc też polega na tym, że pamięć jest błędnie oznaczona jako
zajęta. Co to znaczy, że pamięć się "urywa"?

> - bardzo gruby: nie bardzo podobny
> do mem-leaka i analogiczny do zlego poustawiania pol w strukturach

Właśnie bardzo podobny.

> - takie rzeczy sie raczej wogole nie zdarzaja, (tj trudno tego nie
> zauwazyc),

Dokładnie tak samo się zdarzają jak z malloc. Jeśli statystycznie
występują rzadziej, to raczej dlatego, że statystycznie częściej używa
się malloc niż alokacji na statycznych tablicach.

> takie borykanie sie z owymi leakami (odpadnietymi kawalkami ramu)
> to doswiadczenie _absolutnie_ mi w c nie znane, niemozliwe i po prostu
> nie wystepujace

Bo to, że nie używasz malloc znaczy, że użycie malloc w C jest niemożliwe?

do góry

On Tue, 03 May 2011 00:30:49 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 02/05/2011 21:26, f...@W...gazeta.pl wrote:
>> Michoo<m...@v...pl> napisał(a):
>>
>> co do alokatorow to alokatory czesto nie sa potrzebne bo wiele
>> zjawisk w programowaniu dotyczy dzialan na stalej liczbie obiektow
>
>Ogólnie to jest jednak nieprawda: większość rzeczywistych problemów jak
>najbardziej wymaga takiej czy innej formy dynamicznego przydzielania
>pamięci na dane: po pierwsze dlatego, że programy często przyjmują
>jakieś dane z zewnątrz, które muszą przetwarzać, trzymając jednocześnie
>informacje o danych wcześniej wprowadzonych, ale też dlatego, że wiele
>struktur danych wymaga dodatkowych alokacji dla swoich "wnętrzności",
>przykładem choćby implementacje konteneró asocjacyjnych jak hash-table
>czy self-balancing tree.

Owszem. Pamietam jak implementowalem pamiec dynamiczna w Fortranie IV.
Pol Warszawy tego uzywalo :)

A.L.

do góry

W dniu 2011-05-02 23:52, f...@W...gazeta.pl pisze:
[...]
> co do leakow - przypadek z niepoodznaczaniem rekordow w tablicy mz
> nie odpowiada pojeciu lika - to by bardziej odpowiadalo ewentualnie
> przypadkowi gdy mnozysz malloki i odpowiadajace im referencje-wskazniki
> i nie zwlaniasz tego wszystkiego, np az do momentu
> kiedy skonczy sie ram - mozna tak zapchac pamiec, ale to nie beda
> wycieki - leak jest wtedy gdy _stracisz_ referencje do kawalka
> ramu np przypisujac do uzywanego wskaznika nowy kawalek - to jest leak
> - i to niema odpowiednika w alokatorach na statycznych tablicach w c
> (bo tam nie mozna zgubic rekordu w pozaprzestrzeni)

Różnica między tym, co piszesz, a tym co napisał Michoo jest taka,
że ty piszesz tylko o przypadku, gdy zasobu nie da się zwolnić, bo
nie ma już jego uchwytu, a Michoo pokazuje, że istotą wycieku jest
niezwalnianie zasobu. Również dlatego, że programista zwyczajnie
zapomniał, choć dostęp do uchwytu nadal istnieje. I tu się z nim
zgadzam. Uzupełnił bym to jeszcze o warunek, że żeby nazwać coś
wyciekiem trzeba tracić zasoby w sposób rosnący w trakcie pracy
programu. Niektóre biblioteki (starsze wersje Qt na przykład, nie wiem,
jak obecne) mają zwyczaj alokowania skończonej liczby obiektów na
starcie. Do tych obiektów nie ma potem dostępu, ale wyciek to nie jest,
bo mniej więcej wiadomo ile pamięci jest potrzebne. Taki program (o ile
nie ma innych wycieków) może potem pracować w nieskończoność - zasobów
nie zabraknie.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2011-05-03 01:14, Andrzej Jarzabek pisze:
> On 02/05/2011 22:06, f...@W...gazeta.pl wrote:
>> czyli w skrocie -> ZAPCHANIE sobie tablicy (przez bledy w poodznaczaniu
>> flag) to nie WYCIEKI
>
> To są wycieki.
>
>> (z tego jak to widze leaki raczej nieodzownie lacza
>> sie z utraconymi referencjami czyli nieodzownie zagubionym ramem)
>
> To jest tylko kwestia implementacyjna. Logicznie masz ten sam problem:
> jeśli element w tablicy nie może być już do niczego użyty (nie ma i
> logicznie nie mogą pojawić się indeksy tego elementu), a nie został
> oznaczony jako wolny czy wpisany do puli wolnych elementów, to RAM
> zajmowany przez ten element jest "nieodzownie zagubiony".

Inaczej - zgubienie uchwytu do zasobu (np. wskaźnika do bloku pamięci)
jest jednym (pewnie najpopularniejszym) sposobem powstawania wycieków.
Ale nie jedynym.

Uwaga - już co najmniej trzy osoby w tym wątku prezentują w tej materii
zdanie odmienne od twojego. Jest takie powiedzenie (w różnych wersjach):
Jeśli jedna osoba mówi, że jesteś koniem, zignoruj to. Jeśli druga
osoba mówi to samo - zastanów się i ewentualnie daj jej w mordę. Jeśli
trzecia osoba powtarza to samo - kup sobie siodło.

--
Paweł Kierski
n...@p...net

do góry

Paweł Kierski <n...@p...net> napisał(a):

> W dniu 2011-05-02 23:52, f...@W...gazeta.pl pisze:
> [...]
> > co do leakow - przypadek z niepoodznaczaniem rekordow w tablicy mz
> > nie odpowiada pojeciu lika - to by bardziej odpowiadalo ewentualnie
> > przypadkowi gdy mnozysz malloki i odpowiadajace im referencje-wskazniki
> > i nie zwlaniasz tego wszystkiego, np az do momentu
> > kiedy skonczy sie ram - mozna tak zapchac pamiec, ale to nie beda
> > wycieki - leak jest wtedy gdy _stracisz_ referencje do kawalka
> > ramu np przypisujac do uzywanego wskaznika nowy kawalek - to jest leak
> > - i to niema odpowiednika w alokatorach na statycznych tablicach w c
> > (bo tam nie mozna zgubic rekordu w pozaprzestrzeni)
>
> Różnica między tym, co piszesz, a tym co napisał Michoo jest taka,
> że ty piszesz tylko o przypadku, gdy zasobu nie da się zwolnić, bo
> nie ma już jego uchwytu, a Michoo pokazuje, że istotą wycieku jest
> niezwalnianie zasobu. Również dlatego, że programista zwyczajnie
> zapomniał, choć dostęp do uchwytu nadal istnieje. I tu się z nim
> zgadzam. Uzupełnił bym to jeszcze o warunek, że żeby nazwać coś
> wyciekiem trzeba tracić zasoby w sposób rosnący w trakcie pracy
> programu. Niektóre biblioteki (starsze wersje Qt na przykład, nie wiem,
> jak obecne) mają zwyczaj alokowania skończonej liczby obiektów na
> starcie. Do tych obiektów nie ma potem dostępu, ale wyciek to nie jest,
> bo mniej więcej wiadomo ile pamięci jest potrzebne. Taki program (o ile
> nie ma innych wycieków) może potem pracować w nieskończoność - zasobów
> nie zabraknie.
>

ten przypadek z nie zaznaczaniem rekordow w tablicolaokatorze
jako wolnych raczej odpowiada sytuacji gdy ktos w c++ uzywa np
stlowego wektora po czym nie usuwa tych jego pol ktore juz do czegos
uzyl i mozna je skasowac - jest to bardzo gruby blad - jak czesto sie
cos takiego zdarza, praktycznie nigdy;; nie wywalone elementy od razu
widac ((czesto ta flaga "airplane[i].enabled" uzywana jest do
odlaczania encji z petli przetwarzania - jak ktos tego nie wylaczy
to np airplane po spotkaniu z kolką nie zniknie z ekranu))

tymczasem leaki z jakimi ja od czasu do czasu sie borykam calymi
godzinami w inych srodowiskach to zupelnie cos innego - nowa jakosc
bledow i wlasnie to nabralo znaczenia slowa 'leak'



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

jesli o mnie chodzi to poki co nie
mam wogole wyrobionego podejscia
do obslugi bledow

chyba najblizsze sa mi dwa podejscia

1. if(error) then exit(-1) // o ile moze byc np -1

inaczej mowiac nalezy nie uwzgledniac
opcji ze sa bledy

2. oprogramowywac je w pelni tj tak samo
jak normalne sciezki wykonania, np
jak nie ma bitmapy to wczytac/wygenerowac
inna albo odlaczyc kawalek kodu

apropos samego posta to z tego ze tak
ladnie niektorym poudawalo sie odzielic
crashe aplikacji od crashy systemu mogloby
wynikac ze moznaby moze podobnie probowac
zamykac crashe w obrebie modulow


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Wed, 4 May 2011 06:12:28 +0000 (UTC), " "
<f...@g...SKASUJ-TO.pl> wrote:
> apropos samego posta to z tego ze tak
> ladnie niektorym poudawalo sie odzielic
> crashe aplikacji od crashy systemu mogloby
> wynikac ze moznaby moze podobnie probowac
> zamykac crashe w obrebie modulow

Banalne: wystarczy moduły zaimplementować jako osobne procesy.

do góry