Eine einfache Möglichkeit ist mit @ gegeben - da kannst du ggf. ansetzen.

Kann ich leider nicht, weil das Script trotzdem stirbt :(
Ich hab ja ein @ davor: $result = @imagecreatefrom...
Trotzdem stirbt das Script genau an der Stelle.

Schlauer Plan ;)

Ja, manchmal bin ich ein Fuchs *öähm.. ja

bedenke allerdings die MB != MiB-Problematik.

Wow, mit was alles ich mich auf einmal beschäftigen muss.
Das Problem kannte ich bislang nicht einmal.
Ich dachte alle Systeme könnten korrekt von Bits bis nach TB umrechnen -.-

Du zeigst mir da Problem von denen ich gar nicht wusste, dass sie existieren.

Bzw. etwas Tolleranz schaffen? Wenn ja, wieviel wär angemessen?

Das kommt drauf an, wieviel dein restliches Script sonst noch benötigt. Harte Nuss, die ich auf den Sprung nicht beantworten kann.

Viel passiert da nicht mehr.
An der Stelle mit dem Fehler wird ein Bild gespeichert, wenn das funktioniert hat kommt noch eine Bestätigung.
Wenn das nicht funktioniert hat, wird ein Eintrag aus einer MySQL-Tabelle gelöscht, das wars.

Wäre es eine gute Idee, die Hälfte des zur Verfügung stehenden Speichers zu "nutzen" oder ist das schnell zu wenig bzw. ist die Hälfte, die für übrige Vorgänge "reserviert" wurde, zu groß bemessen?

Danke und Grüße, Matze

Re:

Schlauer Plan ;) bedenke allerdings die MB != MiB-Problematik. Ich kann auf den Sprung nicht sagen, ob PHP korrekt mit der Basis 1.000 (10^3) für die SI-Vorsätze rechnet oder fälschlicherweise mit 1.024 (2^10) rechnet und trotzdem SI-Präfixe verwendet.

Die Dimension des Bildes hat nichts mit der PHP-internen Speicherzuteilung, wie sie von memory_get_usage() wiedergegeben wird, zu tun. Sie ist zwar abhängig vom Datenvolumen, muss jedoch nicht direkt proportional sein. Daher finde ich den Plan alles andere als „schlau“.

Gruß aus Berlin!
eddi

Nein.
Nein.

Warum nicht? Es schwadet nicht, vorher zu prüfen und ggf. zu sagen "Njet, wird nicht klappen".

Hey Vinzenz!

und halt eben * einem empirisch zu ermittelnden Overhead, der größer ist als 1.
Tom schlägt für den Overhead einen Faktor von 1.65 vor.

Wozu ist der Overhead?

Tom seine schöne Funktion (leider fehlen ein paar Kommentare, ich versuch sie mal nachzuvollziehen):

  
// ich denk mal:  
// $_imageinfo = Array aus getimagesize()  
// $memleft = ?? mein PHP kennt keine solche Konstante  
function image_check_memory($_imageinfo, $memleft = MEMORY_LEFT)  ## X, Y, bits, channels  
{  
    ## fehlende Angaben durch Raten ergänzen  
    if (!isset($_imageinfo['bits'])) $_imageinfo['bits'] = 8;  
    if (!isset($_imageinfo['channels']) and $_imageinfo['bits'] == 24) $_imageinfo['channels'] = 1;  
    if (!isset($_imageinfo['channels'])) $_imageinfo['channels'] = 3;  
    // benötigten Speicherplatz berechnen:  
    // (durch 8 teilen für Bits zu Bytes)  
    // wozu ist +65536 ??  
    // wozu ist der Overhead? Größer 1 ist klar, aber wieso 1.65?  
    // Bildbreite * Bildhöhe * Bits * Farbkanäle / 8Bits + 65536) * Overhead  
    // Ergebniss abrunden  
    $memoryNeeded = round(($_imageinfo[0] * $_imageinfo[1] * $_imageinfo['bits'] * $_imageinfo['channels'] / 8 + 65536) * 1.65);  
    // maximal Speicher der zur Verfügung steht * 1048576  
    // wieso 1048576 ??  
    $memoryLimit = intval(ini_get('memory_limit')) * 1048576;  
    // wenn der von PHP verbrauchte Speicher + berechnetem Speicher + $memleft(??) größer als maximal zur Verfügung stehender Speicher  
    if ((memory_get_usage() + $memoryNeeded) + $memleft > $memoryLimit)  
    {  
        // ist das schlecht  
        error_log('..');  
        return false;  
    }  
    // sonst "sollte" mit dem Bild nix schief gehn ;)  
    return true;  
}

Kannst du mir die Stellen mit den Fragezeichen erklären?
Die Funktion sieht super aus, vielleicht sollte mal jemand einen Artikel über das Problem schreiben. (oder gibts schon?)

Danke und Grüße, Matze

Hello,

Tom schlägt für den Overhead einen Faktor von 1.65 vor.

... den ich auch aufgrund erheblicher Recherche aus Threads von Verwendern der Image-Funktionen ermittelt habe und mir nicht selbst aus den Fingern gesagt habe. Er hat sich scheinbar bewährt bisher. Ich habe damit damals noch ein wenig herumexperimentiert, konnte ihn aber nicht wirklich ernsthaft anzweifeln, weder nach unten, noch nach oben.

Das hängt wohl mit der etwas komplexeren Speicherverwaltung der Funktionen, von PHP und dem jeweils verwendeten Basis-System zusammen. Auf Linux-Systemen (32 Bit) konnte man ihn etwas reduzieren, ohne Fehlermeldungen zu kassieren.

Wesentlich ist die vorherige Nutzung von

$_dummy = getimagesize($filename, $_imageinfo);

http://de2.php.net/manual/de/function.getimagesize.php

Das $_imageinfo wid dann, wenn $_dummy !== false ist, wieder in die Funktion

$ok = image_check_memory($_imageinfo, $memleft = MEMORY_LEFT, $logpath)

eingesetzt. $logpath fehler hier noch. Den sollte man angeben können. In der dargestellten Funktion war er fälschlicherweise noch auf Engins /var/log/web04/php_error_log fest verdrahtet.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg