Citat:
bogdan.kecman
nemoj me zezat, ti radis neko programiranje ako se ja dobro secam, i to ne u nekim kliktackim alatima vec pravo programiranje .. i ne zabada ti nikad? ne prihvatam da sam ja bas toliki baksuz :D
Ne. Ozbiljno, BSOD na svojim masinama nisam video ima ohoho vremena - poslednji sistemski BSOD sam imao u nekoj ranoj verziji Viste.
Ne znam sta da ti kazem, ali deluje mi da ili jesi baksuz ili jednsotavno nemas srece sa hardverom (tj. drajverima za isti).
Citat:
jok ba, winapi ... startas visual studio, cukas neki kod, stisnes run - bang BSOD, stisnes debug - bang BSOD .. nista kernel space, samo user space .. jeste greska kod mene ali
- user space
- nije repeatable (jednom bsodira, 5 puta radi)
to se na linuxu ne desava nikad
Sorry, ali userland kod ne moze da BSOD-uje sam od sebe - jednostavno, nema te privilegije. Ukljucujuci i debager.
Postoje samo 2 nacina da userland kod BSOD-uje*:
a) Da postoji bag u sistemskim API-jima koji propagira u ring0 (recimo neki sistemski API koji radi syscall i prelazi u ring0 - u Windows-u se to desava preko ntdll.dll interfejsa)
ili
b) Da userland kod na kraju zavrsi u nekom drajveru (recimo, crtanje, I/O, itd...).
Sanse da se a) desi su u danasnje vreme drasticno male i na Windows-u i na Linuxu. Dokaz za to se vrlo lako moze prikupiti pregledom sistemskih patch-eva oba OS-a - sistemski krahovi zbog OS bagova su danas jako retki. To takodje pokazuje i broj kernel-level exploit-a koji je danas drasticno manji od situacije pre 10-tak godina.
Medjutim, situacije koje potpadaju pod b) su daleko cesce na zalost. Recimo, tvoj userland kod crta nesto preko OpenGL-a ili Direct3D-a - drajver ima bag, i to se univerzalno zavrsava ring0 exception-om koja na Windows-u znaci BSOD a na Linuxu kernel panic.
Ili tvoj kod radi mrezni I/O - mrezni drajver ima bag, ista stvar - exception u ring0.
Za te svari ne mozes kriviti OS, posto je kod koji pravi problem pisan od strane OEM-a.
Zbog ovih stvari su OS vendori poceli neki drajver kod da vracaju u userland - pa tako od Windows Vista-e drajveri za printere i USB uredjaje mogu ici preko UMDF-a (User Mode Driver Framework) - posto su krahovi userland drajvera daleko manje katastrofalni za sistem. Takodje, pod Windows-om je radjeno na izolaciji display drajvera pa neki bagovi u displej drajverima zavrse "samo" sa restartom displej drajvera - na zalost, kad imas ring0 kod, vecina situacija koje izazivaju exception moraju da se zavrse sa smrzavanjem sistema jer je tako najbolje za integritet podataka.
* Pominjes debugging - nevezano direktno za debager vec za profajler: primeti da profajleri na Intel platformi cesto koriste MSR registre kako bi prikupljali hardverske PMU podatke o broju izvrsenih instrukcija i gomili drugih countera vezanih za performanse - citanje i pisanje MSR registara zahteva ring0 privilegije + pogresno koriscenje MSR registara moze izazvati sistemski krah. Ukoliko profajler nije bas up-to-date cesto se desava da pukne u ring0 modu na nekom novom procesoru. Intel-ovi profajleri (VTune) to resavaju tako sto uopste ne rade na novim platformama dok se ne apdejtuje kod - ali Microsoft-ov profajler, recimo, nema nikakav problem da pokusa da koristi stare MSR registre na novom Intel cipu - sto se nekad zavrsi jako lose (BSOD).
Kada je izasao Sandy Bridge, recimo, Visual Studio profajler je momentalno BSOD-ovao na njemu ako koristis hardverske PMU registre. Opet, to nije userspace bug, vec bag koji se manifestuje kada drajver (za I/O sa PMU unitom procesora) zada outdated MSR komandu.
Citat:
ne znam sta da ti kazem, ja na linuxu radim ozbiljan development a na windozi radim smesan development, linux nukad nism zabo iz userspace-a, windozu jesam milion puta ... kao sto rekoh, mozda je sedmica resila taj problem, ne znam, ne smem da pljujem sta ne znam, ali iskustvo je takvo .. na zalost i sedmica mi je bsodovala tako da mi je tu iskustvo lose (da, verovatno zbog losih drajvera, mada masina gde je pucala ima sve ispravno i nista specijalno, gigabyte maticna sa intel chipsetom, intel procesor, nvidia graficka i to je to)
Moje ili tvoje licno iskustvo ne znaci puno.
Ono sto znaci puno je pregled OS bulletina gde se moze procitati koliko patch-eva su izazivali sistemski krah zbog propagacije problema iz userlanda u ring0 kod koji je deo samog kernela i sistemskih komponenti a ne 3rd party drajvera. Takvih bagova je jako malo danas na oba OS-a - ogromna vecina oops-eva/BSOD-ova su zbog losih drajvera
Evo tipicnog Linux Kernel Oops-a iz userspace-a:
http://www.linuxquestions.org/...ser-space-mounting-4175443455/
Ovaj problem je gotovo sasvim sigurno prouzrokovan losim drajverom.
Lista otvorenih Linux kernel oops-eva - trenutno otvorenih 147 slucaja:
https://bugzilla.kernel.org/bu...&product=&content=oops
Ako se pogledaju komentari/opisi - jasno je da je vecina problema drajverske prirode. Bas kao i na Windows-u.
Ali tesko da oops-eva nema, mislim lista bi bila prazna, je li.
[Ovu poruku je menjao Ivan Dimkovic dana 23.01.2013. u 14:24 GMT+1]
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos:
http://www.digicortex.net/node/17 Gallery:
http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! -
https://github.com/psyq321/PowerMonkey