application has requested the Runtime to terminate it in an unusual way.

Timo P schrieb:
> ARM EABI für AT91SAM7S128
>
> This application has requested the Runtime to terminate it in an unusual
> way. Please contact the application's support team for more information.
> make: *** [application/main.o] Error 3

Da sollte man zuerst einmal identifizieren, welches Programm eigentlich 
mit 'This application' gemeint ist. Ist es der Compiler, der Linker oder 
wer sonst.

So wie das aussieht kommt die Meldung vom make. Also: Welches Programm 
ist gelaufen, bevor make die Meldung gebracht hat?

Hast du das application's support team für die ARM EABI für AT91SAM7S128 
Toolchain bereits kontaktiert?

devkitPro and devkitARM kennen das Problem (und anscheinend NUR diese 
Toolchain)
http://www.coranac.com/tonc/text/setup.htm
http://forums.devkitpro.org/viewtopic.php?f=6&t=119
und weitere...

Ansonsten:
Die Suche nach dem Fehlertext bringt u.a. dies:
http://support.microsoft.com/kb/884538

Timo P schrieb:
> also, das einzige, was ich an "application" laufen habe, ist Cygwin
> unter WinXP. Darunter läuft mein GCC compiler. desweiteren ist das
> Projekt nur in C, nicht C++.
>
> ich kompiliere mit einer makefile, die ich am anhang habe...

und?
wer schmiert jetzt ab?
Compiler, Linker?

Wenn Compiler: Welches Source Code File wird gerade compiliert.

Früher ist es bei Microsoft Compilern auch schon mal vorgekommen, dass 
der Compiler die Grätsche machte. Dann identifizierte man, welches 
Source Code File, welche Stelle im Source Code und verändert dann eben 
diese Stelle ein wenig. Oftmals waren es komplizierte arithmetische 
Ausdrücke, denen es sowieso nicht geschadet hat, wenn man sie in 
Einzelteile aufgebrochen hat.

@ Timo P

Sorry ich dachte das

> ARM EABI für AT91SAM7S128

in deinem ersten Beitrag hätte eine Bedeutung. Bei der DevkitPro and 
devkitARM Toolchain (GCC Compiler usw. für ARM EABI für AT91SAM7S128) 
wurde mehrmals die Fehlermeldung beschrieben, die du auch beobachtet 
hast.

Die Meldung selbst kommt wahrscheinlich von M$. Wer das jetzt genau ist, 
ob das das M$ XP OS selbst ist oder die M$ C-Runtimelibrary von VC++ 
6.0, müsste man nachforschen. Ist aber IMHO unwesentlich.

Auslöser ist die Anwendung, die die M$ C-Runtimelibrary von VC++ 6.0 
benutzt. Und das ist eine derjenigen, die von make aufgerüfen wurden. 
Also ein Programm der Toolchain. Welches genau müsste man 
herausbekommen, indem man sich die Einzelaufrufe der Toolchain 
protokollieren lässt. make räumt danach nur die Reste weg (make: *** 
[application/main.o] Error 3).

> Emuliertes Linuxsystem unter Win XP

Mensch du bist ja wie Houdini - stets ein neues Kaninchen parat :)

Auslöser ist eins der Programme das von make aufgerufen wurde. Das 
schrottet irgendwas in Verbindung mit der M$ Runtime-DLL.

Die darauf folgende Meldung ("This application ... information") kommt 
entweder von dieser M$ Runtime-DLL oder dem M$ XP Betriebssystem.

Der Fehler produziert auch einen Fehlercode beim Beenden des auslösenden 
Programms und der wird von make angezeigt ("make: ... Error 3").

Protokollier doch mal die Ausgaben, die vor der Fehlermeldung kommen.
Da wird ja nicht nur die Fehlermeldung dort stehen, sondern auch noch 
was davor. Interessant ist der letzte Aufruf vor der Fehlermeldung, das 
letzte Programm das gestartet wurde, ehe es abgeschmiert ist. Diesen 
Aufruf brauchen wir.

arm-elf-gcc ist die gesuchte Applikation oder eines der Programme die
der Compilerdriver arm-elf-gcc wiederum aufruft (Präprozessor, Compiler,
Assembler, Linker). Sieht man in dem Log oben nicht.

Wer genau ist aber auch wenig spannend, weil das Problem für alle
Programme grundsätzlich gleich angepackt werden muss, z.B. mit dem ober
verlinkten Hotfix von M$ als erstem Versuch. Oder einer gefixten
Toolchain als nächstem Versuch.

Stefan B. schrieb:

> Wer genau ist aber auch wenig spannend, weil das Problem für alle
> Programme grundsätzlich gleich angepackt werden muss, z.B. mit dem ober
> verlinkten Hotfix von M$ als erstem Versuch. Oder einer gefixten
> Toolchain als nächstem Versuch.

Würde ich auch sagen.
Erst mal die bekannten Fixes anwenden.

Hat man dann immer noch ein Problem, kann man die Sache trickreich 
angehen :-)

Der Absturz passiert beim compilieren von main.c

Da kann man jetzt anfangen alle Funktionen auszukommentieren, so dass 
sie der Compiler nicht mehr sieht
Dann kommentiert man die erste Funktion wieder ein, so dass sie der 
Compiler wieder mitnimmt.
Compilieren
Da werden sicherlich ein paar Fehlermeldungen entstehen, aber die 
ignoriert man. Wichtig ist nur: Absturz oder nicht Absturz.
Hat man keinen Absturz, dann steckt das Problem nicht in der zuletzt 
einkommentierten Funktion. -> Die nächste Funktion wieder von ihrem 
Kommentar befreien und weiter geht die Jagd: compilieren und nachsehen 
ob der Absturz kommt.

Und so tastet man sich ran, bis man die Funktion gefunden hat, die das 
Problem verursacht. Innerhalb der Funktion kann man dann die gleiche 
Auskommentier/Einkommentier-Strategie anwenden um bis auf die Anweisung 
vorzustossen, die das Problem verursacht.

"Und dann schaun wir mal"

Sicherlich gibt es auch eine Möglichkeit, das alles abzukürzen, indem 
man den gcc anweist, die internen Datenstrukturen mitzudumpen, bzw. 
Zwischenfiles anzulegen, aber davon verstehe ich nichts.

in cygwin

1

export TEMP=/tmp

yupp, kann ich bestättigen
Danke Danke
Bin mal wieder in Windows unterwegs ;)

ps: in meinem Fall gehts um avr-gcc compiler, der .. aber sehen sie 
selbst

1

$ avr-gcc -c main.c

2

3

This application has requested the Runtime to terminate it in an unusual way.

4

Please contact the application's support team for more information.