eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingtypologia errorow aplikacji
Ilość wypowiedzi w tym wątku: 88

  • 21. Data: 2011-05-02 21:06:08
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: " " <f...@W...gazeta.pl>

    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/


  • 22. Data: 2011-05-02 21:52:01
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: " " <f...@W...gazeta.pl>

    >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/


  • 23. Data: 2011-05-02 23:14:36
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: Andrzej Jarzabek <a...@g...com>

    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".


  • 24. Data: 2011-05-02 23:30:49
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: Andrzej Jarzabek <a...@g...com>

    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?


  • 25. Data: 2011-05-03 00:28:50
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: A.L. <l...@a...com>

    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.


  • 26. Data: 2011-05-03 06:47:40
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: Paweł Kierski <n...@p...net>

    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


  • 27. Data: 2011-05-03 06:59:52
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: Paweł Kierski <n...@p...net>

    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


  • 28. Data: 2011-05-03 07:51:58
    Temat: Re: typologia errorow aplikacji (a jeszcze leipaj i realoki)
    Od: " " <f...@W...gazeta.pl>

    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/


  • 29. Data: 2011-05-04 06:12:28
    Temat: Re: typologia errorow aplikacji
    Od: " " <f...@g...SKASUJ-TO.pl>

    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/


  • 30. Data: 2011-05-04 07:00:35
    Temat: Re: typologia errorow aplikacji
    Od: Andrzej Jarzabek <a...@g...com>

    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.

strony : 1 . 2 . [ 3 ] . 4 ... 9


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: