czy jest mozliwe 'obsluzenie' general protection faulta?
z tego co pisze w wiki to system 'zwykle' zamyka aplikacje
jesli gpf przytrafil sie aplikacji i wyswietla BSoD gdy gpf
przytrafi sie systemowi (np driverowi)

sam nie jestem specjalnym fanem 'wyjatkow' (aczkolwiek
nie przemyslalem tematu do konca tak ze trudno mi cos
do konca powiedziec), a tu jest przyklad na to ze niby
ludzie od wyjatkow uwazaja ze wyjatki sa po to by je
obslugiwac z kolei tutaj mamy zgola cos innego - na wyjatku
po prostu zamyka sie program

jeszcze inna rzecz to rozmaita typologia tych wyjatkow
bo roznych przyczyn moze byc sporo (np read nieporprawnego
adresu, wykonanie niepoprawnej instrukcji, brak uprawnien
kernala (o ile to tez owocuje gpf bo nie wiem) itp
- czy jakos roznicuje sie te wyjatki cz tez wszystko to owocuje
dokladnie tym samym tj oienkiem w rodzaju 'aplikacja wykonala
niedozwolona operacje' ???


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

do góry

W dniu 2011-11-10 17:24, f...@g...pl pisze:
> czy jest mozliwe 'obsluzenie' general protection faulta?
Tak, nie zrobić go (pisząc w bezpieczniejszym języku itd).

do góry

Jacek Czerwinski <...@...z.pl> napisał(a):

> W dniu 2011-11-10 17:24, f...@g...pl pisze:
> > czy jest mozliwe 'obsluzenie' general protection faulta?
> Tak, nie zrobić go (pisząc w bezpieczniejszym języku itd).
>

z punktu widzenia wyjatkow nieobslugiwanie gpf'ow jest czy byloby
bardzo dziwne (bo defakto nie wiem czy nie sa obslugiwane),
jesli w funkcji f() cos sie schrzani (np dzielenie przez zero
czy odczyt spod niedobrego adresu) to raczej wszystko powinno
byc obslugiwane


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

do góry

f...@g...pl pisze:
> czy jest mozliwe 'obsluzenie' general protection faulta?
z tego co wiem to obsługa wyjątków należy do systemu operacyjnego
jak chcesz poczytać to proszę

Vol 3A rozdzial 6.15
http://www.intel.com/content/dam/doc/manual/64-ia-32
-architectures-software-developer-system-programming
-manual-325384.pdf

--
Pozdrawiam - Grzechu
Linux x86_64

do góry

On Thu, 10 Nov 2011 16:24:58 +0000 (UTC) " " <f...@g...pl>
wrote:

> czy jest mozliwe 'obsluzenie' general protection faulta?
> z tego co pisze w wiki to system 'zwykle' zamyka aplikacje
> jesli gpf przytrafil sie aplikacji i wyswietla BSoD gdy gpf
> przytrafi sie systemowi (np driverowi)

http://en.wikipedia.org/wiki/Structured_Exception_Ha
ndling

do góry

<f...@g...pl> napisał(a):

> Jacek Czerwinski <...@...z.pl> napisał(a):
>
> > W dniu 2011-11-10 17:24, f...@g...pl pisze:
> > > czy jest mozliwe 'obsluzenie' general protection faulta?
> > Tak, nie zrobić go (pisząc w bezpieczniejszym języku itd).
> >
>
> z punktu widzenia wyjatkow nieobslugiwanie gpf'ow jest czy byloby
> bardzo dziwne (bo defakto nie wiem czy nie sa obslugiwane),
> jesli w funkcji f() cos sie schrzani (np dzielenie przez zero
> czy odczyt spod niedobrego adresu) to raczej wszystko powinno
> byc obslugiwane
>
z tego wychodzi ze to obslugiwanie wyjatkow moze miec pewien
sens bo np
1) przydaloby sie wyswietic we wspomnianym oknie gdzie
(w ktorej dokladnie funkcji) wydtapil crash
2) w niektorych przypadkach mozna by wylaczyc blok a reszta
programu moglaby dzialac - choc te przypadki nie sa za czeste



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

do góry

