Zend Weekly Summaries Issue #303

      Comments Off on Zend Weekly Summaries Issue #303

TLK: PHP 5.2.0RC2
TLK: DllMain and libxml2 [continued]
TLK: Default session.gc_maxlifetime
TLK: lib64 not recognized
TLK: APC issues
NEW: PECL releases
CVS: PHP 5.1.6 released
PAT: Chasing up LDAP control

TLK: PHP 5.2.0RC2

PEAR contributor Daniel Convissor had been testing the new Release Candidate, and
had come across a weird PEAR DB test failure when using a combination of PHP 5.2,
MySQL 4.1 and the mysqli extension under Windows. The database connection was
failing for him with the error “Can't create TCP/IP socket (10106)“.
The same setup worked fine – with the exact same DSN and credentials – when Daniel
connected during a regular PHP script, and the failing test, 01connect.phpt,
ran perfectly under PHP 5.0.4. Could anyone cast a light on this?

Apparently not.

Steve Roussey wrote that he was having a problem upgrading an existing WAMP
installation to run the Release Candidate; ‘in the PHP error log it seems to have
a mess of a time loading the libs. Some aren’t found (but are there) and some have
API versioning issues…
‘ Derick Rethans responded, explaining that this is
expected behaviour when you try to load extensions from the wrong PHP version. Steve
finally uncovered the culprit – an unrelated software installation had put a copy of
php5ts.dll somewhere and added its filepath to PATH. ‘I hate Windows‘,
he grumbled, but made up for eating our bandwidth by adding a note that PHP 5.2 was
much faster than PHP 5.1.

Christian Schneider was having issues with OpenSSL 0.9.7g under SuSE 10, and
mailed a patch to supply a missing #define. Pierre-Alain Joye explained
that this was already fixed in CVS, but thanked Christian for posting his fix

Meanwhile John Mertic had been busy, and posted the latest version of his
Windows Installer, also in the testing stages, complete with PHP
5.2.0 RC 2. He’d written up the changes made to the installer on his blog at
dotgeek, but following changes to the site this week the blog is no longer available
there – hence the reproduction here:

Short version: Only the MySQL report remains a mystery.

TLK: DllMain and libxml2 [continued]

XML guru Rob Richards noted that the release cycle for both the PHP_5_1 and
PHP_4_4 branches had finally reached a point where a bit of rampant development is
possible. He wrote to the list asking whether he could put his DllMain changes into ext/libxml
now? Rob would also like to see those changes in the PHP_5_2 branch prior to
release, as they should resolve crashes reported under Win2003. He requested Release
Master Ilia Alshanetsky’s permission to add them there.

Andi Gutmans demurred; he didn’t see a DllMain() entry point as a
good long-term solution, and asked whether xmlDllMain() couldn’t be
called during module initialization instead? Rob explained that this wasn’t
possible. xmlDllMain() is designed to be called from
DllMain() in a DLL that includes libxml statically, and the way
thread-handling is managed changes when the function is used.
xmlDllMain() ensures that thread resources are cleaned up properly on
termination, so the location of the call to it is entirely dependant on whether the
PHP dll is called when ‘in process’ or when ‘out of process’. Rob believed that,
under Win2003, the state is ‘out of process’, preventing one of the spawned threads
from being cleaned up properly on termination – hence the crashes. Besides, the
existing set-up only handles a single message; further message handling isn’t
possible, which isn’t a happy state of affairs.

The only way to eliminate the need for the xmlDllMain() call, a
DllMain() entry point and a new static library build under Windows
would be to drop the whole idea of a static build and use a dynamically loaded
libxml2.dll instead, wrote Rob.

