Discussion:
Obskurer php-Bug: mail()+Referenzen => tried to allocate 6718605744721101138 bytes
(zu alt für eine Antwort)
Hansjoerg Lipp
2021-11-30 21:37:30 UTC
Permalink
Hallo miteinander,

ich versuche gerade verzweifelt einen Bug in einem Script zu verstehen:
Mehrere php-Scripte brechen manchmal mit Status 500 ab, wenn diese mit
mail() eine Mail versenden sollen. Im Log steht dann etwas wie
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 2336086652788670802 bytes)
Das ganze passiert bei einem Hoster unter php 7.4. Auf meiner lokalen
Testumgebung kann ich das Problem nicht reproduzieren. Einfache Scripte,
die mail() aufrufen, funktionieren aber auch beim Hoster einwandfrei.

Ich habe also eines der betroffenen Scripte nach und nach verkleinert,
inklusive 3rd-Party-Geraffel und komme zu folgendem Minimalbeispiel:

-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
<?php

$GLOBALS['USER']=array();

$user =& $GLOBALS['USER'];
$script_name =& $_SERVER['PHP_SELF'];

if (mail("***@invalid.invalid", "s", "b", "From: ***@invalid.invalid")) {
trigger_error("<-1->", E_USER_WARNING);
}
trigger_error("<-2->", E_USER_WARNING);

?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>test mail</title>
</head>
<body>
ok
</body>
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

Dieses Script reproduziert den Fehler zuverlässig, allerdings mit der
weiteren Merkwürdigkeit, dass es beim ersten Aufruf fehlerfrei
funktioniert, um dann bei allen folgenden Aufrufen abzustürzen (hängt
das mit OPCache zusammen?).

Der Fehler tritt nur auf, wenn mindestens die beiden enthaltenen
Referenzen vorkommen. Ersetzt man allerdings z.B. die Referenz auf
$_SERVER['PHP_SELF'] durch eine auf ein anderes Element von $GLOBALS,
verschwindet der Bug.

Eine weitere Auffälligkeit: Die Größe des Speicherbereichs, den mail()
allozieren möchte, variiert - allerdings nicht in den niederen 32 Bits:
beispielsweise
2338326353679483218 = 0x2073676e00000152
7526676551241302354 = 0x6874207200000152
139835545223506 = 0x00007f2e00000152
7308304393684648274 = 0x656c502000000152
6718605744721101138 = 0x5d3d485400000152

Hat jemand von Euch so etwas schon mal gesehen? Ist das ein bekannter
php-Bug? Hat da der Hoster etwas komisches reingepatcht? Hat jemand eine
Idee, wie das Problem zu lösen ist? In welche Richtung könnte ich den
Hoster eventuell schubsen, falls er nichts konstruktives zuwege bringen
sollte?

Viele Grüße
Hansjörg
Hansjoerg Lipp
2021-12-01 20:44:19 UTC
Permalink
Post by Hansjoerg Lipp
<?php
$GLOBALS['USER']=array();
$user =& $GLOBALS['USER'];
$script_name =& $_SERVER['PHP_SELF'];
trigger_error("<-1->", E_USER_WARNING);
}
Welchen Sinn haben die Varbablen, die zumindest hier im Beispiel nicht
verwendet werden?
Speziell die 2 Referenzen?
Sie dienen hier nur dazu, den Fehler auszulösen. Im realen System sind
die Referenzen in den tiefen irgendwelcher Klassen irgendwelcher
3rd-Party-Scripts enthalten. Die würde ich ungern ändern, weil das sonst
in Zukunft ein Wartungs-Albtraum werden dürfte.
Gibt es den Fehler auch ohne diese 3 Zeilen?
Nein, das ist ja das bizarre. Lässt man eine der beiden Referenzen weg,
tritt der Fehler schon nicht mehr auf. Auch ist beispielsweise

$GLOBALS['USER']=array();
$GLOBALS['TEST']=array();

$user =& $GLOBALS['USER'];
$test =& $GLOBALS['TEST'];

wieder okay (mit weggelassenem $script_name =& $_SERVER['PHP_SELF'];).
Hast du Skripte, die immer laufen? (auto_prepend_file)
Nein.

Auch ganz interessant ist die Tatsache, dass die höherwertigen Bytes aus
meiner Originalfrage
Post by Hansjoerg Lipp
2338326353679483218 = 0x2073676e00000152
7526676551241302354 = 0x6874207200000152
139835545223506 = 0x00007f2e00000152
7308304393684648274 = 0x656c502000000152
6718605744721101138 = 0x5d3d485400000152
ASCII-Daten zu sein scheinen. Spricht wohl für ein Problem in der
Speicherverwaltung oder aber zumindest dafür, dass ein 64-Bit-Zugriff
auf eine 32-Bit-Variable erfolgt. Und wie gesagt, erst ab dem zweiten
Zugriff, was ich mir mit OPCache zu erklären versuche...

