Ein einziger Zeilenwert in der php.ini entscheidet aktuell darüber, ob Entwickler ihre eigenen Fehler sehen oder nicht: error_reporting=0. Genau dieser Standardwert sorgte in den Beta-Versionen und in RC2 von PHP 8.6 dafür, dass innerhalb von Fibers sämtliche Warnings und Notices stillschweigend verschluckt wurden. Am 8. Oktober 2026 wurde PHP 8.6 RC3 veröffentlicht, der zweite Release Candidate der kommenden Hauptversion – und er räumt genau dieses Problem sowie vier weitere, teils subtile Bugs aus dem Weg.
Interessant am Fahrplan: RC1 wurde komplett übersprungen, RC3 ist also bereits der zweite tatsächlich veröffentlichte Kandidat. Für PHP-Entwickler, Web-Dev-Teams und DevOps-Verantwortliche, die ihre Infrastruktur auf die neue Version vorbereiten, liefert dieser Artikel eine kompakte, faktenbasierte Einordnung aller Aenderungen.
Inhaltsverzeichnis
Key Takeaways
- PHP 8.6 RC3 erschien am 8. Oktober 2026 und behebt einen kritischen Fiber-Bug, der Warnings und Notices unterdrückte, wenn keine php.ini einen error_reporting-Wert setzt – betrifft Docker-Standardimages und
php -n. - hrtime() maß in den Betas auf manchen Systemen rund 4 Prozent zu schnell, weil auf CLOCK_MONOTONIC_RAW statt CLOCK_MONOTONIC umgestellt wurde; RC3 macht diesen Wechsel rückgängig.
- array_map() warf in RC2 bei
strict_types=1fälschlich TypeErrors durch einen neuen, ungetesteten Code-Pfad – in RC3 für strict_types-Dateien wieder deaktiviert. - Der OPcache-Optimizer faltete
$cond? -0.0: 0.0fehlerhaft zu einer Konstante zusammen und ignorierte dabei die Bedingung – ein Bug, der vor allem in Produktionsumgebungen mit aktiviertem OPcache auffällt. - Der eingebaute PHP-Webserver leckte seit PHP 8.2 bei jedem HEAD-Request auf statische Dateien einen File-Descriptor – mit RC3 ist das behoben.
- Der finale Termin für die General Availability von PHP 8.6.0 ist der 19. November 2026.
Was ist PHP 8.6 RC3 und warum wurde RC1 übersprungen?
PHP 8.6 RC3 ist der zweite veröffentlichte Release Candidate der kommenden Version 8.6.0. Laut den Angaben auf der offiziellen php.internals-Mailingliste sowie den Berichten von phpnews.net und php.watch wurde RC1 im Entwicklungsprozess übersprungen – RC2 war somit faktisch der erste öffentliche Kandidat, RC3 folgt nun als zweiter.
Release Candidates markieren die Phase, in der keine neuen Features mehr aufgenommen werden. Wer sich generell für Release-Zyklen moderner Sprachen interessiert, findet in unserem Artikel über Node.js 27 und dessen neuen Release-Zyklus einen guten Vergleich. Es geht ausschliesslich um Fehlerbehebungen, Stabilität und Feinschliff vor der finalen Freigabe. Genau das zeigt sich auch im Umfang von RC3: Alle Aenderungen sind Bugfixes, keine davon verschiebt das Verhalten der neuen Sprachfeatures von PHP 8.6.
Der Fahrplan bis zur finalen Version von PHP 8.6
Der Zeitplan für die restlichen Release Candidates und die finale Version steht bereits fest. Die folgende Tabelle fasst die Termine zusammen, wie sie von phpnews.net und php.watch übereinstimmend bestätigt wurden:
| Meilenstein | Datum |
|---|---|
| RC3 | 8. Oktober 2026 |
| RC4 | 22. Oktober 2026 |
| RC5 | 5. November 2026 |
| General Availability (PHP 8.6.0 final) | 19. November 2026 |
Zwischen RC3 und der finalen Freigabe liegen demnach noch zwei weitere Release Candidates. DevOps-Teams, die Staging-Umgebungen auf PHP 8.6 vorbereiten, sollten diesen Fahrplan im Blick behalten, da jeder weitere RC potenziell zusätzliche Regressionsfixes mitbringt.
Die wichtigsten Fixes in PHP 8.6 RC3
Der Kern von PHP 8.6 RC3 besteht aus fünf klar dokumentierten Bugfixes, die jeweils unterschiedliche Teile des Oekosystems betreffen – von asynchronem Code über Performance-Messung bis zur Numerik.
Fiber-Bug: error_reporting=0 unterdrückte Warnungen
Der schwerwiegendste Fix betrifft Fibers, PHPs Mechanismus für kooperatives Multitasking, der die Grundlage für asynchrone Bibliotheken wie Revolt oder AMPHP bildet. In den Beta-Versionen sowie in RC2 starteten neu erzeugte Fibers mit error_reporting=0, sofern keine php.ini einen expliziten Wert für diese Einstellung gesetzt hatte. Das ist genau der Zustand in den offiziellen PHP-Docker-Images und bei jedem Aufruf mit php -n.
Die Konsequenz: Alle Warnings und Notices, die innerhalb eines Fiber auftraten, verschwanden lautlos. Ein Entwickler, der einen Bug in asynchronem Code suchte, hätte im Fiber-Kontext schlicht keine Fehlermeldung gesehen – ein klassischer Fall von "funktioniert lokal, schweigt in Produktion". Gina Peter Banyard behob den Fehler unter dem Issue GH-23921. Für jedes Team, das auf Fibers basierende Bibliotheken produktiv einsetzt, ist dieser Fix allein ein triftiger Grund, auf RC3 statt auf RC2 zu testen.
hrtime() lief in den Betas zu schnell
Ein zweiter, besonders kurioser Bug betraf die Funktion hrtime(), die in PHP für hochpräzise Zeitmessung genutzt wird. In den 8.6-Betas wurde die zugrunde liegende Systemuhr von CLOCK_MONOTONIC auf CLOCK_MONOTONIC_RAW umgestellt. Auf manchen Systemen führte das zu messbar zu schnellen Zeitwerten.
Nicolas Grekas dokumentierte das Problem konkret: Bei einem sleep(1) unter WSL2 maß die tatsächliche Wartezeit 1,000072 Sekunden, während hrtime() 1,038898 Sekunden auswies – eine Abweichung von rund 4 Prozent. Für Benchmarking-Tools, Rate-Limiter oder Performance-Monitoring wäre das ein stiller, aber folgenreicher Fehler gewesen. PHP 8.6 RC3 kehrt zur bewährten CLOCK_MONOTONIC-Quelle zurück, wie sie bereits in PHP 8.5 verwendet wurde.
array_map() und strict_types: die TypeError-Falle
Mit RC2 hatte array_map() einen neuen, schnelleren internen Code-Pfad erhalten, der in Dateien mit strict_types=1 die Typen der Callback-Argumente überprüfte. Das Problem: array_map() hat diese Prüfung historisch nie durchgeführt. Bestehender Code, der unter PHP 8.5 fehlerfrei lief, warf in RC2 plötzlich TypeErrors.
"Ein Optimierungspfad, der neues, bislang nie geprüftes Verhalten einführt, ist in einer Release-Phase ohne neue Features besonders riskant."
Tim Düsterhus deaktivierte diesen Pfad für strict_types=1-Kontexte wieder. Für Entwickler bedeutet das: Code, der mit array_map() und strikten Typen arbeitet, verhält sich in RC3 wieder wie in PHP 8.5.
OPcache-Optimizer und das Vorzeichen von Null
Besonders schwer aufzuspüren war ein Bug im OPcache-Optimizer. Dieser faltete Ausdrücke der Form $cond? -0.0: 0.0 fälschlicherweise zu einer einzigen Konstante zusammen – und ignorierte dabei die eigentliche Bedingung komplett. In der Gleitkomma-Arithmetik ist das Vorzeichen der Null jedoch relevant: 1.0 / $zero ergibt je nach Vorzeichen von $zero entweder INF oder -INF.
Besonders gefährlich macht diesen Bug sein Erscheinungsbild: Lokale Entwicklungsumgebungen laufen häufig ohne aktiviertes OPcache, während Produktionssysteme es fast immer aktiviert haben. Ein solcher Fehler fällt also oft erst im Live-Betrieb auf – und genau dort, wo er am teuersten ist.
File-Descriptor-Leck im eingebauten Webserver
Der vierte Fix betrifft den eingebauten PHP-Webserver (php -S), der von vielen Teams für lokale Entwicklung und einfache Testumgebungen genutzt wird. Bei jedem HEAD-Request auf eine statische Datei leckte der Server einen File-Descriptor. Ein Monitoring-Probe, der alle 40 Sekunden einen HEAD-Request sendet, konnte dem Server nach rund 11 Stunden die verfügbaren File-Descriptors vollständig ausgehen lassen – mit der Folge, dass der Server keine weiteren Verbindungen mehr annehmen kann.
Dieser Bug existierte bereits seit PHP 8.2 und wurde erst jetzt im Rahmen der RC3-Vorbereitung entdeckt und behoben. Für Teams, die den eingebauten Server für Health-Checks oder CI-Pipelines mit regelmäßigen Probes nutzen, ist das ein relevanter Stabilitätsfix.
Weitere Verbesserungen: PDO, Intl und OpenSSL
Neben den fünf Hauptfixes enthält PHP 8.6 RC3 eine Reihe kleinerer, aber praxisrelevanter Korrekturen:
- PDO:
PDOStatement::execute()liess nach einer fehlgeschlagenen Ausführung weiterhin das alte Ergebnis verfügbar – das ist nun korrigiert.setFetchMode()wendet Aenderungen jetzt atomar an. Ein Use-after-free-Fehler beim__toString()-Aufruf eines gebundenen Parameters wurde ebenfalls geschlossen. - PDO_DBLIB: Fehler aus
beginTransaction(),commit(),rollBack()undlastInsertId()werden nun korrekt gemeldet, statt verschluckt zu werden. - Intl/Grapheme: Mehrere Fixes rund um die Grapheme- und Intl-Erweiterungen verbessern die Korrektheit bei Textverarbeitung mit mehrsprachigen Zeichen.
- OpenSSL:
openssl_sign()nutzt bei RSA-PSS-Signaturen nun den OpenSSL-Standard-Salt statt des bisherigen Maximalwerts – ein Detail, das Interoperabilität mit anderen Systemen verbessert.
Diese Aenderungen sind einzeln betrachtet klein, summieren sich aber zu einer deutlich robusteren Datenbank- und Kryptografie-Schicht für den finalen Release.
Hintergrund: Was PHP 8.6 sonst noch bringt
Während RC3 selbst ausschliesslich Bugfixes enthält, lohnt sich zur Einordnung ein Blick auf die größeren, bereits feststehenden Neuerungen von PHP 8.6 insgesamt. Dazu zählen partial function application mit ? als Platzhalter für Argumente, eine neue clamp()-Funktion, die Klasse TimeDuration, readonly-Properties mit Default-Werten, eine neue IoPoll-API sowie ein URI-Builder.
Relevant für Sicherheitsverantwortliche: PHP 8.6 ändert mehrere Session-Standardwerte. session.use_strict_mode wird auf 1 gesetzt, session.cookie_httponly ebenfalls auf 1 – damit kann JavaScript das Session-Cookie nicht mehr auslesen. Zusätzlich wechselt session.cookie_samesite auf 'Lax'. Diese Defaults sind bereits eingefroren und nicht Teil der RC3-Aenderungen, sollten aber bei der Migrationsplanung berücksichtigt werden.
Was bedeutet PHP 8.6 RC3 für Entwickler und DevOps-Teams?
Für Teams, die bereits gegen die 8.6-Betas oder RC2 getestet haben, ist der wichtigste Handlungspunkt klar: erneut testen, insbesondere wenn die Anwendung Fibers, hrtime()-basierte Messungen, array_map() mit strict_types=1 oder Berechnungen mit Gleitkomma-Vorzeichen verwendet.
Konkrete Empfehlungen:
- Async-Code prüfen: Wer Revolt, AMPHP oder eigene Fiber-basierte Lösungen einsetzt, sollte sicherstellen, dass Warnings und Notices in Testumgebungen wieder sichtbar sind.
- Performance-Messungen validieren: Wer
hrtime()für Benchmarks oder Rate-Limiting nutzt, sollte die Werte nach dem Update auf RC3 neu abgleichen. - CI-Pipelines mit strict_types testen: Bestehende Tests, die in RC2 TypeErrors bei
array_map()zeigten, sollten in RC3 erneut laufen. - OPcache in Staging aktivieren: Da der Null-Vorzeichen-Bug nur mit aktivem OPcache auftritt, sollte dieses auch in Testumgebungen eingeschaltet sein, um Produktionsbedingungen realistisch abzubilden.
- Monitoring-Intervalle prüfen: Wer den eingebauten PHP-Webserver mit regelmäßigen Health-Checks betreibt, profitiert direkt vom Fix des File-Descriptor-Lecks.
Fazit
PHP 8.6 RC3 zeigt exemplarisch, wofür Release Candidates eigentlich gedacht sind: das Aufspüren und Beheben von Fehlern, bevor sie Millionen von Produktionsumgebungen erreichen. Der Fiber-Bug rund um error_reporting=0 allein hatte das Potenzial, stille Fehler in jedem modernen asynchronen PHP-Projekt zu verursachen. Zusammen mit der Korrektur bei hrtime(), der Entschärfung der array_map()-TypeError-Falle, dem OPcache-Fix für Null-Vorzeichen und dem geschlossenen File-Descriptor-Leck macht RC3 einen klaren Schritt in Richtung Stabilität.
Teams sollten jetzt aktiv werden: Staging-Umgebungen auf PHP 8.6 RC3 aktualisieren, bestehende Testsuiten erneut durchlaufen lassen und insbesondere Fiber-basierten Code sowie Gleitkomma-Logik gezielt prüfen. Bis zur finalen Freigabe am 19. November 2026 stehen mit RC4 (22. Oktober) und RC5 (5. November) noch zwei weitere Gelegenheiten bereit, verbleibende Probleme zu melden – ein frühes, gründliches Testen von PHP 8.6 RC3 zahlt sich für jedes Team aus, das einen reibungslosen Umstieg plant.
Quellen
- phpnews.net: https://phpnews.net/php-8-6-rc3
- php.watch: https://php.watch/versions/8.6/releases/8.6.0RC3
- php.internals Mailingliste: https://news-web.php.net/php.internals/132836
