[C++] new/malloc werkt na een tijd niet meer

[Dragon]

Ik heb een probleem met de functie new (die in feite malloc gebruikt). Mijn applicatie loopt altijd vast op een bepaalde new in de code. Bij deze new/malloc wijs ik een nieuwe blok geheugen toe voor gegevens die in een struct komen, deze struct wordt vaker gebruikt en dit is ongeveer de achtste keer dat malloc gebruikt wordt voor dezelfde struct.

Na het bekijken van de debugger zie ik dat hij de ENOMEM fout krijgt tijdens het aanroepen van de HeapAlloc API. Echter als ik een release build maak en ik voer de code uit dan werkt dit zonder problemen. De applicatie gebruikt overigens ca 7,5MB RAM op het moment van de crash en ik kan geen memory leaks vinden die dit zouden kunnen veroorzaken.

Ik heb al een tijd lopen zoeken naar een oorzaak (en oplossing) voor dit probleem, is er iemand bekend met di t fenomeen?

[farlane]

Heb je misschien last van heap fragmentatie?

[Sappie]

Debug je programma eens met een memory debugger zoals bijvoorbeeld valgrind. Verder, laat eens wat code zien, kunnen we ook zien wat er gebeurt.

[Dragon]

Misschien maar ik weet eigenlijk niet hoeveel ik precies tot mijn beschikking heb. Dit zijn in ieder geval de allocations/deallocations, zoals te zien gaan de laatste 3 mis.

code:

Allocated       0x01f470a8      28 bytes
Allocated       0x01f48140      128 bytes
Allocated       0x01f48870      12 bytes
Allocated       0x01f48908      28 bytes
Allocated       0x01f489b0      28 bytes
Allocated       0x01f48a58      28 bytes
Allocated       0x01f48b10      4 bytes
Allocated       0x01f48b50      8 bytes
Deallocated     0x01f48b10
Allocated       0x01f48b10      4 bytes
Allocated       0x01f48b98      8 bytes
Allocated       0x01f48ee8      600 bytes
Deallocated     0x01f48b10
Allocated       0x01f493d0      600 bytes
Allocated       0x01f49668      8 bytes
Allocated       0x01f496b0      12 bytes
Allocated       0x01f48b10      4 bytes
Allocated       0x01f496f8      8 bytes
Allocated       0x01f49990      176 bytes
Allocated       0x01f49a80      1140 bytes
Allocated       0x01f49f30      8 bytes
Allocated       0x01f48b10      4 bytes
Allocated       0x01f49f78      16 bytes
Allocated       0x01f49fc8      8 bytes
Allocated       0x01f4a010      32 bytes
Allocated       0x01f4a070      16 bytes
Allocated       0x01f4a0c0      4 bytes
Deallocated     0x01f4a070
Deallocated     0x01f4a010
Deallocated     0x01f4a0c0
Deallocated     0x01f49fc8
Deallocated     0x01f49f78
Deallocated     0x01f48b10
Deallocated     0x01f49f30
Allocated       0x01f49f30      8 bytes
Allocated       0x01f48b10      4 bytes
Allocated       0x01f49f78      144 bytes
Allocated       0x01f4a160      128 bytes
Allocated       0x01f4a048      78 bytes
Allocated       0x01f4a8d8      8 bytes
Allocated       0x01f4a638      94 bytes
Allocated       0x01f4a6d8      78 bytes
Allocated       0x01f4a9d8      4 bytes
Deallocated     0x01f4a6d8
Deallocated     0x01f4a638
Deallocated     0x01f4a9d8
Deallocated     0x01f4a8d8
Deallocated     0x01f4a048
Deallocated     0x01f4a160
Deallocated     0x01f49f78
Deallocated     0x01f48b10
Deallocated     0x01f49f30
Allocated       0x01f4a8d8      8 bytes
Allocated       0x01f48b10      4 bytes
Allocated       0x01f4a9d8      16 bytes
Allocated       0x01f4a160      75 bytes
Allocated       0x00000000      8 bytes
Allocated       0x00000000      91 bytes
Allocated       0x00000000      75 bytes

[alx]

Kan aan allerlei dingen liggen. Idd heap fragm, leaks, maar ook heap corruption (of brk()/mmap() blocks of echt out-of-mem, beide onwaarsch). Kun je niet een zwaar debuggende malloc variant proberen of in valgrind runnen? Als heap corruption moet je fast-failure proberen te triggeren.

[Dragon]

Code die new gebruikt, deze gaat dus ca 7x wel goed:

code:

 packet* recvPacket = new packet;
 <code>
 delete recvPacket;

De struct:

code:

#pragma pack(push)  /* push current alignment to stack */
#pragma pack(1)     /* set alignment to 1 byte boundary */

struct packet
{
    BYTE lenStream;
    WORD msgCount;  
        ...

        operator char*()
        {
           code
        }
         
         <meer methodes voor conversie naar een pakket (voor netwerken)>
}

