cryptopp 5.6.0 erzeugt memoryleak unter vs05

[JvA]

grade getestet....macht keinen unterschied...aber ich lass das trotzdem drin denn gelöscht werden musses ja sowieso...
danke auf jeden fall für den hinweis.....ich werd mich heute abend noch mal ran setzen und mal ne runde suchen....4 augen sehen ja eh mehr

bis denne und nochmal danke fürs suchen.

[WiZaRd]

Du kannst mir ja auch mal deine .dat zukommen lassen... ohne antileech kann ich den Teil ja nicht testen.

[Stulle]

na ich hab erst getipselt, dass es nicht viel zu viel sei beim starten und ich das beim shutdown prüfen würde. dann fiel mir auf, dass es beim start ja sogar schneller ist... und dann fiel mir das gleiche noch mal auf beim shutdown... an der stelle war es mir klar, ich hatte fehlerhaft gelesen!

so, gn8, hab morgen vorstellungsgespräch und muss um 4 aufstehen...

[JvA]

also selbst ohne alle alles....also mit ner absoluten clean install steht das zeugs bei mir im log...ergo....das antileech zeugs brauchste nicht....ansonsten nimm das was in der beta2 mit dabei ist....das iss das selbe.... danke für deine gedult...

[WiZaRd]

Dann muss es wohl doch am Compiler liegen, auch wenn mir das sehr seltsam erscheint.
Hier nochmal meine Ausgabe:

'emule.exe': 'C:WindowsSystem32psapi.dll' entladen
Memory usage:
0 bytes in 0 Free Blocks.
65651 bytes in 529 Normal Blocks.
9457 bytes in 129 CRT Blocks.
0 bytes in 0 Ignore Blocks.
45592 bytes in 40 Client Blocks.
Largest number used: 20008161 bytes.
Total allocations: 261901818 bytes.
'emule.exe': 'C:WindowsSystem32ExplorerFrame.dll' entladen

[WiZaRd]

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.

[JvA]

danke auf jeden fall für die ganzen informationen....was soll ich jetzt allerdings wegen dem memleak machen.....selbst wenns am compiler liegt muss es ja ne ursache haben oder kanns sein das der compiler einfach nur mist labert?

[WiZaRd]

Glaube ich nicht... du müsstest mal in alle Files (auch in die Crypto wohl) die Defines

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

einfügen (bzw. überall wo "new" benutzt wird), dann sollte beim Debuggen auch die ZEILENNUMMER angezeigt werden.

[JvA]

wenn ich das in die crypto rein klatsche bekomm ich nur noch fehler bekom kompilieren....

1>c:codingemule modsx-raylocalcryptoppzlib.cpp(16) : error C2370: 'THIS_FILE': Neudefinition; unterschiedliche Speicherklassen
1>c:codingemule modsx-raylocalcryptoppzinflate.cpp(599) : error C2065: 'DEBUG_NEW': nichtdeklarierter Bezeichner

lauter solcher meldungen....ich werde noch wahnsinnig hier...geht das irgendwie aus noch anders oder was muss ich verändern? derzeit hab ichs nur in den cpp's drin...

[WiZaRd]

Das Define ist in der afx.h drin:
#define DEBUG_NEW new(THIS_FILE, __LINE__)
THIS_FILE darf natürlich nicht neu definiert werden, wenn es schon existiert.