Speicherleck möglich???



  • Folgendes Codebeispiel - ist hier ein Speicherleck möglich, wenn functionThrowingException() eine Exception wirft?

    Jedenfalls hat myObject zwar noch den Wert 0 im catch, aber das new wurde ja bereits aufgerufen - so gesehen also doch ein Speicherleck?

    MyClass* myObject=0;
    	try
    	{
    		myObject= new MyClass ( functionThrowingException() );
    	}
    	catch(...)
    	{
    		return false;
    	}
    

  • Mod

    Hier würde functionThrowingException() vor dem new ausgeführt. Insofern kein Problem. Selbst wenn der Konstruktor von MyClass eine Exception werfen würde, wäre garantiert dass der Speicher freigegeben wird*.

    Problematisch wäre folgender Fall:

    MyClass* myObject=0;
        try
        {
            myObject= new MyClass ( functionThrowingException() );
            // Hier eine Exception
        }
        catch(...)
        {
            return false;
        }
        // Oder auch hier
    

    Da du nicht das RAII-Idiom verwendest (warum nicht? Das hätte nur Vorteile), wäre da ein Speicherleck.

    *: Falls MyClass selber Ressourcen beschlagnahmt hat, bevor die Exception kam, muss es diese natürlich trotzdem wieder richtig freigeben. Siehe meinen Tipp über RAII, wie dieser Vorgang automatisiert werden kann.



  • std::unique_ptr<MyClass> myObject;
    try
    {
        myObject.reset(new MyClass ( functionThrowingException() ));
    }
    catch(...)
    {
        return false;
    }
    

    So nix Speicherlöcher mehr.



  • RAII ist schon klar - ich möchte trotzdem wissen, ob es hier zu einem Speicherleck kommen kann.

    Wenn ich im VS mit dem Debugger durchsteppe, so wird zuerst void* __cdecl operator new(size_t nSize) aufgerufen, und erst dann functionThrowingException().
    Also laut dem, was ich im Debugger sehe, gibts ein Speicherleck!


  • Mod

    Zeig ein vollständiges Beispiel!



  • sadasd schrieb:

    Also laut dem, was ich im Debugger sehe, gibts ein Speicherleck!

    Speicherlecks haben es so an sich, dass sie nicht dann auftreten, wenn man sie erwartet, sondern an einer anderen Stelle.

    Bei dir ist es jedenfalls so, dass im Fall von return false kein Speicherleck ist.

    Dass es bei solchem Code woanders auftritt ist allerdings sehr wahrscheinlich. Leute die Pointer verwenden, diese auf 0 initialisieren und mit Exceptions spielen wie vor 30 Jahren sind immer suspekt.



  • Speicherleck gefunden, lag ein paar Zeilen darunter.

    Grund war:

    Dass es bei solchem Code woanders auftritt ist allerdings sehr wahrscheinlich. Leute die Pointer verwenden, diese auf 0 initialisieren und mit Exceptions spielen wie vor 30 Jahren sind immer suspekt.


Log in to reply