Andi agreed that this made sense to him, but wondered why, in that case, libxml2
wasn’t dynamically linked in the first place? He saw this as a far more flexible
approach than ‘messing around with DllMain()‘. Rob couldn’t
remember all the reasons for static linking to libxml2, but knew that library
maintenance and ease of installation were two of them. He personally had no problem
with reverting to DLL usage, but pointed out that this would need to include
libxslt.dll too. Also, as Rob noted, the burden of maintenance would shift
from himself onto Edin Kadribasic – who has responsibility for Windows PHP builds
and distribution – and anyone supporting Windows installations.

Rob’s own libxml2 and libxslt library builds wouldn’t be necessary any more when
building PHP, although he would be prepared to continue making them available for
anyone else needing them. That said, Rob added that there
are issues
when using MSVC compilers this side of version 6.0, if any of the
other libxml2 binaries are used alongside libxml2 itself. He, personally, uses MSVC
6.0 when building his libraries, simply to avoid those problems.

Finally, Rob wondered whether ext/domxml in PHP 4 should also be altered
to link dynamically – would the change percolate down through all PHP branches? He
had no idea whether or not the Win2003 crashes reported in libxml2/PHP 5 were also
seen in domxml/PHP 4, but believed the domxml library to be linked statically within
the DLL, in the same way that libxml2 currently is.

Short version: DLL hell looms.

TLK: Default session.gc_maxlifetime

PHP user Peter Brodersen had been following the exchange over the default value
of memory_limit, and wrote to internals@ asking about the peculiar
default value given to session.gc_maxlifetime. 1440 seconds, or 24
minutes, isn’t a particularly rounded value, and he wondered if there’d been some
error made in php.ini-dist; 1440 minutes, being a full day, would make more
sense. Had someone in the distant past assumed that the value was specified in
minutes? Peter put in a request for the default to be globally changed to 86400
seconds, arguing that a 24-minute timeout can and does confuse both developers and
users. It would be much easier to discard specific values during a long-lasting
session than to introduce hacks to keep a session alive beyond its maximum lifetime

Robert Cummings, another PHP user, felt that having a short session timeout
ensures better privacy, since it only allows ‘snoopy people‘ a few minutes of
access when users forget to close down the browser. 24 minutes seemed to him to be a
compromise between an irritatingly quick session expiry and an overly long one.
Peter retorted that the value seemed ‘pretty arbitrary‘ to him; not all
session data is sensitive, and it isn’t unknown for users to take longer than 24
minutes over a page. Security handling ought to be handled by the code, in his view.
Robert argued that erring on the side of caution was best when it comes to default

Short version: A response from a core developer would have been useful

TLK: lib64 not recognized

Marten Lehmann had needed to compile PHP 4.4 on Red Hat Enterprise, and had duly
made the discovery that the configure script isn’t lib64-aware. He was in the
process of patching the script for his own use, but wrote to the internals list
anyway in the hope that the team might add lib64 directories in future PHP

Short version: Another good reason to upgrade to PHP 5, where x64 libs
are catered for.

TLK: APC issues

Steve Roussey meanwhile was catching up on earlier threads he’d missed while on
holiday. He was happy to discover that there is now support for upload progress
hooks in the PHP_5_2 branch, but confused over what that meant to the end user. Was
an extension still necessary?

Markus Fischer wrote that the current implementation in the PHP core simply
provides hooks at C level and an extension is required that is not available with
the PHP distribution. Steve wondered whether ‘the other extension‘ (?) could
be ported to support the hooks in PHP and added to PECL. Barring that, perhaps APC
should be in the distribution. Was its omission deliberate?

Ilia explained that there are no plans to integrate APC into the PHP 5 distro; it
is, however, on the PHP 6 TODO list.

Christian Schneider, meanwhile, reported a segfault with PHP 5.2.0 RC2 in CLI
mode and APC 3.0.11. Was this a known issue, or did it need investigation? Rasmus
mentioned that ‘an opcode cache doesn’t help a whole lot in CLI mode‘, and
suggested that Christian should simply turn APC off in his php.ini using
apc.enable_cli=0. He added that full PHP 5.2 support isn’t yet in place
in APC anyway, but should be there ‘in about a week‘. Christian tried using
the INI directive but found that it didn’t prevent the segfault, suggesting that the
problem causing the crash comes before the INI setting is evaluated.