W dniu 2011-11-11 10:44, f...@g...pl pisze:
> <f...@g...pl> napisał(a):

>>
> z tego wychodzi ze to obslugiwanie wyjatkow moze miec pewien
> sens bo np
> 1) przydaloby sie wyswietic we wspomnianym oknie gdzie
> (w ktorej dokladnie funkcji) wydtapil crash

GPF jest wyjątkiem o którym trudno coś powiedzieć, np. "właśnie coś ci
zamazało pół pamięci i próbowało wyjść poza dostępny obszar".

nawet adresy mogą być do pewnego stopnia nieprawdziwe (stąd GPF).

do góry

Jacek Czerwinski <...@...z.pl> napisał(a):

> W dniu 2011-11-11 10:44, f...@g...pl pisze:
> > <f...@g...pl> napisał(a):
>
> >>
> > z tego wychodzi ze to obslugiwanie wyjatkow moze miec pewien
> > sens bo np
> > 1) przydaloby sie wyswietic we wspomnianym oknie gdzie
> > (w ktorej dokladnie funkcji) wydtapil crash
>
> GPF jest wyjątkiem o którym trudno coś powiedzieć, np. "właśnie coś ci
> zamazało pół pamięci i próbowało wyjść poza dostępny obszar".
>
> nawet adresy mogą być do pewnego stopnia nieprawdziwe (stąd GPF).
>
jakie adresy?

mz gpfa chyba raczej nalezy traktowac jak dowolny inny
crash/wypadek, sa chyba dwie opcje -

1) albo blad wystapil w momencie crasha

2) albo wczesniej i crash jest widzialnym skutkiem

przy czym (1) jest moim zdaniem znacznie czestsze a (2)
zdarza sie rzadko, przy czym nawet jesli (2) sie zdarzylo to
nie jest powiedziane ze skutki (2) siagaja poza funkcje
w ktorej zdarzyl sie crash, albo ze siegaja poza funkcjonalny
blok (awaryjna funkcje trudno wylaczyc sama w sobie, ew
mozna by probowac wylaczyc caly blok)
Raczej nalezy (lub mozna probowac) zalozyc ze wiecej niz
blok nie jest uszkodzone - i wylaczyc blok, aczkolwiek
jesli ktos boi sie ze uszkodzilo inne bloki i ze moze nastapic
propagacja i lepiej wylaczyc wszystko to tez moze tak zrobic
(ale to zalezy od sytuacji dla jednego moze byc wazniejsze
ryzykowac czy program z wylaczonym blokiem bedzie dzialac
dla innego wazniejsze by nie ryzykowac ze blad sie powiekszy
- chyba tylko o pliki na dysku (czy odpowiedniki) mozna sie
martwic (ale to byc moze lekka przesada w wiekszosci
sytuacji - czesto tez ratowanie programu jest wazniejsze
niz danych) bo innych procesow sie i tak nie uszkodzi
- ogolnie mozna sie jeszcze troche zastanowic, ja osobiscie
pisze bardziej gierki a tam nie badzo wystepują sytuacje
gdzie mozna odlaczyc jakis blok i reszte puscic by dzialalo
pozatym - tak ze i tak robie exit tylko ze komunikat 'gdzie'
by sie przydal






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

do góry

wydaje sie ze bledy maja ograniczona zdolnosc
propagacji bo sa ta badz co badz bledy danych
nie bledy kodu - chyba ze byloby to srodowisko
kodu silnie sterowanego danymi,(=np w agentowce
bledy w skrypcie sztucznej inteligencji agenta)
ale nawet wtady tez sa ograniczone; akurat pisanie
po pamieci w petli to chyba poniekad bylby blad
nie danych tylko twardego kodu - bledy destrukcyjne
ale propagacja tez raczej nie taka latwa, bo raczej
chyba szybko dojdzie do gpf nim zdarzy sie stac
cos innego

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

do góry

W dniu 2011-11-11 14:58, f...@g...pl pisze:
> wydaje sie ze bledy maja ograniczona zdolnosc
> propagacji

Akurat C którego jesteś chyba zwolennikiem, ma duże możliwości "daleko
propagujących" błędów

do góry