Fragen zu ePicLoad bei korrupter Bild-Datei

  • Hi zusammen,

    folgender (wohl Standard-) Code ist im Einsatz:


    Wenn ich mit ePicLoad.startDecode(picName) ein Bild lade, wird dann auch self.finish_decode aufgerufen, wie es sich gehört.

    Ist das Bild allerdings korrupt, wird finish_decode (natürlich) nicht aufgerufen. Und: Wenn ich dasselbe korrupte Bild oft hintereinander mit StartDecode() aufrufe, schmiert die Kiste irgendwann komplett ab, oft sogar so, dass ich nichtmal mehr mit telnet draufkomme - nur noch Netzschalter.


    Weils manchmal einen crashlog gibt, in dem dann sowas steht wie

    vermute ich mit meinem begrenzten Halbwissen, dass der wiederholte Aufruf von StartDecode() mit dem korrupten Bild jedesmal Speicher belegt, der dann nicht mehr freigegeben wird.


    Mit journalctrl sehe ich

    Meine Fragen an die Spezialisten:

    1. Liege ich mit meinen Vermutungen überhaupt richtig?
    2. Wie kann ich das im Code abfangen? Gibt es irgeneine Möglichkeit, im Code das auch rauszukriegen, was mir das journalctrl anzeigt?
    3. Falls meine Vermutung mit dem nicht freigegebene Speicher richtig ist: Wie kann ich den wieder freigeben?

    Danke und Grüsse

    Alfred

  • Jetzt antworte ich mir mal selbst:

    Mit (wieder mal) Hilfe von Sven H haben wir einen "Würgaround" gebastelt. Jetzt nutze ich startDecode(pic, False) synchron und kann dann mit picload.getData(pic) feststellen, dass das Bild korrupt ist (None wird zurückgegeben).

    Nachteil dieser Geschichte: In OE2.0 funktioniert das synchron nicht, so dass ich auch hier wieder 2gleisig fahren muss. In 2.0 wird die Callback-Funktion auch bei korruptem Bild aufgerufen und kann dort auch ausgewertet werden.


    Wurde da in DreamOS etwas "verschlimmbessert"? Oder war es Absicht und hat seine Gründe, dass die callback-Funktion von startDecode() bei korruptem Bild nicht mehr aufgerufen wird?

    Grüsse

    Alfred