Zend Weekly Summaries Issue #226

      Comments Off on Zend Weekly Summaries Issue #226

TLK: Adding a logo
REQ: PHP/win32 stability
TLK: PHP-GTK corner
TLK: Embedding, PHP, and multi-threading
REQ: Generated files in CVS
REQ: Integrated encryption
BUG: PHP 5.0.3 losing $this
TLK: Reflection overgrown?
REQ: Help with segfault tracking
CVS: New egg
PAT: Shutdown order changes

TLK: Adding a logo

Dale Walsh wondered briefly how he could convert a .gif file into the
format required by logos.h – rather frustratingly there was no response, and
Dale appeared to solve that part of the problem home alone. Later he asked for the
rest of the API info to make the logo work; he’d generated project_logo.h,
defined a PROJECT_LOGO_GUID somehow, and added the functions
project_logo_guid() and project_info() already. Johannes
Schlüter responded that Dale should use php_register_info_logo()
(main/php_logos.c) or else just use PECL_Gen, which has logo support built
in. Dale added that call to the module initialization and reported success, but
wondered a) whether he should add anything equivalent to his extension’s
MSHUTDOWN and b) how to select an appropriate
LOGO_GUID.

With all this graphicking out of the way, Dale proceeded to outline the bigger
issue. He had rewritten a module that didn’t used to work cross-platform, and now
had it working as a shared library. However, the moment he tried to embed the
extension into PHP, it stopped functioning on several platforms. He’d tested all the
conditional flags, without success. Could anyone help him, off-list?

Short version: There might be money involved.

REQ: PHP/win32 stability

Along similar lines, but far more strangely, Dominik Smatana offered ‘great
reward (seriously!)
‘ for a stable native version of PHP 4.3.x for Windows,
please no emulation layers. Nothing currently available had worked for his company.
Willing helpers should contact him directly.

Scorpio9a (who?) pointed out that the win32 PHP binaries are actually
native…

Short version: Weird request.

TLK: PHP-GTK corner

Andrei Zmievski’s ‘proof of concept, only with users’ project blossomed this week
when he asked for testers and as much feedback as they could provide. Christian
Weiske, Scott Mattocks and Ivan Rodriguez responded fulsomely – the majority of the
nascent dev team either aren’t in a position to test, or are awaiting Frank
Kromann’s port of PHP-GTK 2 to win32, or both. The threesome’s reports helped Andrei
fix some minor outstanding issues with the build system and versioning. In between
responding to these, Andrei busied himself by implementing the outstanding
connect_*() methods, support for GError (allowing the user
to call PhpGtkGErrorException), the constructor for
PangoFontDescription(), an internal style helper object, and various
other bits and pieces, including an infrastructure for overriding object handlers on
a per-class basis. He tested the latter by implementing the expose
event property in GdkEvent before asking whether anyone was willing to
take on the rest of the event properties. (I offered, but need a working build
environment first.)

One of his commit logs this week simply read, ‘Too much to describe‘. Tell
it like it is, Andrei.

Short version: We can’t be too far from a PHP-GTK 2 release
now…

TLK: Embedding, PHP, and multi-threading

Bob Beaty wrote a lengthy email
detailing the outcome of his investigations into embedded PHP and thread safety, and
asking a number of questions about it. He had a multi-threaded C++ application that
he wanted to embed ‘the PHP 5 engine’ into. He needed to be able to call it from his
code and capture stdout, stderr and friends. Was this possible with PHP 5.0.3? What
should he look out for?

Alan Knowles provided links to his
updates [dead links] of the
php_embed files, adding that they needed a
lot of tidying but that they worked.

Someone named Vadka explained that thread safety is not a problem for a single
thread: ‘The problem is to call user functions from different threads (TSRM_LS
pointed to somewhere in different threads, global vars are not protected, etc)
‘.
This had been Bob’s primary concern; he was worried about the safety of
zend_eval_string() if he were to initialize the engine in one thread
and then have several threads calling the function on different strings. He wasn’t
convinced that simply making the php_embed module thread-local was the
answer; it seemed to him that the design of the engine only allowed for one thread
to make those function calls.

Alan referred Bob to Derick Rethan’s SRM
project
and suggested that he would need to serialize the
opcodes and copy them on a per-thread basis. Thread safety in the Zend Engine was
achieved by having a separate data store for each thread, and treating each as a
separate process.

