Oh mein Gott! Ich habe Windows gekillt! ;-)

Artchi

Wie Windows NT 5.x zum Absturz gebracht? Sorry, aber ich hab es bishe rnoch nie (unabsichtlich) geschafft. OK, vielleicht bin ich auch nicht so ein schlechter Coder. Aber wie kann man denn NT 5.x zum Absturz bringen? Poste mal bitte Code! Ich glaub es nämlich nicht. Vielleicht eine Ausnahmeverletzung, aber mehr auch nicht.

enno-tyrant

ok, und wieder eine ERMAHNUNGan ALLE, thread-thema ist nicht 'lustig machen' sondern DENKEN

langsam STINKT ES MICH AN, wenn nicht der moderator etwas unternehmrn will; gehe ich andere wege

jeder hat sein problem -> resulat:->er wird zum A_R_S_C_H gemacht

das ist nicht das BOARD welches is kenne... was soll das??

KONSTRUKTIVIE KRITIK oder nichts

//edit: rechtschreibfehler entfernt

Artchi

Tja, wie wir "denken" sollen ohne Sourcecode oder nähere Hinweise, ist mir schleierhaft. CSS hat genug Postings auf dem Zähler, das er weiß, wie man eine Frage hier stellt. Hellsehen können wir nicht... abgesehen davon, das ich NT5.x für ziemlich absturzsicher halte. Ich weiß nicht mal, ob es unter NT5.x einen Bluescreen gibt, da ich in all den Jahren keinen gesehen habe.

Was hat er gemacht? Hat er einen Treiber geschrieben? Wir wissen NICHTS!

Jeder hier weiß nur eines: er hat NT5.x ca. 30x zum Absturz gebracht. Und jetzt?

MAG

Ich kann mir nur vorstellen, dass er irgendwie einen vagabundierenden oder NULL-Zeiger erzeugt hat den er dann auch noch von irgendeiner Funktion etc. verwendet wird.

Vielleicht hast du einen Zeiger gelöscht und danach noch weiterverwendet?
Beispiel:

#include <iostream>
using namespace std;

int main()
{
 int* pInt = new int;

 *pInt = 100;

 cout << "*pInt = " << *pInt << endl;
 delete pInt;

 *pInt = 200; // Verwendung von pInt obwohl bereits per delete gelöscht
 cout << "*pInt = " << *pInt << endl;

 return 0;
}

Dieser Code sollte im besten Fall "nur" zu einem Programmabsturz führen.
Der Grund hierfür ist, dass pInt immernoch auf den alten Speicherbereich zeigt aber der Computer wohlmöglich schon neue Daten in diesen Speicher geschrieben hat der Zeiger ja bereits gelöscht wurde. Das kann zu allen möglichen Fehlern führen, aber meistens stürzt das Programm einfach nur ab - sofort oder erst nach einiger Zeit. Aber du sagtest, dass dein ganzer Computer abstürzt? Mir ist es jedenfalls noch nie passiert, dass mir durch die falsche Verwendung von Zeigern das ganze System abgestürzt ist.
Grundsätzlich gilt bei der Verwendung von Zeigern:
Nach dem Löschen immer NULL zuweisen:

pInt = NULL;

Aber am besten könnten wir dir immernoch helfen wenn du uns einen Teil des Codes gibts der deinen Computer zum Absturz bringt!

Sorry @ all.
Hab mich vertan, war unter Win 95.

Shade Of Mine

MAG schrieb:

Grundsätzlich gilt bei der Verwendung von Zeigern:
Nach dem Löschen immer NULL zuweisen:

Mache ich nur, wenn der Zeiger selber state anzeigt. Also zB bei einem smartpointer, wenn zeiger==NULL wird auf nix gezeigt. aber normale zeiger (sofern ich sie mal roh anfassen sollte) setze ich nicht auf 0 - das versteckt das hoechstens fehler...

MAG

Nungut, irgendwie haben uns die letzten beiden Antworten aber bei der Lösung des Problems nicht wirklich weitergebracht - oder?

@CSS

Wäre wirklich gut wenn du endlich den Code postest! Oder sag einfach wenn du inzwischen kein Problem mehr hast.

Also es war wahrscheinlich so das ich unter Win 95 einen Zeiger auf den Reset-Schalter erlangen konnte. Diesen Zeiger habe ich dereferenziert und dann den Wert auf true gesetzt so das eine Strom floß und ein Reset durchgeführt wurde.

Unter Win XP gab es nur einen sogenannten "Acess Violation".

John Doe

Hi Shade Of Mine,

Mache ich nur, wenn der Zeiger selber state anzeigt. Also zB bei einem smartpointer, wenn zeiger==NULL wird auf nix gezeigt. aber normale zeiger (sofern ich sie mal roh anfassen sollte) setze ich nicht auf 0 - das versteckt das hoechstens fehler...

