#33854 [Bgs]: array_diff depending on element sequence
ID: 33854
User updated by: bob dot siefkes at packardbell dot com
Reported By: bob dot siefkes at packardbell dot com
Status: Bogus
Bug Type: Arrays related
Operating System: XP SP2
PHP Version: 5.0.4
New Comment:
I'm aware of the assoc variant. Still I'm not convinced that array_diff
behaves regular.
The manual describes: array_diff() returns an array containing all the
values of array1 that are not present in any of the other arguments.
The value "c" exist in array1 and in array2. The result does also
contain value "c". I would not expect to see "c" in the result.
Previous Comments:
[2005-07-25 22:32:44] [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
if you want keys & position to be considered use the array_diff_assoc()
function.
[2005-07-25 21:26:16] bob dot siefkes at packardbell dot com
I did confuse the two result blocks...
Expected result: <--> Actual result:
[2005-07-25 21:23:22] bob dot siefkes at packardbell dot com
Description:
Behavor of array_diff is dependent on the sequence of the elements in
the array.
See $array2 where I changed the sequence of "a"=>"c" with "a"=>"d" and
it results in different output.
Be noted that the key of both elements is the same, still I would not
expect array_diff to take this into account.
Bob
Reproduce code:
---
// source 1
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "c", "a" => "d" );
$result = array_diff($array1, $array2);
// source 2
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "d", "a" => "c" );
$result = array_diff($array1, $array2);
Expected result:
// result1:
Array
(
[a] => c
[b] => b
)
// result2
Array
(
[b] => b
)
Actual result:
--
// for both I would expect
Array
(
[b] => b
)
--
Edit this bug report at http://bugs.php.net/?id=33854&edit=1
#33861 [NEW]: error date("G") time function
From: yesman78 at hanmail dot net
Operating system: linux 2.6.12
PHP version: 5CVS-2005-07-26 (dev)
PHP Bug Type: Unknown/Other Function
Bug description: error date("G") time function
Description:
error time function
DATE("G")
Reproduce code:
---
error time function
DATE("G")
now time : 2005.7.26 12
echo date("YnjG");
run page : 20057263
3 time error
Expected result:
time function error
Actual result:
--
time function error
--
Edit bug report at http://bugs.php.net/?id=33861&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33861&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33861&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33861&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33861&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33861&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33861&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33861&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33861&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33861&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33861&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33861&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33861&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33861&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33861&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33861&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33861&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33861&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33861&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33861&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33861&r=mysqlcfg
#33859 [NEW]: Failed SQLite assertion when using SQL 'AS'
From: leon at lost dot co dot nz
Operating system: Linux (Debian Sarge)
PHP version: 5CVS-2005-07-26 (dev)
PHP Bug Type: PDO related
Bug description: Failed SQLite assertion when using SQL 'AS'
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr->op==7' failed.
Aborted
Reproduce code:
---
exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER, position
INTEGER)');
$conn->exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = "SELECT count(*) AS count, key FROM ".
"barrel, documents WHERE id == docid AND " .
"wordid == 1 GROUP BY docid ORDER BY count DESC;";
$stmt = $conn->query($sql);
$result = $stmt->fetch();
print_r($result);
?>
Expected result:
Array
(
[count] => 0
[0] => 0
[key] =>
[1] =>
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr->op==7' failed.
Aborted
--
Edit bug report at http://bugs.php.net/?id=33859&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33859&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33859&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33859&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33859&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33859&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33859&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33859&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33859&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33859&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33859&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33859&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33859&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33859&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33859&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33859&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33859&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33859&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33859&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33859&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33859&r=mysqlcfg
#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Comment by: joey at clean dot q7 dot com Reported By: lukem at NetBSD dot org Status: Assigned Bug Type: CGI related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-04) Assigned To: fmk New Comment: it took me many hours of poking around to finally find this page to figure out why php isn't working under the httpd server provided under busybox. php is clearly doing the wrong thing with respect to the cgi specification. SCRIPT_FILENAME is not a standard header and can not be relied on to function. Previous Comments: [2005-05-30 18:33:55] masta at yazzy dot org I ran into this exact same issue with php4-cgi (ver 4.3.11) on FreeBSD due to the SCRIPT_FILENAME problem. I found two ways to avoid the non-standard CGI var is to hack the http server used (mini_httpd) or use LukeM's modifications to php4. Considering that CGI is a standards based domain, modification of the webserver to support non-standard CGI variables is not proper, thus the modification to PHP itself is the solution. I found that the the LukeM modification still allows for proper execution in apache. Can somebody in the php team fix this please? [2005-02-11 03:04:50] [EMAIL PROTECTED] The provided patch was not correct, according to Frank. Assigning to him for now. [2004-12-17 03:02:28] lukem at NetBSD dot org This bug is still present in 4.3.10 as well. Note that NetBSD's pkgsrc system has been using the patch I provided for a few months now, and we haven't received any reports of problems with PHP with that patch when running as a: * php.so module under Apache * php CGI under Apache * php CGI under web servers that don't support the non-standard SCRIPT_FILENAME Please consider applying this patch, because without it PHP is useless as a CGI except under Apache & IIS. [2004-12-13 20:33:52] jbardin at hsc dot usf dot edu Problem still exists in PHP-5.0.2 on SunOS [2004-05-03 19:47:16] shane at caraveo dot com The current code does not rely on script_filename, script_filename is only used as a shortcut if it is available. Otherwise, the init function tries to determine the real script path, IF the fix_pathinfo ini setting is on. The current code was only tested under apache and iis. That said, the patch looks ok, and very likely improves the situation, but needs some good testing on apache/mod_php, apache/cgi, iis/isapi and iis/cgi, with various changes of configuration in php.ini (discard path, fix pathinfo, etc.). Unfortunately I have zero time. -Shane 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/28227 -- Edit this bug report at http://bugs.php.net/?id=28227&edit=1
#33326 [Opn->NoF]: Cannot build extensions with phpize
ID: 33326 Updated by: [EMAIL PROTECTED] Reported By: artooro at gmail dot com -Status: Open +Status: No Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.4.1 PHP Version: 5CVS-2005-06-13 (dev) New Comment: The temporary fix is to just copy-paste the final link line back with all the .lo filenames replaced with .libs/*.o eg. to build pecl/apc I use: gcc -dynamic -flat_namespace -bundle -undefined suppress -DPHP_ATOM_INC -I/Users/rasmus/pecl/apc/include -I/Users/rasmus/pecl/apc/main -I/Users/rasmus/pecl/apc -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -DHAVE_CONFIG_H -g -O2 -o apc.so .libs/*.o instead of: gcc -dynamic -flat_namespace -bundle -undefined suppress -DPHP_ATOM_INC -I/Users/rasmus/pecl/apc/include -I/Users/rasmus/pecl/apc/main -I/Users/rasmus/pecl/apc -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -DHAVE_CONFIG_H -g -O2 -o apc.so apc.lo php_apc.lo apc_cache.lo apc_compile.lo apc_debug.lo apc_fcntl.lo apc_main.lo apc_mmap.lo apc_optimizer.lo apc_pair.lo apc_sem.lo apc_shm.lo apc_sma.lo apc_stack.lo apc_zend.lo Previous Comments: [2005-07-26 01:27:09] artooro at gmail dot com sniper, I have no other machines with OSX so no I can't reproduce on other machine(s). But at least three other people have had this problem as well now. I might be able to look into it some more tomorrow, if needed. [2005-07-26 01:18:00] jeffg at activestate dot com this is still ocurring with php 5.1 b3. I'm trying to build xdebug and getting the same failures, seems to eb something wrong with libtool generated by configure. [2005-07-08 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-06-30 16:24:22] [EMAIL PROTECTED] Can you reproduce this on other machine(s) ? (with same OS and versions of tools) [2005-06-30 11:28:36] bmansion at mamasam dot com Just to confirm the problem on Mac OS X using Tiger both with GCC 4 and GCC 3.3. The problem seems definitely in the generated libtool. I am using PHP 5.1beta2 with phpize. I've had the same messages when I tried to compile PECL translit and mnogosearch extensions. I didn't test with other extensions but I guess the problem will be the same. 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/33326 -- Edit this bug report at http://bugs.php.net/?id=33326&edit=1
#33858 [NEW]: PHP executed in SSI doesn't show output
From: slimandslam at gmail dot com Operating system: FreeBSD 5.4 Stable PHP version: 5.0.4 PHP Bug Type: CGI related Bug description: PHP executed in SSI doesn't show output Description: When running PHP 5.04 as a CGI under Apache 2, PHP files included in Server-Side includes don't show their output. Note that the PHP files in SSI *are* executed, but the output is never shown. Running PHP 5.04 as an Apache module works as expected -- the output of the PHP files in a SSI is displayed. Reproduce code: --- To reproduce, make sure you are running PHP 5.04 as a CGI. Setup your Apache 2 web server to work with Server-Side Includes using the file extension ".shtml". The file we'll run is called "junk.shtml" : In the same directory as junk.shtml, put the file "junk.php": Expected result: FUN FUN FUN Actual result: -- [BLANK PAGE] -- Edit bug report at http://bugs.php.net/?id=33858&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33858&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33858&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33858&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33858&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33858&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33858&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33858&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33858&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33858&r=support Expected behavior: http://bugs.php.net/fix.php?id=33858&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33858&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33858&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33858&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33858&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33858&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33858&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33858&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33858&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33858&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33858&r=mysqlcfg
#33326 [NoF->Opn]: Cannot build extensions with phpize
ID: 33326 User updated by: artooro at gmail dot com Reported By: artooro at gmail dot com -Status: No Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.1 PHP Version: 5CVS-2005-06-13 (dev) New Comment: sniper, I have no other machines with OSX so no I can't reproduce on other machine(s). But at least three other people have had this problem as well now. I might be able to look into it some more tomorrow, if needed. Previous Comments: [2005-07-26 01:18:00] jeffg at activestate dot com this is still ocurring with php 5.1 b3. I'm trying to build xdebug and getting the same failures, seems to eb something wrong with libtool generated by configure. [2005-07-08 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-06-30 16:24:22] [EMAIL PROTECTED] Can you reproduce this on other machine(s) ? (with same OS and versions of tools) [2005-06-30 11:28:36] bmansion at mamasam dot com Just to confirm the problem on Mac OS X using Tiger both with GCC 4 and GCC 3.3. The problem seems definitely in the generated libtool. I am using PHP 5.1beta2 with phpize. I've had the same messages when I tried to compile PECL translit and mnogosearch extensions. I didn't test with other extensions but I guess the problem will be the same. [2005-06-25 18:12:06] artooro at gmail dot com Yes to your question. I checked that over and over again because I thought of that too. There are so many changes between the 5.0.4 and CVS HEAD generated libtool (over 500 diffs) that I wasn't sure where to start :) 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/33326 -- Edit this bug report at http://bugs.php.net/?id=33326&edit=1
#33326 [Com]: Cannot build extensions with phpize
ID: 33326 Comment by: jeffg at activestate dot com Reported By: artooro at gmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.4.1 PHP Version: 5CVS-2005-06-13 (dev) New Comment: this is still ocurring with php 5.1 b3. I'm trying to build xdebug and getting the same failures, seems to eb something wrong with libtool generated by configure. Previous Comments: [2005-07-08 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-06-30 16:24:22] [EMAIL PROTECTED] Can you reproduce this on other machine(s) ? (with same OS and versions of tools) [2005-06-30 11:28:36] bmansion at mamasam dot com Just to confirm the problem on Mac OS X using Tiger both with GCC 4 and GCC 3.3. The problem seems definitely in the generated libtool. I am using PHP 5.1beta2 with phpize. I've had the same messages when I tried to compile PECL translit and mnogosearch extensions. I didn't test with other extensions but I guess the problem will be the same. [2005-06-25 18:12:06] artooro at gmail dot com Yes to your question. I checked that over and over again because I thought of that too. There are so many changes between the 5.0.4 and CVS HEAD generated libtool (over 500 diffs) that I wasn't sure where to start :) [2005-06-23 13:08:40] [EMAIL PROTECTED] You're sure you have the correct build files installed? (for example the libtool.m4 is totally different in HEAD) 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/33326 -- Edit this bug report at http://bugs.php.net/?id=33326&edit=1
#33690 [Csd]: Setting save_path in httpd.conf under safemode gives SEGV
ID: 33690 Updated by: [EMAIL PROTECTED] Reported By: david at madole dot net Status: Closed Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5CVS, 4CVS (2005-07-14) Assigned To: rasmus New Comment: Fix committed to both PHP 4.4 and 5.1 trees Previous Comments: [2005-07-25 19:33:17] david at madole dot net Closed as far as I'm concerned. [2005-07-25 19:32:06] david at madole dot net Yes, that patch does resolve the problem reported here. Thank you! [2005-07-25 16:11:21] [EMAIL PROTECTED] Could someone please try the patch I posted here for this one? http://news.php.net/php.internals/17261 [2005-07-14 08:53:50] [EMAIL PROTECTED] Apperently the fix for #33072 causes this. [2005-07-14 04:20:51] david at madole dot net Description: ./configure \ --prefix=/usr/local/opt/php4-STABLE-200507140043 \ --with-apxs2=/usr/local/opt/httpd-2.0.54/bin/apxs \ --with-config-file-path=/etc \ --enable-debug diff php.ini-dist /etc/php.ini 158c158 < safe_mode = Off --- > safe_mode = On PHP_Admin_Value open_basedir /home/user/ PHP_Admin_Value session.save_path /home/user/tmp/ On serving any page from /home/user/www, even plain HTML files not parsed by PHP, a SEGV is encountered in the Apache child process. The error occurs in sapi/apache2handler/sapi_apache2.c line 173, where ctx is dereferenced while containing NULL (see very end of backtract below): ctx->finfo.st_uid = ctx->r->finfo.user; Removing the newly introduced OnUpdateSaveDir check in ext/session/session.c eliminates the problem. Reproduce code: --- Test Expected result: Display "Test" in browser. Actual result: -- #0 0x2851ba51 in php_apache_sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:173 #1 0x284d9122 in sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/main/SAPI.c:848 #2 0x28487317 in php_statpage () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:73 #3 0x28487383 in php_getuid () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:99 #4 0x284d5b99 in php_checkuid_ex ( filename=0xbfbfdff0 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3, flags=0) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:150 #5 0x284d5cda in php_checkuid (filename=0x81dc6a4 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:191 #6 0x28443c64 in OnUpdateSaveDir (entry=0x81cbf00, new_value=0x81dc6a4 "/home/madole.net/tmp/", new_value_length=21, mh_arg1=0x0, mh_arg2=0x28577900, mh_arg3=0x0, stage=16) at /usr/local/src/php4-STABLE-200507140043/ext/session/session.c:123 #7 0x285101be in zend_alter_ini_entry (name=0x81106a0 "session.save_path", name_length=18, new_value=0x8123698 "/home/madole.net/tmp/", new_value_length=21, modify_type=4, stage=16) at /usr/local/src/php4-STABLE-200507140043/Zend/zend_ini.c:232 #8 0x2851cc48 in apply_config (dummy=0x8123598) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/apache_config.c:167 #9 0x2851c207 in php_handler (r=0x81f2050) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:457 #10 0x0807a45a in ap_run_handler (r=0x81f2050) at config.c:152 #11 0x0807a825 in ap_invoke_handler (r=0x81f2050) at config.c:364 #12 0x08069a35 in ap_process_request (r=0x81f2050) at http_request.c:249 #13 0x08065411 in ap_process_http_connection (c=0x81ec128) at http_core.c:251 #14 0x08083c72 in ap_run_process_connection (c=0x81ec128) at connection.c:43 #15 0x08078c71 in child_main (child_num_arg=0) at prefork.c:610 #16 0x08078e65 in make_child (s=0x80b9760, slot=0) at prefork.c:650 #17 0x08078f2c in startup_children (number_to_start=5) at prefork.c:722 #18 0x080795af in ap_mpm_run (_pconf=0xbfbfec40, plog=0x80ed018, s=0xbfbfec48) at prefork.c:941 #19 0x0807e74b in main (argc=6, argv=0xbfbfed38) at main.c:618 (gdb) print ctx $1 = (php_struct *) 0x0 -- Edit this bug report at http://bugs.php.net/?id=33690&edit=1
#33856 [Bgs]: $this shining through
ID: 33856
User updated by: sr at brightlight dot ch
Reported By: sr at brightlight dot ch
Status: Bogus
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.*
New Comment:
Well, maybe it is not intended that way anymore, but as long
as calling a function that way does not result in an error-
message it should be done correctly. A function opens a new
scope and within that scope, $this should not be visible (as
any other variable from the calling scope).
It is clear to me that this problem does not appear for pure
static functions, but I happen to have some hybrid
functions, that's why I discovered this problem at all.
But a question besides this: if calling via :: is only
possible with static functions in future - is there still a
way for developing hybrid functions that can be called
either via -> or :: or is the only possible solution to have
two different functions for the same?
Previous Comments:
[2005-07-25 23:50:51] [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
Mark the function as static. It is only possible to call non static
methods as static methods for BC reasons.
[2005-07-25 23:46:58] sr at brightlight dot ch
Description:
If a method is called via object::method(); from within a
class method, then inside of the object::method(); the $this
from the calling class method is visible.
This makes it almost impossible to tell if a method was
invoked via -> or ::
Reproduce code:
---
test();
class testclass {
function test() {
otherclass::staticFunction();
normalFunction();
}
}
class otherclass {
function staticFunction() {
echo "staticFunction: ".(isset($this) ? "set and of
class:
".get_class($this)."\n" : "not set\n");
}
}
function normalFunction() {
echo "normalFunction: ".(isset($this) ? "set and of class:
".get_class($this)."\n" : "not set\n");
}
?>
Expected result:
staticFunction: not set
normalFunction: not set
Actual result:
--
staticFunction: set and of class: testclass
normalFunction: not set
--
Edit this bug report at http://bugs.php.net/?id=33856&edit=1
#33857 [NEW]: token_get_all() inconsistent results?
From: sr at brightlight dot ch Operating system: Mac OS X 10.4.1 PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: token_get_all() inconsistent results? Description: Obviously the same problem as in Bug #33093, which is set to bogus (no comment). When I tokenize the very same code over and over again I happen to get different tokens. About 9 times out of 10 I get: Token'<', Token '?', Token T_STRING 'php', Token T_WHITESPACE '\n', About 1 time out of 10 Times I get Token T_OPEN_TAG 'http://bugs.php.net/?id=33857&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33857&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33857&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33857&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33857&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33857&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33857&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33857&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33857&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33857&r=support Expected behavior: http://bugs.php.net/fix.php?id=33857&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33857&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33857&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33857&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33857&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33857&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33857&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33857&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33857&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33857&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33857&r=mysqlcfg
#33856 [Opn->Bgs]: $this shining through
ID: 33856
Updated by: [EMAIL PROTECTED]
Reported By: sr at brightlight dot ch
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
-Operating System: Mac OS X 10.4.1
+Operating System: *
-PHP Version: 5.0.4
+PHP Version: 5.*
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
Mark the function as static. It is only possible to call non static
methods as static methods for BC reasons.
Previous Comments:
[2005-07-25 23:46:58] sr at brightlight dot ch
Description:
If a method is called via object::method(); from within a
class method, then inside of the object::method(); the $this
from the calling class method is visible.
This makes it almost impossible to tell if a method was
invoked via -> or ::
Reproduce code:
---
test();
class testclass {
function test() {
otherclass::staticFunction();
normalFunction();
}
}
class otherclass {
function staticFunction() {
echo "staticFunction: ".(isset($this) ? "set and of
class:
".get_class($this)."\n" : "not set\n");
}
}
function normalFunction() {
echo "normalFunction: ".(isset($this) ? "set and of class:
".get_class($this)."\n" : "not set\n");
}
?>
Expected result:
staticFunction: not set
normalFunction: not set
Actual result:
--
staticFunction: set and of class: testclass
normalFunction: not set
--
Edit this bug report at http://bugs.php.net/?id=33856&edit=1
#33856 [NEW]: $this shining through
From: sr at brightlight dot ch
Operating system: Mac OS X 10.4.1
PHP version: 5.0.4
PHP Bug Type: Class/Object related
Bug description: $this shining through
Description:
If a method is called via object::method(); from within a
class method, then inside of the object::method(); the $this
from the calling class method is visible.
This makes it almost impossible to tell if a method was
invoked via -> or ::
Reproduce code:
---
test();
class testclass {
function test() {
otherclass::staticFunction();
normalFunction();
}
}
class otherclass {
function staticFunction() {
echo "staticFunction: ".(isset($this) ? "set and of
class:
".get_class($this)."\n" : "not set\n");
}
}
function normalFunction() {
echo "normalFunction: ".(isset($this) ? "set and of class:
".get_class($this)."\n" : "not set\n");
}
?>
Expected result:
staticFunction: not set
normalFunction: not set
Actual result:
--
staticFunction: set and of class: testclass
normalFunction: not set
--
Edit bug report at http://bugs.php.net/?id=33856&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33856&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33856&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33856&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33856&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33856&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33856&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33856&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33856&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33856&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33856&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33856&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33856&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33856&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33856&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33856&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33856&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33856&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33856&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33856&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33856&r=mysqlcfg
#33853 [Opn->Csd]: php:function call __autoload with lowercase param
ID: 33853
Updated by: [EMAIL PROTECTED]
Reported By: pasha dot zubkov at gmail dot com
-Status: Open
+Status: Closed
Bug Type: XSLT related
Operating System: *
PHP Version: 5.0.4
Assigned To: helly
New Comment:
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.
Previous Comments:
[2005-07-25 20:45:46] [EMAIL PROTECTED]
It seems to be related to XSLT indeed, as I can't reproduce it with
5.0.4/5.1-dev with this code:
[2005-07-25 20:34:14] [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
[2005-07-25 20:27:23] pasha dot zubkov at gmail dot com
Description:
See example
Reproduce code:
---
loadXML('
http://www.w3.org/1999/XSL/Transform";
xmlns:php="http://php.net/xsl";>
');
$inputdom = new DomDocument();
$inputdom->loadXML('
');
$proc = new XsltProcessor();
$proc->registerPhpFunctions();
$xsl = $proc->importStylesheet($xsl);
$newdom = $proc->transformToDoc($inputdom);
?>
Expected result:
string(4) "TeSt"
Actual result:
--
string(4) "test"
--
Edit this bug report at http://bugs.php.net/?id=33853&edit=1
#33855 [Opn->Bgs]: Unable to identify a nvarchar field without an extra query
ID: 33855 Updated by: [EMAIL PROTECTED] Reported By: mauroi at digbang dot com -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: Irrelevant PHP Version: 5.0.4 New Comment: If MSSQL doesn't differ them, obviously PHP can't do it too. Previous Comments: [2005-07-25 22:47:29] mauroi at digbang dot com Description: Our applications work in Unicode. So, everything we retrieve from the database has to be encoded to Unicode or Unicode from source. That's why we need to identify nvarchar fields (ntext also) and bypass the encoding with them. mssql_field_type only returns 'char'. Maybe a new function that returns the original data type (without making an inner query, if that's possible) could be the best solution. -- Edit this bug report at http://bugs.php.net/?id=33855&edit=1
#33855 [NEW]: Unable to identify a nvarchar field without an extra query
From: mauroi at digbang dot com Operating system: Irrelevant PHP version: 5.0.4 PHP Bug Type: MSSQL related Bug description: Unable to identify a nvarchar field without an extra query Description: Our applications work in Unicode. So, everything we retrieve from the database has to be encoded to Unicode or Unicode from source. That's why we need to identify nvarchar fields (ntext also) and bypass the encoding with them. mssql_field_type only returns 'char'. Maybe a new function that returns the original data type (without making an inner query, if that's possible) could be the best solution. -- Edit bug report at http://bugs.php.net/?id=33855&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33855&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33855&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33855&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33855&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33855&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33855&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33855&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33855&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33855&r=support Expected behavior: http://bugs.php.net/fix.php?id=33855&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33855&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33855&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33855&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33855&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33855&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33855&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33855&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33855&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33855&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33855&r=mysqlcfg
#33854 [Opn->Bgs]: array_diff depending on element sequence
ID: 33854
Updated by: [EMAIL PROTECTED]
Reported By: bob dot siefkes at packardbell dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: XP SP2
PHP Version: 5.0.4
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
if you want keys & position to be considered use the array_diff_assoc()
function.
Previous Comments:
[2005-07-25 21:26:16] bob dot siefkes at packardbell dot com
I did confuse the two result blocks...
Expected result: <--> Actual result:
[2005-07-25 21:23:22] bob dot siefkes at packardbell dot com
Description:
Behavor of array_diff is dependent on the sequence of the elements in
the array.
See $array2 where I changed the sequence of "a"=>"c" with "a"=>"d" and
it results in different output.
Be noted that the key of both elements is the same, still I would not
expect array_diff to take this into account.
Bob
Reproduce code:
---
// source 1
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "c", "a" => "d" );
$result = array_diff($array1, $array2);
// source 2
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "d", "a" => "c" );
$result = array_diff($array1, $array2);
Expected result:
// result1:
Array
(
[a] => c
[b] => b
)
// result2
Array
(
[b] => b
)
Actual result:
--
// for both I would expect
Array
(
[b] => b
)
--
Edit this bug report at http://bugs.php.net/?id=33854&edit=1
#33853 [Fbk->Opn]: php:function call __autoload with lowercase param
ID: 33853
Updated by: [EMAIL PROTECTED]
Reported By: pasha dot zubkov at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: XSLT related
Operating System: *
PHP Version: 5.0.4
Assigned To: helly
Previous Comments:
[2005-07-25 20:45:46] [EMAIL PROTECTED]
It seems to be related to XSLT indeed, as I can't reproduce it with
5.0.4/5.1-dev with this code:
[2005-07-25 20:34:14] [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
[2005-07-25 20:27:23] pasha dot zubkov at gmail dot com
Description:
See example
Reproduce code:
---
loadXML('
http://www.w3.org/1999/XSL/Transform";
xmlns:php="http://php.net/xsl";>
');
$inputdom = new DomDocument();
$inputdom->loadXML('
');
$proc = new XsltProcessor();
$proc->registerPhpFunctions();
$xsl = $proc->importStylesheet($xsl);
$newdom = $proc->transformToDoc($inputdom);
?>
Expected result:
string(4) "TeSt"
Actual result:
--
string(4) "test"
--
Edit this bug report at http://bugs.php.net/?id=33853&edit=1
#33854 [Opn]: array_diff depending on element sequence
ID: 33854
User updated by: bob dot siefkes at packardbell dot com
Reported By: bob dot siefkes at packardbell dot com
Status: Open
Bug Type: Output Control
Operating System: XP SP2
PHP Version: 5.0.4
New Comment:
I did confuse the two result blocks...
Expected result: <--> Actual result:
Previous Comments:
[2005-07-25 21:23:22] bob dot siefkes at packardbell dot com
Description:
Behavor of array_diff is dependent on the sequence of the elements in
the array.
See $array2 where I changed the sequence of "a"=>"c" with "a"=>"d" and
it results in different output.
Be noted that the key of both elements is the same, still I would not
expect array_diff to take this into account.
Bob
Reproduce code:
---
// source 1
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "c", "a" => "d" );
$result = array_diff($array1, $array2);
// source 2
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "d", "a" => "c" );
$result = array_diff($array1, $array2);
Expected result:
// result1:
Array
(
[a] => c
[b] => b
)
// result2
Array
(
[b] => b
)
Actual result:
--
// for both I would expect
Array
(
[b] => b
)
--
Edit this bug report at http://bugs.php.net/?id=33854&edit=1
#33854 [NEW]: array_diff depending on element sequence
From: bob dot siefkes at packardbell dot com
Operating system: XP SP2
PHP version: 5.0.4
PHP Bug Type: Output Control
Bug description: array_diff depending on element sequence
Description:
Behavor of array_diff is dependent on the sequence of the elements in the
array.
See $array2 where I changed the sequence of "a"=>"c" with "a"=>"d" and it
results in different output.
Be noted that the key of both elements is the same, still I would not
expect array_diff to take this into account.
Bob
Reproduce code:
---
// source 1
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "c", "a" => "d" );
$result = array_diff($array1, $array2);
// source 2
$array1 = array("a" => "c", "b" => "b" );
$array2 = array("a" => "d", "a" => "c" );
$result = array_diff($array1, $array2);
Expected result:
// result1:
Array
(
[a] => c
[b] => b
)
// result2
Array
(
[b] => b
)
Actual result:
--
// for both I would expect
Array
(
[b] => b
)
--
Edit bug report at http://bugs.php.net/?id=33854&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33854&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33854&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33854&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33854&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33854&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33854&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33854&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33854&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33854&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33854&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33854&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33854&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33854&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33854&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33854&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33854&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33854&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33854&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33854&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33854&r=mysqlcfg
#33853 [Fbk]: php:function call __autoload with lowercase param
ID: 33853
Updated by: [EMAIL PROTECTED]
Reported By: pasha dot zubkov at gmail dot com
Status: Feedback
-Bug Type: Scripting Engine problem
+Bug Type: XSLT related
Operating System: Linux 2.6.12.2
PHP Version: 5.0.4
New Comment:
It seems to be related to XSLT indeed, as I can't reproduce it with
5.0.4/5.1-dev with this code:
Previous Comments:
[2005-07-25 20:34:14] [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
[2005-07-25 20:27:23] pasha dot zubkov at gmail dot com
Description:
See example
Reproduce code:
---
loadXML('
http://www.w3.org/1999/XSL/Transform";
xmlns:php="http://php.net/xsl";>
');
$inputdom = new DomDocument();
$inputdom->loadXML('
');
$proc = new XsltProcessor();
$proc->registerPhpFunctions();
$xsl = $proc->importStylesheet($xsl);
$newdom = $proc->transformToDoc($inputdom);
?>
Expected result:
string(4) "TeSt"
Actual result:
--
string(4) "test"
--
Edit this bug report at http://bugs.php.net/?id=33853&edit=1
#33853 [Opn->Fbk]: php:function call __autoload with lowercase param
ID: 33853
Updated by: [EMAIL PROTECTED]
Reported By: pasha dot zubkov at gmail dot com
-Status: Open
+Status: Feedback
-Bug Type: XSLT related
+Bug Type: Scripting Engine problem
Operating System: Linux 2.6.12.2
PHP Version: 5.0.4
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
Previous Comments:
[2005-07-25 20:27:23] pasha dot zubkov at gmail dot com
Description:
See example
Reproduce code:
---
loadXML('
http://www.w3.org/1999/XSL/Transform";
xmlns:php="http://php.net/xsl";>
');
$inputdom = new DomDocument();
$inputdom->loadXML('
');
$proc = new XsltProcessor();
$proc->registerPhpFunctions();
$xsl = $proc->importStylesheet($xsl);
$newdom = $proc->transformToDoc($inputdom);
?>
Expected result:
string(4) "TeSt"
Actual result:
--
string(4) "test"
--
Edit this bug report at http://bugs.php.net/?id=33853&edit=1
#33853 [NEW]: php:function call __autoload with lowercase param
From: pasha dot zubkov at gmail dot com
Operating system: Linux 2.6.12.2
PHP version: 5.0.4
PHP Bug Type: XSLT related
Bug description: php:function call __autoload with lowercase param
Description:
See example
Reproduce code:
---
loadXML('
http://www.w3.org/1999/XSL/Transform";
xmlns:php="http://php.net/xsl";>
');
$inputdom = new DomDocument();
$inputdom->loadXML('
');
$proc = new XsltProcessor();
$proc->registerPhpFunctions();
$xsl = $proc->importStylesheet($xsl);
$newdom = $proc->transformToDoc($inputdom);
?>
Expected result:
string(4) "TeSt"
Actual result:
--
string(4) "test"
--
Edit bug report at http://bugs.php.net/?id=33853&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33853&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33853&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33853&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33853&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33853&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33853&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33853&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33853&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33853&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33853&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33853&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33853&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33853&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33853&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33853&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33853&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33853&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33853&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33853&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33853&r=mysqlcfg
#33708 [Opn->Fbk]: Problem with php module recode
ID: 33708
Updated by: [EMAIL PROTECTED]
Reported By: kirameku at email dot cz
-Status: Open
+Status: Feedback
Bug Type: Recode related
Operating System: RedHat ES4 x86_64
PHP Version: 4CVS, 5CVS (2005-07-19)
New Comment:
Did you try with the PHP 5.1-dev snapshot? I've tested this in x86_64
(dual opteron machine) and it does NOT crash for me. (I have FC4
installed in it though)
Previous Comments:
[2005-07-25 18:30:22] kirameku at email dot cz
Thank you for your advice, but still not working. => Segmentation
fault. It is possible the problem is only on x86_64 architecture.
[2005-07-19 20:58:29] [EMAIL PROTECTED]
Please don't attach the same backtrace more than once.
I deleted that comment. You reported that your compiler is:
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)
Try this:
# rm config.cache && ./configure --disable-all --disable-cgi
--with-recode
# make clean && make
# run -r 'echo recode_string("utf-8..html_4.0","Hello, World !");'
[2005-07-18 21:51:44] [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
I can not reproduce this with PHP 5.1-dev.
Also, I have GCC-4.0.0, if that makes any difference..
[2005-07-18 11:03:23] [EMAIL PROTECTED]
I would suggest to use iconv() instead of recode - the recode library
is quite a mess.
[2005-07-18 10:50:59] kirameku at email dot cz
php4.4.0 was compiled with some warnings:
/home/Develop/php-4.4.0/ext/recode/recode.c: In function
`zif_recode_string':
/home/Develop/php-4.4.0/ext/recode/recode.c:156: warning: passing arg 5
of `recode_buffer_to_buffer' from incompatible pointer type
/home/Develop/php-4.4.0/ext/recode/recode.c:156: warning: passing arg 6
of `recode_buffer_to_buffer' from incompatible pointer type
recode version: recode-3.6-17, recode-devel-3.6-17
# gdb ./php core.15829
GNU gdb Red Hat Linux (6.3.0.0-0.31rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
Core was generated by `./php test.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /usr/lib64/librecode.so.0...done.
Loaded symbols for /usr/lib64/librecode.so.0
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/tls/libm.so.6...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libssl.so.4...done.
Loaded symbols for /lib64/libssl.so.4
Reading symbols from /lib64/libcrypto.so.4...done.
Loaded symbols for /lib64/libcrypto.so.4
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /lib64/tls/libc.so.6...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
(gdb) bt
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
#1 0x0038693aa50d in recode_new_task () from
/usr/lib64/librecode.so.0
#2 0x0038693aa82e in recode_perform_task () from
/usr/lib64/librecode.so.0
#3 0x0038693a924c in recode_buffer_to_buffer () from
/usr/lib64/librecode
#33733 [Asn->Csd]: PHP segfaults when using the pspell extension with -a
ID: 33733 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: CGI related -Operating System: linux +Operating System: * PHP Version: 5CVS-2005-07-17 (dev) Assigned To: helly New Comment: thanks for the patch Previous Comments: [2005-07-19 15:46:29] [EMAIL PROTECTED] Marcus, you're the author of CLI completion, plz take a look at the patch. [2005-07-19 15:36:05] [EMAIL PROTECTED] Well, after some debugging I've found the problem. it was much simpler that I though. The problem was that strcpy() was copying 1 more char than the memory allocated, corrupting it. Patch: http://mega.ist.utl.pt/~ncpl/php_cli_interactive.txt [2005-07-19 14:26:17] [EMAIL PROTECTED] Now the program receives a SIGABRT and backtrace shows readline. In fact it seems I cannot reproduce the problem if I execute the script from a file, just when I run PHP in interactive mode (and when I use the auto-completition feature). I'll try to debug this stupid thing. [2005-07-19 13:26:19] [EMAIL PROTECTED] config.nice: './configure' \ '--disable-cgi' \ '--enable-pcntl' \ '--with-ftp' \ '--with-tidy' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--with-readline' \ '--with-bz2' \ '--with-zlib' \ '--with-openssl' \ '--with-pspell' \ '--with-zend-vm=GOTO' [2005-07-18 13:02:30] [EMAIL PROTECTED] I don't know what kind of info you want... Well, here it is the script used (which is above): 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/33733 -- Edit this bug report at http://bugs.php.net/?id=33733&edit=1
#33690 [Opn->Csd]: Setting save_path in httpd.conf under safemode gives SEGV
ID: 33690 User updated by: david at madole dot net Reported By: david at madole dot net -Status: Open +Status: Closed Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5CVS, 4CVS (2005-07-14) Assigned To: rasmus New Comment: Closed as far as I'm concerned. Previous Comments: [2005-07-25 19:32:06] david at madole dot net Yes, that patch does resolve the problem reported here. Thank you! [2005-07-25 16:11:21] [EMAIL PROTECTED] Could someone please try the patch I posted here for this one? http://news.php.net/php.internals/17261 [2005-07-14 08:53:50] [EMAIL PROTECTED] Apperently the fix for #33072 causes this. [2005-07-14 04:20:51] david at madole dot net Description: ./configure \ --prefix=/usr/local/opt/php4-STABLE-200507140043 \ --with-apxs2=/usr/local/opt/httpd-2.0.54/bin/apxs \ --with-config-file-path=/etc \ --enable-debug diff php.ini-dist /etc/php.ini 158c158 < safe_mode = Off --- > safe_mode = On PHP_Admin_Value open_basedir /home/user/ PHP_Admin_Value session.save_path /home/user/tmp/ On serving any page from /home/user/www, even plain HTML files not parsed by PHP, a SEGV is encountered in the Apache child process. The error occurs in sapi/apache2handler/sapi_apache2.c line 173, where ctx is dereferenced while containing NULL (see very end of backtract below): ctx->finfo.st_uid = ctx->r->finfo.user; Removing the newly introduced OnUpdateSaveDir check in ext/session/session.c eliminates the problem. Reproduce code: --- Test Expected result: Display "Test" in browser. Actual result: -- #0 0x2851ba51 in php_apache_sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:173 #1 0x284d9122 in sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/main/SAPI.c:848 #2 0x28487317 in php_statpage () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:73 #3 0x28487383 in php_getuid () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:99 #4 0x284d5b99 in php_checkuid_ex ( filename=0xbfbfdff0 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3, flags=0) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:150 #5 0x284d5cda in php_checkuid (filename=0x81dc6a4 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:191 #6 0x28443c64 in OnUpdateSaveDir (entry=0x81cbf00, new_value=0x81dc6a4 "/home/madole.net/tmp/", new_value_length=21, mh_arg1=0x0, mh_arg2=0x28577900, mh_arg3=0x0, stage=16) at /usr/local/src/php4-STABLE-200507140043/ext/session/session.c:123 #7 0x285101be in zend_alter_ini_entry (name=0x81106a0 "session.save_path", name_length=18, new_value=0x8123698 "/home/madole.net/tmp/", new_value_length=21, modify_type=4, stage=16) at /usr/local/src/php4-STABLE-200507140043/Zend/zend_ini.c:232 #8 0x2851cc48 in apply_config (dummy=0x8123598) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/apache_config.c:167 #9 0x2851c207 in php_handler (r=0x81f2050) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:457 #10 0x0807a45a in ap_run_handler (r=0x81f2050) at config.c:152 #11 0x0807a825 in ap_invoke_handler (r=0x81f2050) at config.c:364 #12 0x08069a35 in ap_process_request (r=0x81f2050) at http_request.c:249 #13 0x08065411 in ap_process_http_connection (c=0x81ec128) at http_core.c:251 #14 0x08083c72 in ap_run_process_connection (c=0x81ec128) at connection.c:43 #15 0x08078c71 in child_main (child_num_arg=0) at prefork.c:610 #16 0x08078e65 in make_child (s=0x80b9760, slot=0) at prefork.c:650 #17 0x08078f2c in startup_children (number_to_start=5) at prefork.c:722 #18 0x080795af in ap_mpm_run (_pconf=0xbfbfec40, plog=0x80ed018, s=0xbfbfec48) at prefork.c:941 #19 0x0807e74b in main (argc=6, argv=0xbfbfed38) at main.c:618 (gdb) print ctx $1 = (php_struct *) 0x0 -- Edit this bug report at http://bugs.php.net/?id=33690&edit=1
#33690 [Fbk->Opn]: Setting save_path in httpd.conf under safemode gives SEGV
ID: 33690 User updated by: david at madole dot net Reported By: david at madole dot net -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5CVS, 4CVS (2005-07-14) Assigned To: rasmus New Comment: Yes, that patch does resolve the problem reported here. Thank you! Previous Comments: [2005-07-25 16:11:21] [EMAIL PROTECTED] Could someone please try the patch I posted here for this one? http://news.php.net/php.internals/17261 [2005-07-14 08:53:50] [EMAIL PROTECTED] Apperently the fix for #33072 causes this. [2005-07-14 04:20:51] david at madole dot net Description: ./configure \ --prefix=/usr/local/opt/php4-STABLE-200507140043 \ --with-apxs2=/usr/local/opt/httpd-2.0.54/bin/apxs \ --with-config-file-path=/etc \ --enable-debug diff php.ini-dist /etc/php.ini 158c158 < safe_mode = Off --- > safe_mode = On PHP_Admin_Value open_basedir /home/user/ PHP_Admin_Value session.save_path /home/user/tmp/ On serving any page from /home/user/www, even plain HTML files not parsed by PHP, a SEGV is encountered in the Apache child process. The error occurs in sapi/apache2handler/sapi_apache2.c line 173, where ctx is dereferenced while containing NULL (see very end of backtract below): ctx->finfo.st_uid = ctx->r->finfo.user; Removing the newly introduced OnUpdateSaveDir check in ext/session/session.c eliminates the problem. Reproduce code: --- Test Expected result: Display "Test" in browser. Actual result: -- #0 0x2851ba51 in php_apache_sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:173 #1 0x284d9122 in sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/main/SAPI.c:848 #2 0x28487317 in php_statpage () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:73 #3 0x28487383 in php_getuid () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:99 #4 0x284d5b99 in php_checkuid_ex ( filename=0xbfbfdff0 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3, flags=0) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:150 #5 0x284d5cda in php_checkuid (filename=0x81dc6a4 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:191 #6 0x28443c64 in OnUpdateSaveDir (entry=0x81cbf00, new_value=0x81dc6a4 "/home/madole.net/tmp/", new_value_length=21, mh_arg1=0x0, mh_arg2=0x28577900, mh_arg3=0x0, stage=16) at /usr/local/src/php4-STABLE-200507140043/ext/session/session.c:123 #7 0x285101be in zend_alter_ini_entry (name=0x81106a0 "session.save_path", name_length=18, new_value=0x8123698 "/home/madole.net/tmp/", new_value_length=21, modify_type=4, stage=16) at /usr/local/src/php4-STABLE-200507140043/Zend/zend_ini.c:232 #8 0x2851cc48 in apply_config (dummy=0x8123598) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/apache_config.c:167 #9 0x2851c207 in php_handler (r=0x81f2050) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:457 #10 0x0807a45a in ap_run_handler (r=0x81f2050) at config.c:152 #11 0x0807a825 in ap_invoke_handler (r=0x81f2050) at config.c:364 #12 0x08069a35 in ap_process_request (r=0x81f2050) at http_request.c:249 #13 0x08065411 in ap_process_http_connection (c=0x81ec128) at http_core.c:251 #14 0x08083c72 in ap_run_process_connection (c=0x81ec128) at connection.c:43 #15 0x08078c71 in child_main (child_num_arg=0) at prefork.c:610 #16 0x08078e65 in make_child (s=0x80b9760, slot=0) at prefork.c:650 #17 0x08078f2c in startup_children (number_to_start=5) at prefork.c:722 #18 0x080795af in ap_mpm_run (_pconf=0xbfbfec40, plog=0x80ed018, s=0xbfbfec48) at prefork.c:941 #19 0x0807e74b in main (argc=6, argv=0xbfbfed38) at main.c:618 (gdb) print ctx $1 = (php_struct *) 0x0 -- Edit this bug report at http://bugs.php.net/?id=33690&edit=1
#33708 [Fbk->Opn]: Problem with php module recode
ID: 33708
User updated by: kirameku at email dot cz
Reported By: kirameku at email dot cz
-Status: Feedback
+Status: Open
Bug Type: Recode related
Operating System: RedHat ES4 x86_64
PHP Version: 4CVS, 5CVS (2005-07-19)
New Comment:
Thank you for your advice, but still not working. => Segmentation
fault. It is possible the problem is only on x86_64 architecture.
Previous Comments:
[2005-07-19 20:58:29] [EMAIL PROTECTED]
Please don't attach the same backtrace more than once.
I deleted that comment. You reported that your compiler is:
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)
Try this:
# rm config.cache && ./configure --disable-all --disable-cgi
--with-recode
# make clean && make
# run -r 'echo recode_string("utf-8..html_4.0","Hello, World !");'
[2005-07-18 21:51:44] [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
I can not reproduce this with PHP 5.1-dev.
Also, I have GCC-4.0.0, if that makes any difference..
[2005-07-18 11:03:23] [EMAIL PROTECTED]
I would suggest to use iconv() instead of recode - the recode library
is quite a mess.
[2005-07-18 10:50:59] kirameku at email dot cz
php4.4.0 was compiled with some warnings:
/home/Develop/php-4.4.0/ext/recode/recode.c: In function
`zif_recode_string':
/home/Develop/php-4.4.0/ext/recode/recode.c:156: warning: passing arg 5
of `recode_buffer_to_buffer' from incompatible pointer type
/home/Develop/php-4.4.0/ext/recode/recode.c:156: warning: passing arg 6
of `recode_buffer_to_buffer' from incompatible pointer type
recode version: recode-3.6-17, recode-devel-3.6-17
# gdb ./php core.15829
GNU gdb Red Hat Linux (6.3.0.0-0.31rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
Core was generated by `./php test.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /usr/lib64/librecode.so.0...done.
Loaded symbols for /usr/lib64/librecode.so.0
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/tls/libm.so.6...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libssl.so.4...done.
Loaded symbols for /lib64/libssl.so.4
Reading symbols from /lib64/libcrypto.so.4...done.
Loaded symbols for /lib64/libcrypto.so.4
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /lib64/tls/libc.so.6...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
(gdb) bt
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
#1 0x0038693aa50d in recode_new_task () from
/usr/lib64/librecode.so.0
#2 0x0038693aa82e in recode_perform_task () from
/usr/lib64/librecode.so.0
#3 0x0038693a924c in recode_buffer_to_buffer () from
/usr/lib64/librecode.so.0
#4 0x004b78c7 in zif_recode_string (ht=72,
return_value=0x9571f8, this_ptr=0x48, return_value_used=9814288)
at /home/Develop/php-4.4.0/ext/recode/recode.c:156
#5 0x0057fc80 in execute (op_array=0x957ad8) at
/home/Develop/php-4.4.0/Zend/zend_execute
#33690 [Asn->Fbk]: Setting save_path in httpd.conf under safemode gives SEGV
ID: 33690 Updated by: [EMAIL PROTECTED] Reported By: david at madole dot net -Status: Assigned +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5CVS, 4CVS (2005-07-14) Assigned To: rasmus New Comment: Could someone please try the patch I posted here for this one? http://news.php.net/php.internals/17261 Previous Comments: [2005-07-14 08:53:50] [EMAIL PROTECTED] Apperently the fix for #33072 causes this. [2005-07-14 04:20:51] david at madole dot net Description: ./configure \ --prefix=/usr/local/opt/php4-STABLE-200507140043 \ --with-apxs2=/usr/local/opt/httpd-2.0.54/bin/apxs \ --with-config-file-path=/etc \ --enable-debug diff php.ini-dist /etc/php.ini 158c158 < safe_mode = Off --- > safe_mode = On PHP_Admin_Value open_basedir /home/user/ PHP_Admin_Value session.save_path /home/user/tmp/ On serving any page from /home/user/www, even plain HTML files not parsed by PHP, a SEGV is encountered in the Apache child process. The error occurs in sapi/apache2handler/sapi_apache2.c line 173, where ctx is dereferenced while containing NULL (see very end of backtract below): ctx->finfo.st_uid = ctx->r->finfo.user; Removing the newly introduced OnUpdateSaveDir check in ext/session/session.c eliminates the problem. Reproduce code: --- Test Expected result: Display "Test" in browser. Actual result: -- #0 0x2851ba51 in php_apache_sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:173 #1 0x284d9122 in sapi_get_stat () at /usr/local/src/php4-STABLE-200507140043/main/SAPI.c:848 #2 0x28487317 in php_statpage () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:73 #3 0x28487383 in php_getuid () at /usr/local/src/php4-STABLE-200507140043/ext/standard/pageinfo.c:99 #4 0x284d5b99 in php_checkuid_ex ( filename=0xbfbfdff0 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3, flags=0) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:150 #5 0x284d5cda in php_checkuid (filename=0x81dc6a4 "/home/madole.net/tmp/", fopen_mode=0x0, mode=3) at /usr/local/src/php4-STABLE-200507140043/main/safe_mode.c:191 #6 0x28443c64 in OnUpdateSaveDir (entry=0x81cbf00, new_value=0x81dc6a4 "/home/madole.net/tmp/", new_value_length=21, mh_arg1=0x0, mh_arg2=0x28577900, mh_arg3=0x0, stage=16) at /usr/local/src/php4-STABLE-200507140043/ext/session/session.c:123 #7 0x285101be in zend_alter_ini_entry (name=0x81106a0 "session.save_path", name_length=18, new_value=0x8123698 "/home/madole.net/tmp/", new_value_length=21, modify_type=4, stage=16) at /usr/local/src/php4-STABLE-200507140043/Zend/zend_ini.c:232 #8 0x2851cc48 in apply_config (dummy=0x8123598) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/apache_config.c:167 #9 0x2851c207 in php_handler (r=0x81f2050) at /usr/local/src/php4-STABLE-200507140043/sapi/apache2handler/sapi_apache2.c:457 #10 0x0807a45a in ap_run_handler (r=0x81f2050) at config.c:152 #11 0x0807a825 in ap_invoke_handler (r=0x81f2050) at config.c:364 #12 0x08069a35 in ap_process_request (r=0x81f2050) at http_request.c:249 #13 0x08065411 in ap_process_http_connection (c=0x81ec128) at http_core.c:251 #14 0x08083c72 in ap_run_process_connection (c=0x81ec128) at connection.c:43 #15 0x08078c71 in child_main (child_num_arg=0) at prefork.c:610 #16 0x08078e65 in make_child (s=0x80b9760, slot=0) at prefork.c:650 #17 0x08078f2c in startup_children (number_to_start=5) at prefork.c:722 #18 0x080795af in ap_mpm_run (_pconf=0xbfbfec40, plog=0x80ed018, s=0xbfbfec48) at prefork.c:941 #19 0x0807e74b in main (argc=6, argv=0xbfbfed38) at main.c:618 (gdb) print ctx $1 = (php_struct *) 0x0 -- Edit this bug report at http://bugs.php.net/?id=33690&edit=1
#33849 [Opn->Bgs]: LOCK TABLES with mysql_query() works wrong
ID: 33849
Updated by: [EMAIL PROTECTED]
Reported By: test157 at starman dot ee
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Linux Fedora Core 4
PHP Version: 4.4.0
New Comment:
Consult mysql support channels for further assistance.
Previous Comments:
[2005-07-25 03:48:10] test157 at starman dot ee
Description:
When I'am locking MySQL ISAM table from PHP env, all other threads
still can use this table for READ/WRITE actions. But I didn't get from
mysql_error() any message, and even cannot access other tables, untill
they not locked too. So it's seems like PHP really thinks that MySQL
locked. I think that this is problem of PHP because from MySQL console
I can lock tables succesfuly, and after this lock even PHP cannot
access this table.
Reproduce code:
---
mysql_pconnect("localhost","root","");
mysql_select_db("test_db");
mysql_query("LOCK TABLES `test_table_1` WRITE");
mysql_query("INSERT INTO `test_table_1` (`a`) VALUES (1)"); // returns
OK
mysql_query("INSERT INTO `test_table_2` (`a`) VALUES (1)"); // Table
was not locked with LOCK TABLES
sleep(100);
mysql_query("UNLOCK TABLES");
Expected result:
with this code I want to show you that all works fine, from side of
thread what lock MySQL table. But really nothing is locked, during this
100 seconds I can edit/read test_table_1, without any problems from
other threads. If I will even remove UNLOCK TABLES command and will use
presistent connection, I will not hang up system. Because nothing is
locked.
Actual result:
--
I tried it on PHP v 4.4.0/5.0.3/snapshots, CLI mode/Apache 2.0.54
compiled as worker/prefork, mysql v 4.1.12,13,14. And everywhere the
same picture. I tried to compile PHP in different ways, from
--disable-all + some only important keys, to full configs. Also tried
to use budle MySQL libraries and what install on system. But all the
same.
Hope on your fast bug_fix.
P.S: Also on this system I cannot flock(file) it all the same like with
MySQL, no any error returned, but file no locked for other threads.
(FS:ext2)
--
Edit this bug report at http://bugs.php.net/?id=33849&edit=1
#33852 [Fbk->Bgs]: Strrpos: offset param works from the end
ID: 33852
Updated by: [EMAIL PROTECTED]
Reported By: sl at yes-co dot nl
-Status: Feedback
+Status: Bogus
Bug Type: Strings related
Operating System: Linux sarge 2.6.8
PHP Version: 5.1.0-dev
New Comment:
Quote whole parts and you will understand it: "As of PHP 5.0.0 offset
may be specified to begin searching an arbitrary number of characters
into the string. Negative values will stop searching at an arbitrary
point prior to the end of the string."
Thus strrpos('0123456789', '3', 5) is equal to strrpos('.56789',
'3') and strrpos('0123456789', '3', -5) is equal to strrpos('012345',
'3').
Previous Comments:
[2005-07-25 12:34:27] [EMAIL PROTECTED]
There are two fields int the report form: one for the result you expect
to get and second for the result you actually get.
Please fill them both.
[2005-07-25 11:58:41] sl at yes-co dot nl
Offset also does not work from the end:
strrpos with offset
string: aaabbaaa
strrpos($string, 'b', 1): 16
strrpos($string, 'b', 5): 16
strrpos($string, 'b', 15): 16
strrpos($string, 'b', 19):
strrpos($string, 'b', -5): 3
strrpos($string, 'b', -15): 3
This does not make sense.
[2005-07-25 11:45:07] sl at yes-co dot nl
Description:
The offset parameter of the strrpos function is the offset from the end
of the string. The documentation is unclear about this:
"As of PHP 5.0.0 offset may be specified to begin searching an
arbitrary number of characters into the string."
I would expect it to start at $string+$offset, searching backwards.
Reproduce code:
---
Actual result:
--
strrpos with offset
string: abcdefghijklmnopqrstuvwxyz
strrpos($string, 'n', 5): 13
strrpos($string, 'n', 15):
strrpos($string, 'n', -5): 13
strrpos($string, 'n', -15):
--
Edit this bug report at http://bugs.php.net/?id=33852&edit=1
#33836 [Bgs]: 1 pixel missing on imagecopyresized and imagecopyresampled
ID: 33836 Updated by: [EMAIL PROTECTED] Reported By: bug_php at yahoo dot fr Status: Bogus Bug Type: *Graphics related Operating System: Linux RedHat 2.4.28 PHP Version: 4.3.11 Assigned To: pajoye New Comment: Not much I can do if you use an extern GD. Ask them to use the bundled GD. I cannot reproduce your problem using bundled GD. You can try it using a local installation of php. --Pierre Previous Comments: [2005-07-25 14:27:19] bug_php at yahoo dot fr So... Did you reproduce the bug with the new details I gave to you? (See my message on 25 Jul 6:33am CEST, before the message on 25 Jul 6:48am CEST) [2005-07-25 08:08:37] [EMAIL PROTECTED] Right, you are using an extern GD. [2005-07-25 06:48:54] bug_php at yahoo dot fr Oops, it seems that I don't use a bundled GD, as on phpinfo() here http://720plan.ovh.net/test.php I can see that: "--with-gd=/usr/local' " Isn't it? [2005-07-25 06:33:43] bug_php at yahoo dot fr I'm sorry but it still doesn't work, and I don't think my code is bogus. I use the bundled GD (version 2.0 or higer) as you can see here: http://720plan.ovh.net/test.php (this is my hosting company's website). Did you try with PHP 4.3.11? I put my sample code here so that you can try it with various couple of width and size and see what I mean. I also put in my code a highlight_file() and a gd_info() so that you can see the actual code and various config paramaters: http://www.demaison.com/boy.php Thanx [2005-07-23 17:39:46] [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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Cannot reproduce, if you still have still problem, tell us if you use the bundled GD (configure --with-gd, without path to any external gd). Have tried with 5.1 and 4.4 --Pierre 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/33836 -- Edit this bug report at http://bugs.php.net/?id=33836&edit=1
#33836 [Bgs]: 1 pixel missing on imagecopyresized and imagecopyresampled
ID: 33836 User updated by: bug_php at yahoo dot fr Reported By: bug_php at yahoo dot fr Status: Bogus Bug Type: *Graphics related Operating System: Linux RedHat 2.4.28 PHP Version: 4.3.11 Assigned To: pajoye New Comment: So... Did you reproduce the bug with the new details I gave to you? (See my message on 25 Jul 6:33am CEST, before the message on 25 Jul 6:48am CEST) Previous Comments: [2005-07-25 08:08:37] [EMAIL PROTECTED] Right, you are using an extern GD. [2005-07-25 06:48:54] bug_php at yahoo dot fr Oops, it seems that I don't use a bundled GD, as on phpinfo() here http://720plan.ovh.net/test.php I can see that: "--with-gd=/usr/local' " Isn't it? [2005-07-25 06:33:43] bug_php at yahoo dot fr I'm sorry but it still doesn't work, and I don't think my code is bogus. I use the bundled GD (version 2.0 or higer) as you can see here: http://720plan.ovh.net/test.php (this is my hosting company's website). Did you try with PHP 4.3.11? I put my sample code here so that you can try it with various couple of width and size and see what I mean. I also put in my code a highlight_file() and a gd_info() so that you can see the actual code and various config paramaters: http://www.demaison.com/boy.php Thanx [2005-07-23 17:39:46] [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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Cannot reproduce, if you still have still problem, tell us if you use the bundled GD (configure --with-gd, without path to any external gd). Have tried with 5.1 and 4.4 --Pierre [2005-07-23 15:04:19] bug_php at yahoo dot fr Description: See PHP info on http://720plan.ovh.net/test.php (PHP version is 4.3.11 as of 2005/07/23). Bug similar to the problem exposed in closed bug report #26254. The code below results in an image that is 1 pixel too small: there is a blank range of pixels. According to the destination image width and height, this range of pixels can be vertical, horizontal, or both. The code below is for a 640*480 image destination. But the same happens for a 40*40 image for instance. This problem occurs with any image and number of pixels I tried. The only case it works: when the image destination has the same size thant the source image. Reproduce code: --- Resized image="); ?> -- Edit this bug report at http://bugs.php.net/?id=33836&edit=1
#29779 [Com]: ORA-24327
ID: 29779 Comment by: jfbustarret at tf1 dot fr Reported By: robertg2 at hope dot ac dot uk Status: Suspended Bug Type: OCI8 related Operating System: Solaris 8 PHP Version: 5.0.1 Assigned To: tony2001 New Comment: I had the same problem and wrote a small patch : http://www.jeuxdecartes.net/static/oci8.ping_freq.patch It adds a oci8.ping_freq php.ini variable (oci8.ping_freq = 60 is a good start). Previous Comments: [2005-07-22 21:41:12] bradpover at gmail dot com I too would appreciate a quick fix to this feature (what does the suspended status mean?). I see the error message using PHP 5.0.4, Apache 2.0.54 on win2k talking to a remote Oracle 10g database through Instant Client. BTW the suggestion to uncomment out ociping() in ori8.c may be for oci_ping() instead? That's what's in the win php5 source anyway. I just need a compiler now (the ms visual c++ toolkit 2003 does not include msdev which is needed to build resolv.lib - what a thing to find out _after_ downloading and installing 1GB of mostly not needed packages). On the brighter side I am running windows so system crashes and reboots will make my admin job easier for once. :) [2005-07-13 09:30:00] ecervetti at ch-hyeres dot fr I use php 5.0.4 On mandrake linux, the bug remains; but I can't see any ociping() function in oci8.c [2005-07-01 19:20:17] chung dot ley at amd dot com Why does 4.3.10 not have this problem? Is it because it is doing the ociping() or similar which means that its performance is less than the 5.0? Or just that the 5.0.x has special optimization with using the Oracle internal library? What is the status of the fix? Will it be in the next release or maybe the next next release? How can I help to push the priority of the fix? I perfer not to use 4.3.10 because I will need to re-test all my applications on 4.3.10, and I also prefer not to uncomment ociping() so that I don't have to degrade the performance... In other words, I want everything :DDD Thanks [2005-06-13 19:58:39] wustl_2008 at yahoo dot com I am experiencing the same problem on Apache 5.0.0 with Oracle 9.2. Any solutions besides rebooting the Apache server are greatly appreciated as I cannot afford to reboot the apache server since I am unable to know when the database has gone down for certain. I am capturing the error codes from OCIError and can determine the cause, but am unable (due to user abilities on the Linux system) to reboot Apache with a script, etc. Fix on this ASAP would be greatly appreciated. [2005-05-24 14:28:34] rootradical at hotbox dot ru I have the same "feature" (oci_connect(): OCISessionBegin: ORA-24327: need explicit attach before authenticating a user) using PHP 5.0.4 on Win2k SP4, Apache 2.0.47, Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production. Unfortunately, I can't recompile oci8.c with ociping() enabled and it's very inconveniently to restart Apache every time database goes down. I hope you release some fix in the not too distant future. Because of this I need to use PHP 4.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/29779 -- Edit this bug report at http://bugs.php.net/?id=29779&edit=1
#33813 [Opn->Asn]: PHP won't build with PostgreSQL < 7.4
ID: 33813
Updated by: [EMAIL PROTECTED]
Reported By: dseg at shield dot jp
-Status: Open
+Status: Assigned
Bug Type: Compile Failure
Operating System: LINUX
PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: yohgaki
Previous Comments:
[2005-07-22 04:57:48] dseg at shield dot jp
Patch for this bug:
--- ext/pgsql/config.m4.orig2005-05-30 08:16:43.0 +0900
+++ ext/pgsql/config.m4 2005-07-22 09:33:47.0 +0900
@@ -88,6 +88,7 @@
AC_CHECK_LIB(pq,
PQputCopyEnd,AC_DEFINE(HAVE_PQPUTCOPYEND,1,[PostgreSQL 7.4 or later]))
AC_CHECK_LIB(pq,
PQgetCopyData,AC_DEFINE(HAVE_PQGETCOPYDATA,1,[PostgreSQL 7.4 or
later]))
AC_CHECK_LIB(pq,
PQsetErrorVerbosity,AC_DEFINE(HAVE_PQSETERRORVERBOSITY,1,[PostgreSQL
7.4 or later]))
+ AC_CHECK_LIB(pq, PQfreemem,AC_DEFINE(HAVE_PQFREEMEM,1,[PostgreSQL
7.4 or later]))
AC_CHECK_LIB(pq,
pg_encoding_to_char,AC_DEFINE(HAVE_PGSQL_WITH_MULTIBYTE_SUPPORT,1,[Whether
libpq is compiled with --enable-multibyte]))
LIBS=$old_LIBS
LDFLAGS=$old_LDFLAGS
--- ext/pgsql/pgsql.c.orig 2005-07-08 09:40:32.0 +0900
+++ ext/pgsql/pgsql.c 2005-07-21 13:21:52.0 +0900
@@ -3598,10 +3598,17 @@
#if HAVE_PQUNESCAPEBYTEA
tmp = (char *)PQunescapeBytea((unsigned char*)from, &to_len);
to = estrndup(tmp, to_len);
- PQfreemem(tmp);
#else
to = (char *)php_pgsql_unescape_bytea((unsigned char*)from,
&to_len);
#endif
+if(tmp) {
+#if HAVE_PQFREEMEM
+ PQfreemem(tmp);
+#else
+ efree(tmp);
+#endif
+ }
+
if (!to) {
RETURN_FALSE;
}
[2005-07-22 04:28:04] dseg at shield dot jp
Description:
PHP-5.1.0b3 won't build with PostgreSQL < 7.4.
The reason for this is that the ext/pgsql/pgsql.c use the PQfreemem
function which is only available in PostgreSQL 7.4 or later.
Reproduce code:
---
configure --with-pgsql
Expected result:
It should build
Actual result:
--
ext/pgsql/.libs/pgsql.o: In function `zif_pg_unescape_bytea':
ext/pgsql/.libs/pgsql.o(.text+0x3c2c): undefined reference to
`PQfreemem'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
--
Edit this bug report at http://bugs.php.net/?id=33813&edit=1
#33852 [Opn->Fbk]: Strrpos: offset param works from the end
ID: 33852 Updated by: [EMAIL PROTECTED] Reported By: sl at yes-co dot nl -Status: Open +Status: Feedback -Bug Type: Scripting Engine problem +Bug Type: Strings related Operating System: Linux sarge 2.6.8 PHP Version: 5.1.0-dev New Comment: There are two fields int the report form: one for the result you expect to get and second for the result you actually get. Please fill them both. Previous Comments: [2005-07-25 11:58:41] sl at yes-co dot nl Offset also does not work from the end: strrpos with offset string: aaabbaaa strrpos($string, 'b', 1): 16 strrpos($string, 'b', 5): 16 strrpos($string, 'b', 15): 16 strrpos($string, 'b', 19): strrpos($string, 'b', -5): 3 strrpos($string, 'b', -15): 3 This does not make sense. [2005-07-25 11:45:07] sl at yes-co dot nl Description: The offset parameter of the strrpos function is the offset from the end of the string. The documentation is unclear about this: "As of PHP 5.0.0 offset may be specified to begin searching an arbitrary number of characters into the string." I would expect it to start at $string+$offset, searching backwards. Reproduce code: --- Actual result: -- strrpos with offset string: abcdefghijklmnopqrstuvwxyz strrpos($string, 'n', 5): 13 strrpos($string, 'n', 15): strrpos($string, 'n', -5): 13 strrpos($string, 'n', -15): -- Edit this bug report at http://bugs.php.net/?id=33852&edit=1
#33852 [Opn]: Strrpos: offset param works from the end
ID: 33852 User updated by: sl at yes-co dot nl Reported By: sl at yes-co dot nl Status: Open -Bug Type: Documentation problem +Bug Type: Scripting Engine problem Operating System: Linux sarge 2.6.8 -PHP Version: Irrelevant +PHP Version: 5.1.0-dev New Comment: Offset also does not work from the end: strrpos with offset string: aaabbaaa strrpos($string, 'b', 1): 16 strrpos($string, 'b', 5): 16 strrpos($string, 'b', 15): 16 strrpos($string, 'b', 19): strrpos($string, 'b', -5): 3 strrpos($string, 'b', -15): 3 This does not make sense. Previous Comments: [2005-07-25 11:45:07] sl at yes-co dot nl Description: The offset parameter of the strrpos function is the offset from the end of the string. The documentation is unclear about this: "As of PHP 5.0.0 offset may be specified to begin searching an arbitrary number of characters into the string." I would expect it to start at $string+$offset, searching backwards. Reproduce code: --- Actual result: -- strrpos with offset string: abcdefghijklmnopqrstuvwxyz strrpos($string, 'n', 5): 13 strrpos($string, 'n', 15): strrpos($string, 'n', -5): 13 strrpos($string, 'n', -15): -- Edit this bug report at http://bugs.php.net/?id=33852&edit=1
#33851 [Opn->Fbk]: date function error
ID: 33851
Updated by: [EMAIL PROTECTED]
Reported By: yesman78 at hanmail dot net
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: linux 2.6.X
PHP Version: 5.1.0b3
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
Previous Comments:
[2005-07-25 09:33:24] yesman78 at hanmail dot net
Description:
error date("G");
Reproduce code:
---
echo date("YnjG");
20057257 error
200572516
Expected result:
error
Actual result:
--
error
--
Edit this bug report at http://bugs.php.net/?id=33851&edit=1
#33851 [NEW]: date function error
From: yesman78 at hanmail dot net
Operating system: linux 2.6.X
PHP version: 5.1.0b3
PHP Bug Type: Unknown/Other Function
Bug description: date function error
Description:
error date("G");
Reproduce code:
---
echo date("YnjG");
20057257 error
200572516
Expected result:
error
Actual result:
--
error
--
Edit bug report at http://bugs.php.net/?id=33851&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33851&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33851&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33851&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33851&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33851&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33851&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33851&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33851&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33851&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33851&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33851&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33851&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33851&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33851&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33851&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33851&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33851&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33851&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33851&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33851&r=mysqlcfg
#33850 [NEW]: PATCH: Support LDAP_X_OPT_CONNECT_TIMEOUT
From: skissane at gmail dot com Operating system: Irrelevant PHP version: 4.3.11 PHP Bug Type: LDAP related Bug description: PATCH: Support LDAP_X_OPT_CONNECT_TIMEOUT Description: I have written a patch to support LDAP_X_OPT_CONNECT_TIMEOUT (which is defined by the Netscape LDAP C SDK). This required also changing ldap_connect to call ldap_init instead of ldap_open (but only if LDAP_X_OPT_CONNECT_TIMEOUT is defined), which is necessary if LDAP_X_OPT_CONNECT_TIMEOUT is to do anything. In any case, ldap_open is deprecated, so PHP shouldn't be calling it unless necessary. Reproduce code: --- http://www.mq.edu.au/~skissane/ldap-nsldap-timeout.patch Expected result: N/A Actual result: -- N/A -- Edit bug report at http://bugs.php.net/?id=33850&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33850&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33850&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33850&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33850&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33850&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33850&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33850&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33850&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33850&r=support Expected behavior: http://bugs.php.net/fix.php?id=33850&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33850&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33850&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33850&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33850&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33850&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33850&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33850&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33850&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33850&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33850&r=mysqlcfg
