Bugg i VC++.NET?

Finns det en bugg i STL i VC++.NET?

Anledningen till att jag frågar är att jag precis har konverterat mitt program till att använde exceptions.

Men vid vissa throws uppstår det Access Violation i <vector> respektive <queue> när objekten ska förstöras under "stack unwinding".

Jag tyckte detta felet inte kunde ha uppkommit av mig så jag testade koden i Borland, där den fungerade utmärkt.

Så, finns det några kända buggar i STL?

(Av utrymmes- och andra skäl kan inte hela koden postas här. Jag har försökt rekonstruera felet och misslyckats)

Implementationen av STL har rört på sig mellan VC 6 och VC 7. Det kanske är därför ?

Uppstår samma problem om du använder dig av STLPort, dvs den STL som används av Borland? I så fall har du nog stött på en bugg vid exceptions, troligtvis orsakat av kompilatorn.

Synd att du inte kunde skapa ett reproducerbart exempel, det är svårt att göra en fel-rapport utan det. Du kan försöka posta problemet på news://msnews.microsoft.com/microsoft.public.vc.stl

Jag skulle rekommendera att du kör ditt program i Release-build, optimerat på min-size (glöm inte att slå på debug-info så du får symboler och kan debugga release-bygget). Poängen med det är att om du skriver där du inte får skriva är det mer sannolikt att upptäcka det i Release-bygge då du mer sannolikt skriver sönder något allvarligt.

Du kan också använda Pageheap, se http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q264471. Med det kan man lägga skrivskyddadde "guard"-sidor kring allokerade block. Om du sedan skriver utanför någon allokerad buffer är det troligt att man försöker skriva på en skrivskyddad sida, och det ger ett exception som du kan titta på i debuggern.

developer: Jag vet precis på vilken rad felet uppkommer. Det är i nån _Tidy() medlems-funktion till vector resp. queue.

Har inte testat det med STLport ännu.

Det här blir skummare och skummare.

Jag har hittat på ett makro, PRINT_INFO som om det är definerat skriver ut lite info om vad som förekommer.

 
#define PRINT_INFO

//..

void foo()
{
#ifdef PRINT_INFO
cout << "Inuti foo()";
#endif
//..
}
//..

Jag tänkte använda mig av det för att kunna rekonstruera felet.

Men när jag slår på makrot fungerar allt!

Usch, jag hatar när till synes slumpmässiga fel uppstår, men jag hatar också när de försvinner slumpmässigt!

Ah, en sån rolig bugg. Minns att jag hade en sån i ett program under Solaris också. Den kraschade med 'bus error' som meddelande. Lösningen var fånig: man skrev detta på raden innan kraschen...

cout << "";

...och sedan funkade det. Fråga mig inte vad som var fel.

Haha!!

Det verkar som om jag har rätt och Microsoft har fel.
Koden funkar nämligen i både i CodeWarrior 7.0 och Borland C++ Builder 5

Microsofts STL görs av Dinkumware (http://www.dinkumware.com).

Har du lyckats göra något exempel som visar problemet? Visst kan det vara en bug i MS STL, men jag skulle ändå oroa mig i ditt fall. Jag har inte sett några problem på news-gruppen jag refererade i mitt tidigare inlägg, och det känns som en sådan bug borde ha hittats tidigare. Samtidigt är det symptom du berättar typiskt för en heap corruption, och det visa sig olika mycket beroende vilken miljö man bygger i, framförallt beroende på hur kompilatorn lägger ut koden.

När ditt problem inträffar, är det 100%igt i alla fall, eller händer det "ibland"?

Har du provat att köra i release-läge?

Har du bara en .exe-fil (eller är det dll:er eller lib:ar inblandade)? Hur är din code generation inställd? Har du "Multi-threaded Debug DLL (/MDd)" eller "Multi-threaded DLL (/MD)" i alla inblandade projekt?

Jaja OK, det är säkert inte nån bugg i VC, det är det (nästan) aldrig.

Har dock testat /MDd /MD och olika inställningar mycket.

Det var ett lib inblandat med felet kvarstod när jag tog bort det.

Jag använder inte new och delete någonstans i koden så när som på ett ställe, vilket jag har kollat och dubbelkollat.

Tja, vem vet.