Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72906
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.46 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <cf540d102b16dc2f6da10a343378623c.squirrel@webmail.klapt.com>
References: <CAH8MpnnmKt2byQU8DcWetnK6W7GB9HuF3srea-ECwQ4RRe1SWQ@mail.gmail.com>
	<CAGAGxbaZ5aCdSxsQrw05_xyxKEAhQY6uGaoAu06GkudKOtdqoQ@mail.gmail.com>
	<CAGAGxbYbvrF+aQP-Tm9S=+t0CXPMKaHuOAXqZO4ZOxtuNMQHPA@mail.gmail.com>
	<54df89551690b2af245dba8088c7032b.squirrel@webmail.klapt.com>
	<CAGAGxbYuEaFLGwR8RhZe5JN5yx_7Mj7Hbxt5U_nPfzpr7v1H+A@mail.gmail.com>
	<312e6d746acb3dec7cf7077ca4e7a804.squirrel@webmail.klapt.com>
	<CAGAGxbash9zbFRDJTAGF-Fo3cdCuPkHVXdjj6ShXF2jp8Bn=PQ@mail.gmail.com>
	<cf540d102b16dc2f6da10a343378623c.squirrel@webmail.klapt.com>
Date: Sun, 2 Mar 2014 21:07:19 +0000
Message-ID: <CAGAGxbbO6uz7OmM4DYMK=WaWKm-Tshi=y-trQdwr653FUcisVA@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Chris Wright <daverandom@php.net>, "internals@lists.php.net" <internals@lists.php.net>, 
	Daniel Lowrey <rdlowrey@gmail.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	Pierre Joye <pierre.php@gmail.com>, =?ISO-8859-1?Q?P=E1draic_Brady?= <padraic.brady@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Windows Peer Verification
From: daverandom@php.net (Chris Wright)

Hi Anatol

Just to follow up on this, I've been kicking around a few ideas to try
and come up with a better way to test this but I've not come up with
anything workable - mostly I've been trying to come up with something
sane based on non-blocking I/O and have concluded that there's no way
to do it that doesn't involved too much code for a meaningful unit
test (and it's of limited usefulness anyway). There really are a lot
of variables here and it's difficult to come up with something that's
going to work in every environment every time, which for me really
limits the usefulness anything you might call a unit test.

One thing I was pondering is throwing together a small server that
could be started by run-tests.php in another process before any tests
are run, which exposes a set of various defined behaviours on various
ports. This way, all unit tests that involve testing the client side
(or where which side you test from is irrelevant) can simply connect
to the appropriate port for the behaviour they want. This would also
have the benefit of making the tests themselves (considerably)
simpler. However, even I am still not sure whether I like the idea.

Thoughts?

On 26 February 2014 15:37, Anatol Belski <anatol.php@belski.net> wrote:
> Hi Chris,
>
> On Wed, February 26, 2014 12:57, Chris Wright wrote:
>> On 26 February 2014 11:35, Anatol Belski <anatol.php@belski.net> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>> On Wed, February 26, 2014 12:09, Chris Wright wrote:
>>>
>>>> Hi Anatol
>>>>
>>>>
>>>>
>>>> It's interesting that you should have a problem here, both Daniel and
>>>>  I extensively "tested the tests" to ensure they would run and pass
>>>> on both windows and *nix - although I never tested on mac because I
>>>> don't have easy access to one (I'm not sure if Daniel did) but I
>>>> assumed they would work nicely there since they worked on all the *nix
>>>> flavours I tested. WHat OS are you running these on?
>>>>
>>> It's win8 64 bit build of the PHP-5.6
>>>
>>>>
>>>> The diff you show doesn't look like it would fix the problem as it
>>>> seems to be waiting for eof on stdin in the worker, which shouldn't
>>>> ever happen until the test is completed in the main process (the
>>>> handle isn't closed until the main process code has finished
>>>> executing, which if it uses a `wait()` will never happen if the worker
>>>> executes successfully.
>>> The issue I saw there is that while(1) has never exited because it's
>>> expected '---' to appear to break. The way i did it at least jumps out
>>> from the loop. For example stream_server_reneg_limit.phpt does
>>> something else, but also hangs forever similar way. Maybe the piece with
>>> '---'
>>> should be restored and '---' appended to all the tests, but actually it
>>> were better to not depend on that.
>>
>> The reason it was designed like this is to allow two way communication
>> between the processes via their standard streams to remain open, so that
>> the wait/notify system works in both directions. As it stands none of the
>> tests use this, but I figured it was better to leave it there for future
>> use. It's somewhat concerning if `---` never appears in the stream and
>> that loop runs forever, since it's explicitly added as an end delimiter by
>> spawnWorkerProcess()...
>>
>> stream_server_reneg_client.phpt is actually something of a special case.
>> It's a dirty hack using an external openssl binary to trigger
>> renegotiations, as there's no way to trigger this directly in userland PHP
>> at the moment, and both Daniel and I had issues running this test on
>> Windows. As it turned out, the reason for this was actually a very
>> old and buggy openssl binary that ships with msysgit bins and so was in
>> %path% - when we installed a 1.0.1f binary from
>> http://slproweb.com/products/Win32OpenSSL.html the test ran without
>> issues. I'm working to figure out exactly when the bug was fixed so we can
>> check for it in the SKIPIF.
>>
>> Are you having issues with only certain tests or is it all of the
>> modified ones?
>>
>>>
>>>> I think it's likely that your machine is having difficulties
>>>> launching the background process for some reason, I suggest you
>>>> inspect the $cmd path generated in spawnWorkerProcess().
>>>>
>>> I've checked that by copying the server code explicitly and ran it in a
>>>  separate process. The hang was still there (so not leaving the
>>> while(1) part), for instance with bug46127.phpt .
>>>
>>>> One thought that does occur is that it might be worth changing the
>>>> sprintf pattern to "%s" "%s" %s - if you had any spaces in the path to
>>>> the PHP binary then the unquoted command would probably fail to
>>>> launch.
>>> There are no spaces in the paths, that's standard approach with
>>> c:\php-sdk\... I'll try this anyway.
>>>
>>
>> OK that's not likely to be the issue here then, although we should
>> probably still make the change to cover this case.
>>
>>> Have you tested also on 64 bit builds? Maybe it's specific to that. But
>>>  the impression I have is that there's something in the PHP
>>> code/environment behaving different for whatever reason.
>>
>> I've not run the tests against a 64 bit build, I did create a 64 bit
>> binary to verify that it worked but I ran the tests against a 32 bit build.
>>
> I've figured out what's wrong. The issue is the way how the server process
> is spawned, under circumstances it might not load the openssl extension.
> That's none of issue when openssl is compiled statically like it often
> might be done on linux. On windows it's always shared, so the solution is
> to ensure there's a suitable php.ini is laying around or explicitly
> passing a temporary php.ini to the spawnee and ensuring the openssl deps
> are on the path.
>
> Still stream_server_reneg_limit.phpt hangs, but sa you mentioned that
> being an issue. Lets see how it behaves further.
>
> Thanks for the help on this.
>
> Anatol