Unter welchen Bedingungen sagt die cmd, dass ein Programm nicht mehr funktioniert?

kknd schrieb:

Das Programm cmd kann nicht denken wenn das programm sich beendet hast du ein fehler gemacht und es ist keine endlosschleife !.

Wer sagt mir, dass es nicht irgendwo einen Überlauf gibt, ab dem er abbricht? Das hat ja absolut nichts mit denken zu tun. Wenn ich durch 0 Teile und das Programm bricht ab, dann hat das ja auch nichts mit denken zu tun, sondern durch einen Standardfehler der durch das Standardfehlerprotokoll abgefangen wird.

SeppJ

Dein Programm wird einfach fehlerhaft sein. Besonders wenn du solche mystischen Fragen über Computer und Gefühle stellst. Merke: Die Programme, die du benutzt, sind in der Regel fehlerfrei. Es kommt ganz, ganz, ganz selten vor, dass ein Programmierer einen Fehler in einem Compiler oder gar der Systemshell findet. Ich habe hier im Forum insgesamt ungefähr 3 Fälle erlebt, allesamt waren das höchst exotische Konstrukte, oft unter Benutzung relativ neuer Features. Aber Schleifen und break? Nein, die sind nicht kaputt. Stattdessen ist es wohl an der Zeit für dich, grundlegende Debugtechniken zu erlernen.

Ich hab nu auf deinen Kommentar hin den dynamischen Speicher einfach mal mehr als 10 mal so viel Speicherplatz wie nötig zur Verfügung gegeben, nun gibt es kein Problem mehr. Die Frage interessier mich dennoch weiterhin.

SeppJ

Wie viel deutlich muss der Hinweis denn noch sein, dass dein Programm fehlerhaft ist? Du hast offensichtlich einen Fehler bei der Benutzung des dynamischen Speichers. Üblicherweise endet das in einem Segfault (Windows: "Programm funktioniert nicht mehr"), aber wenn der Fehler subtil ist, dann kann sich das auch in einem fehlerhaften Programmverlauf äußern. Wie zum Beispiel in einem unerwarteten, aber regulären, Abbruch, oder aber in einer unerwarteten Endlosschleife.

rkhb

Verrain schrieb:

Ich hab nu auf deinen Kommentar hin den dynamischen Speicher einfach mal mehr als 10 mal so viel Speicherplatz wie nötig zur Verfügung gegeben, nun gibt es kein Problem mehr. Die Frage interessier mich dennoch weiterhin.

Erst einmal zur Ausgangsfrage: Die cmd.exe startet ein Programm und wartet, bis es wieder zurückkommt. Sie bricht kein Programm ab. Entweder wird das Programm 1) vom Betriebssystem abgebrochen oder 2) es bricht sich selbst ab oder 3) es beendet sich selbst zu einem unpassenden Zeitpunkt.

Im ersten Fall gibt es eine deutlich vernehmbare Meldung.
Im zweiten Fall kehrt das Programm mit einem Wert != 0 zurück. Drum solltest die main() immer mit 'return 0;' beenden, und im Abbruchfall 'return(1)' oder 'exit(1);' (oder einen anderen Wert != 0) benutzen. Den zurückgegebenen Wert kannst Du mit %ERRORLEVEL% abfragen.
Der dritte Fall ist gemein und der Fehler schwer zu finden.

Als Beispiel ein fehlerhaftes Programm:

#include <stdio.h>

int schleife ( void )
{
	int break_condition = 0;
	int feld[100];

	int i = 0;

	while (!break_condition)
	{
		feld[i++] = i;
	}

	return feld[--i];
}

int main( void )
{
	int i = schleife();
	printf ("wieder da: i=%d\n",i);
	return 0;
}

Kompiliere das Programm ohne Optimierung.

Nun brauchst Du noch eine Batch-Datei:

@ECHO OFF
Programm.exe
echo ERRORLEVEL: %ERRORLEVEL%

Führe die Batch-Datei aus.

Ein mit MinGW-GCC (oder Cygwin-GCC oder PellesC oder LCC32) kompiliertes Programm, bringt:

`wieder da: i=100

ERRORLEVEL: 0`

