GX-Abgewiesen #61273
geschlossenLogConfiguration zu speicherintensiv
0%
Beschreibung
Die LogConfiguration sorgt bei einigen Kunden für Speicherprobleme.
system/core/logging/LogConfiguration.inc.php in handleFatalError
Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 58267343 bytes) in /system/core/logging/LogEvent.inc.php on line 451
FATAL ERROR(1): "Allowed memory size of 134217728 bytes exhausted (tried to allocate 58267343 bytes)"
protected function var_export($p_expression) { $t_print_r = print_r($p_expression, true); if(strpos($t_print_r, '*RECURSION*') !== false) { $t_var_export = str_replace("\n", "\n\t\t\t", print_r($p_expression, true)); } else { $t_var_export = str_replace("\n", "\n\t\t\t", var_export($p_expression, true)); } unset($t_print_r); return $t_var_export; }
Die Funktion "var_export" läuft über die Log Einträge und ersetzt da Zeichen. Wenn die Datei zu viele Daten enthält ist das Ersetzen zu speicherintensiv.
Hier sollte eine Alternative geschaffen werden, die var_export ersetzt oder die Funktion muss gestrichen werden.
Von Ulrich Wenk vor fast 5 Jahren aktualisiert
- Status wurde von Gemeldet zu Anerkannt geändert
Von Ronald Loyko vor mehr als 4 Jahren aktualisiert
- Status wurde von Anerkannt zu In Bearbeitung geändert
- Zugewiesen an wurde auf Ronald Loyko gesetzt
Von Ronald Loyko vor mehr als 4 Jahren aktualisiert
- Status wurde von In Bearbeitung zu Abgewiesen geändert
Von Ronald Loyko vor mehr als 4 Jahren aktualisiert
Diese Methode wird aufgerufen, wenn eine geworfene Exception geloggt werden soll und wenn im Stack-Trace mehrere rekursive Aufrufe enthalten sind. Leider kann man den Context der Exception bei Sentry nicht herleiten und dementsprechend konnte ich so eine Exception nicht reproduzieren.
Von Till Tepelmann vor mehr als 4 Jahren aktualisiert
- Tracker wurde von GX-Bug zu GX-Abgewiesen geändert