PHP security expert Stefan Esser wrote to say that he was seeing a
segfault when running complex applications under APC 3.0.11 and PHP 5.1.6. He hadn’t
tried earlier versions of APC at this point. Rasmus asked for a backtrace, but
Stefan replied that the one he’d already obtained was unusable; it had attempted to
execute in unpaged memory. He’d try again later.

Sara Golemon wrote that Christian’s CLI issue is already known – in fact she’d
blogged about it – but is very much an edge case, only occurring
in ZTS CLI builds where enable_cli is not turned on. Switching on
enable_cli should resolve the problem.

Jared Williams begged to differ. He reported that PHP 5.1.6 and APC 3.0.11-dev
crash on shutdown regardless of the apc.enable_cli setting, in the same
way Christian had found with PHP 5.2. He created a bug report against
APC for Rasmus to mull over and everyone else to add their complaints to.

Short version: Something’s gone awry there.

NEW: PECL releases

Since this was a quiet week, let’s take a quick tour around the PECL releases
announced during the course of it.

First up was Olivier Hill, announcing the first PECL release of his package
pecl/geoip. You may recall that Olivier went to some trouble to work through
the licensing issues with Maxmind, the company that created and maintains the database behind
this extension. This is the result of all his groundwork over the summer months;
geoip-0.2.0 (beta) is available at http://pecl.php.net/geoip, and is likely to prove a popular

Zend’s own Tony Dovgal came next with a stable release of the PECL version of the
oci8 extension. Version 1.2.2 contains several bug fixes, bringing it up to date
with ext/oci8 at the point of the PHP 5.1.6 release. It is available for download at

Core developer Pierre-Alain Joye fixed some issues he’d come across when working
with relative paths in a threaded environment, and as a result released zip-1.7.1
(beta) at http://pecl.php.net/zip.

Google Summer of Code student William Candillon was able to make the first alpha
release of his extension to generate an XML parse tree from PHP code. Sebastian
Bergmann was the first to congratulate him, but had a couple of suggestions to make
the extension even better. This ‘tool for tool developers’ is available at http://pecl.php.net/parse_tree.

Mike Wallner busied himself with his pecl/http package, and released
version 1.2.1 (stable) at the end of the week. This HTTP extension, ‘providing a
convenient and powerful set of functionality for one of PHP’s major
‘, has a fair number of fans. Although unlikely to end up in the PHP
core, it’s worth checking out for its easier handling of all things HTTP. The source
download is at http://pecl.php.net/http.

Pierre came in last with another release of pecl/zip; the previous release
had fixed the problem in a threaded environment, but there were now broken paths in
a non-threaded environment. zip-1.7.2 (beta), he promised, works smoothly in

Short version: Everything in PECL that will build under win32 is
available as a Windows binary from http://pecl4win.php.net.

CVS: PHP 5.1.6 released