Dit gebeurd in een thread gemaakt met CreateThread() en ik gebruik MSVS2008.

[.oisyn]

Lekker handig, Valgrind suggereren terwijl hij op Windows runt

Maar idd, waarschijnlijk is het heap corruption, veroorzaakt door een van de volgende punten:
- Je dealloceert een pointer die je niet hebt gealloceert
- Je dealloceert een pointer die je hebt vrijgegeven
- Je schrijft buiten de gealloceerde buffer.
- Je schrijft naar geheugen dat nooit is gealloceerd / al is vrijgegeven.

[Zoijar]

Het is wel raar dat het in debug crashed maar niet in release, meestal is het andersom. Maar dat kan komen doordat je debug build je ongebruikte geheugen initialiseert met 0xDEADBEEF oid, en is een release build het gewoon allemaal nullen zijn. Als je zo'n pointer delete bv dan gaat het in een release build gewoon goed, want je mag een null pointer deleten.

Anders geheugen monitoren in de VC debugger. Vervelende bugs. Sloop er steeds meer functionaliteit uit totdat je op de kern stuit.

offtopic:
zit ik in bordeaux en dan alsnog alleen op m'n hotelkamer C++ probleempjes te kijken... te moe om uit te gaan, ik word oud... hehe

[ Voor 12% gewijzigd door Zoijar op 26-10-2008 21:46 ]

[MSalters]

Er klopt iets ernstig niet, als new een null-pointer teruggeeft. new gooit een exception, als er geen memory meer is. (VS6 had een bekende bug hier, VS2008 niet.)

En ik gok dat je crash het gevolg is van het gebruiken van die null-pointer?

[Reptile209]

Wat de oorzaak is weet ik niet, maar er zit iets geks in je tabel met Allocs en Deallocs (Dragon in "\[C++] new/malloc werkt na een tijd niet ..."). In regel 17 en 22 gebruik je hetzelfde adres, zonder dat dat tussendoor vrijgegeven is. * Reptile209 heeft even wat zitten sorteren in Excel (*).
Zoals gezegd: het is een symptoom, niet de oorzaak. Misschien helpt het om te achterhalen wat er wel gebeurt. Ik neem aan dat vanaf regel 22 je geheugenbeheer naar de spreekwoordelijke rag is, en dat het geluk is dat het nog zo lang goed gaat.

Happy debugging

(*) Regelnummertjes ervoor zetten, dan de hele tabel sorteren op Address en dan op volgnummer. Dan zie je tussen het blok met address 0x01f48b10 opeens twee allocs onder elkaar staan op hetzelfde adres

[ Voor 15% gewijzigd door Reptile209 op 27-10-2008 20:54 ]

[Verwijderd]

Is er niet een equivalent voor Valgrind in Windows? Dat is echt zo'n tool waarmee je dit soort fouten in 5 seconden gevonden hebt.

[Zoijar]

boundschecker

[.oisyn]

Wikipedia: Memory debugger
Overigens kun je ook wel het een en ander met de standaard CRT libraries. Zoals _crtSetDbgFlag() met de _CRTDBG_CHECK_ALWAYS_DF flag om bij elke allocatie en deallocatie een heap consistency check te doen. Op het moment dat die een fout aangeeft weet je dus dat tussen de vorige alloc/dealloc en de huidige de fout optreedt. Verder kun je met _CrtCheckMemory() zelf een consistency check uitvoeren waarmee je de plek van de fout verder kunt isoleren.

[Toolmaker]

Zoijar schreef op zondag 26 oktober 2008 @ 21:38:
Het is wel raar dat het in debug crashed maar niet in release, meestal is het andersom. Maar dat kan komen doordat je debug build je ongebruikte geheugen initialiseert met 0xDEADBEEF oid, en is een release build het gewoon allemaal nullen zijn. Als je zo'n pointer delete bv dan gaat het in een release build gewoon goed, want je mag een null pointer deleten.

Anders geheugen monitoren in de VC debugger. Vervelende bugs. Sloop er steeds meer functionaliteit uit totdat je op de kern stuit.

offtopic:
zit ik in bordeaux en dan alsnog alleen op m'n hotelkamer C++ probleempjes te kijken... te moe om uit te gaan, ik word oud... hehe

Dit is niet helemaal correct... new gooit een exception op het moment dat hij geen geheugen kan alloceren, en niet 0x0000000. Daarnaast wordt het geheugen in release mode niet geinitaliseerd. Het bevat gewoon wat er op dat moment in staat.

VC bewerkt geheugen met diverse adreswaarden voor, tijdens en na allocaties, inclusief memory guards voor en na het geheugen. Als je in release een delete doet, dan wordt je pointer niet op NULL gezet. Wat je zou kunnen doen is een SAFE_DELETE() macro maken die een pointer delete en vervolgens op NULL zet. Wat bevat je geheugen adres op het moment dat die crash optreedt?

[Zoijar]

ik heb het helemaal niet over new in mijn post