Mahlzeit!
Ich habe folgendes Problem: Ich habe auf einem XP System eine DLL
Projekt erstellt, welches dort erfolgreich in einer Applikation
verwendet wird. Nun habe ich diees DLL Projekt auf mein Win CE 6.0 R3
portiert. Alles ging ohne Probleme kompilieren. Lass ich den Code
laufen, so wirft exakt eine bestimmte Member-Methode einer Klasse ein
Access Violation, sobald ich innerhalb dieser Methode eine externe
Funktion oder eine andere Member-Methode aufrufe. Das Deklarieren und
Initialisieren von lokalen Variablen und der Zugriff auf
Member-Variablen funktioniert.
Selbst ein simples "printf("Hallo Welt!\n")" innerhalb dieser
Member-Methode wirft eine Access Violation in "coredll.dll". Rufe ich
eine Member-Methode auf, so führt meine DLL zu dieser Access Violation.
Woran kann dies liegen? Hat jemand einen guten Tip?
Vielen Dank!
Grüße, JoW
Hi!
Also die Dateien werden in "obj\...\retail" erstellt und dann in das
Release-Verzeichnis unter "...\retail" kopiert, worauf dann das MakeImg
ausgeführt wird.
Global habe ich Release eingestellt. Das wird dann doch für das
Subproject übernommen, oder?
Grüße, JoW
JoW schrieb:> Also die Dateien werden in "obj\...\retail" erstellt und dann in das> Release-Verzeichnis unter "...\retail" kopiert, worauf dann das MakeImg> ausgeführt wird.
dann sollte das passen.
Warum debugs du die Stelle nicht einfach mal? Dann sieht man doch worauf
er zugreifen will.
Ja, das ist ein wenig ein Problem. Ich hab erstens kein zuverlässiges
Debug-Image. Außerdem müsste ich dieses auf Grund der Größe und des
begrenzten RAMs meiner Zielhardware jedes mal bei einer Änderung in den
Flash schreiben. Dies dauert ca. 30-40 Minuten. Davon möchte ich als
eher absehen. Klingt doof, aber geht halt nicht.
Ich kann aber mit dem KITL auch im Release durch den Code-Steppen, die
Sprungweite stimmt dann zwar nicht immer - er springt manchmal in eine
if, obwohl er dies nicht tut - aber man kann sehen, wo es hängt.
Dabei habe ich eben festgestellt, dass alle anderen Methoden der Klasse,
die bis zu der Zugriffsverletzung aufgerufen werden, erfolgreich
terminieren. Erst in dieser einen Methode tritt, egal was man macht -
Aufrufen einer Member-Methode oder einer externen Funktion wie
prinft(..) - die Zugriffsverletzung ein.
Greets, JoW
JoW schrieb:> Ich kann aber mit dem KITL auch im Release durch den Code-Steppen, die> Sprungweite stimmt dann zwar nicht immer - er springt manchmal in eine> if, obwohl er dies nicht tut - aber man kann sehen, wo es hängt.
dann must du einfach mal auf ASM umschalten und schauen was da genau
passiert.
Das habe ich noch nie im Platform Builder gemacht. Wie funktioniert das?
Er unterbricht ja das Steppen, sobald ich an einer dieser Fehlerstellen
weiterlaufe.
Danke!
JoW schrieb:> Das habe ich noch nie im Platform Builder gemacht. Wie funktioniert das?
keine Ahnung wie es dort genau geht, aber bei den anderne IDEs von MS
kann man einfach per Rechte maustaste auf ASM umschalten und dann dort
im einzelschritt steppen.
Das hier spuckt mir das Debug-Fenster im Visual Studio aus:
72246 PID:41b000a TID:528000a Exception 'Data Abort' (4): Thread-
Id=0528000a(pth=895e29c0), Proc-Id=041b000a(pprc=8952b364)
'MeineTestExe.EXE', VM-active=041b000a(pprc=8952b364)
'MeineTestExe.EXE'
72246 PID:41b000a TID:528000a PC=40051544(coredll.dll+0x00041544)
RA=4091ef18(MeineDLL.dll+0x0001ef18) SP=001ffdec, BVA=001ffddc
Und an der letzten Zeile wirft die coredll.dll die Access Violation,
wenn ich als erste aufgerufene Funktion an dieser Stelle ein
printf("...\n") einfüge. Was sagt mir dies nun?
printf:
40051540 mov r12, sp
40051544 stmdb sp!, {r0 - r3}
Danke für Rat und Tat!
JoW schrieb:> Was sagt mir dies nun?>> printf:> 40051540 mov r12, sp> 40051544 stmdb sp!, {r0 - r3}
dafür müsste man etwas mehr wissen, was steht in Rl2, was steht in sp,
was steht in R0 oder R3.
dann muss man auch etwas mehr vom ASM sehen.
Ich werde mich mal mit dem ASM Code auseinandersetzen.
Woran könnte es denn grundsätzlich liegen, dass exakt eine
Member-Methode keinerlei externe Funktionen oder andere Member-Methoden
aurufen kann?
Viele Grüße, JoW
eigentlich nur wenn der "this" zeiger unsinn ist. Dann geht der Zugriff
auf die Members der Klasse schief. Oder der Fehler ist schon vorher
passiert (z.b. es wurde speicher überschrieben) und wirkt sich erst beim
nächsten zugriff auf dem Stack aus.
"Access Violation" ist halt ein ungültiger speicherzugriff, dafür müsste
man erstmal wissen warauf er zugreifen wollte.
JoW schrieb:> Nützt es evtl. wenn ich mir den this-Pointer im Konstruktor mal ausgeben> lasse und später direkt zu Beginn der "fehlerhaften" Methode?
schaden tut es auf jeden fall nicht.
Eine eigene Frage?
Dieser Thread ist über 15 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