Viele Grüße
Hansjörg
Karl Pflästerer
2021-12-02 14:52:03 UTC
Permalink
Post by Hansjoerg Lipp
Post by Hansjoerg Lipp
<?php
$GLOBALS['USER']=array();
$user =& $GLOBALS['USER'];
$script_name =& $_SERVER['PHP_SELF'];
trigger_error("<-1->", E_USER_WARNING);
}
Welchen Sinn haben die Varbablen, die zumindest hier im Beispiel nicht
verwendet werden?
Speziell die 2 Referenzen?
Sie dienen hier nur dazu, den Fehler auszulösen. Im realen System sind
die Referenzen in den tiefen irgendwelcher Klassen irgendwelcher
3rd-Party-Scripts enthalten. Die würde ich ungern ändern, weil das sonst
in Zukunft ein Wartungs-Albtraum werden dürfte.
Gibt es den Fehler auch ohne diese 3 Zeilen?
Nein, das ist ja das bizarre. Lässt man eine der beiden Referenzen weg,
tritt der Fehler schon nicht mehr auf. Auch ist beispielsweise
$GLOBALS['USER']=array();
$GLOBALS['TEST']=array();
$user =& $GLOBALS['USER'];
$test =& $GLOBALS['TEST'];
wieder okay (mit weggelassenem $script_name =& $_SERVER['PHP_SELF'];).
Hast du Skripte, die immer laufen? (auto_prepend_file)
Nein.
Auch ganz interessant ist die Tatsache, dass die höherwertigen Bytes aus
meiner Originalfrage
Post by Hansjoerg Lipp
2338326353679483218 = 0x2073676e00000152
7526676551241302354 = 0x6874207200000152
139835545223506 = 0x00007f2e00000152
7308304393684648274 = 0x656c502000000152
6718605744721101138 = 0x5d3d485400000152
ASCII-Daten zu sein scheinen. Spricht wohl für ein Problem in der
Speicherverwaltung oder aber zumindest dafür, dass ein 64-Bit-Zugriff
auf eine 32-Bit-Variable erfolgt. Und wie gesagt, erst ab dem zweiten
Zugriff, was ich mir mit OPCache zu erklären versuche...
Um ehrlich zu sein, das bezweifle ich. Das ist kein PHP bug.
Tritt der Fehler nur auf, wenn ein Fehler geloggt wird?
Ist vielleicht ein custom error Handler hinterlegt? Wenn dieser error
handler einige Variablen ausgibt, durch die Referenz aber in eine
Endlosschleife rennt, geht irgendwann der Speicher aus.

Ist es mod_php? php-fpm? Etwas anderes?

KP
Hansjoerg Lipp
2021-12-02 21:01:14 UTC
Permalink
Post by Karl Pflästerer
Post by Hansjoerg Lipp
Auch ganz interessant ist die Tatsache, dass die höherwertigen Bytes aus
meiner Originalfrage
Post by Hansjoerg Lipp
2338326353679483218 = 0x2073676e00000152
7526676551241302354 = 0x6874207200000152
139835545223506 = 0x00007f2e00000152
7308304393684648274 = 0x656c502000000152
6718605744721101138 = 0x5d3d485400000152
ASCII-Daten zu sein scheinen. Spricht wohl für ein Problem in der
Speicherverwaltung oder aber zumindest dafür, dass ein 64-Bit-Zugriff
auf eine 32-Bit-Variable erfolgt. Und wie gesagt, erst ab dem zweiten
Zugriff, was ich mir mit OPCache zu erklären versuche...
Um ehrlich zu sein, das bezweifle ich. Das ist kein PHP bug.
Tritt der Fehler nur auf, wenn ein Fehler geloggt wird?
Nein, der Fehler tritt wohl in mail() auf, es gibt den 500-er-Status mit
der Meldung über die fehlgeschlagene Speicherreservierung von um die
2^64 Bytes, die Zeilen danach werden nicht erreicht. Tritt der Fehler
nicht auf, weil z.B. die Referenzen weggelassen werden, kommt es dagegen
zu den zu erwartenden Log-Ausgaben über trigger_error().
Post by Karl Pflästerer
Ist vielleicht ein custom error Handler hinterlegt?
Nein. In der Tat ist die Konfiguration sehr übersichtlich, weil es hier
um ein Shared-Hosting-Paket geht, wo man nur über .htaccess und ein sehr
rudimentäres Web-Interface einige Einstellungen vornehmen kann.

Das ist auch die Hintergrund meiner Frage hier, im Grunde habe ich meine
Möglichkeiten zum Debuggen ausgeschöpft, bin mir aber noch nicht sicher,
ob mein Hoster sich viel Mühe machen wird bei diesem Informationsstand:

Ich habe bei der Kommunikation mir dem Support einerseits die Erfahrung
gemacht, dass es zu einer schnellen Problembehebung kommt, wenn ich
schreibe "Ich habe Problem A, vermutlich ist es Bug
https://bugs.php.net/bug.php?id=XXXX, könnt Ihr Euch Commit
http://git.php.net/?YYYY ansehen?". Komme ich dagegen mit "Seit Eurem
Systemupdate passiert nicht mehr A sondern B, macht das weg.", gibt es
erst die sich im Kreis drehende Diskussion, dass natürlich A geht, und
dann nach dem Zeigen des Beispielcodes "A ist überbewertet, wir ändern
doch nicht die Apache-Konfiguration, kauf Dir halt den teureren
Root-Server." Insofern hoffe ich darauf, dass dieses komische Verhalten
irgendjemandem was sagen könnte...
Post by Karl Pflästerer
Ist es mod_php? php-fpm? Etwas anderes?
mod_php

