#38273 [Bgs]: Incorrect return address after the execution of a signal handler?
ID: 38273 User updated by: axelluttgens at swing dot be Reported By: axelluttgens at swing dot be Status: Bogus Bug Type: PCNTL related Operating System: Mac OSX 10.4.7 PHP Version: 5.2.4 New Comment: Yes, of course. :-) Thanks a lot, Axel Previous Comments: [2009-03-19 13:26:54] lbarn...@php.net Looking at this code, we can see that between socket_select() call and HandleInt() call, the code have no tickable statements. So the first time the tick functions (signal handlers) are called after socket_select() is before returning from PollSigs(). This is why the output differs in the first interrupt. This also explains why the two variants (the one with a dummy statement before calling PollSigs() and the one with switch) have a different behavior. (this is at most counter-intuitive, but not a bug) [2008-07-19 22:25:58] axelluttgens at swing dot be Hello Jani, Thanks for your follow-up. But I don't understand the relationship with ticks. Could you explain? TIA, Axel [2008-07-18 16:16:09] j...@php.net Ticks are deprecated in PHP 5.3.0 and will be completely removed in PHP 6. We're not going to waste time trying to fix the inherently broken thing. [2007-07-14 11:03:56] axelluttgens at swing dot be So, as announced, I've compiled the php5.2-200707130630 snapshot. Here follows the output of a php -i command: PHP Version = 5.2.4-dev System = Darwin ALMbp.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 Build Date = Jul 13 2007 10:13:10 Configure Command = './configure' '--prefix=/usr/local/php5' '--with-zlib-dir=/usr' '--with-zlib' '--enable-zip' '--enable-mbstring' '--enable-exif' '--enable-sockets' '--enable-ftp' '--enable-pcntl' '--with-iodbc=/usr' '--with-curl=/usr' '--with-curlwrappers' '--with-ldap=/usr' '--with-kerberos=/usr' '--with-apxs=/usr/sbin/apxs Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /usr/local/php5/lib Loaded Configuration File = (none) PHP API = 20041225 PHP Extension = 20060613 Zend Extension = 220060519 Debug Build = no Thread Safety = disabled Zend Memory Manager = enabled IPv6 Support = enabled Registered PHP Streams = zip, php, file, data, ftp, gopher, telnet, dict, ldap, http, https, ftps, compress.zlib Registered Stream Socket Transports = tcp, udp, unix, udg Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, zlib.* This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Of course, things have changed since July 2006, as I am now on an Intel Mac, with OS X 10.4.10. Anyway, I doubt to be able to exacly reproduce the former environement; but, if needed, I could perhaps try the same on a 10.4.10 PPC. So, I first tried the original reproduce code, the one dated 2006-07-31 with the if statement. It seems that I still get the unexpected behavior when the dummy statement ($err = $err;) is commented out: $ ./sigtest.php ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Handling SIGINT Received SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Handling SIGINT Received SIGINT [and so on...] and that uncommenting the dummy statement still brings the expected behavior back: $ ./sigtest.php ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT Handling SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT Handling SIGINT [and so on...] In a word, it looks like the same behavior has been carried over from php 4 to php 5. On the other hand, re-reading my variant dated 2006-08-02, the one with the switch statement instead of the if statement, I believe I just introduced noise (sorry for that...). Indeed, one may notice that I
#38273 [WFx]: Incorrect return address after the execution of a signal handler?
ID: 38273 User updated by: axelluttgens at swing dot be Reported By: axelluttgens at swing dot be Status: Wont fix Bug Type: PCNTL related Operating System: Mac OSX 10.4.7 PHP Version: 5.2.4 New Comment: Hello Jani, Thanks for your follow-up. But I don't understand the relationship with ticks. Could you explain? TIA, Axel Previous Comments: [2008-07-18 16:16:09] [EMAIL PROTECTED] Ticks are deprecated in PHP 5.3.0 and will be completely removed in PHP 6. We're not going to waste time trying to fix the inherently broken thing. [2007-07-14 11:03:56] axelluttgens at swing dot be So, as announced, I've compiled the php5.2-200707130630 snapshot. Here follows the output of a php -i command: PHP Version = 5.2.4-dev System = Darwin ALMbp.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 Build Date = Jul 13 2007 10:13:10 Configure Command = './configure' '--prefix=/usr/local/php5' '--with-zlib-dir=/usr' '--with-zlib' '--enable-zip' '--enable-mbstring' '--enable-exif' '--enable-sockets' '--enable-ftp' '--enable-pcntl' '--with-iodbc=/usr' '--with-curl=/usr' '--with-curlwrappers' '--with-ldap=/usr' '--with-kerberos=/usr' '--with-apxs=/usr/sbin/apxs Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /usr/local/php5/lib Loaded Configuration File = (none) PHP API = 20041225 PHP Extension = 20060613 Zend Extension = 220060519 Debug Build = no Thread Safety = disabled Zend Memory Manager = enabled IPv6 Support = enabled Registered PHP Streams = zip, php, file, data, ftp, gopher, telnet, dict, ldap, http, https, ftps, compress.zlib Registered Stream Socket Transports = tcp, udp, unix, udg Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, zlib.* This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Of course, things have changed since July 2006, as I am now on an Intel Mac, with OS X 10.4.10. Anyway, I doubt to be able to exacly reproduce the former environement; but, if needed, I could perhaps try the same on a 10.4.10 PPC. So, I first tried the original reproduce code, the one dated 2006-07-31 with the if statement. It seems that I still get the unexpected behavior when the dummy statement ($err = $err;) is commented out: $ ./sigtest.php ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Handling SIGINT Received SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Handling SIGINT Received SIGINT [and so on...] and that uncommenting the dummy statement still brings the expected behavior back: $ ./sigtest.php ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT Handling SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT Handling SIGINT [and so on...] In a word, it looks like the same behavior has been carried over from php 4 to php 5. On the other hand, re-reading my variant dated 2006-08-02, the one with the switch statement instead of the if statement, I believe I just introduced noise (sorry for that...). Indeed, one may notice that I introduced a statement between the case SOCKET_EINTR: and the PollSigs() call. Removing that extraneous statement, the socket_clear_error() call, I just get the same unexpected behavior as with he original reproduce code. In a sense, this is good news, as the basic features of the language thus behave similary! HTH, Axel [2007-07-13 07:56:57] axelluttgens at swing dot be Hello Jani, I'll try to test the case with the php5.2-200707130630 snapshot during this week-end. Thanks for the follow-up, Axel [2007-07-11 13:05:39] [EMAIL PROTECTED] Please try the 5.2 snapshot as requested before. We are going to discontinue support for PHP 4
#38273 [Fbk-Opn]: Incorrect return address after the execution of a signal handler?
ID: 38273 User updated by: axelluttgens at swing dot be Reported By: axelluttgens at swing dot be -Status: Feedback +Status: Open Bug Type: PCNTL related Operating System: Mac OSX 10.4.7 PHP Version: 4.4.2 New Comment: So, as announced, I've compiled the php5.2-200707130630 snapshot. Here follows the output of a php -i command: PHP Version = 5.2.4-dev System = Darwin ALMbp.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 Build Date = Jul 13 2007 10:13:10 Configure Command = './configure' '--prefix=/usr/local/php5' '--with-zlib-dir=/usr' '--with-zlib' '--enable-zip' '--enable-mbstring' '--enable-exif' '--enable-sockets' '--enable-ftp' '--enable-pcntl' '--with-iodbc=/usr' '--with-curl=/usr' '--with-curlwrappers' '--with-ldap=/usr' '--with-kerberos=/usr' '--with-apxs=/usr/sbin/apxs Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /usr/local/php5/lib Loaded Configuration File = (none) PHP API = 20041225 PHP Extension = 20060613 Zend Extension = 220060519 Debug Build = no Thread Safety = disabled Zend Memory Manager = enabled IPv6 Support = enabled Registered PHP Streams = zip, php, file, data, ftp, gopher, telnet, dict, ldap, http, https, ftps, compress.zlib Registered Stream Socket Transports = tcp, udp, unix, udg Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, zlib.* This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Of course, things have changed since July 2006, as I am now on an Intel Mac, with OS X 10.4.10. Anyway, I doubt to be able to exacly reproduce the former environement; but, if needed, I could perhaps try the same on a 10.4.10 PPC. So, I first tried the original reproduce code, the one dated 2006-07-31 with the if statement. It seems that I still get the unexpected behavior when the dummy statement ($err = $err;) is commented out: $ ./sigtest.php ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Handling SIGINT Received SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Handling SIGINT Received SIGINT [and so on...] and that uncommenting the dummy statement still brings the expected behavior back: $ ./sigtest.php ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT Handling SIGINT ^C Warning: socket_select(): unable to select [4]: Interrupted system call in /Volumes/ALMbpData/sigtest.php on line 32 Received SIGINT Handling SIGINT [and so on...] In a word, it looks like the same behavior has been carried over from php 4 to php 5. On the other hand, re-reading my variant dated 2006-08-02, the one with the switch statement instead of the if statement, I believe I just introduced noise (sorry for that...). Indeed, one may notice that I introduced a statement between the case SOCKET_EINTR: and the PollSigs() call. Removing that extraneous statement, the socket_clear_error() call, I just get the same unexpected behavior as with he original reproduce code. In a sense, this is good news, as the basic features of the language thus behave similary! HTH, Axel Previous Comments: [2007-07-13 07:56:57] axelluttgens at swing dot be Hello Jani, I'll try to test the case with the php5.2-200707130630 snapshot during this week-end. Thanks for the follow-up, Axel [2007-07-11 13:05:39] [EMAIL PROTECTED] Please try the 5.2 snapshot as requested before. We are going to discontinue support for PHP 4 this year so it is very unlikely that this bug will ever get fixed in PHP 4. But if the bug does not exist in PHP 5.2 it's possible to backport the fix from it to PHP 4. [2006-08-02 11:05:58] axelluttgens at swing dot be As a follow-up: a switch statement, instead of reproduce code's if statement, does not seem to be affected by the problem. So, replacing the while loop in reproduce code with this one: while
#38273 [Fbk-Opn]: Incorrect return address after the execution of a signal handler?
ID: 38273
User updated by: axelluttgens at swing dot be
Reported By: axelluttgens at swing dot be
-Status: Feedback
+Status: Open
Bug Type: PCNTL related
Operating System: Mac OSX 10.4.7
PHP Version: 4.4.2
New Comment:
Hello Jani,
I'll try to test the case with the php5.2-200707130630 snapshot during
this week-end.
Thanks for the follow-up,
Axel
Previous Comments:
[2007-07-11 13:05:39] [EMAIL PROTECTED]
Please try the 5.2 snapshot as requested before. We are going to
discontinue support for PHP 4 this year so it is very unlikely that this
bug will ever get fixed in PHP 4. But if the bug does not exist in PHP
5.2 it's possible to backport the fix from it to PHP 4.
[2006-08-02 11:05:58] axelluttgens at swing dot be
As a follow-up: a switch statement, instead of reproduce code's if
statement, does not seem to be affected by the problem.
So, replacing the while loop in reproduce code with this one:
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL,
NULL))
switch ($err = socket_last_error())
{
case SOCKET_EINTR:
socket_clear_error();
PollSigs();
break;
default:
echo socket_select() failed with $err\n;
break 2;
}
I get the expected behavior back (without having to resort to the
dummy statement kludge):
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 32
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 32
Received SIGINT
Handling SIGINT
Could this be of some help for narrowing the cause?
[2006-08-01 11:59:14] axelluttgens at swing dot be
Hello Tony, thanks again for your follow up!
For various reasons, I am currently really stuck with PHP 4 here. In
that sense, PHP 5 isn't an alternative for me yet.
But perhaps were you considering a very precise point?
Do you want me to try something else?
TIA,
Axel
[2006-07-31 20:13:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-07-31 19:40:17] axelluttgens at swing dot be
Description:
It seems there is a problem with the construction of the return address
to be used after an interrupt handler.
Now, I'm not sure whether the problem is a general one, or more
precisely located in the socket_xxx() family of functions.
I used the socket_select() function for building the example, as I
needed a function whose execution is liable to be suspended until the
occurence of an interrupt.
But the workaround described hereafter anyway seems to reveal some
misbehavior.
Reproduce code:
---
Create an executable file, say sigtest.php, with following contents:
#!/usr/local/bin/php
?php
declare(ticks = 1);
$gotINT = FALSE;
function SaveINT()
{
$GLOBALS['gotINT'] = TRUE;
echo Received SIGINT\n;
}
function HandleINT()
{
echo Handling SIGINT\n;
}
function PollSigs()
{
if ($GLOBALS['gotINT'])
HandleINT();
}
pcntl_signal(SIGINT, 'SaveINT');
$endpoint = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($endpoint, '127.0.0.1', 12345);
socket_listen($endpoint, 10);
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL,
NULL))
if (($err = socket_last_error()) === SOCKET_EINTR)
{
# $err = $err;
PollSigs();
}
else
{
echo socket_select() failed with $err\n;
exit(1);
}
?
Expected result:
During execution of above file on the terminal, a break (^C) should
result in:
1. the capture of SIGINT, and thus the execution of SaveINT(),
2. the continuation of execution after socket_select(), and thus the
execution of HandleINT() consecutively to the call of PollSigs().
Actual result:
--
[1] With above code, launching the executable yields:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Handling SIGINT
Received SIGINT
[2] Now, uncomment the
# $err
#38273 [Opn]: Incorrect return address after the execution of a signal handler?
ID: 38273
User updated by: axelluttgens at swing dot be
Reported By: axelluttgens at swing dot be
Status: Open
Bug Type: PCNTL related
Operating System: Mac OS 10.4.7
PHP Version: 4.4.2
New Comment:
As a follow-up: a switch statement, instead of reproduce code's if
statement, does not seem to be affected by the problem.
So, replacing the while loop in reproduce code with this one:
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL,
NULL))
switch ($err = socket_last_error())
{
case SOCKET_EINTR:
socket_clear_error();
PollSigs();
break;
default:
echo socket_select() failed with $err\n;
break 2;
}
I get the expected behavior back (without having to resort to the
dummy statement kludge):
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 32
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 32
Received SIGINT
Handling SIGINT
Could this be of some help for narrowing the cause?
Previous Comments:
[2006-08-01 11:59:14] axelluttgens at swing dot be
Hello Tony, thanks again for your follow up!
For various reasons, I am currently really stuck with PHP 4 here. In
that sense, PHP 5 isn't an alternative for me yet.
But perhaps were you considering a very precise point?
Do you want me to try something else?
TIA,
Axel
[2006-07-31 20:13:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-07-31 19:40:17] axelluttgens at swing dot be
Description:
It seems there is a problem with the construction of the return address
to be used after an interrupt handler.
Now, I'm not sure whether the problem is a general one, or more
precisely located in the socket_xxx() family of functions.
I used the socket_select() function for building the example, as I
needed a function whose execution is liable to be suspended until the
occurence of an interrupt.
But the workaround described hereafter anyway seems to reveal some
misbehavior.
Reproduce code:
---
Create an executable file, say sigtest.php, with following contents:
#!/usr/local/bin/php
?php
declare(ticks = 1);
$gotINT = FALSE;
function SaveINT()
{
$GLOBALS['gotINT'] = TRUE;
echo Received SIGINT\n;
}
function HandleINT()
{
echo Handling SIGINT\n;
}
function PollSigs()
{
if ($GLOBALS['gotINT'])
HandleINT();
}
pcntl_signal(SIGINT, 'SaveINT');
$endpoint = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($endpoint, '127.0.0.1', 12345);
socket_listen($endpoint, 10);
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL,
NULL))
if (($err = socket_last_error()) === SOCKET_EINTR)
{
# $err = $err;
PollSigs();
}
else
{
echo socket_select() failed with $err\n;
exit(1);
}
?
Expected result:
During execution of above file on the terminal, a break (^C) should
result in:
1. the capture of SIGINT, and thus the execution of SaveINT(),
2. the continuation of execution after socket_select(), and thus the
execution of HandleINT() consecutively to the call of PollSigs().
Actual result:
--
[1] With above code, launching the executable yields:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Handling SIGINT
Received SIGINT
[2] Now, uncomment the
# $err = $err;
line in the source and launch the executable again:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
The dummy instruction (ie, $err = $err;) thus allows to restore
exepected behavior.
--
Edit this bug report at http://bugs.php.net/?id=38273edit=1
#38273 [Fbk-Opn]: Incorrect return address after the execution of a signal handler?
ID: 38273
User updated by: axelluttgens at swing dot be
Reported By: axelluttgens at swing dot be
-Status: Feedback
+Status: Open
Bug Type: PCNTL related
Operating System: Mac OS 10.4.7
PHP Version: 4.4.2
New Comment:
Hello Tony, thanks again for your follow up!
For various reasons, I am currently really stuck with PHP 4 here. In
that sense, PHP 5 isn't an alternative for me yet.
But perhaps were you considering a very precise point?
Do you want me to try something else?
TIA,
Axel
Previous Comments:
[2006-07-31 20:13:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-07-31 19:40:17] axelluttgens at swing dot be
Description:
It seems there is a problem with the construction of the return address
to be used after an interrupt handler.
Now, I'm not sure whether the problem is a general one, or more
precisely located in the socket_xxx() family of functions.
I used the socket_select() function for building the example, as I
needed a function whose execution is liable to be suspended until the
occurence of an interrupt.
But the workaround described hereafter anyway seems to reveal some
misbehavior.
Reproduce code:
---
Create an executable file, say sigtest.php, with following contents:
#!/usr/local/bin/php
?php
declare(ticks = 1);
$gotINT = FALSE;
function SaveINT()
{
$GLOBALS['gotINT'] = TRUE;
echo Received SIGINT\n;
}
function HandleINT()
{
echo Handling SIGINT\n;
}
function PollSigs()
{
if ($GLOBALS['gotINT'])
HandleINT();
}
pcntl_signal(SIGINT, 'SaveINT');
$endpoint = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($endpoint, '127.0.0.1', 12345);
socket_listen($endpoint, 10);
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL,
NULL))
if (($err = socket_last_error()) === SOCKET_EINTR)
{
# $err = $err;
PollSigs();
}
else
{
echo socket_select() failed with $err\n;
exit(1);
}
?
Expected result:
During execution of above file on the terminal, a break (^C) should
result in:
1. the capture of SIGINT, and thus the execution of SaveINT(),
2. the continuation of execution after socket_select(), and thus the
execution of HandleINT() consecutively to the call of PollSigs().
Actual result:
--
[1] With above code, launching the executable yields:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Handling SIGINT
Received SIGINT
[2] Now, uncomment the
# $err = $err;
line in the source and launch the executable again:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
The dummy instruction (ie, $err = $err;) thus allows to restore
exepected behavior.
--
Edit this bug report at http://bugs.php.net/?id=38273edit=1
#38273 [NEW]: Incorrect return address after the execution of a signal handler?
From: axelluttgens at swing dot be
Operating system: Mac OS 10.4.7
PHP version: 4.4.2
PHP Bug Type: PCNTL related
Bug description: Incorrect return address after the execution of a signal
handler?
Description:
It seems there is a problem with the construction of the return address to
be used after an interrupt handler.
Now, I'm not sure whether the problem is a general one, or more precisely
located in the socket_xxx() family of functions.
I used the socket_select() function for building the example, as I needed
a function whose execution is liable to be suspended until the occurence
of an interrupt.
But the workaround described hereafter anyway seems to reveal some
misbehavior.
Reproduce code:
---
Create an executable file, say sigtest.php, with following contents:
#!/usr/local/bin/php
?php
declare(ticks = 1);
$gotINT = FALSE;
function SaveINT()
{
$GLOBALS['gotINT'] = TRUE;
echo Received SIGINT\n;
}
function HandleINT()
{
echo Handling SIGINT\n;
}
function PollSigs()
{
if ($GLOBALS['gotINT'])
HandleINT();
}
pcntl_signal(SIGINT, 'SaveINT');
$endpoint = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($endpoint, '127.0.0.1', 12345);
socket_listen($endpoint, 10);
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL, NULL))
if (($err = socket_last_error()) === SOCKET_EINTR)
{
# $err = $err;
PollSigs();
}
else
{
echo socket_select() failed with $err\n;
exit(1);
}
?
Expected result:
During execution of above file on the terminal, a break (^C) should result
in:
1. the capture of SIGINT, and thus the execution of SaveINT(),
2. the continuation of execution after socket_select(), and thus the
execution of HandleINT() consecutively to the call of PollSigs().
Actual result:
--
[1] With above code, launching the executable yields:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call in
/Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call in
/Volumes/Data/Sources/sigtest.php on line 31
Handling SIGINT
Received SIGINT
[2] Now, uncomment the
# $err = $err;
line in the source and launch the executable again:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call in
/Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call in
/Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
The dummy instruction (ie, $err = $err;) thus allows to restore exepected
behavior.
--
Edit bug report at http://bugs.php.net/?id=38273edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38273r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38273r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38273r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38273r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38273r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38273r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38273r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38273r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38273r=support
Expected behavior:http://bugs.php.net/fix.php?id=38273r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38273r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38273r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38273r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38273r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38273r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38273r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38273r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38273r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38273r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38273r=mysqlcfg
#38251 [Csd]: socket_select() and invalid arguments
ID: 38251
User updated by: axelluttgens at swing dot be
Reported By: axelluttgens at swing dot be
Status: Closed
Bug Type: Sockets related
Operating System: Mac OS X 10.4.7
PHP Version: 4.4.2
New Comment:
Thanks for your quick reply!
I didn't have yet the opportunity to build/test the CVS version, but I
had a quick look a the changes in the code: it seems that they indeed
should do the trick.
Thanks again,
Axel
Previous Comments:
[2006-07-30 11:54:33] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2006-07-29 16:07:27] axelluttgens at swing dot be
Sorry,the reproduce code should have a NULL timeout instead of 1 in
socket_select().
Otherwise, my comments are a bit confusing...
[2006-07-29 16:03:45] axelluttgens at swing dot be
Description:
socket_select(), when executed without timeout, is liable to block
indefinitely in case of obviously incorrect arguments.
I may be wrong, but this doesn't seem to exactly reflect the behavior
of select(2).
In which case the PHP layer might be too permissive while building the
descriptors from the arguments passed to socket_select(); perhaps by
building valid descriptors when it shouldn't be the case.
Reproduce code:
---
Create an executable file (say, test.php) with following contents:
#!/usr/local/bin/php
?php
while (!$cnt = socket_select($r = array('xyzt'), $w = NULL, $e = NULL,
1))
{
echo Count: $cnt\n;
echo Err#: , socket_last_error(), \n;
}
?
Expected result:
socket_select() should exit immediately with an error code reported
through socket_last_error() (for example SOCKET_EBADF).
Actual result:
--
[1] When running above executable, a warning gets emitted on stdout:
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 4
^C
but execution indefinitely continues in socket_select(): the loop's
body is never executed, and one has to interrupt the program (hence the
^C).
[2] Note that the behavior differs with
$r = 'xyzt';
instead of:
$r = array('xyzt');
socket_select() then exits, allowing to enter the loop's body; the
output is:
Warning: socket_select() expects parameter 1 to be
array, string given in /path/to/test.php on line 4
Count:
Err#: 0
Warning: socket_select() expects parameter 1 to be
array, string given in /path/to/test.php on line 4
Count:
Err#: 0
^C
Here, PHP quits socket_select() and reports an error (at least through
the value FALSE asigned to $cnt).
[3] Now, with
$r = array('xyzt')
again, but changing the timeout value from NULL to 1, the output is:
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Count: 0
Err#: 0
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Count: 0
Err#: 0
^C
Strange... why does the warning get emitted twice at the beginning of
the execution?
==
Additional info:
Configure Command = './configure' '--prefix=/usr/local' '--with-apxs'
'--disable-dependency-tracking' '--with-ldap=/usr'
'--with-kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr'
'--enable-trans-sid' '--with-xml' '--enable-exif' '--enable-ftp'
'--enable-mbstring' '--enable-mbregex' '--enable-dbx'
'--enable-sockets' '--with-iodbc=/usr' '--with-curl=/usr'
'--with-mysql' '--enable-dba' '--with-db4=/usr/local/BerkeleyDB'
'--enable-pcntl'
--
Edit this bug report at http://bugs.php.net/?id=38251edit=1
#38251 [NEW]: socket_select() and invalid arguments
From: axelluttgens at swing dot be
Operating system: Mac OS X 10.4.7
PHP version: 4.4.2
PHP Bug Type: Sockets related
Bug description: socket_select() and invalid arguments
Description:
socket_select(), when executed without timeout, is liable to block
indefinitely in case of obviously incorrect arguments.
I may be wrong, but this doesn't seem to exactly reflect the behavior of
select(2).
In which case the PHP layer might be too permissive while building the
descriptors from the arguments passed to socket_select(); perhaps by
building valid descriptors when it shouldn't be the case.
Reproduce code:
---
Create an executable file (say, test.php) with following contents:
#!/usr/local/bin/php
?php
while (!$cnt = socket_select($r = array('xyzt'), $w = NULL, $e = NULL,
1))
{
echo Count: $cnt\n;
echo Err#: , socket_last_error(), \n;
}
?
Expected result:
socket_select() should exit immediately with an error code reported
through socket_last_error() (for example SOCKET_EBADF).
Actual result:
--
[1] When running above executable, a warning gets emitted on stdout:
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 4
^C
but execution indefinitely continues in socket_select(): the loop's body
is never executed, and one has to interrupt the program (hence the ^C).
[2] Note that the behavior differs with
$r = 'xyzt';
instead of:
$r = array('xyzt');
socket_select() then exits, allowing to enter the loop's body; the output
is:
Warning: socket_select() expects parameter 1 to be
array, string given in /path/to/test.php on line 4
Count:
Err#: 0
Warning: socket_select() expects parameter 1 to be
array, string given in /path/to/test.php on line 4
Count:
Err#: 0
^C
Here, PHP quits socket_select() and reports an error (at least through the
value FALSE asigned to $cnt).
[3] Now, with
$r = array('xyzt')
again, but changing the timeout value from NULL to 1, the output is:
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Count: 0
Err#: 0
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Count: 0
Err#: 0
^C
Strange... why does the warning get emitted twice at the beginning of the
execution?
==
Additional info:
Configure Command = './configure' '--prefix=/usr/local' '--with-apxs'
'--disable-dependency-tracking' '--with-ldap=/usr' '--with-kerberos=/usr'
'--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' '--with-xml'
'--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex'
'--enable-dbx' '--enable-sockets' '--with-iodbc=/usr' '--with-curl=/usr'
'--with-mysql' '--enable-dba' '--with-db4=/usr/local/BerkeleyDB'
'--enable-pcntl'
--
Edit bug report at http://bugs.php.net/?id=38251edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38251r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38251r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38251r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38251r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38251r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38251r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38251r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38251r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38251r=support
Expected behavior:http://bugs.php.net/fix.php?id=38251r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38251r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38251r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38251r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38251r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38251r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38251r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38251r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38251r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38251r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38251r=mysqlcfg
#38251 [Opn]: socket_select() and invalid arguments
ID: 38251
User updated by: axelluttgens at swing dot be
Reported By: axelluttgens at swing dot be
Status: Open
Bug Type: Sockets related
Operating System: Mac OS X 10.4.7
PHP Version: 4.4.2
New Comment:
Sorry,the reproduce code should have a NULL timeout instead of 1 in
socket_select().
Otherwise, my comments are a bit confusing...
Previous Comments:
[2006-07-29 16:03:45] axelluttgens at swing dot be
Description:
socket_select(), when executed without timeout, is liable to block
indefinitely in case of obviously incorrect arguments.
I may be wrong, but this doesn't seem to exactly reflect the behavior
of select(2).
In which case the PHP layer might be too permissive while building the
descriptors from the arguments passed to socket_select(); perhaps by
building valid descriptors when it shouldn't be the case.
Reproduce code:
---
Create an executable file (say, test.php) with following contents:
#!/usr/local/bin/php
?php
while (!$cnt = socket_select($r = array('xyzt'), $w = NULL, $e = NULL,
1))
{
echo Count: $cnt\n;
echo Err#: , socket_last_error(), \n;
}
?
Expected result:
socket_select() should exit immediately with an error code reported
through socket_last_error() (for example SOCKET_EBADF).
Actual result:
--
[1] When running above executable, a warning gets emitted on stdout:
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 4
^C
but execution indefinitely continues in socket_select(): the loop's
body is never executed, and one has to interrupt the program (hence the
^C).
[2] Note that the behavior differs with
$r = 'xyzt';
instead of:
$r = array('xyzt');
socket_select() then exits, allowing to enter the loop's body; the
output is:
Warning: socket_select() expects parameter 1 to be
array, string given in /path/to/test.php on line 4
Count:
Err#: 0
Warning: socket_select() expects parameter 1 to be
array, string given in /path/to/test.php on line 4
Count:
Err#: 0
^C
Here, PHP quits socket_select() and reports an error (at least through
the value FALSE asigned to $cnt).
[3] Now, with
$r = array('xyzt')
again, but changing the timeout value from NULL to 1, the output is:
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Count: 0
Err#: 0
Warning: socket_select(): supplied argument is not a
valid Socket resource in /path/to/test.php on line 5
Count: 0
Err#: 0
^C
Strange... why does the warning get emitted twice at the beginning of
the execution?
==
Additional info:
Configure Command = './configure' '--prefix=/usr/local' '--with-apxs'
'--disable-dependency-tracking' '--with-ldap=/usr'
'--with-kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr'
'--enable-trans-sid' '--with-xml' '--enable-exif' '--enable-ftp'
'--enable-mbstring' '--enable-mbregex' '--enable-dbx'
'--enable-sockets' '--with-iodbc=/usr' '--with-curl=/usr'
'--with-mysql' '--enable-dba' '--with-db4=/usr/local/BerkeleyDB'
'--enable-pcntl'
--
Edit this bug report at http://bugs.php.net/?id=38251edit=1
#29399 [Csd]: Unserialize() really doesn't like some input strings...
ID: 29399
User updated by: AxelLuttgens at swing dot be
Reported By: AxelLuttgens at swing dot be
Status: Closed
Bug Type: Reproducible crash
Operating System: Mac OS 10.3.4
PHP Version: 4.3.8
New Comment:
Thanks a lot for the follow-up.
Sincerely,
Axel
Previous Comments:
[2004-10-04 04:22:24] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2004-07-28 16:52:32] AxelLuttgens at swing dot be
First of all, sorry for the inaccuracy of my previous information.
I forgot to use the compiled CLI, so that I used the stock install one
(which I leave in place for maintaining compatibility with Apple's
upgrades, if any).
In a word, both my compiled CLI and apache module fail in the same
way.
Fortunately, in a sense ;-)
Same crash in var_unserializer.c at line 320.
So, I reviewed what I wrote at the time of another report (Bug #26078),
which had been classified as Won't Fix.
Since then, some slight differences have been introduced in the code of
var_unserializer.re, so that the potential problems I noticed at that
time may now have turned into real problems.
So, I just tried this change in the code of var_unserializer.c:
309 if(yych = '}') goto yy13;
310 /* if(yych = '\277') goto yy15; */
311 if(yych = 255) goto yy15;
312 goto yy2;
Of course, the compile warning now goes as comparison always true.
All tests (make test) concerning serialize/unserialize pass.
(they did before too, so that I didn't notice anything at that level)
The resulting CLI and module now both accept something like this:
?php
for ($i = 0; $i 256; $i++)
{
$str = chr($i);
unserialize($str);
}
?
without crashing.
And I didn't encounter crashes with my real work php codings any more.
Of course, these are not extensive testings.
But there is good hope to be on the right way.
HTH,
Axel
[2004-07-27 18:48:49] [EMAIL PROTECTED]
Please leave at feedback until more information is
available.
[2004-07-27 17:09:39] AxelLuttgens at swing dot be
Thanks for the reply!
I downloaded the cvs, and noticed that var_unserializer.c has not been
modified since the version I have compiled (files 100% identical).
Do you really think the problem could be solved with the cvs?
I ask because I'm really busy at the moment, and possibly a bit lazy
too... :-)
But your reply of course made me think a bit further.
So, executing the short sample file through the CLI doesn't trigger the
exception.
I also performed some other quick tests, that could lead to the
conclusion that my compile has some flaws :-(
I'll investigate further, and hope to be able to keep you informed as
soon as possible.
In the meantime, sorry for what could prove to be just noise,
Axel
[2004-07-27 02:10:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I've tried the sample script and I got the expected FALSE
output as well as E_NOTICE saying: unserialize(): Error at
offset 0 of 1 bytes
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
http://bugs.php.net/29399
--
Edit this bug report at http://bugs.php.net/?id=29399edit=1
#29399 [Fbk-Opn]: Unserialize() really doesn't like some input strings...
ID: 29399
User updated by: AxelLuttgens at swing dot be
Reported By: AxelLuttgens at swing dot be
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Mac OS 10.3.4
PHP Version: 4.3.8
New Comment:
First of all, sorry for the inaccuracy of my previous information.
I forgot to use the compiled CLI, so that I used the stock install one
(which I leave in place for maintaining compatibility with Apple's
upgrades, if any).
In a word, both my compiled CLI and apache module fail in the same
way.
Fortunately, in a sense ;-)
Same crash in var_unserializer.c at line 320.
So, I reviewed what I wrote at the time of another report (Bug #26078),
which had been classified as Won't Fix.
Since then, some slight differences have been introduced in the code of
var_unserializer.re, so that the potential problems I noticed at that
time may now have turned into real problems.
So, I just tried this change in the code of var_unserializer.c:
309 if(yych = '}') goto yy13;
310 /* if(yych = '\277') goto yy15; */
311 if(yych = 255) goto yy15;
312 goto yy2;
Of course, the compile warning now goes as comparison always true.
All tests (make test) concerning serialize/unserialize pass.
(they did before too, so that I didn't notice anything at that level)
The resulting CLI and module now both accept something like this:
?php
for ($i = 0; $i 256; $i++)
{
$str = chr($i);
unserialize($str);
}
?
without crashing.
And I didn't encounter crashes with my real work php codings any more.
Of course, these are not extensive testings.
But there is good hope to be on the right way.
HTH,
Axel
Previous Comments:
[2004-07-27 18:48:49] [EMAIL PROTECTED]
Please leave at feedback until more information is
available.
[2004-07-27 17:09:39] AxelLuttgens at swing dot be
Thanks for the reply!
I downloaded the cvs, and noticed that var_unserializer.c has not been
modified since the version I have compiled (files 100% identical).
Do you really think the problem could be solved with the cvs?
I ask because I'm really busy at the moment, and possibly a bit lazy
too... :-)
But your reply of course made me think a bit further.
So, executing the short sample file through the CLI doesn't trigger the
exception.
I also performed some other quick tests, that could lead to the
conclusion that my compile has some flaws :-(
I'll investigate further, and hope to be able to keep you informed as
soon as possible.
In the meantime, sorry for what could prove to be just noise,
Axel
[2004-07-27 02:10:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I've tried the sample script and I got the expected FALSE
output as well as E_NOTICE saying: unserialize(): Error at
offset 0 of 1 bytes
[2004-07-26 23:42:50] AxelLuttgens at swing dot be
Description:
It took me a long time to locate the source of seemingly random crashes
I was experiencing these days.
But I now believe to have found a very clean example of crashing code
on my system.
Of course, my real code handles more interesting strings than the one
used in the example ;-)
This could help to explain some other bug reports related to
unserialize(), but that remained rather elusive or without a clear
conclusion.
Could also be related to another note of mine (Bug #26078).
HTH,
Axel
Reproduce code:
---
?php
$str = chr(236);
print_r(unserialize($str));
?
Expected result:
According to the docs, I would have expected unserialize() to return
FALSE, as the input string clearly doesn't result from a prior
serialize().
Actual result:
--
Here follows an excerpt of the resulting crash log:
Date/Time: 2004-07-26 17:56:11 +0200
OS Version: 10.3.4 (Build 7H63)
Report Version: 2
Command: httpd
Path:/usr/sbin/httpd
PID: 1237
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0002
Thread 0 Crashed:
0 libphp4.so 0x020eccc8 php_var_unserialize + 0x180
(var_unserializer.c:320)
1 libphp4.so 0x020e5418 zif_unserialize + 0xa4 (var.c:681)
2 libphp4.so 0x0214bc68 execute + 0x1b58 (zend_execute.c:1635)
3 libphp4.so 0x0213db34
#29399 [Fbk-Opn]: Unserialize() really doesn't like some input strings...
ID: 29399 User updated by: AxelLuttgens at swing dot be Reported By: AxelLuttgens at swing dot be -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Mac OS 10.3.4 PHP Version: 4.3.8 New Comment: Thanks for the reply! I downloaded the cvs, and noticed that var_unserializer.c has not been modified since the version I have compiled (files 100% identical). Do you really think the problem could be solved with the cvs? I ask because I'm really busy at the moment, and possibly a bit lazy too... :-) But your reply of course made me think a bit further. So, executing the short sample file through the CLI doesn't trigger the exception. I also performed some other quick tests, that could lead to the conclusion that my compile has some flaws :-( I'll investigate further, and hope to be able to keep you informed as soon as possible. In the meantime, sorry for what could prove to be just noise, Axel Previous Comments: [2004-07-27 02:10:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I've tried the sample script and I got the expected FALSE output as well as E_NOTICE saying: unserialize(): Error at offset 0 of 1 bytes [2004-07-26 23:42:50] AxelLuttgens at swing dot be Description: It took me a long time to locate the source of seemingly random crashes I was experiencing these days. But I now believe to have found a very clean example of crashing code on my system. Of course, my real code handles more interesting strings than the one used in the example ;-) This could help to explain some other bug reports related to unserialize(), but that remained rather elusive or without a clear conclusion. Could also be related to another note of mine (Bug #26078). HTH, Axel Reproduce code: --- ?php $str = chr(236); print_r(unserialize($str)); ? Expected result: According to the docs, I would have expected unserialize() to return FALSE, as the input string clearly doesn't result from a prior serialize(). Actual result: -- Here follows an excerpt of the resulting crash log: Date/Time: 2004-07-26 17:56:11 +0200 OS Version: 10.3.4 (Build 7H63) Report Version: 2 Command: httpd Path:/usr/sbin/httpd PID: 1237 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0002 Thread 0 Crashed: 0 libphp4.so 0x020eccc8 php_var_unserialize + 0x180 (var_unserializer.c:320) 1 libphp4.so 0x020e5418 zif_unserialize + 0xa4 (var.c:681) 2 libphp4.so 0x0214bc68 execute + 0x1b58 (zend_execute.c:1635) 3 libphp4.so 0x0213db34 zend_execute_scripts + 0xd8 (zend.c:892) 4 libphp4.so 0x02113064 php_execute_script + 0x258 (main.c:1736) 5 libphp4.so 0x0214f958 apache_php_module_main + 0xb8 (sapi_apache.c:59) 6 libphp4.so 0x02150618 send_php + 0x294 (mod_php4.c:623) 7 httpd 0xd05c ap_invoke_handler + 0xe8 [...] -- Edit this bug report at http://bugs.php.net/?id=29399edit=1
#29399 [NEW]: Unserialize() really doesn't like some input strings...
From: AxelLuttgens at swing dot be Operating system: Mac OS 10.3.4 PHP version: 4.3.8 PHP Bug Type: Reproducible crash Bug description: Unserialize() really doesn't like some input strings... Description: It took me a long time to locate the source of seemingly random crashes I was experiencing these days. But I now believe to have found a very clean example of crashing code on my system. Of course, my real code handles more interesting strings than the one used in the example ;-) This could help to explain some other bug reports related to unserialize(), but that remained rather elusive or without a clear conclusion. Could also be related to another note of mine (Bug #26078). HTH, Axel Reproduce code: --- ?php $str = chr(236); print_r(unserialize($str)); ? Expected result: According to the docs, I would have expected unserialize() to return FALSE, as the input string clearly doesn't result from a prior serialize(). Actual result: -- Here follows an excerpt of the resulting crash log: Date/Time: 2004-07-26 17:56:11 +0200 OS Version: 10.3.4 (Build 7H63) Report Version: 2 Command: httpd Path:/usr/sbin/httpd PID: 1237 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0002 Thread 0 Crashed: 0 libphp4.so 0x020eccc8 php_var_unserialize + 0x180 (var_unserializer.c:320) 1 libphp4.so 0x020e5418 zif_unserialize + 0xa4 (var.c:681) 2 libphp4.so 0x0214bc68 execute + 0x1b58 (zend_execute.c:1635) 3 libphp4.so 0x0213db34 zend_execute_scripts + 0xd8 (zend.c:892) 4 libphp4.so 0x02113064 php_execute_script + 0x258 (main.c:1736) 5 libphp4.so 0x0214f958 apache_php_module_main + 0xb8 (sapi_apache.c:59) 6 libphp4.so 0x02150618 send_php + 0x294 (mod_php4.c:623) 7 httpd 0xd05c ap_invoke_handler + 0xe8 [...] -- Edit bug report at http://bugs.php.net/?id=29399edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29399r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29399r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29399r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29399r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29399r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29399r=needscript Try newer version: http://bugs.php.net/fix.php?id=29399r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29399r=support Expected behavior: http://bugs.php.net/fix.php?id=29399r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29399r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29399r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29399r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29399r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29399r=dst IIS Stability: http://bugs.php.net/fix.php?id=29399r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29399r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29399r=float
#26078 [NEW]: Comparison always false in var_unserializer.c
From: AxelLuttgens at swing dot be
Operating system: Darwin 7.0.0 (Panther)
PHP version: 4.3.3
PHP Bug Type: Compile Warning
Bug description: Comparison always false in var_unserializer.c
Description:
I know this has already been reported, with reassuring replies such as
that warning may be safely ignored or there is no need to fix this
one.
A a reminder, the message goes so:
var_unserializer.c:308: warning: comparison is always false due to limited
range of data type
(I tried with PHP 4.3.3, as well as with php4-STABLE-200311020830: same
results)
I am of the opinion that it is just lucky programming that it works now,
and that the whole matter could easily break in case of a slight change in
the code.
I don't know much about re2c, but I think I can guess how it works by
comparing the .re and the resulting .c files.
So, looking at the var_unserializer.re file, these lines seem to be the
relevant ones:
0086: #define YYCTYPE unsigned char
0097: any = [\000-\277];
0411: any { return 0; }
0415: return 0;
Corresponding lines in var_unserializer.c are:
0087: #define YYCTYPE unsigned char
0308: if(yych = '\277') goto yy15;
0309: }
0310: }
0311: }
0312: yy2: YYCURSOR = YYMARKER;
0313: switch(yyaccept){
0314: case 0: goto yy4;
0315: }
0319: yy4:
0320: { return 0; }
0359: yy15: yych = *++YYCURSOR;
0360: goto yy4;
In the comparison, yych is promoted to an unsigned in, while (on lots of
systems) '\277' is promoted to a signed int, hence the comparison
failure.
Now, the lucky part is that yyaccept is never set in the code and thus
keeps its initialisation value (ie, zero).
So, jumping to yy15 or continuing execution through yy2 have finally the
same effect...
But the question is: shouldn't the any symbol be defined as
[\000-\377] instead of [\000-\277]?
If it is the case, I guess re2c would just forget about comparisons with
characters having decimal code greater than 127.
And one would thus alleviate spurious warnings.
If it isn't the case, well, my apologies ;-)
HTH
Axel
--
Edit bug report at http://bugs.php.net/?id=26078edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26078r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26078r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26078r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26078r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26078r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26078r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26078r=support
Expected behavior: http://bugs.php.net/fix.php?id=26078r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26078r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26078r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26078r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26078r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26078r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26078r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26078r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26078r=float
#26080 [NEW]: Comparisons always true in xml.c
From: AxelLuttgens at swing dot be
Operating system: Darwin 7.0.0 (Panther)
PHP version: 4.3.3
PHP Bug Type: Compile Warning
Bug description: Comparisons always true in xml.c
Description:
Warnings while compiling xml.c with 4.3.3 as well as
php4-STABLE-200311020830:
ext/xml/xml.c: In function `xml_utf8_encode':
ext/xml/xml.c:489: warning: comparison is always true due to limited range
of data type
ext/xml/xml.c:493: warning: comparison is always true due to limited range
of data type
Relevant lines in xml.c are:
0455: static XML_Char *xml_utf8_encode(const char *s, int len, int
*newlen, const XML_Char *encoding)
0459: unsigned short c;
0484: if (c 0x80) {
0486: } else if (c 0x800) {
0489: } else if (c 0x1) {
0493: } else if (c 0x20) {
On Darwin, a short seems to be a 32 bit value; comparisons at lines 0489
and 0493 are thus, indeed, always true.
Now, function xml_utf8_encode seems to be used only for implementing
utf8_encode(), thus for encoding iso-8559-1 into UTF-8.
So, one could be tempted to consider those warnings as don't care ones.
On the other hand, it seems that those warnings could be easily avoided
and thus allow for easier code maintenance.
HTH,
Axel
--
Edit bug report at http://bugs.php.net/?id=26080edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26080r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26080r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26080r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26080r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26080r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26080r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26080r=support
Expected behavior: http://bugs.php.net/fix.php?id=26080r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26080r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26080r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26080r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26080r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26080r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26080r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26080r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26080r=float
#26056 [Csd-Opn]: Warnings while compiling exif.c
ID: 26056
User updated by: AxelLuttgens at swing dot be
Reported By: AxelLuttgens at swing dot be
-Status: Closed
+Status: Open
Bug Type: Compile Warning
Operating System: Darwin 7.0.0 (Panther)
PHP Version: 4.3.3
New Comment:
Sorry to say so, but nothing seems to have been fixed in the snapshots:
I get exactly same warnings with php4-STABLE-200310311630 and
php4-STABLE-200311010830.
One could consider that this is more a cosmetic matter than something
to worry about; after all, it seems to work...
Yet, this could prove problematic in a long term maintenance
perspective, as there are clearly inconsistencies within a same
library: once an int, once a size_t value for similar purposes.
An int being a signed value, and a size_t being an unsigned one (seems
to be an unsigned long here), some weird truncations or expansions
could finally be overlooked on some platforms.
But I'm perhaps missing something, in which case I apologize for being
so meticulous!
And anyway, thanks for the follow-up.
Previous Comments:
[2003-10-31 09:37:41] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-10-31 09:27:39] AxelLuttgens at swing dot be
Description:
When compiling PHP, I get two warnings related to lines 1555 and 1582
of exif.c; both warnings read:
warning: passing arg 3 of `php_addslashes' from incompatible pointer
type
Function php_addslashes gets called 4 times in file ext/exif/exif.c (/*
$Id: exif.c,v 1.118.2.23 2003/06/25 13:21:54 edink Exp $ */).
In function exif_iif_add_value, where argument 'length' is of type
size_t:
line 1555: info_value-s = php_addslashes(value, length, length, 0
TSRMLS_CC);
line 1582: info_value-s = php_addslashes(value, length, length, 0
TSRMLS_CC);
In function exif_iif_add_str:
line 1708: info_data-value.s = php_addslashes(value,
strlen(value), NULL, 0 TSRMLS_CC);
In function exif_iif_add_buffer, where argument 'length' is of type
int:
line 1756: info_data-value.s = php_addslashes(value, length,
length, 0 TSRMLS_CC);
In ext/standard/string.c, definition of php_addsclashes reads as:
PHPAPI char *php_addslashes(char *str, int length, int *new_length, int
should_free TSRMLS_DC)
{
...
}
which is consistent with what appears in ext/standard/php_string.h:
PHPAPI char *php_addslashes(char *str, int length, int *new_length, int
freeit TSRMLS_DC);
Clearly, line 1708 is a don't care, and line 1756 is just compliant
with the definition of php_addslashes.
But lines 1555 and 1582 both use a length of type size_t instead of
type int.
I am wondering what the compiler really compiles (as it just warns and
goes on).
Could this be a source of confusion (such as an unsigned long being
interpreted as a signed one)?
And would it be safe to just change the definition of function
exif_iif_add_value so as to set type of argument 'lentgh' to int
instead of size_t?
--
Edit this bug report at http://bugs.php.net/?id=26056edit=1