Wez Furlong advised that ZTS-enabled PHP has “strong thread affinity”, in the
sense that calls into the engine are thread-safe provided that you have previously
initialized the engine on that thread. He added that memory allocated from outside a
thread should not be efree()d, and resources could not safely be passed
between threads.

Bob asked how it would be possible to differentiate ub_write,
log_message, and sapi_error on different threads, there
being no way of identifying the thread that it was being called under? What was he
missing?

Wez explained:

Short version: Looks like fun.

REQ: Generated files in CVS

Jani Taskinen wanted to know whether there was a good reason not to commit the
scanner/parser files generated by bison and flex into CVS, thereby killing all
outstanding issues over third-party library versions.

Short version: Good question. Is there?

REQ: Integrated encryption

Mark Evans wondered whether there were any plans to include integrated encryption
routines in the PHP core. He said that, in his experience, the fact that the mcrypt
library wasn’t always installed meant that a pure PHP fallback was needed. He’d also
like to see some kind of asymmetrical encryption routine included, as writing this
in pure PHP was relatively inefficient. An option would be to bundle mcrypt…

Derick explained ‘we’d rather not bundle any library, and definitely not an
LGPL’d library
‘. He added that PHP was intended as a glue providing access to
libraries, and should not be implementing their functionality itself.

Matthew Charles Kavanagh backed Mark’s request, citing portability as a major
issue to him. If web hosts couldn’t be relied on to provide ext/mcrypt, he
couldn’t use the mcrypt library in his web applications. He’d like to write
applications that many people could run, ‘not just those who take out a loan
against their house to pay for webhosting’
.

Christian Schneider, in turn, backed Derick, saying that either every single
extension should be bundled and installed by default, or there had to be decisions
made regarding those that were part of the core. Encryption functionality, and
mcrypt, weren’t in demand.

Matthew pointed out that this discussion showed otherwise, and added that he felt
he had indicated his position.

Derick felt that the onus was on the application developer to cope with the
situation as it stood, by re-implementing functionality, by making functionality
optional, or by recommending a decent webhost that would add extensions on request.
Both he and Adam Maccabee Trachtenberg mentioned that bundling libmcrypt had legal
implications that they felt were best avoided; the licensing for one, and the
nasty export restrictions in some countries‘ for another. Adam made the
point that user education was preferable to bundling libraries with every package.
He added: ‘We’ve hashed this type of issue over many times. I can assure you, we
won’t bundle mcrypt at this time. It’s not worth debating, really. Please don’t
continue asking as it will only annoy people. Honestly. :)

Short version: Never, ever, tell anyone that requested functionality
isn’t in demand. It gives me the giggles. Honestly :)

BUG: PHP 5.0.3 losing $this

The longest thread of the week came courtesy of PHP user Yermo Lamers, following
his claim that ‘PHP 5.0.3 is losing $this‘. He had submitted
a bug report, but felt that
he was getting nowhere. He was not able to reproduce the bug in a few lines; the
best he’d managed needed three classes to set it up. Hence the direct appeal to the
internals list. Several paragraphs later, the problem turned out to be that a
reference to $this was not being returned as an object, which it always
had been before. He also would like feedback regarding another bug report he had open, as
he had been unhappy over the response there too. He concluded that ‘showing no
interest and dismissing serious bugs out of hand is a real problem
‘.

Wez pointed out that Yermo was not giving the right information. If he’d tracked
down buffer overrun errors as he claimed, attaching them to the bug report would be
a useful thing to do. In fact, writing good bug reports was the biggest issue here,
particularly when problems were hard to pin down. Yermo’s test script was definitely
too large; it would be immediately unattractive to someone slotting in a bit of
recreational bug-squashing at the end of an already busy day.

A frustrated Yermo asked what he was supposed to do when he couldn’t reduce the
test script any further? He’d spent 16 hours to produce his test case from a body of
code that included over 60 thousand lines. He just wanted to know the next step,
having failed to produce that small script. He needed to get this bug fixed.

Someone named Michael promptly rewrote Yermo’s test case in 11 lines of code.


<?php

class Foo {

    function &getThis() {
        return(
$this);
    }