Vielen Dank für die Bemühungen
Hansjörg
Karl Pflästerer
2021-12-02 22:10:45 UTC
Permalink
Post by Hansjoerg Lipp
Post by Karl Pflästerer
Post by Hansjoerg Lipp
Auch ganz interessant ist die Tatsache, dass die höherwertigen Bytes aus
meiner Originalfrage
Post by Hansjoerg Lipp
2338326353679483218 = 0x2073676e00000152
7526676551241302354 = 0x6874207200000152
139835545223506 = 0x00007f2e00000152
7308304393684648274 = 0x656c502000000152
6718605744721101138 = 0x5d3d485400000152
ASCII-Daten zu sein scheinen. Spricht wohl für ein Problem in der
Speicherverwaltung oder aber zumindest dafür, dass ein 64-Bit-Zugriff
auf eine 32-Bit-Variable erfolgt. Und wie gesagt, erst ab dem zweiten
Zugriff, was ich mir mit OPCache zu erklären versuche...
Um ehrlich zu sein, das bezweifle ich. Das ist kein PHP bug.
Tritt der Fehler nur auf, wenn ein Fehler geloggt wird?
Nein, der Fehler tritt wohl in mail() auf, es gibt den 500-er-Status mit
der Meldung über die fehlgeschlagene Speicherreservierung von um die
2^64 Bytes, die Zeilen danach werden nicht erreicht. Tritt der Fehler
nicht auf, weil z.B. die Referenzen weggelassen werden, kommt es dagegen
zu den zu erwartenden Log-Ausgaben über trigger_error().
Dann genügte als Minimalbeispiel der mail() Aufruf mit den Variablen.
Hast du das getestet?


KP
Hansjoerg Lipp
2021-12-02 22:30:51 UTC
Permalink
Post by Karl Pflästerer
Dann genügte als Minimalbeispiel der mail() Aufruf mit den Variablen.
Hast du das getestet?
Ja, gerade noch einmal getestet, extra in einem neuen Verzeichnis ohne
.htaccess etc. Der erste Aufruf resultiert in einer Mail, ab dem zweiten
Aufruf gibt es den Fehler. Diesmal wieder mit 139835545223506 =
0x7f2e00000152 Bytes...

Viele Grüße
Hansjörg
Karl Pflästerer
2021-12-03 13:14:49 UTC
Permalink
Post by Hansjoerg Lipp
Post by Karl Pflästerer
Dann genügte als Minimalbeispiel der mail() Aufruf mit den Variablen.
Hast du das getestet?
Ja, gerade noch einmal getestet, extra in einem neuen Verzeichnis ohne
.htaccess etc. Der erste Aufruf resultiert in einer Mail, ab dem zweiten
Aufruf gibt es den Fehler. Diesmal wieder mit 139835545223506 =
0x7f2e00000152 Bytes...
Hast du diese Werte alle geprüft?

https://www.php.net/manual/en/mail.configuration.php


Spannend ist vielleicht:

mail.log string

The path to a log file that will log all mail() calls. Log entries include the full path of the script, line number, To address and headers.


Da du eine Referenz zum Scriptname hast. Eventuell knallt es an dieser
Stelle


KP
Karl Pflästerer
2021-12-03 16:02:21 UTC
Permalink
Post by Karl Pflästerer
Hast du diese Werte alle geprüft?
https://www.php.net/manual/en/mail.configuration.php
Ja.
Post by Karl Pflästerer
mail.log string
The path to a log file that will log all mail() calls. Log entries include the full path of the script, line number, To address and headers.
Da du eine Referenz zum Scriptname hast. Eventuell knallt es an dieser
Stelle
Ist nicht gesetzt.
Vielen Dank für den Input, es wäre wirklich schön, wenn ich nur etwas
übersehen hätte...
Hast du bestimmt. Die Funktion mail() gibt es schon ziemlich lange und
ich gehe davon aus, dass es nicht die seltenst genutzte PHP Funktion
ist. Referenzen (auch so seltsame wie in deinem beispiel; wer macht
so etwas und warum?) gibt es auch schon lange in PHP und auch
Entwickler, die sehr kreativ werden.

Ist es denn eine bestimme Referenz? Oder jede Referenz? Irgendwo werden
diese Daten verarbeitet (vielleicht hat dein Hoster irgendetwas
definiert). Die Definition alleine (du selbst benutzt diese Variablen ja
nirgendwo), kann keinen Abbruch erzeugen.

Wenn es mod_php ist; welches Aapche MPM ist im Einsatz? Wenn du das
weißt, könntest du das Environment mit Docker leicht nachbauen

KP
Hansjoerg Lipp
2021-12-09 22:54:32 UTC
Permalink
Entschuldige bitte die späte Antwort, es ist gerade recht stressig hier.
Post by Karl Pflästerer
Ist es denn eine bestimme Referenz? Oder jede Referenz? Irgendwo werden
diese Daten verarbeitet (vielleicht hat dein Hoster irgendetwas
definiert).
Es sind bestimmte Kombinationen von Referenzen, die den Bug triggern,
andere tun es nicht. Ich kann kein Muster erkennen.
Post by Karl Pflästerer
Die Definition alleine (du selbst benutzt diese Variablen ja
nirgendwo), kann keinen Abbruch erzeugen.
Ein möglicher Mechanismus wäre folgender: In mail() wird eine 32-Bit
Variable, die den Speicherbedarf enthält, mit einem 64-Bit-Zugriff
gelesen. Ob dies zu einem Fehler führt, hängt nun davon ab, ob der
Speicherbereich nach dieser Variable nur Nullen enthält. In diesem Fall
ist alles in Ordnung. Unter manchen Umständen sind dort aber nicht nur
Nullen; manchmal liegen da z.B. ASCII-Daten (siehe OP); dann geschieht
der Fehler. Ich weiß nicht, wie php intern funktioniert. Ich könnte
spekulieren, dass für String-Variablen genullter Speicher in gewissen
Größenabstufungen angefordert wird, der dann mit dem String gefüllt
wird. Dann ist je nach String-Variable hinten String-Inhalt oder eben
nur Nullen. Vielleicht liegt die 32-Bit-Variable an einer Stelle im
Speicher, an der zuvor eine String-Variable lag? Vielleicht wird mit
OPCache Speicher nicht genullt? Spekulationen sind hier leider müßig,
solange ich kein System habe, auf dem ich das Problem reproduzieren kann.
Post by Karl Pflästerer
Wenn es mod_php ist; welches Aapche MPM ist im Einsatz?
Wenn ich es richtig sehe, mpm-itk.
Post by Karl Pflästerer
Wenn du das weißt, könntest du das Environment mit Docker leicht nachbauen
Ich denke, es gibt kaum eine Komponente, wo der Hoster nichts
dazugepatcht hat. Zumindest sehen die Versionsnummern danach aus. Mit
out of the box php + Apache auf einem 08/15-Linux tritt der Fehler
leider nicht auf...