hat sich also fehlerlos beendet (3. Fall).

MSVC, BCC32 oder TCC:

ERRORLEVEL: -1073741819

hat sich also mit Fehler beendet (2. Fall).

Mit Optimierung wird break_condition in einem Register gehalten und von 'feld[i++] = i; ' nicht überschrieben. Eigentlich müsste jetzt das Betriebssystem abbrechen (1. Fall), das ist aber bei meinen Versuchen nicht der Fall gewesen (ich forsche jetzt nicht weiter nach). Trotzdem dürften die Ergebnisse nicht wunschgemäß sein.

Wenn unerwünschte Ergebnisse mit wilder Vergrößerung des Speichers (scheinbar) verschwinden, dann stimmt etwas mit dem Speicherzugriff nicht. Im Programm oben ist mit 'int feld[100]' nur feld[0] bis feld[99] (100 Elemente) zugeteilt worden. Ein Zugriff auf feld[100] überschreibt dann bereits anderweitig zugeteilten Speicher, in diesem Fall break_condition.

viele grüße
ralph

Bashar

rkhb schrieb:

Ein mit MinGW-GCC (oder Cygwin-GCC oder PellesC oder LCC32) kompiliertes Programm, bringt:

`wieder da: i=100

ERRORLEVEL: 0`

hat sich also fehlerlos beendet (3. Fall).

MSVC, BCC32 oder TCC:

ERRORLEVEL: -1073741819

hat sich also mit Fehler beendet (2. Fall).

Mit Optimierung wird break_condition in einem Register gehalten und von 'feld[i++] = i; ' nicht überschrieben. Eigentlich müsste jetzt das Betriebssystem abbrechen (1. Fall), das ist aber bei meinen Versuchen nicht der Fall gewesen (ich forsche jetzt nicht weiter nach).

Der Rückgabewert ist hexadezimal c0000005, das steht für die von Blue Screens bekannte "Access Violation" (was eigentlich auch nicht anders zu erwarten ist, wenn man wild Speicher überschreibt). Mein Tipp ist, dass diese Compiler die main() in einen Exception-Handler einkapseln (Windows-SEH), weshalb du den Absturz nicht wie gewohnt zu sehen kriegst, sondern nur einen Fehlercode als Rückgabewert.

Wutz

Verrain schrieb:

Wenn ich durch 0 Teile und das Programm bricht ab, dann hat das ja auch nichts mit denken zu tun, sondern durch einen Standardfehler der durch das Standardfehlerprotokoll abgefangen wird.

Quatsch.
Es gibt keinen "Standard"fehler.
Es gibt kein "Standard"fehlerprotokoll.
Was zur Laufzeit in solchen Fällen passiert oder nicht, ist dem jeweiligen Compilerhersteller überlassen evtl. in Anhängigkeit von bereitgestellten OS-Funktionalitäten. Dafür gibt es keine "Standards", der C-Standard schreibt nirgendwo Implementierungsdetails vor, sondern nur das Verhalten zur Compilezeit.

Verrain schrieb:

Ich hab nu auf deinen Kommentar hin den dynamischen Speicher einfach mal mehr als 10 mal so viel Speicherplatz wie nötig zur Verfügung gegeben, nun gibt es kein Problem mehr. Die Frage interessier mich dennoch weiterhin.

Welcher Hinweis wo steht mehr speicherplatz löst das Problem ??? Woher hast du ihn entnommen stammt er aus der endlosen Leere deines Gehirns. Du hast gesagt du hast eine endlosschleife wie kann da mehr speicherplatz das Problem lösen. Ich glaub eher du willst uns alle für dumm verkaufen und nicht zugeben das du es einfach nicht drauf hast.

Lol, kknd DU bist hier einfach nur 'n unregistrierter Forentroll...

Danke, Bashar für die ausführliche Erklärung, das war echt interessant

Das Problem lag darin, dass ich einen Byte zu wenig Speicherplatz zur Verfügung gestellt habe, was ich ja bereits schrieb. Die Hintergründe hinter dem Programmabbruch haben mich dennoch interessiert, deswegen danke für die Hinterleuchtung

Ups, der Dank ging natürlich vorrangig an rkhb