Und wenn der Zeiger von woanders referenziert wird hat dann keiner ne Chance mehr
festzustellen ob der Zeiger (noch) gültig ist.

mfg JJ

DrGreenthumb

John Doe schrieb:

Und wenn der Zeiger von woanders referenziert wird hat dann keiner ne Chance mehr
festzustellen ob der Zeiger (noch) gültig ist.

äh, man hat im Programm doch irgendeinen logischen Ablauf. Entweder es ist ein Zeiger der zugleich ein Flag ist, oder nicht.

Einfach mal immer auf null setzen bzw. bei jedenm Zugriff auf null testen, ist ganz großer blödsinn.
Man sollte sich schon im Klaren sein, was das Programm überhaupt tut.

John Doe

Bei Programmen ab einer gewissen Grösse hab ich die Menge aller möglichen
Abläufe (=Benutzerinteraktionen) jedenfalls nicht mehr im Kopf. Wenn du das kannst
alle Achtung. (wofür brauchst du eigentlich einen Computer )

Bei mir zumindest prüfen alle Funktionen die Zeiger übergeben bekommen diese auf
Gültigkeit (!= 0). Im einfachsten Fall durch assert, dadurch finde ich definitiv
frühzeitig Fehler. Dies gehört ausserdem zu den Codingvorgaben die in unserer
Firma strikt vorgegeben sind und die auch persönlich für sinnvoll halte.

mfg JJ

Das Überprüfen auf Null ist ja auch sinnvoll.

Aber nicht das Null-Setzen. :p

John Doe

Hey du Cleverle, wie willst du denn auf Null prüfen wenn du das Ding nach Verwendung nie wieder auf Null setzt.

Ausserdem, wer nach Gebrauch nicht wieder "aufräumt", wird Pointer vermutlich auch
nicht mit NULL initialisieren, warum auch, den Ablauf des Programms hat man ja
schliesslich im Kopf.

mfg JJ

Du machst also wirklich

delete p;
p = NULL;

? Wie peinlich...

Shade Of Mine

John Doe schrieb:

Bei Programmen ab einer gewissen Grösse hab ich die Menge aller möglichen
Abläufe (=Benutzerinteraktionen) jedenfalls nicht mehr im Kopf. Wenn du das kannst
alle Achtung. (wofür brauchst du eigentlich einen Computer )

Deshalb haelt man variablen ganz lokal.
da hast du vielleicht 10 Zeilen code die du ueberschauen musst, oder es ist eine Klassenvariable - dann muss man den Zweck der Klasse kennen.

Alles in allem sollte man also schon wissen, was welche Variable macht.

Bei mir zumindest prüfen alle Funktionen die Zeiger übergeben bekommen diese auf
Gültigkeit (!= 0). Im einfachsten Fall durch assert, dadurch finde ich definitiv
frühzeitig Fehler. Dies gehört ausserdem zu den Codingvorgaben die in unserer
Firma strikt vorgegeben sind und die auch persönlich für sinnvoll halte.

die frage ist halt immer, wieviel es bringt.
ein

foo* p=allocate();
foo* p2=p;

destroy(p2);
p2=0;

foobar(p);

macht ja trotzdem Peng - das null setzen bringt sich also nur dann, wenn die Variable gleichzeitig ein Flag ist. Denn wenn sie kein flag ist, dann kille ich sie ja nicht einfach so, ohne das irgendwie erkenntlich zu machen. normalerweise wird der gueltigkeitsbereich der variable nach dem delete verlassen.

das problem mit dem 0 setzen ist aber, dass mehrfache deletes (also krasse logikfehler) nicht auffallen.

Zeiger 0 setzen ist also kein allheilmittel.

John Doe

Mehrfaches deleten fällt nicht auf weils eben keine Problem ist.
Wenn ichs nicht tue zerlegts mich irgendwann und irgendwo. Da find ich meinen
Ansatz beruhigender. In einem Standardprodukt sollte man defensiv programmieren
und Fehler schon im Ansatz vermeiden. Fehler beim Zugriff auf nicht mehr
gültige Pointer dürfen gar nicht auftreten sondern müssen im Vorfeld bereits
vermieden werden.

Wenn deine Zeiger nur funktionslokal sind macht das wenig Sinn. Bei mir kommen
aber durchaus Pointer als Membervariablen vor da behälts du nicht so einfach die
Übersicht, vor allem wenn der Zugriff halt über GUI und Benutzereingaben erfolgt.

mfg JJ

Shade Of Mine

John Doe schrieb:

Mehrfaches deleten fällt nicht auf weils eben keine Problem ist.

Oh, es ist ein verdammt grosses problem. weil deine ablauf logik im arsch ist.
sowas waere praktisch, wenn es beim debuggen auffaellt

