#27403 [Bgs]: session maintenance across SSL and Non SSL pages
ID: 27403 User updated by: venky at smartxp dot com Reported By: venky at smartxp dot com Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.3.4 New Comment: I feel sorry that I thought PHP was not working properly with SSL. But the reason this was happening is: When I go to SSL page from Non SSL page then the user name in server is getting changed so the session file created in the temp is owned by SSL user name in SSL page and when in non SSL page user is different so PHP is unable to access the session file. We have solved this problem making the user name same for SSL and Non SSl page. Sorry for my poor english. Thanks Previous Comments: [2004-02-26 07:57:55] venky at smartxp dot com I am doing this on online server. In same page with same session id it is unable to open the session file and if i see on the server the session file created is with read and write permissions to the root user only. SO the error unable to open is coming how to set the whole file permissions for the session file. [2004-02-26 07:14:13] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You're doing something wrong, this works absolutely fine when a) script is correct b) configuration is correct. [2004-02-26 07:09:28] venky at smartxp dot com Description: When i access through http://mydomain/start.php it creates a session file and start session. Again when i access same file in same browser through SSL https://mydomain/start.php Warning: session_start(): open(/tmp/sess_5e99b05aa4e84d8304778ab34ae8e68a, O_RDWR) failed: Permission denied (13) in /home/www/hollywoodclicks/index.php on line 1 Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/www/hollywoodclicks/index.php:1) in /home/www/hollywoodclicks/index.php on line 1 Reproduce code: --- start.php Expected result: When i access through http://mydomain/start.php it creates a session file and start session. Again when i access same file in same browser through SSL https://mydomain/start.php Warning: session_start(): open(/tmp/sess_5e99b05aa4e84d8304778ab34ae8e68a, O_RDWR) failed: Permission denied (13) in /home/www/hollywoodclicks/index.php on line 1 Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/www/hollywoodclicks/index.php:1) in /home/www/hollywoodclicks/index.php on line 1 Actual result: -- It should maintain maitain the same session across SSL and Non SSL pages -- Edit this bug report at http://bugs.php.net/?id=27403&edit=1
#27423 [Opn]: Session hang
ID: 27423 Updated by: [EMAIL PROTECTED] Reported By: ypout at mail dot ru Status: Open Bug Type: Session related Operating System: Linux 2.4.25 PHP Version: 4.3.4 New Comment: Try a call to session_write_close() before the system()/popen() call. Previous Comments: [2004-02-27 10:35:54] ypout at mail dot ru Description: PHP sessions will hang if an external command is executed either through system() or the popen() calls. The session restores as soon as the external command terminates. The problem is when I try to follow another link in a multiframed view. Reproduce code: --- session_start(); . . set_time_limit(0); ignore_user_abort(TRUE); system($cmd, $sys_res); // Takes very long . note (I tried popen aswell) Expected result: does not matter Actual result: -- does not matter -- Edit this bug report at http://bugs.php.net/?id=27423&edit=1
#27428 [NEW]: serialize brakes output for unserialize, returning garbage
From: black at scene-si dot org
Operating system: debian unstable
PHP version: Irrelevant
PHP Bug Type: Strings related
Bug description: serialize brakes output for unserialize, returning garbage
Description:
The following has been tested on:
php-4.3.2
php-4.3.4
php-4.3.5rc2
php-4.3.5rc3
php4-STABLE-200310032330
php4-STABLE-200402101030
php4-STABLE-200402272030
with various compile options turned on/off (oracle support &
turckmmcache), always giving same result
basically with every version of this some or most serialize() calls result
in an incorrectlly constructed serialized string... given i only input
plaintext, the serialized string must have a length of 6+strlen(original),
albeit:
["cache_data"]=> string(9277) "s:9309:"... (oops!)
["cache_data"]=> string(24259) "s:24248:"... (correct.)
["cache_data"]=> string(23850) "s:23881:"... (oops!)
["cache_data"]=> string(224081) "s:224069:"... (correct.)
["cache_data"]=> string(21055) "s:21107:"... (WTF!)
["cache_data"]=> string(19590) "s:19663:"... (wrong)
...
http://scene-si.org/test.tgz - 800kb, contains 15Mb output of the
reproduce code.
http://193.77.198.80/phpinfo.php for phpinfo()
Linux dahim 2.4.23-1-686 #1 Sun Nov 30 20:51:10 EST 2003 i686 GNU/Linux
(thats the server this runs on).
the funny part is, that this code (the same code to generate the entries
in condor_dbcache) works also on other servers, also debian, iis,
apache-win, redhat, mandrake, openbsd, freebsd.. it only fucked here..
after the serialize is done, the ONLY command it goes trough is
mysql_escape_string, so there is no character or other conversions which
could explain the wrong length in serialized() output
Reproduce code:
---
";'
... but the content length is 9277..
the content was input with serialize in the following way:
$content = serialize($content);
mysql_query("update condor_dbcache set cache_timestamp='".time()."',
cache_data='".mysql_escape_string($content)."' where
cache_filename='".mysql_escape_string($filename)."'");
filename beeing the correspondant key to this dbcache table.
--
Edit bug report at http://bugs.php.net/?id=27428&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27428&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27428&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27428&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27428&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27428&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27428&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27428&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27428&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27428&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27428&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27428&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27428&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27428&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27428&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27428&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27428&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27428&r=float
#27412 [Opn]: nsapi will not load for NS/Iplanet ver 3 and 4
ID: 27412
User updated by: chris at seismo dot usbr dot gov dot spamfree
Reported By: chris at seismo dot usbr dot gov dot spamfree
Status: Open
Bug Type: iPlanet related
Operating System: IRIX 6.5
PHP Version: 4CVS, 5CVS (2004-02-27)
New Comment:
Thanks for taking a look. Given Netscape's definitive statement that
NSAPI does not support pthreads, it may be more luck than anything else
if it appears to be working for some. More likely it's implementation
dependent, as indicated by the bug reports where people just gave up on
PHP - even with Solaris. The biggest risk could be not knowing what
other problems pthreads are causing.
A more robust approach might be to always use NES/iPlanet's thread API
(NSAPI) - no matter what version or platform. Since NSAPI seems to
already include a common thread API, does PHP really need to worry with
those details?
Both NSAPI and XP_UNIX should be defined in CFLAGS because TSRM.h
includes nsapi.h. Just defining XP_UNIX or NSAPI in nsapi.c won't work.
Previous Comments:
[2004-02-27 10:27:31] [EMAIL PROTECTED]
I will go through your changes. The problem is that even in iPlanet4 /
NES3 the pthreads work correct on the most used platforms (e.g.
Solaris). So changing could be a risk and needs a lot of testing. But
for PHP5 we should think about it.
One question: Why not update to a "supported" version of the NSAPI
(e.g. SunONE webserver 6.1 ?). NES3 is really old...
One comment: explicit defining of XP_UNIX is not needed in the current
version because this is done by a #define in the sapi/nsapi/nsapi.c
file - the problem is only if you change the TSRM to include nsapi.h
here - you also need this there. But for that you can copy the code to
TSRM.
[2004-02-27 08:43:12] chris at seismo dot usbr dot gov dot spamfree
Corrections/typos:
(1) NSAPI.h should read TSRM.h
(2) Fix for TSRM.c should read
#elif defined(NSAPI)
crit_enter(mutexp); /* returns void */
return 0;
#elif defined(PI3WEB)
(3) Also need to disable test for $pthreads_working in configure NSAPI
section:
enable_experimental_zts=yes
# if test "$pthreads_working" != "yes"; then
#{ echo "configure: error: ZTS currently requires working POSIX
threads. We were unable to verify that your system supports Pthreads."
1>&2; exit 1; }
# fi
(4) sapi/nsapi/config.m4 is semi-busted even without the NSAIP
thread/pthread bug:
change
if test -d $PHP_NSAPI/include ; then
NSAPI_INCLUDE=$PHP_NSAPI/include
AC_MSG_RESULT(Netscape-Enterprise 3.x style)
AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h])
fi
to
if test -d $PHP_NSAPI/include ; then
NSAPI_INCLUDE=$PHP_NSAPI/include
AC_MSG_RESULT(Netscape-Enterprise 3.x style)
AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h])
NSAPI_INCLUDE="$NSAPI_INC_DIR -I$NSAPI_INCLUDE" dnl basic bug fix
AC_DEFINE(NSAPI,1,[ ]) dnl partial pthread fix
AC_DEFINE(XP_UNIX,1,[ ]) dnl partial pthread fix
fi
In configure, these lines would be
change
fi
if test -d $PHP_NSAPI/plugins/include ; then
test -n "$NSAPI_INCLUDE" && NSAPI_INC_DIR="-I$NSAPI_INCLUDE"
to
CFLAGS="$CFLAGS -DNSAPI -DXP_UNIX"
NSAPI_INCLUDE="$NSAPI_INC_DIR -I$NSAPI_INCLUDE"
fi
if test -d $PHP_NSAPI/plugins/include ; then
test -n "$NSAPI_INCLUDE" && NSAPI_INC_DIR="-I$NSAPI_INCLUDE"
sapi/nsapi/config.m4 needs a more general fix though, including
modifying the macro PHP_BUILD_THREAD_SAFE for
NS3 and 4 to require enable_experimental_zts=yes, but not pthread.
[2004-02-26 22:21:36] chris at seismo dot usbr dot gov dot spamfree
Description:
NSAPI with old versions of Netscape Enterprise Server (3 and 4) bombs
when the server tries to load it. PHP-cli works fine. And if one
removes the load statements from obj.conf, the server has no problem
(and no PHP). On Irix 6.5, the startup error with PHP NSAPI is "PANIC
pt_bootstrap() Couldn't INIT_THREADS - {0x0, 0x0}".
The basic problem here is that NS/Iplanet versions 3 and 4 do not
support pthreads whereas PHP requires them (sort of). See article:
http://kb.netscape.com/NASApp/kb/Article?id=2861
Although NS/Iplanet has threads, they are not pthreads. To get a
working NSAPI, one must use NSAPI threads instead.
That's a big problem because TSRM wants pthreads. So the issue is
simply how to build NSAPI without pthreads.
It can be done with 3 simple fixes: (1) TSRM fixes; (2) use correct
configure flags; (3) configure hacks.
(Note that php-cli needs to be built separately)
# FIRST
TSRM.h mostly *has* support for NSAPI threads, it's just that the
pthread ifdef's are reached first. Also, a couple of lines are
missing. Here are the few simple code change
#27416 [Opn->Bgs]: Accents not supported by mssql functions
ID: 27416
Updated by: [EMAIL PROTECTED]
Reported By: mooseyproductions at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: MSSQL related
Operating System: Windows 2000/XP
PHP Version: 4.3.4
New Comment:
You need to use the same codepage to insert and fetch the data. When
you insert data as binary values there is no codepage involved in the
process but when you select the data it uses the OEM to ANSI convertion
defined by the client library.
Previous Comments:
[2004-02-27 10:22:38] mooseyproductions at hotmail dot com
I have tried connecting to the SQL Server database using ODBC and it
retrieves the data perfectly, as expected. I think I will use the ODBC
functions for the meanwhile, until this bug is sorted.
[2004-02-27 09:03:03] mooseyproductions at hotmail dot com
Description:
When reading data from a SQL Server database, certain ASCII characters
are incorrectly retrieved. Entering accented characters into the
database works fine, however reading them from the database gives
unexpected results.
ASCII chars 33 - 255 entered into database:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL PROTECTED]|}~
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
(This appears fine when looking at the database using MS Enterprise
Manager)
Result from read query:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL
PROTECTED]|}~__'".ÅÎ^%So_zYÿ½Ï¾Ýõù¸¦®ªð©îøñýüïæôú÷û§¯¬«ó¨·µ¶ÇÔÒÓÞÖ×ØÑ¥ãàâåëéêíèá
ơФ¢äö£ìç
It appears that characters after ASCII #127 are incorrectly returned
from the database.
Using SQL Server 7.0 (ISO 8859-1 charset)
Reproduce code:
---
$string = '';
for ($i = 33; $i <= 255; $i++)
{
$string .= chr($i);
}
$db->query("UPDATE Test SET charset = 0x".bin2hex($string)." WHERE
rowID = 1");
$result = $db->query("SELECT charset FROM Test WHERE rowID = 1");
$row = $db->getAssoc($result);
echo $row['charset'];
Expected result:
I expected to see what I had previously entered into the database. All
text that contains accents is wrongly displayed.
Expected:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL PROTECTED]|}~
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Actual result:
--
Actual:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL
PROTECTED]|}~__'".ÅÎ^%So_zYÿ½Ï¾Ýõù¸¦®ªð©îøñýüïæôú÷û§¯¬«ó¨·µ¶ÇÔÒÓÞÖ×ØÑ¥ãàâåëéêíèá
ơФ¢äö£ìç
--
Edit this bug report at http://bugs.php.net/?id=27416&edit=1
#21197 [Opn]: socket_read() outputs error with PHP_NORMAL_READ
ID: 21197
Updated by: [EMAIL PROTECTED]
Reported By: bool at boolsite dot net
Status: Open
Bug Type: Sockets related
Operating System: win32 only
PHP Version: php 4.3.5RC4-dev
Assigned To: wez
New Comment:
Using latest PHP 5 snapshot and I still receive the error.
Previous Comments:
[2004-02-25 18:54:27] bool at boolsite dot net
it's again the same thing :
> X-Powered-By: PHP/4.3.5RC4-dev
> erreur [0] avec socket_read : OpÚration rÚussie.
[2004-02-25 18:38:44] [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
Bug #21760 was fixed, and it's pretty likely this is the same issue.
[2004-01-10 20:30:41] [EMAIL PROTECTED]
Assigning to Wez who might know why streams are borked.
[2003-12-15 11:11:42] nunoplopes at sapo dot pt
I'm using latest snapshot and I have the same problem. With
PHP_BINARY_READ everything works but with PHP_NORMAL_READ I receive the
following error:
"Warning: socket_read() unable to read from socket [0]: The operation
completed s
uccessfully."
[2003-08-26 02:00:58] bool at boolsite dot net
Ok, this is a short example : (a little echo server)
Debut de la connexion...',"\r\n";
$EndTime=time()+15;
do{
$buffer=socket_read($MsgSock,1024,PHP_NORMAL_READ);
if($buffer===false) {
echo 'socket_read() a échoué :
',socket_strerror(socket_last_error($MsgSock)),"\r\n";
break;
}
elseif(!$buffer){
continue;
}
$buffer=trim($buffer);
echo '< ',$buffer,"\r\n";
if($buffer=='quit') {
break;
}
$back='You sent : ['.$buffer.']';
echo '> ',$back,"\r\n";
socket_write($MsgSock,$back."\r\n");
} while(time()<$EndTime);
@socket_close($MsgSock);
echo '=> End...',"\r\n";
}
}
socket_close($Sock);
?>
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/21197
--
Edit this bug report at http://bugs.php.net/?id=21197&edit=1
#27321 [Com]: open_basedir setting leaking between vhosts
ID: 27321 Comment by: ibaldo at esquemas dot com Reported By: jg at execulink dot com Status: Feedback Bug Type: Apache related Operating System: Redhat Linux 7.3 PHP Version: 4.3.5RC3 New Comment: With Fedora Core 1, php-4.3.4-1.1 and httpd-2.0.48-1.2 we are experiencing the exact same problem with open_basedir. Settings of open_basedir are being reflected in other vhosts that doesn't specify an open_basedir! To reproduce the problem we accesed continuosly to a vhost that has the open_basedir set, and simultaneusly we accesed continuosly a vhost without the open_basedir, and the open_basedir of the first was sometimes applied to the second vhost mentioned, trying diferent vhosts which had the basedir and others that don't, we seen that the first was applied to the second in accordance to the hosts being tested at that particular time! This is not a configuration problem as someone mentions but clearly a nasty bug. If someone gets an specific patch for this that could be tested in a production environment then please contact us. Thank you guys! Previous Comments: [2004-02-25 08:09:29] [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 [2004-02-25 08:08:59] jg at execulink dot com Actually this is not a configuration problem, since the open_basedir it's complaining about is NOT the one I have configured for that vhost. [2004-02-24 17:12:12] [EMAIL PROTECTED] This is some configuration failure on user's side: File(/usr/ppp/p/pookie/public_html/index.php) is not within the allowed path(s): (/usr/ppp/p/pdipietro) in Unknown on line 0 (this is perfectly valid and expected error when you try to access file outside the open_basedir..) [2004-02-20 08:06:22] jg at execulink dot com I'm using Apache/1.3.27 (Unix) (Red-Hat/Linux) I've already tried running this snapshot: php4-STABLE-200402191630 with no luck. [2004-02-19 13:57:04] jg at execulink dot com Description: INI Settings, specificially open_basedir seems to be leaking between apache virtualhost settings. Bug seems to be very similar to #25753, but was not resolved for me in 4.3.5RC3. e.g., One user - pookie's php fails with the following error: (pdipietro is another user on the system, in another virtualhost). I would really appreciate either a workaround, patch, or fix! phpinfo(); PHP Version 4.3.5RC3 Warning: Unknown(): open_basedir restriction in effect. File(/usr/ppp/p/pookie/public_html/index.php) is not within the allowed path(s): (/usr/ppp/p/pdipietro) in Unknown on line 0 Warning: Unknown(/usr/ppp/p/pookie/public_html/index.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/usr/ppp/p/pookie/public_html/index.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=27321&edit=1
#27413 [Bgs]: SimpleXML text comparison
ID: 27413
User updated by: rbro at hotmail dot com
Reported By: rbro at hotmail dot com
Status: Bogus
Bug Type: XML related
Operating System: Linux
PHP Version: 5CVS-2004-02-26 (dev)
New Comment:
Thanks for your reply, but if that's the intended behavior (that
echo'ing the attribute prints it out as a string, but trying to compare
it doesn't work without a cast to a string), then the documentation
then needs to be updated. The 'Using attributes' example on
http://docs.php.net/en/ref.simplexml.html says that what I'm trying to
do should work. That example then is invalid too.
Previous Comments:
[2004-02-27 13:34:25] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
As Derick said, the explicit conversion is necessary because php tries
to convert the second argument to the first argument\'s type which is
an object. Generally it could work when you switch the order of
arguments but the explicit conversion makes it visible what you do.
[2004-02-27 09:04:12] [EMAIL PROTECTED]
If you cast to a string, it works:
if ((string) $sxe['a'] == '123')
I do think that should be necessary though.
[2004-02-27 09:00:12] rbro at hotmail dot com
Yes, doing 'var_dump($sxe['a']);' gives:
object(simplexml_element)#2 (1) {
[0]=>
string(3) "123"
}
But then changing my if line to:
if ($sxe['a'][0] == '123')
doesn't work either.
How does one then compare an attribute to another value? The
documentation at http://docs.php.net/en/ref.simplexml.html states that
my original if statement should work (the example under 'Using
attributes'). That example doesn't work locally either because of the
same issue on the switch statement used.
[2004-02-27 02:16:45] [EMAIL PROTECTED]
Try doing a 'var_dump($sxe['a']);'...comparing string to an object
can't really be true in any case?
[2004-02-27 00:11:03] rbro at hotmail dot com
Description:
Doing the following SimpleXML text comparison does not give the
expected results.
Reproduce code:
---
');
echo $sxe['a']."\n";
if ($sxe['a'] == '123')
{
echo 'They are equal.'."\n";
}
else
{
echo 'They are not equal.'."\n";
}
?>
Expected result:
123
They are equal.
Actual result:
--
123
They are not equal.
--
Edit this bug report at http://bugs.php.net/?id=27413&edit=1
#27413 [Opn->Bgs]: SimpleXML text comparison
ID: 27413
Updated by: [EMAIL PROTECTED]
Reported By: rbro at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: XML related
Operating System: Linux
PHP Version: 5CVS-2004-02-26 (dev)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
As Derick said, the explicit conversion is necessary because php tries
to convert the second argument to the first argument's type which is an
object. Generally it could work when you switch the order of arguments
but the explicit conversion makes it visible what you do.
Previous Comments:
[2004-02-27 09:04:12] [EMAIL PROTECTED]
If you cast to a string, it works:
if ((string) $sxe['a'] == '123')
I do think that should be necessary though.
[2004-02-27 09:00:12] rbro at hotmail dot com
Yes, doing 'var_dump($sxe['a']);' gives:
object(simplexml_element)#2 (1) {
[0]=>
string(3) "123"
}
But then changing my if line to:
if ($sxe['a'][0] == '123')
doesn't work either.
How does one then compare an attribute to another value? The
documentation at http://docs.php.net/en/ref.simplexml.html states that
my original if statement should work (the example under 'Using
attributes'). That example doesn't work locally either because of the
same issue on the switch statement used.
[2004-02-27 02:16:45] [EMAIL PROTECTED]
Try doing a 'var_dump($sxe['a']);'...comparing string to an object
can't really be true in any case?
[2004-02-27 00:11:03] rbro at hotmail dot com
Description:
Doing the following SimpleXML text comparison does not give the
expected results.
Reproduce code:
---
');
echo $sxe['a']."\n";
if ($sxe['a'] == '123')
{
echo 'They are equal.'."\n";
}
else
{
echo 'They are not equal.'."\n";
}
?>
Expected result:
123
They are equal.
Actual result:
--
123
They are not equal.
--
Edit this bug report at http://bugs.php.net/?id=27413&edit=1
#27427 [NEW]: imageftbbox() is unstable with text containing newlines
From: spam747 at mynamehere dot com Operating system: Fedora Core 1 PHP version: 4.3.4 PHP Bug Type: GD related Bug description: imageftbbox() is unstable with text containing newlines Description: Calling imageftbbox() multiple times with the same arguments gives substantially differing results if the text contains a newline. The exact results vary between executions, so an uninitialized variable or buffer overflow is suspected. The results are similar whether the function is run in Apache or from the command line. Changing fonts or the text doesn't have an effect, so long as the text contains a newline (\n). Occurs using the standard Fedora Core 1 php-4.3.4-1.1 from RPM, and also php4-STABLE-200402271630 (configure --with-gd). P.S. the provided email address is valid as-is. Reproduce code: --- #!/usr/bin/php -q Expected result: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 (Perhaps not this exactly, but all the lines should be the same) Actual result: -- 1 1 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 (On occasion, the second line may match the first, but from the third line on things change) -- Edit bug report at http://bugs.php.net/?id=27427&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27427&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27427&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27427&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27427&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27427&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27427&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27427&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27427&r=support Expected behavior: http://bugs.php.net/fix.php?id=27427&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27427&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27427&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27427&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27427&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27427&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27427&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27427&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27427&r=float
#27426 [NEW]: Can't get Sybase or Sybase-ct to compile
From: jeff at opendbms dot com Operating system: Gentoo Linux, 2.4.23 PHP version: 5.0.0b4 (beta4) PHP Bug Type: Compile Failure Bug description: Can't get Sybase or Sybase-ct to compile Description: I get compile errors: first I try to make and I get: t.lo Zend/zend_multibyte.lo Zend/zend_ts_hash.lo Zend/zend_stream.lo Zend/zend_iterators.lo Zend/zend_interfaces.lo Zend/zend_exceptions.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_mm.lo Zend/zend_default_classes.lo Zend/zend_reflection_api.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -linsck -linsck -lsybtcl -lintl -lcomn -lct -lcs -lcrypt -lmysqlclient -lz -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lcrypt -o sapi/cli/php gcc: /usr/lib/libintl.a: No such file or directory make: *** [sapi/cli/php] Error 1 So, I locate libintl.a, its in the sybase directory, so I create a link to it from /opt/sybase/lib to /usr/lib, and now I get this error: .lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcryp t -linsck -linsck -lsybtcl -lintl -lcomn -lct -lcs -lcrypt -lmysqlclient -lz -lr esolv -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lcrypt -o sapi/cli/php /opt/sybase/lib/libcomn.so: undefined reference to `intl_datetime' /opt/sybase/lib/libcomn.so: undefined reference to `intl_errstr' /opt/sybase/lib/libcomn.so: undefined reference to `intl_close' /opt/sybase/lib/libcomn.so: undefined reference to `intl_open' /opt/sybase/lib/libcomn.so: undefined reference to `intl_nextvalue' /opt/sybase/lib/libcomn.so: undefined reference to `intl_nextsection' /opt/sybase/lib/libcomn.so: undefined reference to `intl_nextentry' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Here is my configuration command: CONFIGURE_COMMAND = './configure' '--with-mysql' '--with-apxs2=/usr/sbin/apxs2' '--with-zlib' '--with-sybase-ct=/opt/sybase' I'm using this version of gcc: gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice) compiling --with-sybase also fails. I'm not sure what the difference is between with-sybase and with-sybase-ct. I'm using an older version of sybase: 11.0.3.3 (license free) Reproduce code: --- I can send you the sybase if you need it... contact me on AIM: Nerdbat Expected result: I expect it to compile... Actual result: -- ...It doesn't -- Edit bug report at http://bugs.php.net/?id=27426&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27426&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27426&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27426&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27426&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27426&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27426&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27426&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27426&r=support Expected behavior: http://bugs.php.net/fix.php?id=27426&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27426&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27426&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27426&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27426&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27426&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27426&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27426&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27426&r=float
#27425 [Opn->Ver]: Uncaught exception in try catch block
ID: 27425
Updated by: [EMAIL PROTECTED]
Reported By: kase at gmx dot net
-Status: Open
+Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5CVS-2004-02-27 (dev)
Previous Comments:
[2004-02-27 13:02:56] kase at gmx dot net
Description:
If you throw an exception in a function, which is called in a try/catch
block, after creating 2 objects of a class, which has a function or
method in __destruct(), the exception won´t be caught.
If you create the objects $v1 and $v2 of 2 different classes, and both
classes _have_ the function __destruct(), and the second class (of $v2)
have a function or method in __destruct(), the problem will exist, too.
Reproduce code:
---
Expected result:
The exception should be caught
Actual result:
--
Fatal error: Uncaught exception 'exception' in
/var/www/legendz/web/test/test.php5:12 Stack trace: #0
/var/www/legendz/web/test/test.php5(16): test() #1 {main} thrown in
/var/www/legendz/web/test/test.php5 on line 12
--
Edit this bug report at http://bugs.php.net/?id=27425&edit=1
#27425 [NEW]: Uncaught exception in try catch block
From: kase at gmx dot net
Operating system: linux
PHP version: 5CVS-2004-02-27 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: Uncaught exception in try catch block
Description:
If you throw an exception in a function, which is called in a try/catch
block, after creating 2 objects of a class, which has a function or method
in __destruct(), the exception won´t be caught.
If you create the objects $v1 and $v2 of 2 different classes, and both
classes _have_ the function __destruct(), and the second class (of $v2)
have a function or method in __destruct(), the problem will exist, too.
Reproduce code:
---
Expected result:
The exception should be caught
Actual result:
--
Fatal error: Uncaught exception 'exception' in
/var/www/legendz/web/test/test.php5:12 Stack trace: #0
/var/www/legendz/web/test/test.php5(16): test() #1 {main} thrown in
/var/www/legendz/web/test/test.php5 on line 12
--
Edit bug report at http://bugs.php.net/?id=27425&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27425&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27425&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27425&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27425&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27425&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27425&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27425&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27425&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27425&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27425&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27425&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27425&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27425&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27425&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27425&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27425&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27425&r=float
#27424 [NEW]: flush sets SG(headers_sent) to true preventing sapi_send_headers from running
From: scottmacvicar at ntlworld dot com Operating system: All PHP version: 4CVS-2004-02-27 (stable) PHP Bug Type: Apache2 related Bug description: flush sets SG(headers_sent) to true preventing sapi_send_headers from running Description: If you have zlib.output_compression = On in php.ini and echo some content then flush under apache 2 then you'll get some binary data due to the lack of headers. I've had a look at the code and when you call flush() under Apache 2 it has SG(headers_sent) = 1; sapi_apache2.c line 265 During php_request_shutdown() sapi_send_headers is called to add appropriate gzip headers. Within sapi_send_headers there is a check to see if headers have already been sent. SAPI.c line 701. I've read previous bug reports on flush and Apache 2 in particular, bug #25701. Ilia mentions that Apache 2 and Apache 1 behave differently, on flush Apache 2 sends any pending headers but in this case the gzip headers haven't been added yet. I can see two ways to handle this, Disable zlib.output_compression if flush is called or Make flush do nothing if zlib.output_compression is enabled -- Edit bug report at http://bugs.php.net/?id=27424&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27424&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27424&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27424&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27424&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27424&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27424&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27424&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27424&r=support Expected behavior: http://bugs.php.net/fix.php?id=27424&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27424&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27424&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27424&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27424&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27424&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27424&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27424&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27424&r=float
#27408 [Fbk->Opn]: xmlrpc_decode segfaults on opteron
ID: 27408 User updated by: gregor_macdougall at yahoo dot com Reported By: gregor_macdougall at yahoo dot com -Status: Feedback +Status: Open Bug Type: XMLRPC-EPI related Operating System: Linux PHP Version: 4CVS-2004-02-27 New Comment: A segfault also occurs with the most recent php5 cvs cnapshot. If you would like the backtrace information for php5 as well, please let me know. Previous Comments: [2004-02-27 02:54:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip There are some changes in HEAD, so please try it out. (we can then merge those into the stable branch if they make any difference..) [2004-02-26 18:30:42] gregor_macdougall at yahoo dot com Description: The xmlrpc_decode function causes PHP to segfault on each of our 3 dual opteron servers. These servers are running various versions of linux and all segfault in a similar way. Our 32-bit x86 servers have no problem with the same code. This segfault occurs when running the following program via the command line. Reproduce code: --- Test'; print xmlrpc_decode($response); ?> Expected result: The program should print "Test". Actual result: -- #0 0x002a9626ccdf in _int_free () from /lib/libc.so.6 #1 0x002a9626bb5a in free () from /lib/libc.so.6 #2 0x005c7c2e in convert ( src=0xa12a84 "Test", src_len=4, new_len=0xbfffc78c, from_enc=0x79d11e "UTF-8", to_enc=0x79ca28 "iso-8859-1") at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/encodings.c:87 #3 0x005c7cfa in utf8_decode ( s=0xa12a84 "Test", len=4, newlen=0xbfffc78c, encoding=0x79ca28 "iso-8859-1") at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/encodings.c:117 #4 0x005caa23 in charHandler (userData=0xbfffcbc0, s=0xa12a84 "Test", len=4) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/xml_element.c:621 #5 0x005a3b42 in doContent (parser=0xa11f30, startTagLevel=0, enc=0x912400, s=0xa12a84 "Test", end=0xa12abb "", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:2299 #6 0x005a23d8 in contentProcessor (parser=0xa11f30, start=0xa12a56 "Test", end=0xa12abb "", endPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:1765 #7 0x005a67a5 in doProlog (parser=0xa11f30, enc=0x912400, s=0xa12a56 "Test", end=0xa12abb "", tok=29, next=0xa12a56 "Test", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:3415 #8 0x005a5eb6 in prologProcessor (parser=0xa11f30, s=0xa12a40 "\nTest", end=0xa12abb "", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:3178 #9 0x005a599d in prologInitProcessor (parser=0xa11f30, s=0xa12a40 "\nTest", end=0xa12abb "", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:3009 #10 0x005a1af1 in php_XML_ParseBuffer (parser=0xa11f30, len=123, isFinal=1) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:1447 #11 0x005a1a34 in php_XML_Parse (parser=0xa11f30, s=0xa11ea0 "\nTest", len=123, isFinal=1) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:1435 #12 0x005cabcc in xml_elem_parse_buf ( in_buf=0xa11ea0 "\nTest", len=123, options=0xbfffcd20, error=0xbfffccb0) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/xml_element.c:695 #13 0x005cb6ac in XMLRPC_REQUEST_FromXML ( in_buf=0xa11ea0 "\nTest", len=123, in_options=0xbfffcd20) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/xmlrpc.c:756 #14 0x005c3e36 in decode_request_worker (xml_in=0x9fbf30, encoding_in=0x0, method_name_out=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/xmlrpc-epi-php.c:720 #15 0x005c4083 in zif_xmlrpc_decode (ht=1, return_value=0xa0cbe0, this_ptr=0x0, return_value_used=1) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/xmlrpc-epi-php.c:788 #16 0x0062c8b1 in execute (op_array=0xa0d800) #17 0x006185fa in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/gregor/php4-STABLE-200402262030/Zend/zend.c:886 #18 0x005dab8d in php_execute_script (primary_file=0xb680) at /home/gregor/php4-STABLE-200402262030/main/main.c:1731 #19 0x006351e6 in
#27422 [Opn->Bgs]: problem migrating form iis4 to iis6
ID: 27422 Updated by: [EMAIL PROTECTED] Reported By: y dot beyet at ouestfrance-multimedia dot com -Status: Open +Status: Bogus Bug Type: IIS related Operating System: 2003 and NT4 PHP Version: 4.3.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-02-27 10:24:09] y dot beyet at ouestfrance-multimedia dot com Description: I have several programs working under php with sql server 7 under nt4 (this server is also domain controller). When i try to access to database from iis6/2003 web server, the only way is to be domain administrator under IIS. It works under IIS4 with guest user. -- Edit this bug report at http://bugs.php.net/?id=27422&edit=1
#27423 [NEW]: Session hang
From: ypout at mail dot ru Operating system: Linux 2.4.25 PHP version: 4.3.4 PHP Bug Type: Session related Bug description: Session hang Description: PHP sessions will hang if an external command is executed either through system() or the popen() calls. The session restores as soon as the external command terminates. The problem is when I try to follow another link in a multiframed view. Reproduce code: --- session_start(); . . set_time_limit(0); ignore_user_abort(TRUE); system($cmd, $sys_res); // Takes very long . note (I tried popen aswell) Expected result: does not matter Actual result: -- does not matter -- Edit bug report at http://bugs.php.net/?id=27423&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27423&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27423&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27423&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27423&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27423&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27423&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27423&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27423&r=support Expected behavior: http://bugs.php.net/fix.php?id=27423&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27423&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27423&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27423&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27423&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27423&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27423&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27423&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27423&r=float
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: bernoico at netcabo dot pt
Reported By: golden at riscom dot com
Status: Closed
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
I also have made the change you sugested and the problem continues...
You have to reopen this bug report.
Thanks.
Previous Comments:
[2004-02-27 08:49:34] php at lathwood dot co dot uk
We are having the same problem described in this bug report.
I have tried both the patch and two CVS versions of PHP, none of which
have solved this problem yet.
We are currently running php4-STABLE-200402261430 which still causes
the errors reported above, the only thing I can see that is wrong is:
PHP Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp)
The storage module above is user but php.ini defines the storage module
as files which is what it should be and is being used.
[2004-02-26 05:44:15] zsubscriber at mail dot ru
I have such problem, but I tried to solve this by installing older
version of PHP. This problem persist and error appears in random time
and for all sites which using session modules. I have two questions:
Does this patch fully solving the problem or just stop generating fatal
error? Does php.ini settings affects to this error?
P.S. Sorry for my spelling
[2004-02-24 11:56:34] [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-02-24 05:16:45] [EMAIL PROTECTED]
In the ext/session/mod_files.c inside the function PS_OPEN_FUNC(files)
replace the next content:
---
if ((p = strchr(save_path, ';'))) {
errno = 0;
data->dirdepth = (size_t) strtol(save_path, NULL, 10);
if (errno == ERANGE) {
efree(data);
PS_SET_MOD_DATA(0);
return FAILURE;
}
save_path = p + 1;
}
---
by this one:
---
if ((p = strrchr(save_path, ';'))) {
data->dirdepth = (size_t)atol(save_path);
save_path = p + 1;
}
---
Compile again and try your scripts.
The problem exists from old php versions, but in 4.3.4 was added the
errno control to generate an error. Now the functionality is the
correct one and never produce abnormal errors!
Carlos Vilasis Faura & Javier Tacon Iglesias
[2004-02-20 21:42:44] [EMAIL PROTECTED]
Apply this patch, run for awhile, then post updated logs of the error
messages.
Index: ext/session/mod_files.c
===
RCS file: /repository/php-src/ext/session/mod_files.c,v
retrieving revision 1.83.2.7
diff -u -r1.83.2.7 mod_files.c
--- ext/session/mod_files.c 25 Sep 2003 14:53:58 -
1.83.2.7
+++ ext/session/mod_files.c 21 Feb 2004 02:49:05 -
@@ -239,6 +239,7 @@
errno = 0;
data->dirdepth = (size_t) strtol(save_path, NULL, 10);
if (errno == ERANGE) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Invalid save_path (%s)(%d)", save_path, strlen(save_path));
efree(data);
PS_SET_MOD_DATA(0);
return FAILURE;
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#27412 [Opn]: nsapi will not load for NS/Iplanet ver 3 and 4
ID: 27412
Updated by: [EMAIL PROTECTED]
Reported By: chris at seismo dot usbr dot gov dot spamfree
Status: Open
Bug Type: iPlanet related
Operating System: IRIX 6.5
PHP Version: 4CVS, 5CVS (2004-02-27)
New Comment:
I will go through your changes. The problem is that even in iPlanet4 /
NES3 the pthreads work correct on the most used platforms (e.g.
Solaris). So changing could be a risk and needs a lot of testing. But
for PHP5 we should think about it.
One question: Why not update to a "supported" version of the NSAPI
(e.g. SunONE webserver 6.1 ?). NES3 is really old...
One comment: explicit defining of XP_UNIX is not needed in the current
version because this is done by a #define in the sapi/nsapi/nsapi.c
file - the problem is only if you change the TSRM to include nsapi.h
here - you also need this there. But for that you can copy the code to
TSRM.
Previous Comments:
[2004-02-27 08:43:12] chris at seismo dot usbr dot gov dot spamfree
Corrections/typos:
(1) NSAPI.h should read TSRM.h
(2) Fix for TSRM.c should read
#elif defined(NSAPI)
crit_enter(mutexp); /* returns void */
return 0;
#elif defined(PI3WEB)
(3) Also need to disable test for $pthreads_working in configure NSAPI
section:
enable_experimental_zts=yes
# if test "$pthreads_working" != "yes"; then
#{ echo "configure: error: ZTS currently requires working POSIX
threads. We were unable to verify that your system supports Pthreads."
1>&2; exit 1; }
# fi
(4) sapi/nsapi/config.m4 is semi-busted even without the NSAIP
thread/pthread bug:
change
if test -d $PHP_NSAPI/include ; then
NSAPI_INCLUDE=$PHP_NSAPI/include
AC_MSG_RESULT(Netscape-Enterprise 3.x style)
AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h])
fi
to
if test -d $PHP_NSAPI/include ; then
NSAPI_INCLUDE=$PHP_NSAPI/include
AC_MSG_RESULT(Netscape-Enterprise 3.x style)
AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h])
NSAPI_INCLUDE="$NSAPI_INC_DIR -I$NSAPI_INCLUDE" dnl basic bug fix
AC_DEFINE(NSAPI,1,[ ]) dnl partial pthread fix
AC_DEFINE(XP_UNIX,1,[ ]) dnl partial pthread fix
fi
In configure, these lines would be
change
fi
if test -d $PHP_NSAPI/plugins/include ; then
test -n "$NSAPI_INCLUDE" && NSAPI_INC_DIR="-I$NSAPI_INCLUDE"
to
CFLAGS="$CFLAGS -DNSAPI -DXP_UNIX"
NSAPI_INCLUDE="$NSAPI_INC_DIR -I$NSAPI_INCLUDE"
fi
if test -d $PHP_NSAPI/plugins/include ; then
test -n "$NSAPI_INCLUDE" && NSAPI_INC_DIR="-I$NSAPI_INCLUDE"
sapi/nsapi/config.m4 needs a more general fix though, including
modifying the macro PHP_BUILD_THREAD_SAFE for
NS3 and 4 to require enable_experimental_zts=yes, but not pthread.
[2004-02-26 22:21:36] chris at seismo dot usbr dot gov dot spamfree
Description:
NSAPI with old versions of Netscape Enterprise Server (3 and 4) bombs
when the server tries to load it. PHP-cli works fine. And if one
removes the load statements from obj.conf, the server has no problem
(and no PHP). On Irix 6.5, the startup error with PHP NSAPI is "PANIC
pt_bootstrap() Couldn't INIT_THREADS - {0x0, 0x0}".
The basic problem here is that NS/Iplanet versions 3 and 4 do not
support pthreads whereas PHP requires them (sort of). See article:
http://kb.netscape.com/NASApp/kb/Article?id=2861
Although NS/Iplanet has threads, they are not pthreads. To get a
working NSAPI, one must use NSAPI threads instead.
That's a big problem because TSRM wants pthreads. So the issue is
simply how to build NSAPI without pthreads.
It can be done with 3 simple fixes: (1) TSRM fixes; (2) use correct
configure flags; (3) configure hacks.
(Note that php-cli needs to be built separately)
# FIRST
TSRM.h mostly *has* support for NSAPI threads, it's just that the
pthread ifdef's are reached first. Also, a couple of lines are
missing. Here are the few simple code changes that are needed (sorry, I
don't have CVS):
In NSAPI.h change
#elif defined(PTHREADS)
# define THREAD_T pthread_t
# define MUTEX_T pthread_mutex_t *
#elif defined(PI3WEB)
to
#elif defined(PTHREADS)
# define THREAD_T pthread_t
# define MUTEX_T pthread_mutex_t *
#elif defined(NSAPI)
# define THREAD_T SYS_THREAD
# define MUTEX_T CRITICAL
#elif defined(PI3WEB)
In TSRM.c, change
#elif defined(NSAPI)
return crit_enter(mutexp)
#elif defined(PI3WEB)
to
#elif defined(NSAPI)
crit_enter(mutexp); /* returns void */
return crit_enter(mutexp);
#elif defined(PI3WEB)
and also change
#elif defined(NSAPI)
return crit_exit(mutexp);
#elif defined(PI3WEB)
to
#elif defined(NSAPI)
crit_exit(mutexp); /* returns void */
return 0;
#elif defined(PI3WEB)
In nsapi.h, be sure to define XP_UNIX, or do it in con
#27422 [NEW]: problem migrating form iis4 to iis6
From: y dot beyet at ouestfrance-multimedia dot com Operating system: 2003 and NT4 PHP version: 4.3.4 PHP Bug Type: IIS related Bug description: problem migrating form iis4 to iis6 Description: I have several programs working under php with sql server 7 under nt4 (this server is also domain controller). When i try to access to database from iis6/2003 web server, the only way is to be domain administrator under IIS. It works under IIS4 with guest user. -- Edit bug report at http://bugs.php.net/?id=27422&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27422&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27422&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27422&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27422&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27422&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27422&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27422&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27422&r=support Expected behavior: http://bugs.php.net/fix.php?id=27422&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27422&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27422&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27422&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27422&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27422&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27422&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27422&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27422&r=float
#27416 [Opn]: Accents not supported by mssql functions
ID: 27416
User updated by: mooseyproductions at hotmail dot com
Reported By: mooseyproductions at hotmail dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000/XP
PHP Version: 4.3.4
New Comment:
I have tried connecting to the SQL Server database using ODBC and it
retrieves the data perfectly, as expected. I think I will use the ODBC
functions for the meanwhile, until this bug is sorted.
Previous Comments:
[2004-02-27 09:03:03] mooseyproductions at hotmail dot com
Description:
When reading data from a SQL Server database, certain ASCII characters
are incorrectly retrieved. Entering accented characters into the
database works fine, however reading them from the database gives
unexpected results.
ASCII chars 33 - 255 entered into database:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL PROTECTED]|}~
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
(This appears fine when looking at the database using MS Enterprise
Manager)
Result from read query:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL
PROTECTED]|}~__'".ÅÎ^%So_zYÿ½Ï¾Ýõù¸¦®ªð©îøñýüïæôú÷û§¯¬«ó¨·µ¶ÇÔÒÓÞÖ×ØÑ¥ãàâåëéêíèá
ơФ¢äö£ìç
It appears that characters after ASCII #127 are incorrectly returned
from the database.
Using SQL Server 7.0 (ISO 8859-1 charset)
Reproduce code:
---
$string = '';
for ($i = 33; $i <= 255; $i++)
{
$string .= chr($i);
}
$db->query("UPDATE Test SET charset = 0x".bin2hex($string)." WHERE
rowID = 1");
$result = $db->query("SELECT charset FROM Test WHERE rowID = 1");
$row = $db->getAssoc($result);
echo $row['charset'];
Expected result:
I expected to see what I had previously entered into the database. All
text that contains accents is wrongly displayed.
Expected:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL PROTECTED]|}~
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Actual result:
--
Actual:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL
PROTECTED]|}~__'".ÅÎ^%So_zYÿ½Ï¾Ýõù¸¦®ªð©îøñýüïæôú÷û§¯¬«ó¨·µ¶ÇÔÒÓÞÖ×ØÑ¥ãàâåëéêíèá
ơФ¢äö£ìç
--
Edit this bug report at http://bugs.php.net/?id=27416&edit=1
#27421 [NEW]: mbstring.func_overload set in .htaccess becomes global
From: php at strategma dot bg Operating system: Slackware 9.1 kernel: 2.4.22 PHP version: 4.3.4 PHP Bug Type: mbstring related Bug description: mbstring.func_overload set in .htaccess becomes global Description: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --prefix=/usr/local/php --enable-mbstring \ --with-mbregex apache version 1.3.29 we set in .htaccess PHP_VALUE mbstring.internal_encoding UTF-8 PHP_VALUE default_charset UTF-8 PHP_VALUE mbstring.http_output UTF-8 PHP_VALUE mbstring.encoding_translation On PHP_VALUE mbstring.detect_order UTF-8 PHP_VALUE mbstring.func_overload 7 for specific site, but string functions on other web sites at the same apache doest work (other sites use CP1251 enconding). The string functions stop to work when anyone access the unicode site. When we stop apache and start it again cp1251 string functions work properly. we tryed the same configuration in the directive at apache's httpd.conf for the UNICODE site and in the but it is the same result With or without setlocale(LC_ALL,"bg_BG.CP1251") or bg_BG or bg_BG.UTF-8 we have tryed all combinations and it still doesnt work. thanks in advance Reproduce code: --- Expected result: Òîâà å òåñò Actual result: -- Òîâà -- Edit bug report at http://bugs.php.net/?id=27421&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27421&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27421&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27421&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27421&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27421&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27421&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27421&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27421&r=support Expected behavior: http://bugs.php.net/fix.php?id=27421&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27421&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27421&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27421&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27421&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27421&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27421&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27421&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27421&r=float
#27420 [NEW]: Can't execute any SQL query after this kind of query
From: godwizard at hotmail dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: Can't execute any SQL query after this kind of query
Description:
Executing SQL query and trying to move next SQL query but after this query
db connection is closed and you can't open db connection again. This
problem come's always after that kind of query.
Reproduce code:
---
$result = mssql_query( "if exists (select kuvaurl from kuvagalleria where
koiraid = $koiraID and oletus = '1') begin select kuvaurl from
kuvagalleria where koiraid = $koiraID and oletus = '1' end else select
'00091' as kuvaurl" );
while ($a_row = mssql_fetch_array( $result ) )
{
$kuvaurl = "$a_row[kuvaurl]";
}
Expected result:
I'd like to make another SQL query.
Actual result:
--
DB connection is closed and you can't execute any SQL query after that
code in same page like it should. Problem is not in SQL Server, the code
do sth what anybody doesn't understand.
--
Edit bug report at http://bugs.php.net/?id=27420&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27420&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27420&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27420&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27420&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27420&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27420&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27420&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27420&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27420&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27420&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27420&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27420&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27420&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27420&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27420&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27420&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27420&r=float
#27419 [Opn]: shuffle no longer working properly
ID: 27419 User updated by: php at zoobio dot net Reported By: php at zoobio dot net Status: Open Bug Type: Unknown/Other Function Operating System: redhat 9 PHP Version: 4.3.4 New Comment: Description: My web host just upgraded to 4.3.4 from 4.3.2, and now my shuffle script does not work properly. It acts as though the seed generator is no longer a part of the function call. I have been using it to output information from a mysql database. The output from the shuffle is always the same, though it isn't in the order of the mysql table. Previous Comments: [2004-02-27 09:51:58] php at zoobio dot net Description: My web host just upgraded to 4.3.4 from the previous most recent version, and now my shuffle script does not work properly. It acts as though the seed generator is no longer a part of the function call. I have been using it to output information from a mysql database. The output from the shuffle is always the same, though it isn't in the order of the mysql table. -- Edit this bug report at http://bugs.php.net/?id=27419&edit=1
#27419 [NEW]: shuffle no longer working properly
From: php at zoobio dot net Operating system: redhat 9 PHP version: 4.3.4 PHP Bug Type: Unknown/Other Function Bug description: shuffle no longer working properly Description: My web host just upgraded to 4.3.4 from the previous most recent version, and now my shuffle script does not work properly. It acts as though the seed generator is no longer a part of the function call. I have been using it to output information from a mysql database. The output from the shuffle is always the same, though it isn't in the order of the mysql table. -- Edit bug report at http://bugs.php.net/?id=27419&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27419&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27419&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27419&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27419&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27419&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27419&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27419&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27419&r=support Expected behavior: http://bugs.php.net/fix.php?id=27419&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27419&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27419&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27419&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27419&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27419&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27419&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27419&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27419&r=float
#27418 [NEW]: SimpleXML Object forgetting values.
From: wb at pro-net dot co dot uk
Operating system: FreeBSD, WindowsXP
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: *XML functions
Bug description: SimpleXML Object forgetting values.
Description:
When using simpleXML you are unable to fetch some information. The
information is displayed with print_r() but you can't get it it directly.
Use the example provided as an example.
Reproduce code:
---
user1
letMeIn
www.pro-net.co.uk
www.example.com
user2
myPassword
www.pro-net.co.uk
';
$nl = "\r\n";
$xml = simplexml_load_string($xmlstr);
print('Current PHP version is : '.phpversion().$nl.$nl);
print('$xml is:'.$nl);
print_r($xml);
print($nl.$nl);
// Test authentication to get the correct user information
$login = 'user1';
$password = 'letMeIn';
print($nl.$nl.'Trying to authenticate "'.$login.'" with password
"'.$password.'".'.$nl.$nl);
$isAuth = false;
foreach($xml->user as $user){
if(utf8_decode($user->login) == $login && utf8_decode($user->password)
== $password){
$isAuth = true;
break;
}
}
if(!$isAuth){
print($nl.$nl.'Invalid User.'.$nl);
die();
}
// So lets output the variables to see what we have...
print('$user is:'.$nl);
print_r($user);
print($nl.$nl);
print('$user->site is:'.$nl);
print_r($user->site);
print($nl.$nl);
print('$user->site[0] is:'.$nl);
print_r($user->site[0]);
print($nl.$nl);
?>
Expected result:
$xml is:
simplexml_element Object
(
[user] => Array
(
[0] => simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
[1] => simplexml_element Object
(
[login] => user2
[password] => myPassword
[site] => www.pro-net.co.uk
)
)
)
Trying to authenticate "user1" with password "letMeIn".
$user is:
simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
$user->site is:
Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
$user->site[0] is:
www.pro-net.co.uk
Actual result:
--
$xml is:
simplexml_element Object
(
[user] => Array
(
[0] => simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
[1] => simplexml_element Object
(
[login] => user2
[password] => myPassword
[site] => www.pro-net.co.uk
)
)
)
Trying to authenticate "user1" with password "letMeIn".
$user is:
simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
$user->site is:
Array
(
[0] => simplexml_element Object
(
)
[1] => simplexml_element Object
(
)
)
$user->site[0] is:
simplexml_element Object
(
)
--
Edit bug report at http://bugs.php.net/?id=27418&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27418&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27418&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27418&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27418&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27418&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27418&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27418&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27418&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27418&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27418&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27418&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27418&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27418&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27418&r=dst
IIS Stability:
#27417 [NEW]: feof under register_stream
From: phillip dot hegarty at ntlworld dot com Operating system: Win2000 PHP version: 5.0.0b4 (beta4) PHP Bug Type: Filesystem function related Bug description: feof under register_stream Description: Example code from current documentation of the stream_register_wrapper function includes an feof test. This always returns a non-false value. Code works on 4.3.4 but not on 5.0.0b4. Altered class function "stream_eof" to emit debug message, which duly echoe'd but whatever this function returns, the feof returns true ! Reproduce code: --- See example code from online documentation of the stream_register_wrapper function Expected result: Expected feof to return false -- Edit bug report at http://bugs.php.net/?id=27417&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27417&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27417&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27417&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27417&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27417&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27417&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27417&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27417&r=support Expected behavior: http://bugs.php.net/fix.php?id=27417&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27417&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27417&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27417&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27417&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27417&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27417&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27417&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27417&r=float
#27413 [Bgs->Opn]: SimpleXML text comparison
ID: 27413
Updated by: [EMAIL PROTECTED]
Reported By: rbro at hotmail dot com
-Status: Bogus
+Status: Open
Bug Type: XML related
Operating System: Linux
PHP Version: 5CVS-2004-02-26 (dev)
New Comment:
If you cast to a string, it works:
if ((string) $sxe['a'] == '123')
I do think that should be necessary though.
Previous Comments:
[2004-02-27 09:00:12] rbro at hotmail dot com
Yes, doing 'var_dump($sxe['a']);' gives:
object(simplexml_element)#2 (1) {
[0]=>
string(3) "123"
}
But then changing my if line to:
if ($sxe['a'][0] == '123')
doesn't work either.
How does one then compare an attribute to another value? The
documentation at http://docs.php.net/en/ref.simplexml.html states that
my original if statement should work (the example under 'Using
attributes'). That example doesn't work locally either because of the
same issue on the switch statement used.
[2004-02-27 02:16:45] [EMAIL PROTECTED]
Try doing a 'var_dump($sxe['a']);'...comparing string to an object
can't really be true in any case?
[2004-02-27 00:11:03] rbro at hotmail dot com
Description:
Doing the following SimpleXML text comparison does not give the
expected results.
Reproduce code:
---
');
echo $sxe['a']."\n";
if ($sxe['a'] == '123')
{
echo 'They are equal.'."\n";
}
else
{
echo 'They are not equal.'."\n";
}
?>
Expected result:
123
They are equal.
Actual result:
--
123
They are not equal.
--
Edit this bug report at http://bugs.php.net/?id=27413&edit=1
#27416 [NEW]: Accents not supported by mssql functions
From: mooseyproductions at hotmail dot com
Operating system: Windows 2000/XP
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: Accents not supported by mssql functions
Description:
When reading data from a SQL Server database, certain ASCII characters are
incorrectly retrieved. Entering accented characters into the database
works fine, however reading them from the database gives unexpected
results.
ASCII chars 33 - 255 entered into database:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL PROTECTED]|}~
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
(This appears fine when looking at the database using MS Enterprise
Manager)
Result from read query:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL
PROTECTED]|}~__'".ÅÎ^%So_zYÿ½Ï¾Ýõù¸¦®ªð©îøñýüïæôú÷û§¯¬«ó¨·µ¶ÇÔÒÓÞÖ×ØÑ¥ãàâåëéêíèá
ơФ¢äö£ìç
It appears that characters after ASCII #127 are incorrectly returned from
the database.
Using SQL Server 7.0 (ISO 8859-1 charset)
Reproduce code:
---
$string = '';
for ($i = 33; $i <= 255; $i++)
{
$string .= chr($i);
}
$db->query("UPDATE Test SET charset = 0x".bin2hex($string)." WHERE rowID
= 1");
$result = $db->query("SELECT charset FROM Test WHERE rowID = 1");
$row = $db->getAssoc($result);
echo $row['charset'];
Expected result:
I expected to see what I had previously entered into the database. All
text that contains accents is wrongly displayed.
Expected:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL PROTECTED]|}~
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Actual result:
--
Actual:
!"#$%&'()*+,-./0123456789:;<=>[EMAIL
PROTECTED]|}~__'".ÅÎ^%So_zYÿ½Ï¾Ýõù¸¦®ªð©îøñýüïæôú÷û§¯¬«ó¨·µ¶ÇÔÒÓÞÖ×ØÑ¥ãàâåëéêíèá
ơФ¢äö£ìç
--
Edit bug report at http://bugs.php.net/?id=27416&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27416&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27416&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27416&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27416&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27416&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27416&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27416&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27416&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27416&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27416&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27416&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27416&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27416&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27416&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27416&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27416&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27416&r=float
#27413 [Bgs]: SimpleXML text comparison
ID: 27413
User updated by: rbro at hotmail dot com
Reported By: rbro at hotmail dot com
Status: Bogus
Bug Type: XML related
Operating System: Linux
PHP Version: 5CVS-2004-02-26 (dev)
New Comment:
Yes, doing 'var_dump($sxe['a']);' gives:
object(simplexml_element)#2 (1) {
[0]=>
string(3) "123"
}
But then changing my if line to:
if ($sxe['a'][0] == '123')
doesn't work either.
How does one then compare an attribute to another value? The
documentation at http://docs.php.net/en/ref.simplexml.html states that
my original if statement should work (the example under 'Using
attributes'). That example doesn't work locally either because of the
same issue on the switch statement used.
Previous Comments:
[2004-02-27 02:16:45] [EMAIL PROTECTED]
Try doing a 'var_dump($sxe['a']);'...comparing string to an object
can't really be true in any case?
[2004-02-27 00:11:03] rbro at hotmail dot com
Description:
Doing the following SimpleXML text comparison does not give the
expected results.
Reproduce code:
---
');
echo $sxe['a']."\n";
if ($sxe['a'] == '123')
{
echo 'They are equal.'."\n";
}
else
{
echo 'They are not equal.'."\n";
}
?>
Expected result:
123
They are equal.
Actual result:
--
123
They are not equal.
--
Edit this bug report at http://bugs.php.net/?id=27413&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: php at lathwood dot co dot uk
Reported By: golden at riscom dot com
Status: Closed
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
We are having the same problem described in this bug report.
I have tried both the patch and two CVS versions of PHP, none of which
have solved this problem yet.
We are currently running php4-STABLE-200402261430 which still causes
the errors reported above, the only thing I can see that is wrong is:
PHP Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp)
The storage module above is user but php.ini defines the storage module
as files which is what it should be and is being used.
Previous Comments:
[2004-02-26 05:44:15] zsubscriber at mail dot ru
I have such problem, but I tried to solve this by installing older
version of PHP. This problem persist and error appears in random time
and for all sites which using session modules. I have two questions:
Does this patch fully solving the problem or just stop generating fatal
error? Does php.ini settings affects to this error?
P.S. Sorry for my spelling
[2004-02-24 11:56:34] [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-02-24 05:16:45] [EMAIL PROTECTED]
In the ext/session/mod_files.c inside the function PS_OPEN_FUNC(files)
replace the next content:
---
if ((p = strchr(save_path, ';'))) {
errno = 0;
data->dirdepth = (size_t) strtol(save_path, NULL, 10);
if (errno == ERANGE) {
efree(data);
PS_SET_MOD_DATA(0);
return FAILURE;
}
save_path = p + 1;
}
---
by this one:
---
if ((p = strrchr(save_path, ';'))) {
data->dirdepth = (size_t)atol(save_path);
save_path = p + 1;
}
---
Compile again and try your scripts.
The problem exists from old php versions, but in 4.3.4 was added the
errno control to generate an error. Now the functionality is the
correct one and never produce abnormal errors!
Carlos Vilasis Faura & Javier Tacon Iglesias
[2004-02-20 21:42:44] [EMAIL PROTECTED]
Apply this patch, run for awhile, then post updated logs of the error
messages.
Index: ext/session/mod_files.c
===
RCS file: /repository/php-src/ext/session/mod_files.c,v
retrieving revision 1.83.2.7
diff -u -r1.83.2.7 mod_files.c
--- ext/session/mod_files.c 25 Sep 2003 14:53:58 -
1.83.2.7
+++ ext/session/mod_files.c 21 Feb 2004 02:49:05 -
@@ -239,6 +239,7 @@
errno = 0;
data->dirdepth = (size_t) strtol(save_path, NULL, 10);
if (errno == ERANGE) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Invalid save_path (%s)(%d)", save_path, strlen(save_path));
efree(data);
PS_SET_MOD_DATA(0);
return FAILURE;
[2003-10-17 04:39:19] golden at riscom dot com
/tmp is not a separate partition
/dev/da0s1a 4.7G 133M 4.2G 3%/
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#27412 [Opn]: nsapi will not load for NS/Iplanet ver 3 and 4
ID: 27412
User updated by: chris at seismo dot usbr dot gov dot spamfree
Reported By: chris at seismo dot usbr dot gov dot spamfree
Status: Open
Bug Type: iPlanet related
Operating System: IRIX 6.5
PHP Version: 4CVS, 5CVS (2004-02-27)
New Comment:
Corrections/typos:
(1) NSAPI.h should read TSRM.h
(2) Fix for TSRM.c should read
#elif defined(NSAPI)
crit_enter(mutexp); /* returns void */
return 0;
#elif defined(PI3WEB)
(3) Also need to disable test for $pthreads_working in configure NSAPI
section:
enable_experimental_zts=yes
# if test "$pthreads_working" != "yes"; then
#{ echo "configure: error: ZTS currently requires working POSIX
threads. We were unable to verify that your system supports Pthreads."
1>&2; exit 1; }
# fi
(4) sapi/nsapi/config.m4 is semi-busted even without the NSAIP
thread/pthread bug:
change
if test -d $PHP_NSAPI/include ; then
NSAPI_INCLUDE=$PHP_NSAPI/include
AC_MSG_RESULT(Netscape-Enterprise 3.x style)
AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h])
fi
to
if test -d $PHP_NSAPI/include ; then
NSAPI_INCLUDE=$PHP_NSAPI/include
AC_MSG_RESULT(Netscape-Enterprise 3.x style)
AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h])
NSAPI_INCLUDE="$NSAPI_INC_DIR -I$NSAPI_INCLUDE" dnl basic bug fix
AC_DEFINE(NSAPI,1,[ ]) dnl partial pthread fix
AC_DEFINE(XP_UNIX,1,[ ]) dnl partial pthread fix
fi
In configure, these lines would be
change
fi
if test -d $PHP_NSAPI/plugins/include ; then
test -n "$NSAPI_INCLUDE" && NSAPI_INC_DIR="-I$NSAPI_INCLUDE"
to
CFLAGS="$CFLAGS -DNSAPI -DXP_UNIX"
NSAPI_INCLUDE="$NSAPI_INC_DIR -I$NSAPI_INCLUDE"
fi
if test -d $PHP_NSAPI/plugins/include ; then
test -n "$NSAPI_INCLUDE" && NSAPI_INC_DIR="-I$NSAPI_INCLUDE"
sapi/nsapi/config.m4 needs a more general fix though, including
modifying the macro PHP_BUILD_THREAD_SAFE for
NS3 and 4 to require enable_experimental_zts=yes, but not pthread.
Previous Comments:
[2004-02-26 22:21:36] chris at seismo dot usbr dot gov dot spamfree
Description:
NSAPI with old versions of Netscape Enterprise Server (3 and 4) bombs
when the server tries to load it. PHP-cli works fine. And if one
removes the load statements from obj.conf, the server has no problem
(and no PHP). On Irix 6.5, the startup error with PHP NSAPI is "PANIC
pt_bootstrap() Couldn't INIT_THREADS - {0x0, 0x0}".
The basic problem here is that NS/Iplanet versions 3 and 4 do not
support pthreads whereas PHP requires them (sort of). See article:
http://kb.netscape.com/NASApp/kb/Article?id=2861
Although NS/Iplanet has threads, they are not pthreads. To get a
working NSAPI, one must use NSAPI threads instead.
That's a big problem because TSRM wants pthreads. So the issue is
simply how to build NSAPI without pthreads.
It can be done with 3 simple fixes: (1) TSRM fixes; (2) use correct
configure flags; (3) configure hacks.
(Note that php-cli needs to be built separately)
# FIRST
TSRM.h mostly *has* support for NSAPI threads, it's just that the
pthread ifdef's are reached first. Also, a couple of lines are
missing. Here are the few simple code changes that are needed (sorry, I
don't have CVS):
In NSAPI.h change
#elif defined(PTHREADS)
# define THREAD_T pthread_t
# define MUTEX_T pthread_mutex_t *
#elif defined(PI3WEB)
to
#elif defined(PTHREADS)
# define THREAD_T pthread_t
# define MUTEX_T pthread_mutex_t *
#elif defined(NSAPI)
# define THREAD_T SYS_THREAD
# define MUTEX_T CRITICAL
#elif defined(PI3WEB)
In TSRM.c, change
#elif defined(NSAPI)
return crit_enter(mutexp)
#elif defined(PI3WEB)
to
#elif defined(NSAPI)
crit_enter(mutexp); /* returns void */
return crit_enter(mutexp);
#elif defined(PI3WEB)
and also change
#elif defined(NSAPI)
return crit_exit(mutexp);
#elif defined(PI3WEB)
to
#elif defined(NSAPI)
crit_exit(mutexp); /* returns void */
return 0;
#elif defined(PI3WEB)
In nsapi.h, be sure to define XP_UNIX, or do it in configure.
# SECOND
Make sure the following flags are given to configure:
--with-nsapi=/your/path/to/Netscape/3.5 --without-tsrm-pthreads
--disable-cli --without-pear
# THIRD
Configure needs to be modified for several things to disable any use of
pthreads and set CFLAGS for NSAPI threads:
(1) For NS 3 and 4, don't use pthreads
(2) Make sure CFLAGS="$CFLAGS -DNSAPI -DXP_UNIX"
(3) Make sure -lpthread is never used
(4) Make sure there's no pthread support in main/php_config.h
A quick, if ugly hack to configure that does that is to change
occurrences of
if test "$cross_compiling" = yes"; then
to
if test "$cross_compiling" = yes -o "ugly" = "ugly" ; then
A more elegant fix would change sapi/nsapi/config.m4 to reflect the
logic: i
#27415 [Opn->Bgs]: error on make install
ID: 27415 Updated by: [EMAIL PROTECTED] Reported By: eero at jlug dot fi -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: 2.6.3 PHP Version: 5CVS-2004-02-27 (dev) New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Already filed, please search the bug databsae before submitting. Previous Comments: [2004-02-27 06:45:28] eero at jlug dot fi Description: Pear error on latest cvs Reproduce code: --- [EMAIL PROTECTED] php5-200402271030]# make install Installing PHP SAPI module: apache [activating module `php5' in /home/apache/conf/httpd.conf] cp libs/libphp5.so /home/apache/libexec/libphp5.so chmod 755 /home/apache/libexec/libphp5.so cp /home/apache/conf/httpd.conf /home/apache/conf/httpd.conf.bak cp /home/apache/conf/httpd.conf.new /home/apache/conf/httpd.conf rm /home/apache/conf/httpd.conf.new Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Fatal error: Declaration of PEAR_Installer::download() must be compatible with that of PEAR_Downloader::download() in /home/eero/php5b4/php5-200402271030/pear/PEAR/Installer.php on line 49 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 -- Edit this bug report at http://bugs.php.net/?id=27415&edit=1
#27415 [NEW]: error on make install
From: eero at jlug dot fi Operating system: 2.6.3 PHP version: 5CVS-2004-02-27 (dev) PHP Bug Type: Unknown/Other Function Bug description: error on make install Description: Pear error on latest cvs Reproduce code: --- [EMAIL PROTECTED] php5-200402271030]# make install Installing PHP SAPI module: apache [activating module `php5' in /home/apache/conf/httpd.conf] cp libs/libphp5.so /home/apache/libexec/libphp5.so chmod 755 /home/apache/libexec/libphp5.so cp /home/apache/conf/httpd.conf /home/apache/conf/httpd.conf.bak cp /home/apache/conf/httpd.conf.new /home/apache/conf/httpd.conf rm /home/apache/conf/httpd.conf.new Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Fatal error: Declaration of PEAR_Installer::download() must be compatible with that of PEAR_Downloader::download() in /home/eero/php5b4/php5-200402271030/pear/PEAR/Installer.php on line 49 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 -- Edit bug report at http://bugs.php.net/?id=27415&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27415&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27415&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27415&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27415&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27415&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27415&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27415&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27415&r=support Expected behavior: http://bugs.php.net/fix.php?id=27415&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27415&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27415&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27415&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27415&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27415&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27415&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27415&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27415&r=float
#27414 [NEW]: setlocale doesn't work when called in an included file
From: rmarth at firemail dot de
Operating system: Win2k SP4
PHP version: 4.3.5RC3
PHP Bug Type: *Languages/Translation
Bug description: setlocale doesn't work when called in an included file
Description:
Calling setlocale() in an included file doesn't change the format of
strftime().
System: Apache/1.3.29 (Win32) PHP/4.3.5RC3
Short Testcase:
foo1.php
-->
echo setlocale (LC_ALL, array('de_DE', '[EMAIL PROTECTED]', 'de', 'ge',
'german');
strftime("%A, %d.%B.");
<--
Output: German_Germany.1252
Donnerstag, 26.Februar
Works.
bar.php
-->
echo setlocale (LC_ALL, array('de_DE', '[EMAIL PROTECTED]', 'de', 'ge',
'german');
<-
foo2.php
-->
require('bar.php');
strftime("%A, %d.%m.");
<-
Output: German_Germany.1252
Thursday, 26.February
Doesn't Work.
--
Edit bug report at http://bugs.php.net/?id=27414&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27414&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27414&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27414&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27414&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27414&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27414&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27414&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27414&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27414&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27414&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27414&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27414&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27414&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27414&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27414&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27414&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27414&r=float
#27347 [Fbk->Csd]: Cannot query SNMPv1 devices (version cannot be set)
ID: 27347 User updated by: Ernest at Beinrohr dot sk Reported By: Ernest at Beinrohr dot sk -Status: Feedback +Status: Closed Bug Type: SNMP related Operating System: linux 2.4 PHP Version: 4.3.4 New Comment: in php-4.3.4 new install the bug has not show up. damn, sorry for robbing your time. Previous Comments: [2004-02-26 15:48:08] [EMAIL PROTECTED] Forgot to ask: EXACTLY what error do you get? (About the version: It _is_ set to 1 in snmpget() ) [2004-02-23 03:20:32] Ernest at Beinrohr dot sk Ok, but this fails only with SNMPv1 device. That's the problem. [2004-02-22 08:42:35] Ernest at Beinrohr dot sk Description: I use the newest stable php 4.3.4 and I cannot query my old jetdirect network device with php-snmp. With command line tools it works only when I specify version 1. linux 2.4.22 net-snmp-5.1 Reproduce code: --- with SNMPv1 devices Expected result: should get a response Actual result: -- no response from SNMPv1 device. -- Edit this bug report at http://bugs.php.net/?id=27347&edit=1
#27408 [Opn->Fbk]: xmlrpc_decode segfaults on opteron
ID: 27408 Updated by: [EMAIL PROTECTED] Reported By: gregor_macdougall at yahoo dot com -Status: Open +Status: Feedback Bug Type: XMLRPC-EPI related Operating System: Linux -PHP Version: 4CVS-2004-02-26 (stable) +PHP Version: 4CVS-2004-02-27 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip There are some changes in HEAD, so please try it out. (we can then merge those into the stable branch if they make any difference..) Previous Comments: [2004-02-26 18:30:42] gregor_macdougall at yahoo dot com Description: The xmlrpc_decode function causes PHP to segfault on each of our 3 dual opteron servers. These servers are running various versions of linux and all segfault in a similar way. Our 32-bit x86 servers have no problem with the same code. This segfault occurs when running the following program via the command line. Reproduce code: --- Test'; print xmlrpc_decode($response); ?> Expected result: The program should print "Test". Actual result: -- #0 0x002a9626ccdf in _int_free () from /lib/libc.so.6 #1 0x002a9626bb5a in free () from /lib/libc.so.6 #2 0x005c7c2e in convert ( src=0xa12a84 "Test", src_len=4, new_len=0xbfffc78c, from_enc=0x79d11e "UTF-8", to_enc=0x79ca28 "iso-8859-1") at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/encodings.c:87 #3 0x005c7cfa in utf8_decode ( s=0xa12a84 "Test", len=4, newlen=0xbfffc78c, encoding=0x79ca28 "iso-8859-1") at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/encodings.c:117 #4 0x005caa23 in charHandler (userData=0xbfffcbc0, s=0xa12a84 "Test", len=4) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/xml_element.c:621 #5 0x005a3b42 in doContent (parser=0xa11f30, startTagLevel=0, enc=0x912400, s=0xa12a84 "Test", end=0xa12abb "", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:2299 #6 0x005a23d8 in contentProcessor (parser=0xa11f30, start=0xa12a56 "Test", end=0xa12abb "", endPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:1765 #7 0x005a67a5 in doProlog (parser=0xa11f30, enc=0x912400, s=0xa12a56 "Test", end=0xa12abb "", tok=29, next=0xa12a56 "Test", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:3415 #8 0x005a5eb6 in prologProcessor (parser=0xa11f30, s=0xa12a40 "\nTest", end=0xa12abb "", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:3178 #9 0x005a599d in prologInitProcessor (parser=0xa11f30, s=0xa12a40 "\nTest", end=0xa12abb "", nextPtr=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:3009 #10 0x005a1af1 in php_XML_ParseBuffer (parser=0xa11f30, len=123, isFinal=1) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:1447 #11 0x005a1a34 in php_XML_Parse (parser=0xa11f30, s=0xa11ea0 "\nTest", len=123, isFinal=1) at /home/gregor/php4-STABLE-200402262030/ext/xml/expat/xmlparse.c:1435 #12 0x005cabcc in xml_elem_parse_buf ( in_buf=0xa11ea0 "\nTest", len=123, options=0xbfffcd20, error=0xbfffccb0) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/xml_element.c:695 #13 0x005cb6ac in XMLRPC_REQUEST_FromXML ( in_buf=0xa11ea0 "\nTest", len=123, in_options=0xbfffcd20) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/libxmlrpc/xmlrpc.c:756 #14 0x005c3e36 in decode_request_worker (xml_in=0x9fbf30, encoding_in=0x0, method_name_out=0x0) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/xmlrpc-epi-php.c:720 #15 0x005c4083 in zif_xmlrpc_decode (ht=1, return_value=0xa0cbe0, this_ptr=0x0, return_value_used=1) at /home/gregor/php4-STABLE-200402262030/ext/xmlrpc/xmlrpc-epi-php.c:788 #16 0x0062c8b1 in execute (op_array=0xa0d800) #17 0x006185fa in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/gregor/php4-STABLE-200402262030/Zend/zend.c:886 #18 0x005dab8d in php_execute_script (primary_file=0xb680) at /home/gregor/php4-STABLE-200402262030/main/main.c:1731 #19 0x006351e6 in main (argc=2, argv=0xb768) at /home/gregor/php4-STABLE-200402262030/sapi/cli/php_cli.c:822 -- Edit this bug report at http://bugs.php