Viele Grüße
Hansjörg
Karl Pflästerer
2021-12-10 21:15:17 UTC
Permalink
Post by Hansjoerg Lipp
Entschuldige bitte die späte Antwort, es ist gerade recht stressig hier.
Post by Karl Pflästerer
Ist es denn eine bestimme Referenz? Oder jede Referenz? Irgendwo werden
diese Daten verarbeitet (vielleicht hat dein Hoster irgendetwas
definiert).
Es sind bestimmte Kombinationen von Referenzen, die den Bug triggern,
andere tun es nicht. Ich kann kein Muster erkennen.
Post by Karl Pflästerer
Die Definition alleine (du selbst benutzt diese Variablen ja
nirgendwo), kann keinen Abbruch erzeugen.
Ein möglicher Mechanismus wäre folgender: In mail() wird eine 32-Bit
Variable, die den Speicherbedarf enthält, mit einem 64-Bit-Zugriff
gelesen. Ob dies zu einem Fehler führt, hängt nun davon ab, ob der
Speicherbereich nach dieser Variable nur Nullen enthält. In diesem Fall
ist alles in Ordnung. Unter manchen Umständen sind dort aber nicht nur
Nullen; manchmal liegen da z.B. ASCII-Daten (siehe OP); dann geschieht
der Fehler. Ich weiß nicht, wie php intern funktioniert. Ich könnte
spekulieren, dass für String-Variablen genullter Speicher in gewissen
Größenabstufungen angefordert wird, der dann mit dem String gefüllt
wird. Dann ist je nach String-Variable hinten String-Inhalt oder eben
nur Nullen. Vielleicht liegt die 32-Bit-Variable an einer Stelle im
Speicher, an der zuvor eine String-Variable lag? Vielleicht wird mit
OPCache Speicher nicht genullt? Spekulationen sind hier leider müßig,
solange ich kein System habe, auf dem ich das Problem reproduzieren kann.
Sei mir nicht böse, aber obiges erscheint mir extrem spekulativ. Wie
kommst du darauf, dass auf dem Host irgendetwas nicht für 64bit
kompiliert ist? Im Serverbereich hat man (zumindest unter linux) schon
seit vielen Jahren nur 64bit Systeme.

Wenn ein Prozess auf Speicherbereiche zugreift, die ihm nicht geören
erwarte ich eine segfault, nicht eine ordentliche Fehlermeldung.
Post by Hansjoerg Lipp
Post by Karl Pflästerer
Wenn es mod_php ist; welches Aapche MPM ist im Einsatz?
Wenn ich es richtig sehe, mpm-itk.
Ein nicht standard MPM; letzte Änderung 2016. Beste Voraussetzungen, das
alles klappt :-)
Post by Hansjoerg Lipp
Post by Karl Pflästerer
Wenn du das weißt, könntest du das Environment mit Docker leicht nachbauen
Ich denke, es gibt kaum eine Komponente, wo der Hoster nichts
dazugepatcht hat. Zumindest sehen die Versionsnummern danach aus. Mit
out of the box php + Apache auf einem 08/15-Linux tritt der Fehler
leider nicht auf...
Dann wird es an diesem Environment luegen und nicht an PHP.
Hoster wechseln.

KP
Hansjoerg Lipp
2021-12-13 03:01:24 UTC
Permalink
[ Sorry für die folgende "Rechtschreibschwäche", ich bin etwas müde... ]
Post by Karl Pflästerer
Post by Hansjoerg Lipp
Ein möglicher Mechanismus wäre folgender: In mail() wird eine 32-Bit
Variable, die den Speicherbedarf enthält, mit einem 64-Bit-Zugriff
gelesen. Ob dies zu einem Fehler führt, hängt nun davon ab, ob der
Speicherbereich nach dieser Variable nur Nullen enthält. In diesem Fall
ist alles in Ordnung. Unter manchen Umständen sind dort aber nicht nur
Nullen; manchmal liegen da z.B. ASCII-Daten (siehe OP); dann geschieht
der Fehler. Ich weiß nicht, wie php intern funktioniert. Ich könnte
spekulieren, dass für String-Variablen genullter Speicher in gewissen
Größenabstufungen angefordert wird, der dann mit dem String gefüllt
wird. Dann ist je nach String-Variable hinten String-Inhalt oder eben
nur Nullen. Vielleicht liegt die 32-Bit-Variable an einer Stelle im
Speicher, an der zuvor eine String-Variable lag? Vielleicht wird mit
OPCache Speicher nicht genullt? Spekulationen sind hier leider müßig,
solange ich kein System habe, auf dem ich das Problem reproduzieren kann.
Sei mir nicht böse, aber obiges erscheint mir extrem spekulativ. Wie
kommst du darauf, dass auf dem Host irgendetwas nicht für 64bit
kompiliert ist? Im Serverbereich hat man (zumindest unter linux) schon
seit vielen Jahren nur 64bit Systeme.
Dass die Details spekulativ sind, schrieb ich ja. Dass diese Art von
Fehlern bei "systemnäherer" Programmierung vorkommt, ist dagegen
gar nicht so selten (bei Projekten, in denen gerne mal die
Compilerwarnungen heruntergedreht werden oder so zahlreich sind, dass
sie ignoriert werden).

Es geht hierbei nicht darum, dass etwas nicht für eine 64-Bit-Platform
compiliert ist, sondern um die Datentypen der Variablen. Hier wird die
Größe des angeforderten Speichers in einer 64-Bit-Variable hinterlegt
(size_t, siehe zend_mm_alloc_huge oder zend_mm_realloc_huge). Wenn jetzt
irgendwo in mail() oder irgendetwas dazugepatchtem (oder entsprechend in
irgendwelchen Stringfunktionen) die Größe erst mal in einer unsigned
32-Bit-Variable liegt, die man als Pointer kreuz und quer über
Funktionsaufrufe herumschickt, passieren solche Dinge.

Wenn man sich alle Log-Ausgaben ansieht, hat im Fehlerfall die Größe des
angeforderten Speichers (Parameter size_t size von
zend_mm_{re]alloc_huge()) immer Werte der Art

0x2073676e00000152
0x6874207200000152
0x00007f2e00000152
0x656c502000000152
0x5d3d485400000152

Die niederen 32 Bits sind also immer plausibel, die höherwertigen 32
Bits müssen dagegen 0 sein, sind es aber nicht. Diese enthalten
irgendwelchen Datenmüll, meist ASCII-Daten. Dafür gibt es zwei mögliche
Erklärungen:

1. Die oberen 32 Bits wurden nach Berechnung der gewünschten
Speichergröße überschrieben, durch fehlerhafte Pointer,
Probleme in der Speicherverwaltung, ...
2. Die oberen 32 Bits wurden nie initialisiert.

Ich tippe auf 2., weil das auch erklären könnte, warum ohne OPCache kein
Fehler auftritt, wenn man spekuliert, dass in diesem Fall frischer
Speicher genullt wird. Meiner Erfahrung nach führen Fehler der 1. Art
auch ohnehin zu so großen Problemen, dass die Symptome viel auffälliger
sein müssten.

Also mal als Semi-Pseudo-Code:

struct spezial_struct {
char *spezial_string_des_hosters;
size_t size;
};

void berechne_platzbedarf(unsigned *size)
{
*size = 42;
}

PHP_FUNCTION(mail)
{
....
struct spezial_struct *sp = spezial_alloc(sizeof *sp);
berechne_platzbedarf(&sp->size);
sp->spezial_string_des_hosters = zend_mm_alloc_huge(..., sp->size);
....
}

Hier werden in berechne_platzbedarf() die unteren 32 Bits von sp->size
gesetzt, die oberen sind dagegen unverändert die, die spezial_alloc()
zurückgegeben hat. Das Ergebnis bekommt dann zend_mm_alloc_huge() als
Parameter. Wurde der Speicher in spezial_alloc() genullt, ist das kein
Problem, anderenfalls wird ein sehr großer Speicherbereich angefordert.

Es gibt schon einige plausible Szenarien, nur werde ich das ohne den
Quelltext nicht lösen können. Ist ja auch eigentlich nicht meine Aufgabe:-/
Post by Karl Pflästerer
Wenn ein Prozess auf Speicherbereiche zugreift, die ihm nicht geören
erwarte ich eine segfault, nicht eine ordentliche Fehlermeldung.
Innerhalb des Prozesses nicht. Und bei der 2. Möglichkeit passiert ja
auch nicht mal das.
Post by Karl Pflästerer
Dann wird es an diesem Environment luegen und nicht an PHP.
Hoster wechseln.
Wenn ich gerade nicht so viel anderes zu tun hätte, wäre ich so langsam
tatsächlich genervt genug... Das war aber halt vor gefühlt 100 Jahren
anders, da hat alles ordentlich funktioniert, und der gelegentliche
PHP-Bug wurde auf einen Hinweis hin gepatcht...

Viele Grüße
Hansjörg
Arno Welzel
2021-12-10 23:03:04 UTC
Permalink
Post by Hansjoerg Lipp
Entschuldige bitte die späte Antwort, es ist gerade recht stressig hier.
[...]
Post by Hansjoerg Lipp
Post by Karl Pflästerer
Wenn es mod_php ist; welches Aapche MPM ist im Einsatz?
Wenn ich es richtig sehe, mpm-itk.
Davon rate ich ab. mpm-itk basiert auf mpm-prefork, was
performance-mäßig absolut nicht sinnvoll ist. Zudem ist von 2016(!).
Siehe auch <http://mpm-itk.sesse.net>.

Die saubere Lösung statt der Bastelei mit PHP als Apache-Modul und
mpm-itk wäre PHP als FPM mit einem eigenen Pool für die Website und *da*
den User einstellen, mit dem PHP laufen soll und das über fcgi
einbinden. Apache dann mit mpm-worker.
Post by Hansjoerg Lipp
Post by Karl Pflästerer
Wenn du das weißt, könntest du das Environment mit Docker leicht nachbauen
Ich denke, es gibt kaum eine Komponente, wo der Hoster nichts
dazugepatcht hat. Zumindest sehen die Versionsnummern danach aus. Mit
out of the box php + Apache auf einem 08/15-Linux tritt der Fehler
leider nicht auf...
Ja - weil "out of the box" auch nicht so eine Kombination verwendet wird.
--
Arno Welzel
https://arnowelzel.de
Arno Welzel
2021-12-04 23:44:33 UTC
Permalink
Hansjoerg Lipp:

[...]
Post by Hansjoerg Lipp
Ich habe also eines der betroffenen Scripte nach und nach verkleinert,
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
<?php
$GLOBALS['USER']=array();
$user =& $GLOBALS['USER'];
$script_name =& $_SERVER['PHP_SELF'];
trigger_error("<-1->", E_USER_WARNING);
}
trigger_error("<-2->", E_USER_WARNING);
?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>test mail</title>
</head>
<body>
ok
</body>
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
Dieses Script reproduziert den Fehler zuverlässig, allerdings mit der
weiteren Merkwürdigkeit, dass es beim ersten Aufruf fehlerfrei
funktioniert, um dann bei allen folgenden Aufrufen abzustürzen (hängt
das mit OPCache zusammen?).
Was sagt den phpinfo() zur Umgebung?
Post by Hansjoerg Lipp
Hat jemand von Euch so etwas schon mal gesehen? Ist das ein bekannter
php-Bug? Hat da der Hoster etwas komisches reingepatcht? Hat jemand eine
Idee, wie das Problem zu lösen ist? In welche Richtung könnte ich den
Hoster eventuell schubsen, falls er nichts konstruktives zuwege bringen
sollte?
Sorry, nein. Ich habe sowas noch nie gesehen. Aber ohne konkrete Angabe,
was da genau seitens des Hosters läuft, ist es auch schwer, eine
konkretere Aussage zu machen.
--
Arno Welzel
https://arnowelzel.de
Hansjoerg Lipp
2021-12-09 22:31:22 UTC
Permalink
Post by Arno Welzel
Post by Hansjoerg Lipp
Dieses Script reproduziert den Fehler zuverlässig, allerdings mit der
weiteren Merkwürdigkeit, dass es beim ersten Aufruf fehlerfrei
funktioniert, um dann bei allen folgenden Aufrufen abzustürzen (hängt
das mit OPCache zusammen?).
Was sagt den phpinfo() zur Umgebung?
Weil das alles ein bisschen viel wäre und ich mir nicht sicher bin, was
alles interessant sein könnte, habe ich den phpinfo()-Output nach
https://controlc.com/6809ee19
hochgeladen (pastebin wollte nicht, da meine phpinfo anscheinend
offensive Sprache enthält). Dies und die leichte Zensur darin dient der
Verschleierung des Hosters, falls mir im laufe dieses Threads doch noch
die Hutschnur platzen sollte bezüglich der Kommunikation mit dem Support
dort (de.alt.talk.unmut.support wäre aktuell *sehr* nötig)...
Post by Arno Welzel
Post by Hansjoerg Lipp
Hat jemand von Euch so etwas schon mal gesehen? Ist das ein bekannter
php-Bug? Hat da der Hoster etwas komisches reingepatcht? Hat jemand eine
Idee, wie das Problem zu lösen ist? In welche Richtung könnte ich den
Hoster eventuell schubsen, falls er nichts konstruktives zuwege bringen
sollte?
Sorry, nein. Ich habe sowas noch nie gesehen. Aber ohne konkrete Angabe,
was da genau seitens des Hosters läuft, ist es auch schwer, eine
konkretere Aussage zu machen.
OPCache scheint jedenfalls eine wichtige Rolle zu spielen: Folgende zwei
Methoden unterdrücken den Bug zuverlässig:

1) .htaccess: php_flag opcache.enable Off
2) im Script: opcache_invalidate(__FILE__, true);

Hat hier jemand Erfahrung oder gar schon mal gemessen, wieviel
Performance OPCache in der Regel bringt? Bei der Erfahrung mit dem
Hoster tendiere ich nämlich tatsächlich zum globalen Ausschalten...

OT: Hat hier jemand Erfahrung, wie man Kommunikation mit einem Hoster
effizienter gestaltet? Wenn ich nicht genau den php-Bug o.Ä. benennen
kann, läuft das bei mir in der Regel so:

1a) Ich schicke aufwendig recherchierte und doppelt und dreifach
abgesicherte detaillierte Problembeschreibung mit Minimalbeispiel.
1b) Antwort: Vielen Dank für die nette Frage! Wenn Sie im Web-Interface
auf Transmogrify gehen wird das HTML viel bunter. Ich habe das mal für
Sie eingestellt!

2a) Ich: Es liegt nicht an dieser Einstellung, das Problem besteht
weiterhin, darf ich bitte mit einem Techniker kommunizieren?
Wiederholung von 1a in einfachen Worten.
2b) Support: Wir leiten weiter zu den Technikern!
2c) Techniker: Ich habe das Testskript im Browser gestartet, im Log ist
eine Fehlermeldung, Ihr Script ist falsch!

3a) Ich: Genau, das Log zeigt Fehler wegen A, B, C, außerdem sind, wie
schon in 1a) und 2a) geschrieben zum Reproduzieren die Schritte x, y, z
nötig.
3b) Support: Wir leiten weiter zu den Technikern!
Fallunterscheidung:
3c1) Techniker: Oh, tatsächlich. Als Workaround ginge das deaktivieren
von Server-Feature a oder b. Aber es liegt nicht am Server, Ihr Skript
macht alles kaputt! Ein serverseitiges Problem kann nicht existieren!
3c2) Techniker: Wir wollen unsere Konfiguration nicht ändern, gehen Sie weg!

Das Kommunikationsproblem geht hier weiter als in https://xkcd.com/806/
In meinem Umfeld wäre die Reaktion auf Probleme dieser Art irgendwo
zwischen "Oh wow, faszinierendes Problem, mal schauen ob ich das
debuggen kann" und "schönes Problem, leider keine Zeit, versuchen wir
Workaround a oder b". Dieses Abstreiten von offensichtlichen Problemen
will mir nicht in den Kopf. Ist manchmal im Firmenumfeld das wegschieben
von Verantwortung ein Motiv? Ist es juristisch schwierig ein Problem
einzuräumen?

Managed hosting kann soo mühsam sein, aber noch ein System vollständig
zu administrieren kann ich leider nicht leisten...:-/

Danke fürs Zuhören und die Therapiestunde;-)
Hansjörg
Arno Welzel
2021-12-10 17:15:38 UTC
Permalink
Post by Hansjoerg Lipp
Post by Arno Welzel
Post by Hansjoerg Lipp
Dieses Script reproduziert den Fehler zuverlässig, allerdings mit der
weiteren Merkwürdigkeit, dass es beim ersten Aufruf fehlerfrei
funktioniert, um dann bei allen folgenden Aufrufen abzustürzen (hängt
das mit OPCache zusammen?).
Was sagt den phpinfo() zur Umgebung?
Weil das alles ein bisschen viel wäre und ich mir nicht sicher bin, was
alles interessant sein könnte, habe ich den phpinfo()-Output nach
https://controlc.com/6809ee19
hochgeladen (pastebin wollte nicht, da meine phpinfo anscheinend
offensive Sprache enthält). Dies und die leichte Zensur darin dient der
Verschleierung des Hosters, falls mir im laufe dieses Threads doch noch
die Hutschnur platzen sollte bezüglich der Kommunikation mit dem Support
dort (de.alt.talk.unmut.support wäre aktuell *sehr* nötig)...
Auf Anhieb fällt mir da auf:

Zend Extension Build API320190902,NTS
PHP Extension Build API20190902,NTS
apache2handler

PHP läuft hier nicht als PHP-FPM sondern als non-thread-safe-Modul in
Apache. Das ist die denkbar ungünstigste Variante.

memory_limit 512M 256M

Sicher, dass die Anwendung mit 256MB auskommt?

[...]
Post by Hansjoerg Lipp
Post by Arno Welzel
Sorry, nein. Ich habe sowas noch nie gesehen. Aber ohne konkrete Angabe,
was da genau seitens des Hosters läuft, ist es auch schwer, eine
konkretere Aussage zu machen.
OPCache scheint jedenfalls eine wichtige Rolle zu spielen: Folgende zwei
1) .htaccess: php_flag opcache.enable Off
2) im Script: opcache_invalidate(__FILE__, true);
Hat hier jemand Erfahrung oder gar schon mal gemessen, wieviel
Performance OPCache in der Regel bringt? Bei der Erfahrung mit dem
Hoster tendiere ich nämlich tatsächlich zum globalen Ausschalten...
Hier bringt OPCache ca. Faktor 20-50. Denn bei *jedem* Aufruf muss ohne
OPCache das Script neu interpretiert und un OP-Codes umgewandelt werden.

Mit OPCache dauert der erste manche Anwendung Aufruf ca. 2-3 Sekunden,
danach geht es im Bereich 20-50 ms. Allerdings läuft PHP hier auch als
FPM mit statischem Prozess-Pool und nicht als Apache-Modul, was auch
noch einige Vorteile bringt.
Post by Hansjoerg Lipp
OT: Hat hier jemand Erfahrung, wie man Kommunikation mit einem Hoster
effizienter gestaltet? Wenn ich nicht genau den php-Bug o.Ä. benennen
[...]

Man sucht sich einen fähigeren Hoster. Erstmal einen, der PHP als FPM
bereitstellt und nicht als Apache-Modul. Wenn der Hoster nicht weiß, was
FPM ist oder die Frage danach damit abwiegelt, dass das nicht möglich
sei oder für Dich nicht relevant wäre - anderen Hoster suchen.

Wenn Du möchtest, kann ich Dir auch eine Testumgebung inkl. FTP etc. auf
einem meiner Server bereitstellen, nur damit Du siehst, ob es woanders
auch solche Effekt gibt - Details dann gerne per E-Mail.
--
Arno Welzel
https://arnowelzel.de
Hansjoerg Lipp
2021-12-13 03:48:14 UTC
Permalink
Post by Arno Welzel
Post by Hansjoerg Lipp
[...]
memory_limit 512M 256M
Sicher, dass die Anwendung mit 256MB auskommt?
Momentan läuft hier eher älterer Code, der auch schon mit weniger klar
kommen musste. Insofern gibt es da aktuell keine Probleme.
Post by Arno Welzel
Post by Hansjoerg Lipp
OPCache scheint jedenfalls eine wichtige Rolle zu spielen: Folgende zwei
1) .htaccess: php_flag opcache.enable Off
2) im Script: opcache_invalidate(__FILE__, true);
Hat hier jemand Erfahrung oder gar schon mal gemessen, wieviel
Performance OPCache in der Regel bringt? Bei der Erfahrung mit dem
Hoster tendiere ich nämlich tatsächlich zum globalen Ausschalten...
Hier bringt OPCache ca. Faktor 20-50. Denn bei *jedem* Aufruf muss ohne
OPCache das Script neu interpretiert und un OP-Codes umgewandelt werden.
Mit OPCache dauert der erste manche Anwendung Aufruf ca. 2-3 Sekunden,
danach geht es im Bereich 20-50 ms. Allerdings läuft PHP hier auch als
FPM mit statischem Prozess-Pool und nicht als Apache-Modul, was auch
noch einige Vorteile bringt.
Okay, dann also leider die 2. Variante, bis der Hoster in die Pötte
kommt oder ich doch wechsle...

