cryptopp 5.6.0 erzeugt memoryleak unter vs05

[JvA]

ich werd mich da heute abend nochmal ran setzen wenn ich muse habe....bin inzwischen echt frustriert.....aber danke erstmal ich werds die tage nochmal testen....bis dann

[JvA]

so und wieder neue fehler beim compilieren.....hab jetzt die oben genannte definition in die pch.h eingefügt weil die überall includiert wird.....allerdings kommen jetzt lauter solcher fehler:

1>c:codingemule modsx-raylocalcryptoppdefault.cpp(119) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente
1>c:codingemule modsx-raylocalcryptoppdefault.cpp(181) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente
1>c:codingemule modsx-raylocalcryptoppdefault.cpp(207) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente
1>c:codingemule modsx-raylocalcryptoppdefault.cpp(214) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente
1>c:codingemule modsx-raylocalcryptoppdefault.cpp(221) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente
1>c:codingemule modsx-raylocalcryptoppdefault.cpp(236) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente
1>c:codingemule modsx-raylocalcryptoppdefault.cpp(244) : error C2661: 'operator new': Keine überladene Funktion akzeptiert 3 Argumente

ich weiß nicht was mir vs damit sagen will.....

[WiZaRd]

Ich glaube fast, dass die Crypto eine eigene Speicherverwaltung verwendet und mit dem Makro nicht klarkommt... muss ich mir echt mal bei Gelegenheit anschaun.

[JvA]

ne ich habs jetzt hin bekommen....ich hab die afx.h eingebunden anstatt das makro einzufügen.....eigenartig aber naja....dann noch eine zeile auskommentiert und jetzt gehts.....aber die änderungen mach ich zum release definitiv wieder rückgängig...iss mir zu riskant da jetzt bugs reingebaut zu haben....
außerdem hat das nix gebracht.....

der selbe mist wieder:

Detected memory leaks!
Dumping objects ->
{17225} normal block at 0x02657258, 28 bytes long.
Data: <class CryptoPP::> 63 6C 61 73 73 20 43 72 79 70 74 6F 50 50 3A 3A
{17224} normal block at 0x02657210, 8 bytes long.
Data: <Xre > 58 72 65 02 00 00 00 00
Object dump complete.

noch ne idee?

[WiZaRd]

Hmm... ist mir vorher nie aufgefallen, aber die Daten werden ja auch mit angezeigt... wo zur Hölle wird denn Speicher mit dem Wert "class CryptoPP" reserviert/belegt?

[JvA]

mhh....wenn ich das wüsste hätte ich nich gefragt

[WiZaRd]

Wg. A4AF... der Part mit den UpCompleteSources... jetzt fällt mir das wieder ein! Das ist im DL-Teil komplett FEHL am Platze und wäre nur sinnvoll, wenn du (wie ich das IIRC bei mir gemacht habe) auch "Keep A4AF" für UPLOADFILES eingebaut hast (dann mit Verweis auf CKnownFile natürlich) - ich hoffe das hilft ebenfalls

[Stulle]

Wegen A4AF noch kurz:

Sowas z.B.

// X-Ray :: KeepA4AFInfos :: Start
/*
delete[] m_abyPartStatus;
*/
uint8* thisAbyPartStatus;
if(m_PartStatus_list.Lookup(reqfile, thisAbyPartStatus))
{
delete[] thisAbyPartStatus;
m_PartStatus_list.RemoveKey(reqfile);
}
// X-Ray :: KeepA4AFInfos :: End

macht das ganze kaputt... korrekt wäre, in dem Fall die Flags zu aktualisieren, sonst gehen die alten Daten (ICS, HideOS, etc. - was du da eben drin hast) verloren.
Dasselbige hier:

// X-Ray :: KeepA4AFInfos :: Start
/*
m_abyPartStatus = new uint8[m_nPartCount];
memset(m_abyPartStatus, 1, m_nPartCount);
*/
if (m_abyPartStatus == NULL)
{
m_abyPartStatus = new uint8[m_nPartCount];
m_PartStatus_list.SetAt(reqfile, m_abyPartStatus);
}
memset(m_abyPartStatus, SC_AVAILABLE, m_nPartCount);
// X-Ray :: KeepA4AFInfos :: End

Durch das memset wird alles überschrieben.

Es gab noch mehr, aber ich hab den Kram nicht mehr im Kopf... irgendwas war auch mit dem gespeicherten Srccount.

Also Wiz, ich habe das noch mal durch gesehen und du hättest recht, wenn wir denn m_PartStatus_list im Upload benutzen würden. Machen wir aber nicht. Wir benutzen es ausschließlich im DownloadClient Teil. Dementsprechend wird es nur für ICS und Available benutzt, alles andere wird ignoriert. Da nun - korrigier mich, wenn ich mich verlesen habe - OP_FILESTATUS direkt vor OP_FILEINCSTATUS kommt wird die ICS Information zwar durchaus gelöscht, aber direkt wieder geschrieben, wodurch nichts verloren, aber dafür geupdated wird.

Von daher weiß ich nicht ob du nur auf supersicher gehen willst oder ob du m_abyUpPartStatus und m_abyPartStatus beide in der m_PartStatus_list hältst. Letzteres wäre IMO übrigens wenig sinnvoll, da wir ja A4AF related Infos sammeln wollen und nicht generell uns an alles "erinnern" wollen.

Ergo, alles im grünen Bereich.

edit: Huch, habe gerad erst deinen letzten Post gelesen... ist dir wohl schon selbst eingefallen. X-D

[WiZaRd]

Richtig, in dem Fall hast du nur 2 Infos (ich hab dasselbe noch für den UL gemacht, darum ist mir das aufgefallen, da dort ja mehr Status' existieren) - es ist aber auf keinen Fall gut die alten Infos zu löschen wenn du neue erhältst, du bekommst ja entweder den Partstatus und löscht dann den ICS oder vice versa - das geht so ja nicht?
Was mein letzter Post meinte war, dass der Kram wegen UpCompleteSources ÜBERHAUPT nicht in den Morph gehört, da ihr die A4AF-Sachen ja nur für den DL speichert, diese Info aber für den UL wichtig ist!

[Stulle]

Ich denke du vertust dich da gerade ein wenig. Soweit wie ich das verfolgen konnte werden OP_FILESTATUS und OP_FILEINCSTATUS immer genau in dieser Reihenfolge gesendet. Da dies also der aktuellste Stand ist macht es keinen großen Unterschied ob ich lösche und alles neu setze oder alles da lasse und dann trotzdem setze (1) bzw. zurücksetze (0). Was nun besser ist wegen der Ressourcen weiß ich nicht unbedingt, aber es ist wohl beides äquivalent.

Mit UpCompleteSources kann ich aber auch nicht wirklich was Falsches erkennen.