Browscap crashes PHP 8.1.12 on request shutdown (apache2) #10052
Comments
|
What is the value of the php.ini setting |
cmb69
added
Extension: standard
Status: Needs Feedback
and removed
Status: Needs Triage
labels
|
Nope, it's an absolute one - The file itself is lite_php_browscap.ini. |
|
Thanks for the feedback. I still can't reproduce this issue, though. Looking at the code reveals no issues either, although there is a comment which hints at potential issues: php-src/ext/standard/browscap.c Line 66 in e4ef394 Since this is about apache2handler, the issue might only happen with certain MPMs. I'm using mpm_winnt and there is "just" a memory leak, because PHP is started up in the control process, which is never used to handle requests (see #7865). Which MPM do you use? |
cmb69
added
Status: Needs Feedback
SAPI: apache2handler
and removed
Status: Needs Triage
labels
|
It's apache 2.4.51 with mpm-itk. Also this is the minimal reproducer I could come up with: <?php
get_browser();[foo]
Comment="foo"
[bar]
Parent="foo" |
|
I did some more tests: browscap doesn't trigger a crash in 7.2.34, but 7.3+ is certainly broken. I've stumbled upon 5eb1f92 while looking through |
|
My guess was correct, bisect has revealed that 5eb1f92 is the first bad commit. I'd be happy if someone explains me what is the refactoring behind these changes, and how could they particularly affect mpm-itk. Although the commit affects a bunch of other extension files, the only issue of a kind I know about so far is the browscap problem. Should I run some tests to make sure that my SAPI is sane? I know that PHP has a lot of tests already written, but they are usually run within CLI, and I don't know how to run them for apache2. Is that possible? Thanks. |
|
The Zend Engine distinguishes between persistent and regular memory allocations. Regular allocation are supposed to be freed after each request; persistent allocations are supposed to be freed when the process shuts down.
|
Ah, I think that explains the problem (previously, I tried the setting in php.ini, and that didn't cause issues). If I revert the respective changes to browscap.c, I can now go beyond the original failure, but still get an assertion violation in Anyhow, it seems that string interning is the concrete issue, but a more general problem is that the browscap ini is read again for every request what is wasteful. I shall have a closer look. |
…che2) get_browser() implements a lazy parse system for the browscap INI configuration. There are two possible moments when a browscap configuration can be loaded: during module startup or during request. In case of module startup, the strings are persistent strings, while for the request they are not. The INI parser must therefore know whether to create persistent or non-persistent strings. It does this by looking at CG(ini_parser_unbuffered_errors). If that value is 1 it's persistent, otherwise non-persistent. Note that this also controls how the errors are reported: if it's 1 then the errors are sent to stderr, otherwise we get E_WARNINGs. Currently, a hardcoded value of 1 is always used for that CG value in browscap_read_file(). This means we'll always create persistent strings *and* we'll not report parse errors correctly as E_WARNINGs. We fix both the crash and the lack of warnings by passing the value of persistent instead of a hardcoded 1. This is also in line with how other INI parsing code is called in ext/standard: they also make sure that during request a value of 0 is passed.
* PHP-8.1: Fix GH-10052: Browscap crashes PHP 8.1.12 on request shutdown (apache2)
* PHP-8.2: Fix GH-10052: Browscap crashes PHP 8.1.12 on request shutdown (apache2)
and others
Description
The following code:
Resulted in "zend_mm_heap corrupted" and exit code 1.
But I expected this output instead (or similar):
PHP Version
8.1.12
Operating System
Ubuntu 18.04
The text was updated successfully, but these errors were encountered: