Re: kompilacja i "'Naruszenie ochrony pamięci"
Jedno moje pytanie brzmi nstępująco... dlaczego tak się dzieje na debianie
skoro wczesnie na tym samym sprzecie identyczna konfiguracja wprost nic nie
zmienione , bylo wszystko ok i kompilowalo sie bez problemow co sie tylko
chcialo. slack byl tam co prawda niecaly tydzien, ale zaraz po wgraniu
debiana i po 2 dniach gdy chcialem skompilowac sobie jajko wywalil taki blad
i potem juz prawie przy kazdej kompilcji (a juz na pewno przy kazdej
dluzszej) wywala ten sam blad. Stad moje stwierdzenie ze to wina raczej nie
sprzetu, widac sie mylilem, ale jak wytlumaczyc to ze slack dzialal i
kompilowal wszystko bez problemow?!
Piotrek
>To JEST na 100% problem sprzetu. Mialem identyczny problem. Wystepowal
>on na maszynie serwerowej... GCC 3.2 zawieszal sie losowo, 2.95 nie.
>Mozna by powiedziec wiec, ze to wina GCC 3.2... gdyby nie to, ze dosc
>losowo (kilka dni do dwoch tygodni) wywalal sie caly system. Pomyslalem,
>ze obie sprawy sa powiazane, i ze jak rozwiaze sprawe z GCC, system sie
>ustabilizuje. Probowalem roznych mozliwosci - zmiany ustawien pamieci w
>menu CMOS, underclockingu. Co ciekawe, underclocking POMAGAL.
>Ostatecznie, ustawilem najdluzsze opoznienia do pamieci, wyjalem dwie z
>czterech kosci, tamte dwie wsadzilem w inne sloty. I dziala. GCC 3.2 juz
>sie nie wywraca, wskaznik uptime radosnie pokazuje 31 dni.
>Wniosek
>Nie osadzac zbyt szybko, ze cos nie jest wina sprzetu. Jesli wystepuja
>losowe segfaulty, niemalze na 100% winny jest sprzet.
>Odsylam do doskonalego GCC sig11 FAQ.
>http://www.bitwizard.nl/sig11/
Reply to: