php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38926 --zend-multibyte doesn't work for a few seconds on startup
Submitted: 2006-09-22 13:36 UTC Modified: 2009-01-18 10:35 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:1 (33.3%)
From: lapo at lapo dot it Assigned:
Status: Closed Package: mbstring related
PHP Version: 5.2.8 OS:
Private report: No CVE-ID: None
 [2006-09-22 13:36 UTC] lapo at lapo dot it
Description:
------------
Zend multibyte option (that ought to automagically detect script file format and read it accordingly) starts working correctly after a few seconds (I tested it only in FastCGI, as I use lighty and not Apache).

Reproduce code:
---------------
File checkUTF8.php (encoded in UTF-8 with explicit BOM, aka UTF-8Y):
\xEF\xBB\xBF<?= ('?' == "\xC3\xA0") ? "OK\n" : "Broken\n" ?>
(the first three chars are the UTF8-encoded BOM)

Expected result:
----------------
% php -r checkUTF8.php
OK
% while true; do elinks -dump 'http://wlocalhost/checkUTF8.php'; sleep 1; done
   OK
   OK
(lighttpd restarted from a different shell)
ELinks: Connection refused
ELinks: Connection refused
   OK
   OK
   OK
   OK

Actual result:
--------------
% php -r checkUTF8.php
Broken
% while true; do elinks -dump 'http://wlocalhost/checkUTF8.php'; sleep 1; done
   OK
   OK
(lighttpd restarted from a different shell)
ELinks: Connection refused
ELinks: Connection refused
   Broken
   Broken
   OK
   OK

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-15 22:11 UTC] lapo at lapo dot it
Sorry, I didn't check the snapshot yet, but I tested it with PHP 5.2.0, with the following result:

% php checkUTF8.php
Broken
% while true; do elinks -dump 'http://localhost/checkUTF8.php'; sleep 1; done
   OK
   OK
(lighttpd restarted from a different shell)
ELinks: Connection refused
ELinks: Connection refused
   Broken
   Broken
   Broken
   Broken
   OK
   OK

Well, something has changed: now the problem shows from CLI too =(
 [2007-05-23 22:54 UTC] sniper@php.net
Try the latest snapshot, and if it fails (propably) then run it through valgrind (using CLI) and see if there are any errors, etc. Also, what was the configure line you used to make php?
 [2007-05-31 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2008-06-21 08:45 UTC] lapo at lapo dot it
Using PHP 5.2.6 the situation is changed slightly: it seems that now the page is broken on the first access only:

% php checkUTF8.php
Broken

(restart webserver)
% while true; do elinks -dump 'http://localhost/checkUTF8.php'; done
   Broken
   OK
   OK
   OK
   OK
^C
 [2009-01-16 10:22 UTC] lapo at lapo dot it
Ah, something changed with 5.2.8 indeed: it now is always broken, doesn't fix after a bit like it did before.

A bit more clarity about the test script, an hex dump:
% hd checkUTF8.php
00000000  ef bb bf 3c 3f 3d 20 28  27 c3 a0 27 20 3d 3d 20  |<?= ('?' == |
00000010  22 5c 78 43 33 5c 78 41  30 22 29 20 3f 20 22 4f  |"\xC3\xA0") ? "O|
00000020  4b 5c 6e 22 20 3a 20 22  42 72 6f 6b 65 6e 5c 6e  |K\n" : "Broken\n|
00000030  22 20 3f 3e                                       |" ?>|
 [2009-01-16 10:25 UTC] lapo at lapo dot it
Re-opening as something clearly changed in the behavior in 5.2.6-5.2.8 changes (something erratically working became something that doesn't work at all).
I will take a look at the diff myself in the weekend.
 [2009-01-18 09:28 UTC] lapo at lapo dot it
I've noticed --zend-multibyte always works if the module mbstring is 
NOT included, fails if it's there.
Can the module interfere with the loading of .php?
 [2009-01-18 10:35 UTC] lapo at lapo dot it
I correct myself, in fact 5.2.8 *fixed the bug*, not the opposite.
In php.ini needs to be "mbstring.language = uni" as changing the 
internal in the script is too late (the script has already been 
loaded) and anything else is too narrow to contain the correctly 
decoded chars.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Nov 29 04:01:23 2020 UTC