speicherleck?



  • hi,

    bin gerade von visual 6 auf visual 2005 umgestiegen und jetzt geht bei meinem alten projekt nix mehr. nachdem ich nun alle stringfunktionen umgeändert habe meckert er jetzt bei free:

    typedef struct
    {
    	double x, y, z, PhiZ;
    } t_coord;
    
    int DrawNumZ (HDC hdc, int offset, REAL *ev, int nx, int ny, double h)
    {
        t_coord	   **P;
        int            i;
    
        if ((P = (t_coord **)calloc((ny), sizeof(t_coord *))) != NULL)		   
        for (i = 0; i < (nx); i++)	
        {  
            if ((((t_coord **)P)[i] = (t_coord *)calloc(nx, sizeof(t_coord))) == NULL)
            {
                P = NULL;		
                break;									
            }	
        }
    
        blabla.....
    
        for (i=0; i<nx; i++)
    	free (P[i]);
        free (P);                  // <- Error
    }
    

    also ich will in einer fkt dynamisch reservierten speicher wieder freigeben, denn ohne macht ers irgenwie auch nicht. Was hab ich falsch gemacht? hoffe mir kann jemand helfen.

    gruß christian



  • Möchtest Du "Fehler" auch noch etwas genauer beschreiben oder sollen wir hellsehen?



  • Erstmal sind da ein paar überflüssige Casts drin, die die LEsbarkeit nicht gerade erhöhen.

    Zweitens solltest du auch nach der Fehlerbehandlung dafür sorgen, daß dein Speicher sauber freigegeben wurde.

    Und drittens: WAS FÜR EINEN Fehler meldet dein Compiler?

    (PS: Viertens gehört das eine Etage höher ;))



  • neandertaler schrieb:

    ...
                P = NULL;		
    ...
    

    solltest du dafür nicht besser P[i] = NULL; schreiben?



  • du holst dir ein array mit platz fuer "ny" t_coord* und beschreibst davon "nx" elemente.
    sinnvoll?



  • dachte es wäre was offensichtiliches, was ich mal wieder übersehen hätte. also für alles nicht-hellseher ; )

    die fehlermeldung

    Windows hat einen Haltepunkt in Rectangular.exe ausgelöst.
    
    Dies kann auf eine Beschädigung des Heaps zurückzuführen sein und weist auf ein Problem in Rectangular.exe oder in einer der geladenen DLLs hin.
    
    Weitere Analyseinformationen finden Sie möglicherweise im Ausgabefenster.
    

    danach springt der debugger in die datei dbgheap.c, Zeile 475 zu

    _munlock(_HEAP_LOCK);
    

    hoffe das ist etwas klarer jetzt. mit der speicherallokierung dürfte es eigentlich keine probleme geben, die benutze ich so öfter und meckert der compiler nicht.



  • sorry, nicht der compiler, sondern der debugger meckert. ist ja wohl ein unterschied



  • ok, war doch die allokierung. danke für den tip, hätte sonst noch lange an der falschen stelle gesucht



  • net schrieb:

    neandertaler schrieb:

    ...
                P = NULL;		
    ...
    

    solltest du dafür nicht besser P[i] = NULL; schreiben?

    Eigentlich braucht er das überhaupt nicht zu schreiben. P = NULL ist an der Stelle logisch falsch, und P[i] = NULL schreibt er ja bereits zwei Zeilen darüber.

    @neandertaler
    Zudem solltest du über deine Speicherreservierung nochmal nachdenken. Evtl. würde es auch reichen, plain zu allokieren.


Anmelden zum Antworten