Changes in CVS that you should probably be aware of include the following (in
PHP_5_2 and CVS HEAD only, unless otherwise stated):

  • In ext/oci8, PECL bug #8112 (OCI8 persistent connections misbehave when Apache
    process times out) was fixed shortly before the extension’s version number was
    bumped to 1.2.2 [Tony Dovgal]
  • PDO bug
    (memory corruption in pdo_pgsql driver on error retrieval inside
    a failed query executed via query() method) was fixed [Ilia]
  • Streams bug
    (Access to php://stdin and family crashes PHP on win32)
    was fixed in PHP_5_1, PHP_5_2 and CVS HEAD [Dmitry Stogov]
  • CLI SAPI bug
    (shutdown_executor() may segfault when
    memory_limit is too low) was fixed [Dmitry]
  • Three similar bugs, #38511, #38473 and #38263, were closed when the session extension was made to shut down
    after the date extension, which it uses [Ilia]
  • Under Windows, ext/spl and ext/reflection are now always built
    as static, closing bug #38556 [Tony]
  • Heap corruption was fixed in the Zend Engine, closing serialization bug
  • In ext/gd, there is now support for entities in hexadecimal format;
    ©, &#169 and © should all work [Pierre]
  • The SOAP extension gained a new method, SoapServer::setObject()
    a simplified version of the existing SoapServer::setClass()
  • In PHP_4_4 branch (only?), ext/wddx bug #38378
    (wddx_serialize_value() generates no wellformed xml) was fixed
  • Also in PHP_4_4 branch, a fix for bug #38450 (constructor
    is not called for classes used in userspace stream wrappers) was backported this
    week, making PHP_5_1 the only branch without this fix [Tony]
  • A final PHP_4_4-only bug, #37812 (aggregate_methods_by_list() fails to take
    certain methods), was fixed this week [Hannes Magnusson]
  • Zend Engine bug
    (Constructing in the destructor causes weird behaviour) was fixed
  • ext/mbstring now has a new configure option,
    --disable-mbregex-backtrack. The bundled onigurama library, used by
    the extension for multibyte regex, was updated to version 4.3.1 this week [Seiji
  • implode() was optimized when using non-string parameters in
    PHP_5_2 branch (only) [Ilia]
  • Maths constants M_SQRTPI, M_SQRT3,
    M_LNPI and M_EULER are now defined in the PHP core,
    closing feature request #33895 [Hannes]
  • In CVS HEAD only, ext/xmlwriter now has Unicode support [Rob]

Somewhat mysteriously, Ilia released PHP 5.1.6 towards the end of the week. It
seems that a couple of things were broken under Windows in the PHP 5.1.5 release –
one of them being the test suite.

Andi objected when Nuno committed changes across a range of extensions to declare
their *INIT, *SHUTDOWN and userspace functions as static.
He didn’t see why these needed to be defined as static at all? Ilia responded; the
idea, he believed, was to minimize the memory usage and allow the compiler to
optimize the code more effectively. Andi saw the symbols as irrelevant here and
didn’t think the change would help in optimization either, since the compiler
wouldn’t inline those particular functions in most cases anyway. He’d prefer to have
all PHP extensions written in a standard way. Besides, it was possible the core team
would need to play around with symbols at a later date. Marcus argued that
non-static declarations in fact make some compilers use an additional
JMP, and that for shared DLLs those functions could end up in the jump
table that would otherwise be initialized during the loading process.

On returning from his holiday, Nuno thanked Marcus for his support and explained
to Andi that marking functions as static actually reduces the code size,
particularly when building PHP with -fPIC. The memory usage part of his
fix came from the ‘constantifying‘, which has been on the TODO for some time.
Nuno went on to say that he had a couple of compiler-related patches he’d like the
Zend team to review, and gave links for three
them. It seems that compilers – and their options – are something Nuno
is passionate about.

Short version: A few fixes for the PHP_4_4 branch in there,

PAT: Chasing up LDAP control

PEAR developer Daniel Convissor posted a patch to make run-tests work with
directories containing spaces on a bug report. Tony subsequently committed Daniel’s patch. Also
this week, someone named Olek produced a patch fixing a crash in com_dotnet as part
of his report for bug
, which Edin tested and committed.

PHP user Chris Stromsoe found Pierangelo Masarati’s patches introducing LDAP
control support some time ago. He uses both patches, and wrote complaining that he
was tired of having to re-apply them with every PHP update. Chris added that
Pierangelo is one of the OpenLDAP developers (new information here), so it seemed
strange not to merge the patches into PHP wholesale; they’ve been sitting in PAT since last December. Could
anything be done to help nudge the process along?

Short version: This used to be Jani’s thing…