ERLEDIGT
NEIN
NEIN
ANTWORTEN
4
4
ZUGRIFFE
2495
2495
EMPFEHLEN
-
24.05.04 18:36 #1
- Registriert seit
- Mar 2004
- Beiträge
- 81
Hallo zusammen!
Ich habe mir eine Klasse gebastelt, die mir aus einem geklammerten String (keine Verschachtelung) bei optionaler Definition der Klammerinhalte alle möglichen Kombinationen als CStringArray zurückgibt.
Bsp:
"a (b)" => "a"; "a b"; "a(b)"
Das klappt auch wunderbar. Allerdings meldet mir mein Compiler (VC++ 6.0 SP5), dass Teile vom Speicher nicht freigegeben wurden.
Code :1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Detected memory leaks! Dumping objects -> {80} normal block at 0x00324CA0, 4 bytes long. Data: < L_> 14 CB 4C 5F {79} normal block at 0x00324C48, 16 bytes long. Data: < pA L2 > 20 70 41 00 CD CD CD CD A0 4C 32 00 02 CD CD CD strcore.cpp(118) : {78} normal block at 0x00324BF0, 14 bytes long. Data: < b > 01 00 00 00 01 00 00 00 01 00 00 00 62 00 {77} normal block at 0x00324BA8, 4 bytes long. Data: < K2 > FC 4B 32 00 {76} normal block at 0x00324B50, 16 bytes long. Data: < pA K2 > 20 70 41 00 00 00 00 00 A8 4B 32 00 01 CD CD CD strcore.cpp(118) : {75} normal block at 0x00324AF8, 14 bytes long. Data: < > 01 00 00 00 01 00 00 00 01 00 00 00 20 00 {74} normal block at 0x00324AB0, 4 bytes long. Data: < K2 > 04 4B 32 00 {73} normal block at 0x00324A58, 16 bytes long. Data: < pA PK2 J2 > 20 70 41 00 50 4B 32 00 B0 4A 32 00 00 CD CD CD strcore.cpp(118) : {72} normal block at 0x00324A00, 14 bytes long. Data: < a > 01 00 00 00 01 00 00 00 01 00 00 00 61 00 {71} normal block at 0x003249B8, 4 bytes long. Data: < J2 > 0C 4A 32 00 {70} normal block at 0x00324960, 16 bytes long. Data: < pA XJ2 I2 > 20 70 41 00 58 4A 32 00 B8 49 32 00 01 CD CD CD {69} normal block at 0x00324908, 20 bytes long. Data: <`I2 PK2 PK2 > 60 49 32 00 50 4B 32 00 50 4B 32 00 03 00 00 00 {68} normal block at 0x003248B0, 20 bytes long. Data: < > 00 00 00 00 00 00 00 00 CD CD CD CD 00 00 00 00 Object dump complete.
Ich suche jetzt seit 2 Tagen nach dem Fehler, aber ich finde ihn einfach nicht!
Wie würdet ihr bei bei einer solchen Meldung vorgehen?
Es scheint mit den CStringwerten zusammenzuhängen (hab in der strcore.h in der betreffenden Zeile nachgesehen).
Falls ihr Zeit und Lust habt selbst mal einen Blick auf den Code zu werfen:
hier
Danke im Voraus,
JohannesGeändert von revelation (24.05.04 um 18:48 Uhr)
-
24.05.04 19:35 #2
- Registriert seit
- Jul 2003
- Ort
- Duisburg (NRW)
- Beiträge
- 1.788
Ich würde mal darauf tippen, dass in deinen Listen der Wurm ist. Allerdings habe ich mir nicht den ganzen Code angesehen. Sieh dir nochmal an, ob alles korrekt freigegeben wird. Mach Ausgaben in die Destruktoren usw.
Ist es übrigens tatsächlich nötig oder sinnvoll, mit delete this; zu arbeiten (in CStructElement::release())? Ich habe es selber in seltenen Fällen schon gemacht, aber man sollte sich schon sehr sicher sein, dass es nötig ist.Chor: "Wir sind der Chor, und wir stimmen zu. Wir stimmen zu, wir stimmen zu, wir stimmen zu."
-
25.05.04 13:48 #3
- Registriert seit
- Mar 2004
- Beiträge
- 81
Hi Kachelator!
Du hast Recht, die release-Funktion und das darin enthaltene delete this haben eigentlich keine Daseinsberechtigung, da ich statt der virtuellen release-Funktion, den Destruktor als virtuell definieren kann, der dann von den abgeleiteten Klassen überschrieben wird!Code :1 2 3 4 5 6 7 8 9 10
class CLstObject { friend class CVerketteteListe; public: virtual ~CLstObject() = 0 {}; private: CLstObject *m_next; };
Auf deinen Tipp hin, habe ich alles Kostruktions- und Destruktionsvorgänge von CStructElement und CPStructElement gezählt und eine Differenz festgestellt. Da die Liste korrekt arbeitet habe ich geprüft, wie oft ich Listen erstelle bzw. terminiere - und siehe da: Wieder eine Differenz.
Der Fehler lag darin, dass ich nur den Speicher der Listen, welche zu Strings geparst wurden, wieder freigegeben habe.
Zwei kleine Änderungen im Code und die Bilanz war richtig (Ich weiß, dass es ein for(int i = 1; i <= 3; ++i) auch getan hätte.):undCode :1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
void CKlammern::rec_create_all(CVerketteteListe *l, int c) { // Wenn wir den String parsen dürfen if(c == 1) { CString *tmp; // 1. "(a)" => "" tmp = cre_parse_string(l, 1); m_result->Add((LPCSTR) *tmp); delete tmp; // 2. "(a)" => "a" tmp = cre_parse_string(l, 2); m_result->Add((LPCSTR) *tmp); delete tmp; // 3. "(a)" => "(a)" tmp = cre_parse_string(l, 3); m_result->Add((LPCSTR) *tmp); delete tmp; delete l; Del++; } // Weiter aufschlüsseln else { CVerketteteListe *ln; // 1. "(a)(b)" => "(b)" ln = cre_copy_list(l, 1); rec_create_all(ln, c - 1); // 2. "(a)(b)" => "a(b)" ln = cre_copy_list(l, 2); rec_create_all(ln, c - 1); // 3. "(a)(b)" => "(a)(b)" ln = cre_copy_list(l, 3); rec_create_all(ln, c - 1); [B]if(l != m_struct) delete l;[/B] } }
Code :1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
CStringArray *CKlammern::get_mutanted_strings(CString *src) { int count = 0; m_struct = new CVerketteteListe; count = analyse_string(src, &m_struct); if(count == 0) { delete m_struct; return NULL; } m_result = new CStringArray; rec_create_all(m_struct, count); [B]delete m_struct;[/B] return m_result; }
Vielen Dank nochmal an dich, Kachelator, für deinen Tipp!
Leider gab es noch ein kleines weiteres Problem!Code :1 2 3 4 5
Detected memory leaks! Dumping objects -> {68} normal block at 0x003248B0, 20 bytes long. Data: < > 00 00 00 00 00 00 00 00 CD CD CD CD 00 00 00 00 Object dump complete.
Daraufhin habe ich einfach alle Intantiierungen und alle Terminierungen von CVerketteteListe gezählt. Die Zahl war indentisch.
Eigentlich nur zur Sicherheit habe alle Konstruktionen und Destruktionen derselben Klasse gezählt, deren Zahl ja eigentlich mit den oben bestimmten übereinstimmen müsste.
Merkwürdigerweise ist es eine Destruktion weniger Das erklärt zwar das Leak, steht aber im Widerspruch mit den oberen Messwerten!
Wäre nett, wenn sich dazu jemand äussern würde (Der Link zu den Code wurde aktualisiert).
Gruß
JohannesGeändert von revelation (25.05.04 um 15:01 Uhr)
-
25.05.04 18:20 #4
- Registriert seit
- Mar 2004
- Beiträge
- 81
Hallo zusammen!
Ich habe endlich den (hoffentlich) letzen Fehler in diesem Programm gefunden
Es lag daran, dass die Liste für die Grundstruktur in zwei verschiedenen Funktionen (einmal als Parameter übergeben), doppelt erzeugt wurde!
Gruß
Johannes
PS:
Das im vorigen Post geschilderte merkwürdige Verhalten, lag nur an meiner Unfähigkeit...
Werschreibt und dabei denkt, New würde nur dann inkrementiert, wenn XYZ intanziiert wird... - selber schuld!Code :1 2
(if a != b) c = new XYZ; New++;
Das zeigt doch nur mal wieder, wie wichtig richtige Codeformatierung ist! Denn das Auge hängt mehr an der Struktur, als an dem eigentlichen Code!
-
25.05.04 19:10 #5
- Registriert seit
- Jan 2002
- Ort
- Bayern
- Beiträge
- 1.390
JaJa recursive Parser sind gefährlich

Gruß Homerwe would change the world if god gave us the source code...
and remember, science is nothing more than reverse engineering nature...
Current projects:
- LdrawConverter
Ähnliche Themen
-
Memory mit MVC 2
Von Tipsy im Forum Enterprise Java (JEE, J2EE, Spring & Co.)Antworten: 2Letzter Beitrag: 18.01.11, 22:04 -
Memory Leaks o.ä. aufspüren?
Von Anime-Otaku im Forum C/C++Antworten: 3Letzter Beitrag: 13.09.06, 14:24 -
MEMORY LEAKS Hilfe! Vc .Net
Von lalala123 im Forum C/C++Antworten: 2Letzter Beitrag: 02.03.05, 12:00 -
[FYI]Memory Leaks aufspüren/verhindern
Von Thomas Darimont im Forum C/C++Antworten: 0Letzter Beitrag: 14.10.04, 23:17 -
[vc++] Detecting Memory Leaks
Von a_d im Forum VisualStudio & MFCAntworten: 10Letzter Beitrag: 09.03.04, 16:58





Zitieren
Login






