|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67375 JIT enabled sometimes breaks filters
Submitted: 2014-06-03 17:21 UTC Modified: 2014-07-03 06:32 UTC
Avg. Score:2.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: garyamort at gmail dot com Assigned:
Status: Open Package: Filter related
PHP Version: 5.5.13 OS: Arch Linux 64bit
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: garyamort at gmail dot com
New email:
PHP Version: OS:


 [2014-06-03 17:21 UTC] garyamort at gmail dot com
In some situations, if you have auto_globals_jit enables then not only are super global variables not initialized unless they are called, the underlying data storage for the original data[used by filter_input] will not be populated.

As I read filter.c, there seems to be a weird schism on how it deals with this.

For INPUT_SERVER and INPUT_ENV it seems as if filter will make sure to initialize the data, example:
        if (PG(auto_globals_jit)) {
                                zend_is_auto_global("_SERVER", sizeof("_SERVER")-1 TSRMLS_CC);

For INPUT_POST, INPUT_GET, and INPUT_COOKIE however there is no safety net.

Test script:

// execute from web browser as http://domain/filename.php?test=123

$before = filter_input(INPUT_GET, 'test');  // $before = null
$var = $_GET('test');           // $var = 'test'
$after = filter_input(INPUT_GET, 'test');       // $after = 'test'

if ($before !== $after)
echo 'Raw input failed to load';


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-06-03 17:26 UTC] garyamort at gmail dot com
Note: I am not able to recreate this error at this time.   I am running under Arch Linux which as an extremely odd PHP package - virtually every module is installed as a shared library rather - even rather basic libraries such as sockets.

Since discovering this error, I created my own package and recompiled moving most shared php module libraries to static and the problem went away.  This leads me to think that either the problem is that there is no 'safety net' definitions for PARSE_GET, PARSE_POST, and PARSE_COOKIE here

OR that I simply messed up something when I was testing
 [2014-06-04 01:35 UTC] is a possible duplicate for this one.
 [2014-07-03 06:32 UTC]
nope, is unrelated.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Nov 29 14:01:29 2023 UTC