Fehler bei Programm beenden
-
Ich habe ein Programm geschrieben und führe zum beenden des Programms den Befehl Close(); aus per Klick auf einen Eintrag im Popup-Menü des TrayIcons.
Wenn ich die dynamischen RTL udn die Laufzeitpackages rausnehme, also eine stand alone bastel, kommt folgende Fehlermeldung und das Programm beendet sich nicht korrekt:
Debug-Ausgabe: Invalid Address specified to RtlFreeHeap( 00F30000, 00F31EA0 ) Prozess KonzernT.exe (3752)
Lasse ich die RTL und die Laufzeitpackages drin, funzt alles einwandfrei.
Woran könnte das liegen?
-
Hi,
ich glaube da ist es verdammt schwer eine pauschale Aussage zu treffen, ohne den Code zu debuggen.
Allerdings ist mir das schonmal in einem anderen Kontext über den Weg gelaufen und da lag das Problem darin, dass Speicher mit free() freigegeben wurde, obwohl ein delete hätte genutzt werden müssen. Es gilt: alloc => free, new => delete
Hast du evtl. so einen Fehler in deinem Destruktor?!Schönen Gruß
-
ich habe gar keinen Destruktor.
Ich habe nur einen WSDL-Import und zeige dann die Return-Werte an.
In der automatisch erstellten Interface-Datei wird ein Objekt mit new erstellt und mit delete auch wieder gelöscht.Hier mal mein Code:
//--------------------------------------------------------------------------- #include <vcl.h> #pragma hdrstop #include "KonzernTool.h" #include "oi_4players_01.h" //--------------------------------------------------------------------------- #pragma package(smart_init) #pragma resource "*.dfm" TForm2 *Form2; _di_OilImperiumPort oi; //--------------------------------------------------------------------------- __fastcall TForm2::TForm2(TComponent* Owner) : TForm(Owner) { RECT rect; SystemParametersInfo(SPI_GETWORKAREA, 0, &rect, 0); Form2->Left = rect.right - Form2->Width; Form2->Top = rect.bottom - Form2->Height; oi = GetOilImperiumPort(); update(this); } //--------------------------------------------------------------------------- void __fastcall TForm2::update(TObject *Sender) { oilArray prices = oi->getOilPrice(4); labOel->Caption = prices[0]+"€"; labBenzin->Caption = prices[3]+"€"; labKerosin->Caption = prices[1]+"€"; labDiesel->Caption = prices[2]+"€"; } //--------------------------------------------------------------------------- void __fastcall TForm2::closeProg(TObject *Sender) { Close(); } //---------------------------------------------------------------------------
die update-Funktion wird durch einen Timer ausgelöst.
Die Interface-Datei ist hier zu finden:
http://c-plusplus.net/forum/viewtopic-var-t-is-229213.html
-
Hallo,
schonmal mit exit(0); probiert?
-
Puh...
Das war jetzt auch nur mal eine schnelle Idee ^^Die Beschädigung des Heaps kann natürlich weiß der Geier wo vorher bereits entstehen und dann beim Beenden des Programms zum Fehler führen.
Verwendest du DLL's in deinem Programm?
-
Benutze den Debugger.
-
der Debugger hilft mir nicht weiter.
Sobald man mit x das Fenster schließt oder man auf beenden klickt im Popup springt der in den CPU-Thread und bringt den Fehler unten in der Console.
Aber ich probiers mal mit exit(0)
/edit: habe es mit exit(0) ausprobiert, genau das gleiche.
Das seltsame daran ist halt nur, dass es nur passiert wenn ich eine stand alone-exe kompiliere. Lasse ich alles bei den Standard-Einstellungen läuft der ganz normal durch.
-
Padde85 schrieb:
der Debugger hilft mir nicht weiter.
Sobald man mit x das Fenster schließt oder man auf beenden klickt im Popup springt der in den CPU-Thread und bringt den Fehler unten in der Console.
Na, das ist doch wunderbar. Da hast du einen Call-Stack zur Verfügung, kannst Breakpoints setzen für den nächsten Start und so versuchen, die Ursache des Problems einzugrenzen - z.B., bei der Freigabe welches Objektes das Problem auftritt.
-
würdest du dir das Programm mal ansehen?
Könnte dir das Prog schicken und parallel dazu auch mal schauen ob ich da den Fehler finde
-
Vor dem Close() sollte ev. Der timer angehalten werden. Sonst könnte der nochmal angesprochen werden, während das Beenden ausgeführt wird.
Oder läuft irgendwo noch ein Thread? Damit hatte ich schon Probleme.
Seitdem "würge" ich Threads immer erst ab und lass dann Beenden. Damit hat es bisher immer geklappt.Gruss
Frank
-
habe testweise eben den Timer mit Timer->Enabled=false; deaktiviert.
Danach kompiliert udn er bleibt wieder im CPU-Thread hängen mit dem Befehl ret.
Hier mal ein Screen davon, falls das hilft:
-
Der Call-Stack deutet darauf hin, daß das Server-Interface erst vom Shutdown-Code freigegeben wird, was offenbar für einige der Cleanup-Tätigkeiten zu spät ist.
Der Zeitpunkt, zu dem globale Variablen initialisiert oder zerstört werden, ist praktisch unvorhersagbar. Und das ist nur einer der guten Gründe, keine globalen Variablen zu verwenden, um "lokale Probleme" zu lösen.
DerAltenburger schrieb:
Seitdem "würge" ich Threads immer erst ab und lass dann Beenden. Damit hat es bisher immer geklappt.
Lieber die harte Tour, anstatt Bugs zu suchen?
Never ever call TerminateThread.
MSDN schrieb:
TerminateThread is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.
Windows Server 2003 and Windows XP/2000: The target thread's initial stack is not freed, causing a resource leak.
TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:
* If the target thread owns a critical section, the critical section will not be released.
* If the target thread is allocating memory from the heap, the heap lock will not be released.
* If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
* If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.
-
ich danke euch allen für eure Hilfe
ich habe einfach noch ein oi->Release(); gesetzt in das closeProg und siehe da es funzt
Also nochmals vielen lieben Dank
-
Warum beseitigst du nicht einfach die globale Variable?
Weil es zwei Zeilen mehr kostet?
-
Kann mich iwie grad net mehr einloggen, daher dann so.
Nein, ich brauche diese variable in den nächsten Tagen noch in mehreren anderen Funktionen, die teilweise durch Buttons oder sonstiges aufgerufen werden.
Und da die variable andauernd neu zu erstellen dauert mir zu lange und frisst nur unnötig Code.
-
audacia schrieb:
DerAltenburger schrieb:
Seitdem "würge" ich Threads immer erst ab und lass dann Beenden. Damit hat es bisher immer geklappt.
Lieber die harte Tour, anstatt Bugs zu suchen?
Ist doch kein Bug. Ist doch normal, dass Aktivitäten gestoppt werden müssen, bevor das Programm terminiert.
Dafür gibt es doch wohl OnCanClose().Passiert auchh mit GIFIMAGE, wenn eine GIF- Animation aktiv ist. Die muss auch erst gestoppt werden. Sonst kommt auch gelegentlich ein Error.
Gruss
Frank
-
Padde85- schrieb:
Und da die variable andauernd neu zu erstellen dauert mir zu lange und frisst nur unnötig Code.
Du könntest sie einfach zu einer Membervariablen machen.
@Altenburger: Daß manche Dinge beim Aufräumen manuell beendet werden müssen, mag ja sein, aber wenn du deine Threads "abwürgst", anstelle sie sauber auf dem Wege der Threadkommunikation zu beenden, dann ist das ein Bug. Gründe oben.
-
audacia@Altenburger schrieb:
Daß manche Dinge beim Aufräumen manuell beendet werden müssen, mag ja sein, aber wenn du deine Threads "abwürgst", anstelle sie sauber auf dem Wege der Threadkommunikation zu beenden, dann ist das ein Bug. Gründe oben.
Na was glaubst Du, was ich mit "abwürgen" mach?
Was verstehst Du denn unter "abwürgen".Gruss
frank
-
DerAltenburger schrieb:
Was verstehst Du denn unter "abwürgen".
TerminateThread.
-
audacia schrieb:
DerAltenburger schrieb:
Was verstehst Du denn unter "abwürgen".
TerminateThread.
Da sind wir uns ja einig. Und zusammen mit WaitFor klappt das bestens.
Gruss
Frank