#46990 [NEW]: Passing UTF8 strings to filesystem functions produce wrong filenames
From: alex dot bazan at concatel dot com Operating system: Windows XP PHP version: 5.2.8 PHP Bug Type: *Directory/Filesystem functions Bug description: Passing UTF8 strings to filesystem functions produce wrong filenames Description: Under Windows, when I use fpoen() or mkdir() with a UTF8 encoded string, the file or directory name is not converted to the filesystem encoding and thus the file or directory is created with a wrong file name. Reproduce code: --- Expected result: Directory 日本語 should be created Actual result: -- Directory æ¥æ¬èª is created -- Edit bug report at http://bugs.php.net/?id=46990&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46990&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46990&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46990&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46990&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46990&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46990&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46990&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46990&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46990&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46990&r=support Expected behavior: http://bugs.php.net/fix.php?id=46990&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46990&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46990&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46990&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46990&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46990&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46990&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46990&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46990&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46990&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46990&r=mysqlcfg
#46990 [Opn]: Passing UTF8 strings to filesystem functions produce wrong filenames
ID: 46990 User updated by: alex dot bazan at concatel dot com Reported By: alex dot bazan at concatel dot com Status: Open Bug Type: *Directory/Filesystem functions Operating System: Windows XP PHP Version: 5.2.8 New Comment: The UTF string did not get saved correctly in the bug report. It was a japanese string. Previous Comments: [2009-01-02 08:03:37] alex dot bazan at concatel dot com Description: Under Windows, when I use fpoen() or mkdir() with a UTF8 encoded string, the file or directory name is not converted to the filesystem encoding and thus the file or directory is created with a wrong file name. Reproduce code: --- Expected result: Directory 日本語 should be created Actual result: -- Directory æ¥æ¬èª is created -- Edit this bug report at http://bugs.php.net/?id=46990&edit=1
#46937 [Opn->NoF]: Make getopt() usable with non-option arguments
ID: 46937 Updated by: d...@php.net Reported By: kristof dot coomans at telenet dot be -Status: Open +Status: No Feedback Bug Type: Feature/Change Request Operating System: Doesn't matter PHP Version: 5.3CVS-2008-12-24 (snap) New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2008-12-24 10:03:30] kristof dot coomans at telenet dot be Description: Now that PHP 5.3 will have getopt() available on all platforms, I think it's important to also make it as usable as possible. Currently, getopt() is not usable for command line scripts that have both option and non-option arguments, because it doesn't modify argv, as pointed out already in 2003 in this comment: http://www.php.net/getopt#34163. Stripping away the option arguments from argv when a call to getopt() is made would be a great improvement. User land code can handle the remaining non-option arguments from argv then. -- Edit this bug report at http://bugs.php.net/?id=46937&edit=1
#46937 [NoF->Bgs]: Make getopt() usable with non-option arguments
ID: 46937 Updated by: d...@php.net Reported By: kristof dot coomans at telenet dot be -Status: No Feedback +Status: Bogus Bug Type: Feature/Change Request Operating System: Doesn't matter PHP Version: 5.3CVS-2008-12-24 (snap) 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 Expected behavior. Previous Comments: [2009-01-02 12:54:58] d...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2008-12-24 10:03:30] kristof dot coomans at telenet dot be Description: Now that PHP 5.3 will have getopt() available on all platforms, I think it's important to also make it as usable as possible. Currently, getopt() is not usable for command line scripts that have both option and non-option arguments, because it doesn't modify argv, as pointed out already in 2003 in this comment: http://www.php.net/getopt#34163. Stripping away the option arguments from argv when a call to getopt() is made would be a great improvement. User land code can handle the remaining non-option arguments from argv then. -- Edit this bug report at http://bugs.php.net/?id=46937&edit=1
#46938 [Opn->Bgs]: Make getopt() report wrong options
ID: 46938 Updated by: d...@php.net Reported By: kristof dot coomans at telenet dot be -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.3CVS-2008-12-24 (snap) 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 Expected behavior. Previous Comments: [2008-12-24 10:13:45] kristof dot coomans at telenet dot be Description: Now that PHP 5.3 will have getopt() available on all platforms, I think it's important to also make it as usable as possible. Currently, getopt() does not report in any way if there were any wrong options provided on the command line. It would be nice to be able to give the end user feedback on non-existing options he/she provided, or about options he/she provided that require a value but for which no value was supplied. The ability to retrieve a list of option errors should be provided, either by: - throwing an exception or - a 3rd by-reference array argument to getopt() -- Edit this bug report at http://bugs.php.net/?id=46938&edit=1
#46937 [Bgs]: Make getopt() usable with non-option arguments
ID: 46937 User updated by: kristof dot coomans at telenet dot be Reported By: kristof dot coomans at telenet dot be Status: Bogus Bug Type: Feature/Change Request Operating System: Doesn't matter PHP Version: 5.3CVS-2008-12-24 (snap) New Comment: I didn't report this as a bug, but under the category "Feature/Change RequestFeature". I think this is a good enhancement and do not understand why it gets closed with a standard reply of "Please double-check the documentation". Previous Comments: [2009-01-02 12:56:16] d...@php.net 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 Expected behavior. [2009-01-02 12:54:58] d...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2008-12-24 10:03:30] kristof dot coomans at telenet dot be Description: Now that PHP 5.3 will have getopt() available on all platforms, I think it's important to also make it as usable as possible. Currently, getopt() is not usable for command line scripts that have both option and non-option arguments, because it doesn't modify argv, as pointed out already in 2003 in this comment: http://www.php.net/getopt#34163. Stripping away the option arguments from argv when a call to getopt() is made would be a great improvement. User land code can handle the remaining non-option arguments from argv then. -- Edit this bug report at http://bugs.php.net/?id=46937&edit=1
#46938 [Bgs]: Make getopt() report wrong options
ID: 46938 User updated by: kristof dot coomans at telenet dot be Reported By: kristof dot coomans at telenet dot be Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.3CVS-2008-12-24 (snap) New Comment: I didn't report this as a bug, but under the category "Feature/Change RequestFeature". I think this is a good enhancement and do not understand why it gets closed with a standard reply of "Please double-check the documentation". Previous Comments: [2009-01-02 13:03:06] d...@php.net 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 Expected behavior. [2008-12-24 10:13:45] kristof dot coomans at telenet dot be Description: Now that PHP 5.3 will have getopt() available on all platforms, I think it's important to also make it as usable as possible. Currently, getopt() does not report in any way if there were any wrong options provided on the command line. It would be nice to be able to give the end user feedback on non-existing options he/she provided, or about options he/she provided that require a value but for which no value was supplied. The ability to retrieve a list of option errors should be provided, either by: - throwing an exception or - a 3rd by-reference array argument to getopt() -- Edit this bug report at http://bugs.php.net/?id=46938&edit=1
#46954 [Bgs]: pg_prepare silently truncates query name
ID: 46954
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
Status: Bogus
Bug Type: PostgreSQL related
Operating System: Linux
PHP Version: 5.2.8
New Comment:
The maximum length of the name is NAMEDATALEN-1 - see
http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html . I
assume that constant is available in the postgresql include files.
Unless manually overwritten, NAMEDATALEN is 64. In the example above,
the name was also truncated to length 63.
Using NAMEDATALEN, it should be trivial to manually add the warning.
Previous Comments:
[2009-01-01 19:35:02] il...@php.net
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.
The truncation is done by Postgre and the PQPrepare() function does not
provide any indicators about truncation.
[2008-12-27 15:17:26] thuejk at gmail dot com
Description:
When using pg_prepare(string $stmtname, string $query) with a very long
$stmtname, the $stmtname will be silently truncated. It would be nice if
PHP emitted an E_NOTICE, as postgresql itself does:
psql=> PREPARE
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
as SELECT NOW();
NOTICE: identifier
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
will be truncated to
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk"
PREPARE
Note that it is a sane idea to try to use the query itself as $stmtname
(less bookkeeping), which naturally leads to trying large $stmtname's.
Reproduce code:
---
pg_connect(...);
pg_prepare("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
1", "SELECT 1");
pg_prepare("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
2", "SELECT 2");
Expected result:
An E_NOTICE because the name was truncated.
Actual result:
--
No E_NOTICE.
pg_prepare() [function.pg-prepare]: Query failed: ERROR: prepared
statement
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
2" already exists
--
Edit this bug report at http://bugs.php.net/?id=46954&edit=1
#46954 [Bgs]: pg_prepare silently truncates query name
ID: 46954
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
Status: Bogus
Bug Type: PostgreSQL related
Operating System: Linux
PHP Version: 5.2.8
New Comment:
Hmm, which of course will not work since the database we are actually
connecting to may have a different length compiled in. But perhaps there
is a way to ask the database what its NAMEDATALEN is. (though I can't
find it just now)
Previous Comments:
[2009-01-02 14:37:06] thuejk at gmail dot com
The maximum length of the name is NAMEDATALEN-1 - see
http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html . I
assume that constant is available in the postgresql include files.
Unless manually overwritten, NAMEDATALEN is 64. In the example above,
the name was also truncated to length 63.
Using NAMEDATALEN, it should be trivial to manually add the warning.
[2009-01-01 19:35:02] il...@php.net
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.
The truncation is done by Postgre and the PQPrepare() function does not
provide any indicators about truncation.
[2008-12-27 15:17:26] thuejk at gmail dot com
Description:
When using pg_prepare(string $stmtname, string $query) with a very long
$stmtname, the $stmtname will be silently truncated. It would be nice if
PHP emitted an E_NOTICE, as postgresql itself does:
psql=> PREPARE
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
as SELECT NOW();
NOTICE: identifier
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
will be truncated to
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk"
PREPARE
Note that it is a sane idea to try to use the query itself as $stmtname
(less bookkeeping), which naturally leads to trying large $stmtname's.
Reproduce code:
---
pg_connect(...);
pg_prepare("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
1", "SELECT 1");
pg_prepare("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
2", "SELECT 2");
Expected result:
An E_NOTICE because the name was truncated.
Actual result:
--
No E_NOTICE.
pg_prepare() [function.pg-prepare]: Query failed: ERROR: prepared
statement
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
2" already exists
--
Edit this bug report at http://bugs.php.net/?id=46954&edit=1
#46444 [Com]: invalid session.save_path crashes
ID: 46444
Comment by: crrodriguez at opensuse dot org
Reported By: hostmaster at uuism dot net
Status: Open
Bug Type: Session related
Operating System: Fedora Core 4
PHP Version: 5.2CVS-2008-11-02
New Comment:
Same here
Program received signal SIGSEGV, Segmentation fault.
0x75d56560 in strlen () from /lib64/libc.so.6
(gdb) bt full
#0 0x75d56560 in strlen () from /lib64/libc.so.6
No symbol table info available.
#1 0x005a06d8 in ps_open_files (mod_data=0xddd960,
save_path=0x7b , session_name=0xaaa37a
"PHPSESSID")
at /home/cristian/php5/ext/session/mod_files.c:325
data = (ps_files *) 0xfdfaf0
p = 0xdeff7a ";213"
last = 0xdeff74 ",23123;213"
argv = {0xdeff50
"123;:/really\\completely:::/invalid;;,23123;213", 0xdeff54
":/really\\completely:::/invalid;;,23123;213",
0xdeff73 ";,23123;213"}
argc = 4
dirdepth = 123
filemode = 0
#2 0x00599118 in php_session_initialize () at
/home/cristian/php5/ext/session/session.c:512
val = 0xfde576 "L)\r�\r�\r�"
vallen = 0
#3 0x0059d732 in php_session_start () at
/home/cristian/php5/ext/session/session.c:1479
ppid = (zval **) 0xfdc678
data = (zval **) 0x78
p = 0x887fd0 "H\211l$�L\211|$�H\215-�}M"
value = 0x0
nrand = 32767
lensess = 9
#4 0x0059ed3d in zif_session_start (ht=0,
return_value=0xfdc6c8, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=0)
at /home/cristian/php5/ext/session/session.c:1886
No locals.
#5 0x00818899 in zend_do_fcall_common_helper_SPEC
(execute_data=0x77e6f090) at
/home/cristian/php5/Zend/zend_vm_execute.h:313
opline = (zend_op *) 0xfddff0
should_change_scope = 0 '\0'
#6 0x0081df90 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x77e6f090) at
/home/cristian/php5/Zend/zend_vm_execute.h:1564
opline = (zend_op *) 0xfddff0
fname = (zval *) 0xfde020
#7 0x00817987 in execute (op_array=0xfdd418) at
/home/cristian/php5/Zend/zend_vm_execute.h:104
ret = 0
execute_data = (zend_execute_data *) 0x77e6f090
nested = 1 '\001'
original_in_execution = 0 '\0'
#8 0x007e77e9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/cristian/php5/Zend/zend.c:1181
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fffb7e0, reg_save_area = 0x7fffb720}}
i = 1
file_handle = (zend_file_handle *) 0x7fffdc60
orig_op_array = (zend_op_array *) 0x0
orig_retval_ptr_ptr = (zval **) 0x0
#9 0x0076a1d9 in php_execute_script
(primary_file=0x7fffdc60) at /home/cristian/php5/main/main.c:2101
realfile =
"/home/cristian/php5/ext/session/tests/016.phpt\000\000�\177\000\000�\n|\000\000\000\000\000�r���\177\000\000p~�",
'\0' ,
"uct\000�\a\000\000X\000\000\000\000\000�p���\177\000\000\020\177\000\000z\005\177\000\000\000\000\000\002\000\000\000�\177\000\000X\000\000\000\000\000V\a\000\000\000\000\000\000\202\005\000\000\000\000\000\000�mQ��\177\000\000\210��\000\000\000\00---Type
to continue, or q to quit---
0\000P\177\000\000\030\177\000\000�\214\222D\000\000\000\000\000��"...
__orig_bailout = (jmp_buf *) 0x7fffdaf0
__bailout = {{__jmpbuf = {8945616, 1504162217199220120,
4369584, 140737488346800, 0, 0, 1504162220334462360,
-1504162127358118504}, __mask_was_saved = 0, __saved_mask =
{__val = {140737353931176, 0, 4294967295, 47784, 14397440, 4369584,
140737488346800, 0, 0, 0, 140737351963577, 1, 0, 0,
7301032, 140737317299080
prepend_file_p = (zend_file_handle *) 0x0
append_file_p = (zend_file_handle *) 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0,
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {
handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0,
buf = 0x0, old_handle = 0x0, old_closer = 0}, reader = 0, fsizer = 0,
closer = 0}}, free_filename = 0 '\0'}
append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0,
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0,
isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0,
old_handle = 0x0, old_closer = 0}, reader = 0, fsizer = 0, closer =
0}},
free_filename = 0 '\0'}
old_cwd = 0x7fffb800 ""
use_heap = 0 '\0'
retval = 0
#10 0x00887449 in main (argc=5, argv=0x7fffdeb8) at
/home/cristian/php5/sapi/cli/php_cli.c:1138
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {8945616, 1504162217448781208,
4369584, 140737488346800, 0, 0, 1504162217209705880,
-1504161051082934888}, __mask_was_saved = 0, __saved_mask =
{__val = {140737353925464, 140737488346240, 140737488346184,
2972705047,
140737488346400, 61765110, 140737354121608, 0, 140737351945772,
140733193388033, 14073735
#46993 [NEW]: strtotime inconsistently parses M-j-Y and Y-M-j format dates
From: anomie at users dot sourceforge dot net
Operating system: Linux
PHP version: 5.3CVS-2009-01-02 (snap)
PHP Bug Type: Date/time related
Bug description: strtotime inconsistently parses M-j-Y and Y-M-j format dates
Description:
M-j-Y format dates are parsed correctly if the day is 10-31, but as M-j-Hi
if the day is 1-9. Or, you could say that M-j-Hi format dates are parsed
correctly if the day is 1-9, but incorrectly if the day is 10-31.
Y-M-j format dates are parsed correctly if the day is 10-31, but as Y-M in
the timezone UTC-j if the day is 1-9. Or, you could say that this odd
method of specifying the time zone fails for UTC-10, UTC-11, and so on.
Both M-d-Y and Y-M-d formats are parsed correctly for all days.
I would find it more consistent if the M-j-Y and Y-M-j formats were
recognized for all days, as the other option would conflict with M-d-Y and
Y-M-d recognition and both "M-j-Hi" and "Y-M"-with-timezone seem to be
unlikely input formats.
This bug is also present in PHP 5.2.6.
Reproduce code:
---
date_default_timezone_set("UTC");
echo date("Y-m-d H:i:s\n", strtotime("Dec-9-2006"));
echo date("Y-m-d H:i:s\n", strtotime("9-Dec-2006"));
echo date("Y-m-d H:i:s\n", strtotime("2006-Dec-9"));
echo date("Y-m-d H:i:s\n", strtotime("Dec-10-2006"));
echo date("Y-m-d H:i:s\n", strtotime("10-Dec-2006"));
echo date("Y-m-d H:i:s\n", strtotime("2006-Dec-10"));
Expected result:
2006-12-09 00:00:00
2006-12-09 00:00:00
2006-12-09 00:00:00
2006-12-10 00:00:00
2006-12-10 00:00:00
2006-12-10 00:00:00
Actual result:
--
2009-12-09 20:06:00
2006-12-09 00:00:00
2006-12-01 09:00:00
2006-12-10 00:00:00
2006-12-10 00:00:00
2006-12-10 00:00:00
--
Edit bug report at http://bugs.php.net/?id=46993&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46993&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46993&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46993&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46993&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46993&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46993&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46993&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46993&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46993&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46993&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46993&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46993&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46993&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46993&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46993&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46993&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46993&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46993&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46993&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46993&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46993&r=mysqlcfg
#46994 [NEW]: CLOB size does not update when using CLOB IN OUT param in stored procedure
From: n dot bier at icarnegie dot com
Operating system: CentOS 5
PHP version: 5.2.8
PHP Bug Type: OCI8 related
Bug description: CLOB size does not update when using CLOB IN OUT param in
stored procedure
Description:
When using stored procedures, a variable bound to an IN OUT CLOB param
does not have its size updated appropriately after execution. The value of
the variable is updated correctly, but only to the length of the initial
variable value. For example, we allocate a CLOB descriptor and initialize
to 10 characters (in this case, 0 - 9), then bind and execute. The stored
procedure clears the CLOB, then inserts new text into the clob that is
longer (for our example below, the 26 characters of the alphabet).
Although the php variable is reflecting the change in the CLOB contents (it
changes from 0-9 to a-j), it is not reflecting the change in size (since it
should be a-z).
This seems to be a caching problem; php_oci_lob_get_length() in
oci8_lob.c caches the length, and the cache value isn't updated after
calling the stored procedure.
This can be worked around by modifying php_oci_lob_get_length() to force
execution to fetch the LOB's length by avoiding using the number stored in
the descriptor (a one line change, see comment):
/* {{{ php_oci_lob_get_length()
Get length of the LOB. The length is cached so we don't need to ask Oracle
every time */
int php_oci_lob_get_length (php_oci_descriptor *descriptor, ub4 *length
TSRMLS_DC)
{
php_oci_connection *connection = descriptor->connection;
*length = 0;
/*CHANGED HERE*/ if (0 && descriptor->lob_size >= 0) {
*length = descriptor->lob_size;
return 0;
} else {
...
Note that this fix may be necessary but might not be sufficient, in that
the implementor was trying to be efficient by "caching" the value. The
uses of php_oci_lob_get_length() should be reviewed, as some may still be
able to use the cached value.
Reproduce code:
---
PHP code is below; source for stored procedure at:
http://henry.icarnegie.com/~nbier/testpackage.sql
writeTemporary("0123456789", OCI_TEMP_CLOB);
oci_bind_by_name($stmt, ":inout_clob", $clobVar, -1, SQLT_CLOB);
$success = oci_execute($stmt, OCI_DEFAULT);
if ($success === false) {
echo "Execute failed: " . oci_error($stmt) . "\n";
oci_free_statement($stmt);
exit;
}
echo "\$resultVar is now: " . $resultVar . "|EOL\n";
echo "\$outTextVar is now: " . $outTextVar . "|EOL\n";
$clobVar->rewind();
echo "\$clobVar is now: " . $clobVar->size() . ": " . $clobVar->load()
. "|EOL\n";
echo "\n\n";
oci_free_statement($stmt);
oci_close($db);
?>
Expected result:
PROMPT> php testclobstoredprocedure.php
$resultVar is now: Text input to stored procedure|EOL
$outTextVar is now: 10: 0123456789 CLOB then becomes:
abcdefghijklmnopqrstuvwxyZ|EOL
$clobVar is now: 26: abcdefghijklmnopqrstuvwxyZ|EOL
Actual result:
--
PROMPT> php testclobstoredprocedure.php
$resultVar is now: Text input to stored procedure|EOL
$outTextVar is now: 10: 0123456789 CLOB then becomes:
abcdefghijklmnopqrstuvwxyZ|EOL
$clobVar is now: 10: abcdefghij|EOL
--
Edit bug report at http://bugs.php.net/?id=46994&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46994&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46994&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46994&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46994&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46994&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46994&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46994&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46994&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46994&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46994&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46994&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46994&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46994&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46994&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46994&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46994&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46994&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46994&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46994&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46994&r=nozend
MySQL Configuration Error:
#38457 [Com]: php5ts crash
ID: 38457 Comment by: richard at silcon dot com Reported By: sima at igldesign dot cz Status: No Feedback Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.1.4 New Comment: Same problem. phpBB3 failed install on winXPnt, sp3, noexecute=alwaysoff, All.htaccess removed from phpbb3 folders. No server errors noted. 'httpd.exe': Loaded 'C:\Program Files\PHP\ext\php_mysqli.dll' 'httpd.exe': Loaded 'C:\Program Files\MySQL\MySQL Server 5.1\bin\libmySQL.dll' 'httpd.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll' 'httpd.exe': Loaded 'C:\WINDOWS\system32\dnsapi.dll' 'httpd.exe': Loaded 'C:\WINDOWS\system32\winrnr.dll' 'httpd.exe': Loaded 'C:\WINDOWS\system32\wldap32.dll' 'httpd.exe': Loaded 'C:\WINDOWS\system32\pnrpnsp.dll' 'httpd.exe': Loaded 'C:\WINDOWS\system32\rasadhlp.dll' The thread 'Win32 Thread' (0x548) has exited with code 0 (0x0). Unhandled exception at 0x00d62beb in httpd.exe: 0xC005: Access violation reading location 0x. php5ts.dll!0082bfd0() libhttpd.dll!6ff020e1() libhttpd.dll!6ff0246e() libhttpd.dll!6ff0e90e() libhttpd.dll!6ff0a87c() libhttpd.dll!6ff04d21() libhttpd.dll!6ff04fd3() libhttpd.dll!6ff1d2dc() msvcrt.dll!77c3a3b0() kernel32.dll!7c80b713() [Fri Jan 02 13:35:19 2009] [notice] Parent: child process exited with status 0 -- Restarting. [Fri Jan 02 13:35:23 2009] [notice] Apache/2.2.9 (Win32) PHP/5.2.6 configured -- resuming normal operations [Fri Jan 02 13:35:23 2009] [notice] Server built: Jun 13 2008 04:04:59 [Fri Jan 02 13:35:23 2009] [notice] Parent: Created child process 3612 [Fri Jan 02 13:35:23 2009] [notice] Child 3612: Child process is running [Fri Jan 02 13:35:23 2009] [notice] Child 3612: Acquired the start mutex. [Fri Jan 02 13:35:23 2009] [notice] Child 3612: Starting 64 worker threads. [Fri Jan 02 13:35:23 2009] [notice] Child 3612: Starting thread to listen on port 80. Previous Comments: [2008-09-21 01:00:00] 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". [2008-09-13 12:04:05] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-09-13 11:58:53] alexandermonk1 at googlemail dot com yeah i have that problem to, i have Win XP SP3, Apache 2.2, My SQL 5.0 (and have tried 6.0), and trying to install PHPBB3 but when i submit the Database settings Apache just hangs then crashes [2008-02-21 07:45:27] boak_edogawa at yahoo dot com It happen to me right now, php5ts.dll crashed and apache encountered a problem when I install phpbb3 in my windows home sp2. any help and solution for me will be very great appreciated thanks [2006-12-29 23:37:15] tool_junky187 at hotmail dot com I get this same error, and it happens whenever I try to access a .php file on my webserver. Apache just kind of hangs, then comes up with this error message: Apache HTTP Server has encountered a problem and needs to close. We are sorry for the inconvenience. Error Signature: szAppName : httpd.exe szAppVer : 2.2.3.0 szModName : php5ts.dll szModVer : 5.2.1.1 offset : 00098555 Here is what the appcompat.txt reads: http://www.ActiveState.com"; VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xCE392" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="5.8.7.813" UPTO_BIN_PRODUCT_VERSION="5.8.7.813" LINK_DATE="06/19/2005 01:44:15" UPTO_LINK_DATE="06/19/2005 01:44:15" VER_LANGUAGE="English (United States) [0x409]" /> I hope this is enough info. 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/38457 -- Edit this b
#46917 [Opn->Fbk]: Socket handling completely broken
ID: 46917
Updated by: fel...@php.net
Reported By: jost_boekemeier at users dot sf dot net
-Status: Open
+Status: Feedback
Bug Type: Streams related
Operating System: *
PHP Version: 5.2.8
New Comment:
Hi, I've commited a probable fix, I initialized the errno.
http://news.php.net/php.cvs/55296
Can you test it with a cvs version again?
Previous Comments:
[2008-12-26 17:28:10] jost_boekemeier at users dot sf dot net
Due to its nature (uninitialized variable) you may or may not be able
to reproduce this bug. See
http://sourceforge.net/mailarchive/forum.php?thread_name=828E3F73B78941EAB5AF3E2E07C37D8D%40IBM1020C944423&forum_name=php-java-bridge-users
for details.
However, you should immediately see the bug by looking at the PHP
source code:
0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK
does NOT set errno (the result code is 0, not -1) so that errno
contains a bogus value, most likely the error code from a previously
failed sys call, so that
php_socket_errno() != EAGAIN
fails, depending on the application's PHP code, as errno sometimes
contains EAGAIN (from a previous poll()).
Just search the PHP sources for the pattern
} else if (php_pollfd_for(sock->socket, PHP_POLLREADABLE|POLLPRI, &tv)
>
0) {
if (0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK) &&
php_socket_errno() != EAGAIN) {
alive = 0;
}
and set the errno or the lastErrorCode (for windows) to zero before
calling this pattern.
After that persistent sockets, soap and a few other places will work
reliably.
There are a few caveats, however. First, if you pass the last error
number to application-level, you might have to restore the last errno
immediately after the recv call. Second, I don't know what the
php_socket_errno() != EAGAIN should do, anyway, as EAGAIN is only set
when the previous sys call failed (result code -1, not 0!). So I suggest
to ask the author to explain his/her code before fixing anything.
Regards,
Jost Bökemeier
[2008-12-24 19:48:34] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2008-12-21 16:07:15] jost_boekemeier at users dot sf dot net
The relevant part of the bug trace was missing.
poll([{fd=16, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1
([{fd=16, revents=POLLIN}])
recv(16, ""..., 1, MSG_PEEK)= 0
send(16, "PUT /JavaBridge/JavaBridge.phpjavabridge HTTP/1.1\r\nHost:
localhost\r\nContent-Length: 40\r\nX_JAVABRIDGE_CHANNEL:
/dev/shm/.php_java_bridgexN2WsO\r\n\r\n\177C"..., 185, 0) = 185
poll([{fd=16, events=POLLIN|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=16,
revents=POLLIN|POLLERR|POLLHUP}])
recv(16, ""..., 8192, 0)= 0
[2008-12-21 16:03:05] jost_boekemeier at users dot sf dot net
Description:
PHP cannot handle broken socket connections due to an uninitialized
variable.
xp_socket.c and several other places contain the following pattern:
...
} else if (php_pollfd_for(sock->socket, PHP_POLLREADABLE|POLLPRI, &tv)
> 0) {
if (0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK) &&
php_socket_errno() != EAGAIN) {
alive = 0;
}
...
It is obvious that the above code cannot work on any operating system;
checking if the socket doesn't have an error and then asking for its
error code is simply nonsense.
The same pattern is used in several other places within PHP.
The above code fails constantly on Windows. On Linux/Unix a workaround
is to add the constant 1E512 to the PHP script, which initializes errno
with a value != EAGAIN.
Regards,
Jost Bökemeier
Reproduce code:
---
pfsockopen()
...
// restart back end
...
pfsockopen()
=>
Expected result:
...
poll([{fd=16, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1
([{fd=16, revents=POLLIN}])
recv(16, ""..., 1, MSG_PEEK)= 0
close(16)
...
Actual result:
--
...
poll([{fd=16, events=POLLIN|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=16,
revents=POLLIN|POLLERR|POLLHUP}])
recv(16, ""..., 8192, 0)= 0
gettimeofday({1229844164, 46391}, NULL) = 0
write(2, "[Sun Dec 21 08:22:44 2008] [error] [client 127.0.0.1] PHP
Notice: Undefined index: content_length in
...
-
#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Comment by: geoffers+phpbugs at gmail dot com Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: What is the recommended advice for PHP software that relies upon the XML extension? It'd be easier to say that libxml2.7.02.7.2 wasn't supported if it weren't for the fact that I've had at least one user come who had LIBXML_VERSION equal to 20632 with this issue we can't just add a LIBXML_VERSION based workaround, not just because the constant doesn't exist on 4.3.0, but also because it is seemingly isn't reliable. Previous Comments: [2009-01-01 20:09:07] phpbugs at colin dot guthr dot ie If the Fedora packages do not work then this is a RedHat packaging problem and you should complain to them/open a bug etc. etc. Like I say, in Mandriva we made sure we provided packages that worked because they were compiled with expat. [2009-01-01 19:31:49] alex at peoples dot ru Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel on my server. I tried use 'yum remove' libxml2 and add new, but off course this is stupid and doesn't work. I liked Linux, as the easiest and powerful system, but now, I'm stock. I haven't any idea how I can remove libxml2 and build new system with old one. One idea - change system on Fedora 9, because FC 10 have the same bug with fucking libxml2. Sorry, I was at Data Center 8 hours and I had problem with servers with new system. I don't like updates now... they have bugs every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New Year. I'll never ever will update my systems less when half year. [2008-12-31 15:22:17] scott...@php.net Guys please READ the report, this is a bug in libxml NOT a bug in PHP. [2008-12-31 14:35:13] hougiwro at guerrillamail dot org Why not just fix the bug so that existing installs can pick up a standard update without having to rebuild the program. Not everyone using PHP is necessarily comfortable with recompiling it in order to implement a workaround for a bug. [2008-12-31 13:37:17] phpbugs at colin dot guthr dot ie If you are on a shared host with a fixed PHP version then really the host should be responsible for deploying a well packaged version of PHP. If they are not doing that it is the host that is at fault and you should raise the issue with them. 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/45996 -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
#46995 [NEW]: gmdate("l") returns "Saturday" (correct) but gmdate("w")=6 (Sunday, incorrect)
From: DePhille at gmail dot com
Operating system: Linux CentOS
PHP version: 5.2.8
PHP Bug Type: Date/time related
Bug description: gmdate("l") returns "Saturday" (correct) but gmdate("w")=6
(Sunday, incorrect)
Description:
The gmdate("w") function returns a wrong value.
Reproduce code:
---
Expected result:
the gmdate("w") function returns an incorrect value.
--
Edit bug report at http://bugs.php.net/?id=46995&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46995&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46995&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46995&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46995&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46995&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46995&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46995&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46995&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46995&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46995&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46995&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46995&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46995&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46995&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46995&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46995&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46995&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46995&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46995&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46995&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46995&r=mysqlcfg
#46634 [Opn->Bgs]: Array key differentiates between unicode and binary strings
ID: 46634 Updated by: fel...@php.net Reported By: mike at mikegerwitz dot com -Status: Open +Status: Bogus Bug Type: *Unicode Issues Operating System: GNU/Linux PHP Version: 6CVS-2008-11-20 (snap) New Comment: Nowadays unicode semantics is always enabled. Previous Comments: [2008-11-20 19:04:04] mike at mikegerwitz dot com Description: Array keys in PHP 6 differentiate between unicode and binary strings - that is, a unicode key of 'test' is entirely different than a binary key of 'test'. Reproduce code: --- $arr = array(); $arr[ (unicode)'test' ] = 'unicode'; $arr[ (binary)'test' ] = 'binary'; // If unicode semantics is enabled, this will output 'unicode' var_dump( $arr['test'] ); // Will output 'binary' var_dump( $arr[ b'test'] ); // Will output 'unicode' var_dump( $arr[ (unicode)'test' ] ); Expected result: All three lines should output 'binary' unicode(7) "binary" unicode(6) "binary" unicode(7) "binary" Actual result: -- unicode(7) "unicode" unicode(6) "binary" unicode(7) "unicode" -- Edit this bug report at http://bugs.php.net/?id=46634&edit=1
#46995 [Opn->Bgs]: gmdate("l") returns "Saturday" (correct) but gmdate("w")=6 (Sunday, incorrect)
ID: 46995
Updated by: scott...@php.net
Reported By: DePhille at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux CentOS
PHP Version: 5.2.8
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. 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.
>From the manual page:
Numeric representation of the day of the week
0 (for Sunday) through 6 (for Saturday)
Previous Comments:
[2009-01-03 01:08:24] DePhille at gmail dot com
Description:
The gmdate("w") function returns a wrong value.
Reproduce code:
---
Expected result:
the gmdate("w") function returns an incorrect value.
--
Edit this bug report at http://bugs.php.net/?id=46995&edit=1
#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Comment by: david+phpbugs at midrange dot com Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: Ok, I'm going to try and rebuild the Fedora 8 source RPM to avoid the libxml2 bug ... but I'm not all that familiar with how PHP is built ... and could use a pointer or two on what to change on the configure command line. Any suggestions? Previous Comments: [2009-01-02 23:03:29] geoffers+phpbugs at gmail dot com What is the recommended advice for PHP software that relies upon the XML extension? It'd be easier to say that libxml2.7.02.7.2 wasn't supported if it weren't for the fact that I've had at least one user come who had LIBXML_VERSION equal to 20632 with this issue we can't just add a LIBXML_VERSION based workaround, not just because the constant doesn't exist on 4.3.0, but also because it is seemingly isn't reliable. [2009-01-01 20:09:07] phpbugs at colin dot guthr dot ie If the Fedora packages do not work then this is a RedHat packaging problem and you should complain to them/open a bug etc. etc. Like I say, in Mandriva we made sure we provided packages that worked because they were compiled with expat. [2009-01-01 19:31:49] alex at peoples dot ru Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel on my server. I tried use 'yum remove' libxml2 and add new, but off course this is stupid and doesn't work. I liked Linux, as the easiest and powerful system, but now, I'm stock. I haven't any idea how I can remove libxml2 and build new system with old one. One idea - change system on Fedora 9, because FC 10 have the same bug with fucking libxml2. Sorry, I was at Data Center 8 hours and I had problem with servers with new system. I don't like updates now... they have bugs every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New Year. I'll never ever will update my systems less when half year. [2008-12-31 15:22:17] scott...@php.net Guys please READ the report, this is a bug in libxml NOT a bug in PHP. [2008-12-31 14:35:13] hougiwro at guerrillamail dot org Why not just fix the bug so that existing installs can pick up a standard update without having to rebuild the program. Not everyone using PHP is necessarily comfortable with recompiling it in order to implement a workaround for a bug. 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/45996 -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
#46996 [NEW]: system() function show error unable to fork
From: hardik at promactinfo dot co dot in
Operating system: windows server 2000
PHP version: 5.2.8
PHP Bug Type: *General Issues
Bug description: system() function show error unable to fork
Description:
system("cd D:\\projects\\youngComposers\\web\\forum", $result1);
//system("d:",$result2);
system("c:\\php\\php.exe
D:\\projects\\youngComposers\\web\\forum\\vbregister.php add 0 test432
123123 hards_...@yahoo.com 1983 12 23 1 grpgrp 1 1 1 1 5", $result);
after putting these code in my current application it shows the error
"Warning: system() [function.system]: Unable to fork [cd
D:\projects\youngComposers\web\forum]" but when i put it in independent
page so it's not give me error so please give me proper solution on this.
--
Edit bug report at http://bugs.php.net/?id=46996&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46996&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46996&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46996&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46996&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46996&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46996&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46996&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46996&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46996&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46996&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46996&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46996&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46996&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46996&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46996&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46996&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46996&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46996&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46996&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46996&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46996&r=mysqlcfg
#46701 [Opn]: Creating associative array with long values in the key fails on 32bit linux
ID: 46701 Updated by: sh...@php.net Reported By: testuzer at hotmail dot com Status: Open Bug Type: Arrays related Operating System: Linux 32bit - ubuntu PHP Version: 5CVS, 6CVS (2008-11-28) New Comment: Proposed patches to make $array[$double] perform the same as $array[intval($double)]... http://tekrat.com/patches/bug46701.php6.patch http://tekrat.com/patches/bug46701.php53.patch http://tekrat.com/patches/bug46701.php52.patch Previous Comments: [2008-12-04 01:43:46] msara...@php.net Array ( [-2147483648] => 1 ) Reproduced here. [2008-12-01 01:49:09] cyberquoter at gmail dot com OS: Debian Linux 2.6.18-6-686 (32bit) PHP: 5.2.0-8+etch13 Result: Array ( [-2147483648] => 1 ) [2008-11-29 06:56:11] testuzer at hotmail dot com Can also confirm Linux -ubuntu 64bit works. Actual result Linux 64bit (php 5.2.4): -- Array ( [3428599296] => 1 [3459455488] => 1 [3459616768] => 1 ) Obviously the 32bit os treats it as a signed 32bit value and a 64bit os as a 64bit value. so you get a positive value. The array key handling is _only_ broken on linux 32bit. [2008-11-29 06:18:33] testuzer at hotmail dot com Here is a simple test: Reproduce code: --- echo 0xcc5c4600; var_dump( 0xcc5c4600 ); print_r( 0xcc5c4600 ); For both Windows and Linux - ubuntu the result is the same. Actual result Windows 32bit: -- 3428599296 float(3428599296) 3428599296 Actual result Linux 32bit: -- 3428599296 float 3428599296 3428599296 So it is not a hex to long conversion problem. Running the same array test using decimals and same values. Reproduce code: --- $test_array = array( 3428599296 => 1, 3459455488 => 1, 3459616768 => 1 ); print_r( $test_array ); Actual result Windows 32bit: -- Array ( [-866368000] => 1 [-835511808] => 1 [-835350528] => 1 ) Actual result Linux 32bit: -- Array ( [-2147483648] => 1 ) [2008-11-28 20:10:29] matt...@php.net Is this really only happening with array indexes...? Either way, the bug title isn't accurate. If it's only with array indexes, it shouldn't be hexadecimal-related, but would be coming from the simple (long) cast of any double value (from "long values in the key") in zend_hash_*, resulting in "undefined behavior." But, are those values even correct before the array part gets processed? e.g. does var_dump(0xcc5c4600) give 3428599296? If not, then it's obviously not array-specific. :-) Hmm, I was just going to say, see Bug #45068 for the possible cause (and http://news.php.net/php.internals/40199), but I just noticed that you marked that Bogus Jani? Cross-compiling isn't supported? Well, I guess you're not doing that then when reproducing this... How about you, bug reporter? 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/46701 -- Edit this bug report at http://bugs.php.net/?id=46701&edit=1
