Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72826
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <cf540d102b16dc2f6da10a343378623c.squirrel@webmail.klapt.com>
In-Reply-To:
 <CAGAGxbash9zbFRDJTAGF-Fo3cdCuPkHVXdjj6ShXF2jp8Bn=PQ@mail.gmail.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>
Date: Wed, 26 Feb 2014 16:37:05 +0100
To: "Chris Wright" <daverandom@php.net>
Cc: "Anatol Belski" <anatol.php@belski.net>,
 "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>,
 =?UTF-8?Q?=22P=C3=A1draic_Brady=22?= <padraic.brady@gmail.com>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Windows Peer Verification
From: anatol.php@belski.net ("Anatol Belski")

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