Diskussion:Schutzverletzung

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 12 Jahren von Cvf-ps in Abschnitt Ausnahme 13
Zur Navigation springen Zur Suche springen

mesite Systeme

[Quelltext bearbeiten]

"Auf den mesiten Systemen" meiner Meinung nach zu schwach für die Schutzverletzung

MMn sorgt das eigentlich immer und überall für eine Schutzverletzung oder vegleichbares, weil das etwas C-eigenes ist, unabhängig vom System. Habe die Aussage daher etwas verstärkt
Schutzverletzungen sind nichts C-eigenes sondern eine Sache des betriebsystems. So kann z.B. auf einem Atmel keine Schutzverletzung auftreten, da auf den gesamten Speicher zugegruffen werden kann (ist ja auch unnötig, da keinerlei andere "Processe" laufen (die es eigtl. nicht gibt).
Einzig und allein der Kernel entscheidet, ob etwas eine Schutzverletzung ist. Ein weiteres beispiel ist der Kernel selber: dieser ist auch in C geschrieben und kann (und muss) nach belieben über den Speicher herrschen. (nicht signierter Beitrag von 92.204.69.49 (Diskussion) 01:50, 22. Okt. 2010 (CEST)) Beantworten

Lösungsweg für C-Beispiel

[Quelltext bearbeiten]

Es wäre schön, wenn nach dem C-Beispiel ein Lösungsweg steht, wie man es üblich oder besser machen kann, dass eben keine Schutzverletzung auftritt. Weiß da wer, wie das sonst geht? (nicht signierter Beitrag von 77.116.100.35 (Diskussion | Beiträge) 10:34, 18. Jan. 2010 (CET)) Beantworten

Lösung? naja in C selber gibt es da nur eine Lösung: Aufpassen: Solche Fehler entstehen entweder durch fehlerhafte Pointerarithmetik (z.B. oft bei Buffern oder Zeichenketten, die nicht ordentlich mit '\0' abgeschlossen sind) oder bei zugriffen auf zuvor freigegebene Speicherblöcke:
Bsp Free:
char *p = malloc(100);
strcpy(p, "Wikipedia"); //OK
free(p);
strcpy(p, "Schutzverletzung"); //ARG!!
Beispiel Pointerarithmetik:
char text[] = "Wikipedia"; //Chararray der Länge 10 (9 Zeichn + '\0')
char *p=text; //Pointer auf erstes Zeichen des textes (hier 'W')
while(*p) //Solange zeichen nicht null 
{
   printf("%c ", *p); //gebe Zeichen + Leerzeichen aus 
   p++; //Nächstes Zeichen
}
//Ausgabe: W i k i p e d i a

text[9] = '!'; // '\0' mit '!' überschreiben

p=text;
while(*p) //Solange zeichen nicht null 
{
   printf("%c ", *p); //gebe Zeichen + Leerzeichen aus 
   p++; //Nächstes Zeichen
}

//Ausgabe (Wahrscheinlich): W i k i p e d i a ! 
SEGMENTFAULT
Grund: nach dem ! versucht das Programm auf einen (wharscheinlich) nicht Reservierten Speicher zuzugreifen!
Selbes Problem besteht bei allen string functionne die die Länge des Buffers nicht überprüfen: Bsp: strcpy (schlecht) => strncpy (gut) :) (nicht signierter Beitrag von 92.204.69.49 (Diskussion) 01:50, 22. Okt. 2010 (CEST)) Beantworten

Treiber

[Quelltext bearbeiten]

Schlecht pogrammierte Treiber gehören zu den häufigsten Ursachen von Schutzverletzungen und sollten daher mMn gesondert bei den Beispielen erwähnt werden. --84.114.48.34 19:02, 28. Jan. 2012 (CET)Beantworten

Ergänzt. Gruß --Cvf-psDisk+/− 19:03, 27. Jun. 2012 (CEST)Beantworten

Schutzverletzung unter Fortran notorisch?

[Quelltext bearbeiten]
  1. Warum?
  2. Wo ist diese Info her?
  3. Was hat eine Schutzverletzung mit der konkret verwendeten Programmiersprache zu tun? Es ist ein Bug, sonst nichts!
  4. Warum gerade in Fortran "notorisch"?
  5. Warum? (nicht signierter Beitrag von 84.119.77.120 (Diskussion) 20:00, 28. Mär. 2012 (CEST)) Beantworten
AW zu 1-5: unbelegte Aussage entfernt. --Cvf-psDisk+/− 19:13, 27. Jun. 2012 (CEST)Beantworten

Ausnahme 13

[Quelltext bearbeiten]

Sollte das nicht eher 0x0D heißen? Soviel ich weiß ist da die Hexadezimal-Notation üblich, die Benutzer, die noch Windows 9x kennen, kennen wohl den BSOD über den schweren Ausnahmefehler 0D, der wohl nach 0E der zweithäufigste ist. Dabei handelt es sich um die allgemeine Schutzverletzung, siehe BSOD#Konzept. --MrBurns (Diskussion) 20:15, 27. Jun. 2012 (CEST)Beantworten

Habe die Hexwerte (aus dem Grund, dass der OMA-Benutzer das evtl. in der anderen Darstellung gar nicht erkennt) eingebaut. Eigentlich ist das aber dasselbe; aus einer dezimalen 11 (13) wird durch Darstellung als hexadezimale B (DD) ja keine andere Zahl, es wird nur dieselbe anders dargestellt. Gruß --Cvf-psDisk+/− 20:40, 27. Jun. 2012 (CEST)Beantworten