[VC++] dbgheap bug

[Verwijderd]

Op het werk na veel problemen de oorzaak gevonden van onze crash.

Deze blijkt bij Microsoft te zitten

File: dbgheap

VS98:

>> /* break into debugger at specific memory allocation */
>> if (lRequest == _crtBreakAlloc)
>> _CrtDbgBreak();

VS2003
>> if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)
>> _CrtDbgBreak();


We draaien VC6 met laatste Service Packs. Iemand enig idee hoe we dit kunnen oplossen?

File in project toevoegen en aanpassen lukt niet.

Iemand een andere update?

[MSalters]

Waarom denk je dat er bug bij Microsoft zit? Het verschil in code zegt niets. De hele memory allocator werkt anders in 2003. Sowieso is dit code die niet in release mode wordt gebruikt, dus als je daar ook een probleem hebt weet je zeker dat de bug in je eigen code zit.

PS. Waarom VC6? Dat is niet meer supported.

PS2. gebruikt een [code=c++] tagje.

[BoAC]

En wat is dan de bug/fout?
* BoAC snapt et eigenlijk niet

[Verwijderd]

MSalters schreef op vrijdag 05 augustus 2005 @ 19:44:
Waarom denk je dat er bug bij Microsoft zit? Het verschil in code zegt niets. De hele memory allocator werkt anders in 2003. Sowieso is dit code die niet in release mode wordt gebruikt, dus als je daar ook een probleem hebt weet je zeker dat de bug in je eigen code zit.

PS. Waarom VC6? Dat is niet meer supported.

PS2. gebruikt een [code=c++] tagje.

We draaien de debug voor verdere problemen te ontdekken.

Bij het alloceren van FFFF FFFF aantal geheugen locaties crasht hij. Wat nazicht op het net blijkt dat wij niet de enigen zijn met dit probleem. http://www.mico.org/piper...004-September/008967.html

Indien we geen oplossing vinden wordt het project naar VS2003 omgezet, maar is wel hoop werk.

[Zoijar]

Verwijderd schreef op vrijdag 05 augustus 2005 @ 19:58:
Bij het alloceren van FFFF FFFF aantal geheugen locaties crasht hij.

Je alloceert 4GB in een programma? Wat crashed er dan precies? Misschien kan je in je eigen code iets veranderen dat je niet van deze 'feature' uitgaat?

[BoAC]

Gaat het nu om een aaneengesloten blok geheugen of om allemaal losse blokken?

In het eerste geval zou ik proberen in een file te werken oid.

[MSalters]

Als ik de code zie die je gepost hebt, dan is dit een mogelijke hack (untested)

C++:

extern _CRTIMP long _crtBreakAlloc;
// eenmalig
_crtBreakAlloc ^= 0x80000000;
// Bij elke allocatie
++_crtBreakAlloc

Een andere optie is om een eigen 'operator new' te gebruiken. Dat is helemaal effectief als je de meerderheid van je allocaties van 1 type zijn, dan kun je een class-specifieke operator new gebruiken. Bijkomend voordeel is dat fixed-size allocators effectiever zijn.

Misschien wel de meest eenvoudige optie is om de STL te gebruiken. std::allocator recycled blokken.

[Verwijderd]

Zoijar schreef op vrijdag 05 augustus 2005 @ 20:18:
[...]

Je alloceert 4GB in een programma? Wat crashed er dan precies? Misschien kan je in je eigen code iets veranderen dat je niet van deze 'feature' uitgaat?

Het is niet de hoeveelheid van dat moment, maar de zoveelste. Die "teller" is niet oneindig en programma van Microsoft is niet voorzien voor terug vanaf 0 te beginnen.

[Verwijderd]

schopje....

[MSalters]

Wat is er mis met STL of een eigen operator new? Met 2^32 allocaties is dat een serieuze overeging, ongeacht welke versie van de software je gebruikt. Overigens blijft het een belachelijk groot aantal voor 99% van de applicaties. Zelfs met onafgebroken 100 allocaties per seconde is dat nog meer dan een jaar!

[BoAC]

Plus dat het een 'debug-feature' is en in release geen probs moet geven
_{Je weet zeker dat je nergens buiten arrays oid loopt hoop ik}

[ Voor 39% gewijzigd door BoAC op 08-08-2005 21:17 ]

[Verwijderd]

Het is nu eenmaal een vrij zwaar programma.

Verbinding met 10-PLC's (communiceren (Modnet bus) met elkaar via de PC): hele hoop berichten verwerking
Visualisering: alle variabelen visualisatie systeem (hangen 10 clients aan)
Logging: alles wordt dan nog eens gelogd (opvragen historische gegevens vanaf clients)


Het zal overgaan zijn naar VS2003, release is alsnog geen optie. Die 10 plc's worden één voor één vervangen en via een gateway in server programma omgezet naar nieuwe soort plc's (TCP/IP)

[.oisyn]

Je zou ook altijd nog HeapAlloc/HeapFree aan kunnen roepen ipv malloc/free of new/delete (geloof dat de stdlib implementatie hier ook gewoon gebruik van maakt)

[MSalters]

Verwijderd schreef op dinsdag 09 augustus 2005 @ 17:20:
Het is nu eenmaal een vrij zwaar programma.

Verbinding met 10-PLC's (communiceren (Modnet bus) met elkaar via de PC): hele hoop berichten verwerking
Visualisering: alle variabelen visualisatie systeem (hangen 10 clients aan)
Logging: alles wordt dan nog eens gelogd (opvragen historische gegevens vanaf clients)

"Vrij zwaar"? Zo erg kan dat toch niet zijn? Waar komen al die heapallocaties vandaan? Voor visualisatie zou het allemaal niet nodig moeten zijn.

Gebruik je misschien new/delete op block scope, in plaats van de stack te gebruiken? Dat is een fout die Java programmeurs nog wel eens maken als ze C++ gebruiken.

[MSalters]

.oisyn schreef op dinsdag 09 augustus 2005 @ 17:26:
Je zou ook altijd nog HeapAlloc/HeapFree aan kunnen roepen ipv malloc/free of new/delete (geloof dat de stdlib implementatie hier ook gewoon gebruik van maakt)

Da's niet handig, dan kun je beter zelf een operator new definieren. Die mag dan HeapAlloc aanroepen, maar dan hoef je niet al je code aan te passen .

[.oisyn]

Ik hoef toch niet alles voor te kauwen of wel?