Destruktor - Unhandled exception
2014-04-15T21:11:33+02:00
2014-04-16T13:45:38+02:00
2022-07-22T21:12:26+02:00
  • Nem hinném. Program végén van törlésnél és a framelistenerben nincs semmilyen más ogre objektum amit törölni szeretne. Egyszerűen csak azt is törölni akarja. Ha hagyom neki hogy törölje akkor meg félig meddig törli csak. Ez van.



    80ezer sornyi leak van, ami közül 1 sem az én hibám. Amit én new-al létrehoztam mindet töröltem... Az Ogre által generált példa kódban is hasonló nagyságú leak van, sajnos ilyen
    Mutasd a teljes hozzászólást!
  • Nem lehet, hogy csak annyi van, hogy az Ogre még használná a te FrameListener-ed, miután te törölted?
    Mutasd a teljes hozzászólást!
  • Dehogy hívom meg közvetlen:

    class Button_Football : public BaseApplication Button_Football::~Button_Football(void){ delete mMenu; delete pWorld; }




    és itt halt meg a delete mRoot-nál



    BaseApplication::~BaseApplication(void) { ..... delete mRoot; }

    Értem én, hogy szerintük a delete mRoot törölni fogja az adott osztály elemeit (mMenu egy Ogre::FrameListener) de nem hívja meg a program végén a destruktorát magától. Ha meg megadom neki üresen, akkor meg nyavalyog. FrameListener destruktora sem okozhatja a bajt, külön létrehozva 1et simán törli.



    Közben kaptam választ az egyik régi felhasználótól, azt mondja vannak hibák és néhány esetben nem tudok törölni, mert az ogre bugzik. :D 



    A heap-et mondjuk már megoldottam. Ott az volt a baj, hogy töröltem egy olyan osztályt amit én hoztam létre ugyan new-al, de hozzáadtam egy Ogre-rendszerhez a mutatót. Viszont ott is volt a heap között különbség, szóval az én változómat sem törölte rendesen. Olyan szemétgyűjtője van az Ogre-nak ezek szerint ami közel sem takarít rendesen.



    De a sima példa programban is a CTR Library használatával kiadott vagy 10000 sor üzenetet, ami program kb semmit sem csinál csak megjelenít egy fejet. Ami pozitívum, hogy az én kódomra a Visual Leak Detector-ban nem jelentkezik hiba és az általam konkrétan használt osztályokra sem. Szóval a probléma megoldva. Sajnos ilyen az Ogre.
    Mutasd a teljes hozzászólást!
  • Nekem nem teljesen világos, hogy mit csinálsz:

     "egy leszármazott fő osztályom.. a fő osztályban megadom, hogy törölje a további osztályokat akkor még úgy is hibaüzenetet kapok, hogy a destruktorok tartalmát kikommentelem."

    Milyen további osztályokat törölnél?


    "Így lefut:"
    Utána meg közvetlen azt írod, hogy így sem fut le.


    "Tehát az ég világon ha semmit sem csinálok a destruktorban, akkor is meghal a hibaüzenettel ha egyszerűen meghívom. "
    "Teljesen üres ott is a destruktor, csak simán meghívom és meghal."

    Mit hívsz meg? Destruktorokat hívsz meg közvetlen?
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy a memóriát elronthatja a program bármely pontján valami, és utána egy teljesen más ponton tud elszállni. Attól, hogy a destruktorod nem csinál semmit, még valahol egy memória túlírás ugyanúgy elronthatja az objektum memóriaterületét, ami jelentkezhet abban, hogy a destruktor helyett valami random más címet hív meg. De más módon is elromolhat.

    Itt sajnos minden mindennel összefügg, nem egyszerű leszűkíteni a hiba forrását. Segítségre lehet a debug módú heap használata (ha a környezeted tud ilyen lehetőséget), az ugyanis több ellenőrzést végez, és jobb eséllyel fog ott elszállni, ahol tényleg a hiba van. Ha Linux alá is fejlesztesz, megnézheted a Valgrind nevű eszközt, amit pont ilyen hibák feltárására találtak ki. Nekem nincs tapasztalatom vele (inkább Windowson szeretek fejleszteni), de jókat lehet hallani róla.

    szerk: ja nem figyeltem, MS Visual C++-t használsz. Nagyon nem ástam bele magam a debug opcióiba, hátha jár erre valaki, aki jobban benne van a témában.
    Mutasd a teljes hozzászólást!
  • Ogre-nál azt írják ugye, hogy elvileg töröl ő mondent ami az Ogre namespace-be tartozik, de persze a _CrtDumpMemoryLeaks() szépen megadja nekem, hogy bizony nem törölte. (a 27 millió másik bájttal együtt amit alapban ő maga okoz szivárgást)



    Olyan, mintha nem teljes törléseket végezne. Ugyan úgy indítottam a programot és ugyan úgy léptem ki, csak egy + objektumot tettem be kíváncsiságból. Az objektum 3/4ével lett több csak a leak (excel makróval gyors összeszámoltam, mert kb 1000 darab van)
    Mutasd a teljes hozzászólást!
  • Program indulásakor természetesen new-al és 1 példányban létezik. 1szer szabadítanám fel és meghal. Csak egy üres destruktor van, szóval szerintem nem bennem van a hiba, ezért is kérdeztem rá itt. Nem is nálam hal megy ugye a program hanem később. Ezért nem is értem

    Az Ogre elvileg felszabadítaná amit tud, szerintem ezért is hal meg az mRoot-nál a másik esetben de néztem és vagy millió memory leak van már csak egy alapértelmezett projektnél amit ő generál. Ahhoz képest az én pár foglalásom nem sok, de egy szakdolgozatban azért még sem néz úgy ki szépen, hogy valami nem lett törölve. (elvileg az ogre mindent töröl de gyakorlatban nem hívja meg a destruktort)
    Mutasd a teljes hozzászólást!
  • A pWorld mikor kap értéket, és hogyan? Mutathat több objektum pWorld mezője ugyanarra a PhysxWorld példányra?

    szerk: A heap corruption arra utal, hogy valamit többször szabadítasz fel, vagy esetleg olyat delete-elsz, amit nem new-val foglaltál.
    Mutasd a teljes hozzászólást!
  • Másik osztálynál ugyan így teljesen üres destruktorra ugyan úgy hibát ír, de ott Heap error a változatosság kedvéért. Teljesen üres ott is a destruktor, csak simán meghívom és meghal.

    Ott debug esetén legalább a kódot kírja, bár sokra megyek vele:

    _RPT3(_CRT_ERROR, "HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.\n" "CRT detected that the application wrote to memory after end of heap buffer.\n", szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)], pHead->lRequest, (BYTE *) pbData(pHead)); }




    Az elsőnél az ős osztályban a legutolsó elem törlésénél (delete mRoot) hal meg. De tényleg úgy, hogy csak annyi a különbség hogy meghívom az üres destruktort vagy sem.
    Mutasd a teljes hozzászólást!
  • így meghal:

    Button_Football::~Button_Football(void){ delete pWorld; } PhysxWorld::~PhysxWorld(){/*...*/}

    így lefut:

    Button_Football::~Button_Football(void){ /*delete pWorld;*/ } PhysxWorld::~PhysxWorld(){/*...*/}

    Tehát az ég világon ha semmit sem csinálok a destruktorban, akkor is meghal a hibaüzenettel ha egyszerűen meghívom. Nincs semmi túlindexelés vagy ilyenek.
    Mutasd a teljes hozzászólást!
  • Ennyi infóval nem lehet mit kezdeni! Valamit elrontasz, bár ezt te is tudod. :)
    Mutasd a teljes hozzászólást!
  • C++-ban nagyon sok minden okozhat access violationt (pár példa: túlindexelsz egy tömbön, kétszer hívsz delete-et egy mutatóra, azután használod a mutatót, hogy delete-et hívtál rá). Konkrét kód nélkül nem nagyon lehet benne segíteni.

    Az még jobb lenne, ha debuggerrel futtatnád, mert az jó eséllyel a kódsort is ki tudná jelölni, ahol a hiba keletkezik. (Nem biztos, hogy a hiba azzal a sorral van, ahol az access violation keletkezik, de kiindulópontnak jó szokott lenni.)
    Mutasd a teljes hozzászólást!
  • Sziasztok. Ogre3d-ben fejlesztek és van egy leszármazott fő osztályom ami további osztályokat tartalmaz.

    Problémám az, hogy ha a destruktorában a fő osztályban megadom, hogy törölje a további osztályokat akkor még úgy is hibaüzenetet kapok, hogy a destruktorok tartalmát kikommentelem. Na nem a destruktorok halnak meg, hanem a fő osztály szülője, mikor egy ottani adattagot akar törölni.

    Ha kiveszem az összes delete-t az osztályomból az üres destruktorokhoz, akkor rendesen lefut, különben:

    Unhandled exception at 0x5340c197 in Button_Football.exe: 0xC0000005: Access violation reading location 0x00001d2a.




    Egyszerűen nem tudom mi lehet a hiba oka.
    Mutasd a teljes hozzászólást!
Ez a téma lezárásra került a moderátor által. A lezárás oka: Tud�st�rba val�!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd