Obskurer php-Bug: mail()+Referenzen => tried to allocate 6718605744721101138 bytes

3 views
Skip to first unread message

Hansjoerg Lipp

unread,
Nov 30, 2021, 4:37:33 PM11/30/21
to
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("te...@invalid.invalid", "s", "b", "From: te...@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

Karl Pflästerer

unread,
Dec 1, 2021, 12:52:37 PM12/1/21
to
Welchen Sinn haben die Varbablen, die zumindest hier im Beispiel nicht
verwendet werden?
Speziell die 2 Referenzen?

Gibt es den Fehler auch ohne diese 3 Zeilen?
Hast du Skripte, die immer laufen? (auto_prepend_file)

Hansjoerg Lipp

unread,
Dec 1, 2021, 3:44:21 PM12/1/21
to
Am 01.12.21 um 18:52 schrieb Karl Pflästerer:
> Hansjoerg Lipp <hjl...@web.de> writes:
>> <?php
>>
>> $GLOBALS['USER']=array();
>>
>> $user =& $GLOBALS['USER'];
>> $script_name =& $_SERVER['PHP_SELF'];
>>
>> if (mail("te...@invalid.invalid", "s", "b", "From: te...@invalid.invalid")) {
>> 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
>> 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

unread,
Dec 2, 2021, 9:52:06 AM12/2/21
to
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

unread,
Dec 2, 2021, 4:01:17 PM12/2/21
to
Am 02.12.21 um 15:52 schrieb Karl Pflästerer:
> Hansjoerg Lipp <hjl...@web.de> writes:
>> Auch ganz interessant ist die Tatsache, dass die höherwertigen Bytes aus
>> meiner Originalfrage
>>>> 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().

> 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...

> Ist es mod_php? php-fpm? Etwas anderes?

mod_php

Vielen Dank für die Bemühungen
Hansjörg

Karl Pflästerer

unread,
Dec 2, 2021, 5:10:46 PM12/2/21
to
Hansjoerg Lipp <hjl...@web.de> writes:

> Am 02.12.21 um 15:52 schrieb Karl Pflästerer:
>> Hansjoerg Lipp <hjl...@web.de> writes:
>>> Auch ganz interessant ist die Tatsache, dass die höherwertigen Bytes aus
>>> meiner Originalfrage
>>>>> 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

unread,
Dec 2, 2021, 5:30:52 PM12/2/21
to
Am 02.12.21 um 23:10 schrieb 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

unread,
Dec 3, 2021, 8:14:51 AM12/3/21
to
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

Hansjoerg Lipp

unread,
Dec 3, 2021, 10:09:38 AM12/3/21
to
Am 03.12.21 um 14:14 schrieb Karl Pflästerer:
> Hast du diese Werte alle geprüft?
>
> https://www.php.net/manual/en/mail.configuration.php

Ja.
> 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

Ist nicht gesetzt.

Vielen Dank für den Input, es wäre wirklich schön, wenn ich nur etwas
übersehen hätte...

Viele Grüße
Hansjörg

Karl Pflästerer

unread,
Dec 3, 2021, 11:02:23 AM12/3/21
to
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

Arno Welzel

unread,
Dec 4, 2021, 6:44:36 PM12/4/21
to
Hansjoerg Lipp:

[...]
> 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("te...@invalid.invalid", "s", "b", "From: te...@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?).

Was sagt den phpinfo() zur Umgebung?

> 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

unread,
Dec 9, 2021, 5:31:25 PM12/9/21
to
Am 05.12.21 um 00:44 schrieb Arno Welzel:
> 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)...

>> 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

Hansjoerg Lipp

unread,
Dec 9, 2021, 5:54:34 PM12/9/21
to
Entschuldige bitte die späte Antwort, es ist gerade recht stressig hier.

Am 03.12.21 um 17:02 schrieb 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.

> 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.

> Wenn es mod_php ist; welches Aapche MPM ist im Einsatz?

Wenn ich es richtig sehe, mpm-itk.

> 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

Arno Welzel

unread,
Dec 10, 2021, 12:15:40 PM12/10/21
to
Hansjoerg Lipp:

> Am 05.12.21 um 00:44 schrieb Arno Welzel:
>> 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?

[...]
>> 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...

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.

> 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:
[...]

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.

Karl Pflästerer

unread,
Dec 10, 2021, 4:15:19 PM12/10/21
to
Hansjoerg Lipp <hjl...@web.de> writes:

> Entschuldige bitte die späte Antwort, es ist gerade recht stressig hier.
>
> Am 03.12.21 um 17:02 schrieb 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.
>
>> 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.


>> 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 :-)

>
>> 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

Arno Welzel

unread,
Dec 10, 2021, 6:03:06 PM12/10/21
to
Hansjoerg Lipp:

> Entschuldige bitte die späte Antwort, es ist gerade recht stressig hier.
>
> Am 03.12.21 um 17:02 schrieb 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.

>> 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.

Hansjoerg Lipp

unread,
Dec 12, 2021, 10:01:27 PM12/12/21
to
[ Sorry für die folgende "Rechtschreibschwäche", ich bin etwas müde... ]

Am 10.12.21 um 22:15 schrieb Karl Pflästerer:
> Hansjoerg Lipp <hjl...@web.de> writes:
>>
>> 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:-/

> 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.

> 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

Hansjoerg Lipp

unread,
Dec 12, 2021, 10:48:16 PM12/12/21
to
Am 10.12.21 um 18:15 schrieb Arno Welzel:
> 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.

>> 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...
>
> 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!

>> 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:
> [...]
>
> 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

unread,
Dec 13, 2021, 7:51:46 AM12/13/21
to
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
> 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?

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.

> 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.

Hansjoerg Lipp

unread,
Dec 14, 2021, 3:06:53 PM12/14/21
to
Am 13.12.21 um 13:51 schrieb 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

unread,
Dec 15, 2021, 9:43:21 AM12/15/21
to
Hansjoerg Lipp:

> Am 13.12.21 um 13:51 schrieb 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?
Reply all
Reply to author
Forward
0 new messages