    function destroyThis() {
        
$baz =
&
$this->getThis();
    }
}

$bar = new Foo();

$bar
->destroyThis();
var_dump($bar);

?>

Yermo conceded at this point that it might not be a buffer overflow problem after all.

Andi Gutmans then picked up Yermo’s initial mail and replied to it, explaining
that the team needed to be presented with a solvable problem. He then spotted
Michael’s test script and promptly asked whether there was an error message under
E_STRICT – which there should be, as the code shouldn’t work. You
should only be allowed to return variables by reference; there had been a bug in
earlier versions of PHP that allowed a way around this restriction. Putting
parentheses around a variable makes it read-only.

Yermo replied in another very long email that he always runs
E_ALL… but realized now that he’d made a conceptual error and his
code, rather than PHP, was the problem. Checking the documentation, he found the
note about return() too; it wasn’t even a documentation bug. ‘So the
bug reduces down to a lack of warning on that construct.’
Andi further made his
day by explaining that E_STRICT is not part of E_ALL, and
the thread should have ended there, with Yermo facing 60K lines of code auditing and
two more bug reports closed.

It didn’t.

We kept seeing replies to everyone who ever commented, at some length. Many of
those long emails reiterated the point that Yermo understood how busy the team were;
they really are, and they stopped reading his email (and the responses) long before
the thread ended. Unfortunately some of the team are so busy that they don’t
pick up list mail as it comes in, and don’t read it in reverse order when they
finally do pick up. Zeev Suraski falls into the ‘super-busy’ category, and so we
were treated to the whole ‘how to report bugs in an open source project’ lecture for
the third or fourth time. However, Zeev also produced a nice short essay on
bug-hunting, in response to Yermo’s plaintive ‘How do you guys track it
down?
‘:

Short version: PEBKAC

TLK: Reflection overgrown?

Timm Friebe took issue with two new ReflectionClass methods,
getStaticPropertyValue() and setStaticPropertyValue(). He
wanted to know how they differed from


$value
= $reflectionClass->getProperty('instance')->getValue();

and


$reflectionClass->getProperty('instance')->setValue($value);

and called their existence ‘bloat’.

Zeev wrote to say he very much agreed.

Short version: Mm, but they’ve been there a while…

REQ: Help with segfault tracking

PEAR developer Greg Beaver wrote in to say that their team were seeing quite a
few reports of PEAR segfaulting on a debug_backtrace() call in the
PEAR_Error constructor. He couldn’t reproduce the problem, and needed
tips on how to isolate it.

Derick suggested that he should start by disabling Zend’s memory manager in
zend_alloc.h. Then use valgrind to run PHP and see whether it shows
errors.

Short version: Everything’s easy when you know how.

CVS: New egg

Ilia Alshanetsky committed a new, 15-20% faster, version of
html_entity_decode() as part of his ongoing optimization work.

Jani, who likes to see a small and tidy repository, moved ext/fam and
ext/mnogosearch into PECL.

Marcus Börger added Zend Engine support for methods dynamically added via object
handlers. He also finished his work on the autoload functions in SPL
this week.

Rasmus Lerdorf gave core CVS access to Johannes Schlüter (finally!) at Marcus’
request, and Dan Scott, now known as dbs, at Wez’s instigation. Dan promptly joined
Magnus Määttä in the task of providing PDO and PDO driver test suites.

In a surprise move, Zeev committed a new egg for the PHP Easter logo. His dog,
not Stig’s, apparently. (Why does it look like a rabbit?)

Short version: Welcome on board, Dan and Johannes!

PAT: Shutdown order changes

Wez asked whether there were any objections to his applying a fix for ‘the
unload-module-before-calling-object-dtors bug
‘ (AKA dl()
shutdown)?

Zeev reviewed the patch. He felt it was good, but suggested that it should also
remove redundant code. He wanted to know whether Wez intended it to be applied to
the 5_0 branch or just CVS HEAD, seeing as shutdown order changes ‘almost always
bundle one surprise or another
‘. Wez committed the patch to both PHP 5 branches
following a lengthy review of his own.

Timm supplied a fix for the Reflection API allowing a public static instance
defined as NULL to actually be recognized as NULL. This
was committed immediately by Marcus.

Short version: Nothing new for the PAT
directory
this week.