Vielen Dank für die Werte!
Post by Arno Welzel
Post by Hansjoerg Lipp
OT: Hat hier jemand Erfahrung, wie man Kommunikation mit einem Hoster
effizienter gestaltet? Wenn ich nicht genau den php-Bug o.Ä. benennen
[...]
Man sucht sich einen fähigeren Hoster. Erstmal einen, der PHP als FPM
bereitstellt und nicht als Apache-Modul. Wenn der Hoster nicht weiß, was
FPM ist oder die Frage danach damit abwiegelt, dass das nicht möglich
sei oder für Dich nicht relevant wäre - anderen Hoster suchen.
Wenn Du möchtest, kann ich Dir auch eine Testumgebung inkl. FTP etc. auf
einem meiner Server bereitstellen, nur damit Du siehst, ob es woanders
auch solche Effekt gibt - Details dann gerne per E-Mail.
Uff:-) Das ist ein nettes Angebot. Allerdings bin ich gerade völlig
überlastet, so dass ich da eher nicht weiter debuggen werde.

Auch der hier nahegelegte Hoster-Wechsel wäre mir gerade zu viel. Wenn
es mal nächstes Jahr ruhiger wird, werde ich das wohl ernsthaft in
Erwägung ziehen. Es sind auch die Kleinigkeiten, die sich Summieren:

Anderes Beispiel bei denen: Seit php7 sind E_DEPRECATED und
E_USER_DEPRECATED nicht mehr im Log, weil der Apache fehlkonfiguriert
ist und "LogLevel php7:info" notwendig wäre. Ging früher, selbst dieses
Web-Interface hat eine Einstellung "Logging Level: Alle Meldungen (gemäß
E_ALL)". Die Diskussion mit denen lief dann im Kreis, ich müsse das
error_reporting auf E_ALL setzen. Und ich kam bis zum second level
support. Bin ich da kleinlich, wenn mich das ärgert? Ist das so üblich?

Ich habe bewusst ein Managed-Hosting-Paket, weil ich möchte, dass man
mir Arbeit abnimmt. Funktioniert nur nicht wie gedacht... Nun ja, ist
jetzt wohl auch OT.

Danke jedenfalls für den vielen Input, insbesondere zu OPCache und zur
Beurteilung des eingesetzten php-Setups - das ist ein Punkt, der dann
bei einem zukünftigen Wechsel wichtig sein wird.

Viele Grüße
Hansjörg
Arno Welzel
2021-12-13 12:51:43 UTC
Permalink
Hansjoerg Lipp:

[...]
Post by Hansjoerg Lipp
Auch der hier nahegelegte Hoster-Wechsel wäre mir gerade zu viel. Wenn
es mal nächstes Jahr ruhiger wird, werde ich das wohl ernsthaft in
Anderes Beispiel bei denen: Seit php7 sind E_DEPRECATED und
E_USER_DEPRECATED nicht mehr im Log, weil der Apache fehlkonfiguriert
ist und "LogLevel php7:info" notwendig wäre. Ging früher, selbst dieses
Web-Interface hat eine Einstellung "Logging Level: Alle Meldungen (gemäß
E_ALL)". Die Diskussion mit denen lief dann im Kreis, ich müsse das
error_reporting auf E_ALL setzen. Und ich kam bis zum second level
support. Bin ich da kleinlich, wenn mich das ärgert? Ist das so üblich?
Nein, das ist nicht so üblich. Für mich wirkt das so, als hätte da
jemand selbst nur Server bei einem großen Anbieter gemietet und spielt
jetzt "Hoster" mit selbstgebastelter Umgebung.
Post by Hansjoerg Lipp
Ich habe bewusst ein Managed-Hosting-Paket, weil ich möchte, dass man
mir Arbeit abnimmt. Funktioniert nur nicht wie gedacht... Nun ja, ist
jetzt wohl auch OT.
"Managed" bedeutet erstmal nur, dass man selber nichts machen kann, weil
das der Hoster übernimmt und dafür auch die Verantwortung trägt. Die
Qualität muss aber nicht zwangsläufig besser sein, als wenn man das
selber macht.
--
Arno Welzel
https://arnowelzel.de
Hansjoerg Lipp
2021-12-14 20:06:51 UTC
Permalink
Post by Arno Welzel
Nein, das ist nicht so üblich. Für mich wirkt das so, als hätte da
jemand selbst nur Server bei einem großen Anbieter gemietet und spielt
jetzt "Hoster" mit selbstgebastelter Umgebung.
Nur als Pointe, weil ich momentan einen ähnliche Einschätzung der
Professionalität habe: Es handelt sich tatsächlich um einen großen
bekannten "deutschen" Hoster, Urgestein quasi (wieviel nach diversen
Übernahmen noch so ist wie früher?). Deshalb ja auch die Selbstzweifel,
ob ich irgendwie im falschen Universum aufgewacht bin;-)

Also, nochmal danke euch. Schön, dass die Gruppe noch gelesen wird.

Viele Grüße
Hansjörg
Arno Welzel
2021-12-15 14:43:19 UTC
Permalink
Post by Hansjoerg Lipp
Post by Arno Welzel
Nein, das ist nicht so üblich. Für mich wirkt das so, als hätte da
jemand selbst nur Server bei einem großen Anbieter gemietet und spielt
jetzt "Hoster" mit selbstgebastelter Umgebung.
Nur als Pointe, weil ich momentan einen ähnliche Einschätzung der
Professionalität habe: Es handelt sich tatsächlich um einen großen
bekannten "deutschen" Hoster, Urgestein quasi (wieviel nach diversen
Übernahmen noch so ist wie früher?). Deshalb ja auch die Selbstzweifel,
ob ich irgendwie im falschen Universum aufgewacht bin;-)
Kann man den Namen erfahren?
--
Arno Welzel
https://arnowelzel.de
Loading...