du versuchst fehler zu verstecken, indem du die symptome abfaengst - das ist auf dauer nicht gut. denn der fehler ist ja da - auch wenn er sich nicht in einem absturz zeigt.

Wenn ichs nicht tue zerlegts mich irgendwann und irgendwo.

Nein, exakt beim 2. delete
bzw. bei einem zugriff auf den zeiger (man kann ja problemlos debug allokatoren verwenden, somit sind solche Fehler kinderleicht zu finden (weil sie automatisch entdeckt werden).

Nur kannst du bei einem NULL Zeiger nicht sagen, ob der Zeiger jetzt NULL oder wild ist - was ungut ist, weil es ja ein gravierender Unterschied ist.

Da find ich meinen
Ansatz beruhigender.

Klar, du hast weniger abstuerze.
aber bedenke: nur weil ein fehler (und gerade logikfehler koennen teuflisch sein) sich nicht bemerkbar macht, ist er trotzdem nicht fort.

In einem Standardprodukt sollte man defensiv programmieren
und Fehler schon im Ansatz vermeiden.

Ja, vermeiden. nicht verstecken.

Fehler beim Zugriff auf nicht mehr
gültige Pointer dürfen gar nicht auftreten sondern müssen im Vorfeld bereits
vermieden werden.

Nein. nicht vermieden -> entdeckt.

Wenn deine Zeiger nur funktionslokal sind macht das wenig Sinn. Bei mir kommen
aber durchaus Pointer als Membervariablen vor da behälts du nicht so einfach die
Übersicht, vor allem wenn der Zugriff halt über GUI und Benutzereingaben erfolgt.

??
was hat ne GUI damit zu tun?
wenn du dir unsicher bist, schreib halt immer einen kurzen kommentar, dass dieser zeiger ein flag ist.

ich fuer meinen teil kann das selber ganz gut ueberblicken. denn kleine klassen sind recht uebersichtlich.

wobei ich ja zeiger sowieso nur sehr ungerne roh anfasse - das problem also eigentlich garnicht habe, dass ein ungueltiger zeiger existiert.

aber dennoch halte ich es fuer fragwuerdig fehler zu verstecken...
delete 0;
ist ja OK - aber
delete wildptr;
eben nicht.

denn, wenn man einen wilden zeiger deleten will (den man ja schonmal geloescht hat) hat man einen gravierenden bug in der anwendung, der nicht auffaellt.

anders ist die sache natuerlich wenn du sagst, dass alle zeiger ein flag sind. nur waere mir das zuviel aufwand fuer zuwenig nutzen...

John Doe

Ich kann dir immer noch nicht ganz zustimmen

Wenn ich mehrfach n = 0 schreibe so zeugt das von Paranoia, stellt meines
Erachtens aber keinen Fehler dar. Inbesondere geht dabei nicht schief. Ich
verstecke also keinen Fehler sondern vermeide ihn. Wenn ich bei Benutzung
mit assert abprüfe krieg ich auch definitiv raus ob ich da wo ich einen
gültigen Pointer erwarte auch einen kriege oder ob ich da wo keinen (bereits)
gültigen Pointer haben will versehentlich einen erhalte.

Beispielsweise führen beispielsweise die MS COM-Smartpointer Klassen wie CComPtr
automatisch genaus solche Prüfungen aus. Ich nehme mir übrigens nicht allzu oft
MS als Vorbild

Alls besseres Vorbild halte ich mich dann doch an Steve McConnell "Code Complete"

Set pointers to null after deleteing or freeing them...

Übrigens tritt ein Fehler natürlich nicht erst beim zweiten Delete auf sondern
bei jedem Zugriff auf den inzwischen ungültigen (und ungeprüften) Zugriff auf.

mfg JJ

Artchi

Also, ich bin auch ein 0-Setzer. Weiß auch nicht, was daran nicht richtig oder nicht gut sein soll? Bevor ich etwas instanziere, muß ich doch schauen, ob es nicht schon mal passiert ist. Dafür opfere ich gerne einen Taktzyklus, mehr kostet das heute bestimmt nicht...

DrGreenthumb

Also irgendwie, stell ich mir deinen Code jetzt ziemlich chaotisch vor.

Normalerweise legt man doch klar die Lebenszeit des Objekts fest. Wenn da mehrmals delete auf den selben Zeiger geht, ist das doch dann ein Logikfehler.
Egal ob es im Programm zu einem Fehlverhalten kommt oder nicht. Es ist einfach was, dass man nicht haben will.

du sagst, solche logikfehler sind nicht schlimm, solange das programm noch normal geht. Aber das ist doch ganz großer Mist. Irgendwann schreibt man vor's delete noch ein cout<<"Tschüss" oder etwas das nicht gleich auffällt und irgendwann knallts dann.
Da lasse ich das Programm lieber beim falschen delete sofort abschmieren.