Edit report at https://bugs.php.net/bug.php?id=67584&edit=1
ID: 67584
Updated by: mike@php.net
Reported by: marcus at synchromedia dot co dot uk
Summary: Misleading error in pecl_http 2.0.x
Status: Assigned
Type: Bug
Package: HTTP related
Operating System: OS X
PHP Version: 5.4.30
Assigned To: mike
Block user comment: N
Private report: N
New Comment:
Doh. You could try with a CFLAGS env like:
CFLAGS="-I/usr/local/Cellar/php54-raphf/1.0.4/include
-I/usr/local/Cellar/php54-propro/1.0.0/include" pecl build
Previous Comments:
------------------------------------------------------------------------
[2014-07-08 15:39:42] marcus at synchromedia dot co dot uk
I've managed to grab your latest code from the git repo, but I don't know how to tell it
where to find the raphf header files so it's failing when I do a 'pecl build'. I
installed raphf and propro from source via homebrew, so their header files are in
/usr/local/Cellar/php54-raphf/1.0.4/include and /usr/local/Cellar/php54-propro/1.0.0/include.
------------------------------------------------------------------------
[2014-07-08 11:02:11] marcus at synchromedia dot co dot uk
I'll have a go with a fresh build.
I just tried a few variations on the breakpoint. The segfault happens when I set a breakpoint on the
'$url = ...' line. I run the script in debug mode - it echoes the first class name, then
quits with an error 139, which is a segfault. I'm running xdebug 2.2.5 in PHP 5.4.30 built from
homebrew on OS X 10.9.4.
Without the breakpoint, it does not segfault and completes successfully.
------------------------------------------------------------------------
[2014-07-08 10:23:16] mike@php.net
I forgot to answer the question about the originating request:
The response has its request as parent message:
$request = $response->getParentMessage();
------------------------------------------------------------------------
[2014-07-08 10:21:01] mike@php.net
Disregard the exception behavior I gave before, it seems I tripped over old memory.
$response->getTransferInfo("error") should contain the same information like the
exception message.
I committed a fix for the uninitialized response object to R_2_0 and master. Could you try one of
those?
Do you mean that "get_class($response);" segfaults with XDebug?
I'll have a look! What's your XDebug version=?
------------------------------------------------------------------------
[2014-07-07 15:48:20] marcus at synchromedia dot co dot uk
Thanks for getting back to me.
If I issue my requests with:
while (@$client->once()) {
$client->wait();
}
Where would failure information be stored when iterating over the output of getResponse afterwards?
Dealing with them inside that loop seems like it might interfere with the parallel nature of the
requests? If not, how can I get a handle on which Request object caused the error, assuming they
could complete or fail in random order?
When you say "I'll fix that", do you mean that getResponse will return a proper
Response instance with error info instead of complaining it's a Message?
I'm using this in two places - a link checker and an image grabber - where I want all the
requests to happen (even if some fail), in parallel, and assess the responses afterwards.
I'm also getting consistent segfaults in the test script on the first line inside the
getResponse loop if I step through it with xdebug (in PHPStorm). I don't know if that's
your department.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=67584
--
Edit this bug report at https://bugs.php.net/bug.php?id=67584&edit=1