c ++ - stl :: kortproblemer

Indlæg af Hanne Mølgaard Plasc

Problem



Dette må være mig at gøre noget dumt, men har nogen set denne adfærd før:


Jeg har et kort i et klassemedlem, der er defineret som sådan:


std::map <const std::string, int> m\_fCurveMap;


alle opfører sig fint i fejlfinding, men alt går galt i frigivelsestilstand. kortet bliver initialiseret til et skidt nummer: m\_fCurveMap [14757395258967641292]()


Ethvert medlem jeg har efter kortet bliver fuldstændig ødelagt, dvs. hvis jeg lægger en int på linjen efter kortet som dette:


std::map <const std::string, int> m\_fCurveMap;
int m\_myIntThing;


og i mine konstruktorer satte m\_myIntThing til 0, efter at konstruktøren er blevet kaldt m\_myIntThing er noget skørt nummer. Hvis jeg flytter m\_myIntThing til linjen over kortet er alt for m\_myIntThing fint. Dette medfører store problemer for mig længere nede på linjen. Skal jeg gøre noget på kortet i min konstruktør? Jeg er ikke i øjeblikket.


Jeg bruger visuel studio, det fungerer fint med gcc. Jeg ser kun problemet i udgivelsen. Projektet er en dll.


Hvis du har set denne slags galskab før du hjælper det med at køre mig sur. :-)


Mange tak,
Mærke

Bedste reference


Dette er sket med mig mange gange. Selvom det er svært at sige i dit tilfælde, er det meget sandsynligt, at du har forskellige versioner af C-run-tidsbiblioteket mellem forskellige projekter. Kontrollér din 'kodegenerering' faneblad i kompilatorindstillingerne for dine forskellige projekter og gør visse de er ens.


Hvad der sker effektivt er, at forskellige versioner af C-kørselstidsbiblioteker implementerer STL-containere på forskellige måder. Så når de forskellige projekter forsøger at snakke med hinanden, er betydningen af, hvad et std :: -kart er (for eksempel) ændret og er ikke længere binære kompatible.


Den mærkelige adfærd er meget sandsynligt en slags korrupt korruption, eller hvis den bliver overført som en parameter til en funktion, skal du stable korruption.

Andre referencer 1


Problemet er hukommelseskorruption af en slags.


En fejl, jeg ofte har set i C ++-projekter, bruger et objekt, efter at det er blevet slettet.


En anden mulighed er et bufferoverløb. Det kunne være noget objekt på samme stak eller i nærheden på bunken.


En ret god måde at fange synderen på er at indstille et debugger breakpoint, der brænder på hukommelsesændring. Mens objektet stadig er godt, skal du indstille dit breakpoint. Vent derefter til nogle kode skriver ind i denne hukommelsesplacering. Det burde afsløre din fejl.

Andre referencer 2


Hvis du får dine oplysninger fra VS debugger, ville jeg ikke stole på, hvad det fortæller dig for en Release DLL. Fejlfindingsprogrammet kan kun være virkelig betroet med Debug DLLs.


Hvis program output fortæller dig dette, så er det anderledes - i så fald giver du ikke nok information.

Andre referencer 3


Blander du en release DLL med en debug app?


Ellers lyder det som hukommelseskorruption, selv om jeg ikke kan sige sikkert.



  • Noget andet stamper på hukommelsen

  • Du har adgang til slettet hukommelse

  • Du vender tilbage midlertidigt med peger eller reference

  • etc



Enhver af disse kan synes at fungere fint i nogle tilfælde, da de er udefineret adfærd, og kun i udgivelsesmåde springer de op.

Andre referencer 4


Jeg havde det samme problem på g ++, jeg fik det løst ved at fjerne pragmas i et pragma afsnit før det. Selvom koden er korrekt, spørger jeg mig selv, om dette er en compiler bug på platformen, der viser sig, når du bruger stl :: map i nogle situationer.


#pragma pack(push,1)
xxxx
#pragma(pop)

Andre referencer 5


Bare for at give et konkret eksempel på hukommelseskorruptionen:


typedef std::map<int, int> mymap\_t;

static mymap\_t static\_init() { return mymap\_t(); }

class foo {
   foo(): mymap(static\_init()) {}

   //!> d'oh, don't reference!
   const mymap\_t &mymap;
};


Tilfældigt definerede jeg en ref til en medlem variabel og ikke selve variablen. Det bliver initialiseret okay, men så snart rækkevidden af ​​static\_init () er tilbage, bliver kortet ødelagt, og referencen vil bare dukke op i fejlfinding som 'std :: map med 140737305218461 elementer' (temmelig trykt) eller lignende som det peger på nu ufordelt meory (eller værre).


Pas på uheldige henvisninger!