#20542 [Fbk->NoF]: 0+0=4G on aix4.3 (64bits)
ID: 20542
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Math related
Operating System: aix 4.3.3.0
PHP Version: 4.2.3
New Comment:
No feedback was provided for this bug for over 2 weeks, 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".
Previous Comments:
[2002-11-27 18:54:59] [EMAIL PROTECTED]
Could this be an issue with the C library used on AIX? On a 64 bit
platform (64sparc) I cannot replicate the problem using PHP 4.2.3.
[2002-11-22 02:47:23] [EMAIL PROTECTED]
I am sorry but on this specific platform
does result in 4294967294, really!
And as well.
[2002-11-21 17:25:14] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
string cancatination is done using . not , in PHP.
Results in 0 on any platform.
[2002-11-21 05:45:55] [EMAIL PROTECTED]
Script:
Output of script on php 4.2.3:
0+0=4294967294
which is equal to 2^32-2
(Output of script on php 4.1.2 and 4.0.6:
0+0=4294967296
which is equal to 2^32).
In general, all simple additions and multiplications produce huge
numbers:
0+0=4294967294
0+1=4294967295
1+0=4294967295
1+1=4294967296
0-0=0
0-1=-1
1-0=1
1-1=0
0*0=3.5178585246345E+18
0*1=3.5178585265101E+18
1*0=3.5178585265101E+18
1*1=3.5178585283857E+18
0/1=0
1/1=1
2/1=2
2/2=1
Installation issues
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/rs6000-ibm-aix4.3.3.0/2.95.3/specs
gcc version 2.95.3 20010315 (release)
# make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for rs6000-ibm-aix4.3.3.0
# tar -xf apache_1.3.20.tar
# cd apache_1.3.20
# ./configure --enable-module=most
# cd ..
# tar -xf php-4.2.3.tar
# cd php-4.2.3
# ./configure --without-mysql --with-apache=../apache_1.3.20
--enable-static --with-iodbc=/usr/local --enable-track-vars
# make
# make install
# cd ..
# cd apache_1.3.20
# configure --enable-module=most
--activate-module=src/modules/php4/libphp4.a
# make
# make install
I don't know if it is very relevant but the rs6000 on which aix4.3 is
running
is a 64bits machine. The c program
int main()
{
printf("long=%dbits\n",8*sizeof(long));
return 0;
}
outputs 'long=64bits' when compiled with 'cc -q64', while when
compiled
with 'gcc' it outputs 'long=32bits'.
Thanks very much in advance,
Rein van Vliet
--
Edit this bug report at http://bugs.php.net/?id=20542&edit=1
#20982 [Com]: sort doesn't sort
ID: 20982
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4.2.2
New Comment:
I also tried other various sort functions and they all failed to sort:
# cat sort.php
"lemon", "a"=>"orange", "b"=>"banana",
"c"=>"apple");
asort ($fruits);
reset ($fruits);
while (list ($key, $val) = each ($fruits)) {
echo "$key = $val\n";
}
// ksort() demo
echo "\n";
$fruits = array ("d"=>"lemon", "a"=>"orange", "b"=>"banana",
"c"=>"apple");
ksort ($fruits);
reset ($fruits);
while (list ($key, $val) = each ($fruits)) {
echo "$key = $val\n";
}
// usort() demo
echo "\n";
$fruits = array();
function cmp ($a, $b) {
return strcmp($a["fruit"], $b["fruit"]);
}
$fruits[0]["fruit"] = "lemons";
$fruits[1]["fruit"] = "apples";
$fruits[2]["fruit"] = "grapes";
usort($fruits, "cmp");
while (list ($key, $value) = each ($fruits)) {
echo "\$fruits[$key]: " . $value["fruit"] . "\n";
}
?>
# php -q sort.php
fruits[0] = lemon
fruits[1] = orange
fruits[2] = banana
fruits[3] = apple
d = lemon
a = orange
b = banana
c = apple
d = lemon
a = orange
b = banana
c = apple
$fruits[0]: lemons
$fruits[1]: apples
$fruits[2]: grapes
#
Previous Comments:
[2002-12-13 00:09:11] [EMAIL PROTECTED]
# cat sort.php
# php -v
4.2.2
# php -q sort.php
fruits[0] = lemon
fruits[1] = orange
fruits[2] = banana
fruits[3] = apple
#
--
Edit this bug report at http://bugs.php.net/?id=20982&edit=1
#20982 [NEW]: sort doesn't sort
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4.2.2 PHP Bug Type: Arrays related Bug description: sort doesn't sort # cat sort.php # php -v 4.2.2 # php -q sort.php fruits[0] = lemon fruits[1] = orange fruits[2] = banana fruits[3] = apple # -- Edit bug report at http://bugs.php.net/?id=20982&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20982&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20982&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20982&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20982&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20982&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20982&r=support Expected behavior: http://bugs.php.net/fix.php?id=20982&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20982&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20982&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20982&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20982&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20982&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20982&r=isapi
#20981 [NEW]: --with-db3=shared,dir not working
From: [EMAIL PROTECTED] Operating system: solaris 9 PHP version: 4.2.3 PHP Bug Type: *Configuration Issues Bug description: --with-db3=shared,dir not working The configure script is not taking --with-db3=shared,dir. It works fine if I take out the "shared" or if I modify the configure script and add the DB3 directory to line 16771: for i in /usr/local /usr /usr/local/BerkeleyDB.3.0 $withval; do In my specifc case, DB3 is installed at /usr/local/BerkeleyDB, so I the line above is: for i in /usr/local /usr /usr/local/BerkeleyDB.3.0 /usr/local/BerkeleyDB $withval; do But for sure you guys just have to fix the variable $with_db3 Thanks -- Edit bug report at http://bugs.php.net/?id=20981&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20981&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20981&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20981&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20981&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20981&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20981&r=support Expected behavior: http://bugs.php.net/fix.php?id=20981&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20981&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20981&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20981&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20981&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20981&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20981&r=isapi
#6359 [Com]: PHP has encountered an Access Violation at 084A4E86
ID: 6359 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *General Issues Operating System: Windows 2000 Server PHP Version: 4.0.1pl2 New Comment: Just restart IIS server. No need reboot server Previous Comments: [2000-10-28 23:49:35] [EMAIL PROTECTED] No feedback. [2000-10-02 03:57:26] [EMAIL PROTECTED] not enough information. please supply a reproducing script. [2000-08-25 15:32:44] [EMAIL PROTECTED] Well, After installing PHP it was working fine. A day later I get the following error: PHP has encountered an Access Violation at 084A4E86 Any ideas? I am running under Win2K and IIS5. I rebooted the server and then it seemed to work... -- Edit this bug report at http://bugs.php.net/?id=6359&edit=1
#20980 [Opn->Fbk]: Strings stopped being read in at certain capital letters...
ID: 20980 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Strings related Operating System: Redhat Linux 8.0 PHP Version: 4.2.2 Previous Comments: [2002-12-12 21:27:49] [EMAIL PROTECTED] new email address.. [2002-12-12 21:27:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip If it still does not work, provide a short example of the actual PHP code that does not work. [2002-12-12 21:24:14] [EMAIL PROTECTED] I'm not sure if this is function specific but... I've written an IRC bot in php which runs from the command line. One of it's functions is to read in a message from a channel and to carry out the given command, ie: !privmsg #foo :hello people will send a message to the channel #foo saying "hello people". However, if you do: !privmsg #foo :ABCDEFGHIJKLMNOPQRSTUVWXYZ It will only send "ABCDEF". I have concluded from these tests that it 'doesn't like' the upper case letters : G I M P R S V. It just stops processing the string when it hits one of the above characters, so only this works: !privmsg #foo :ABCDEFgHiJKLmNOpQrsTUvWXYZ (all of the 'rogue' letters converted to lowercase ) I'm not sure if this is a general php bug, perhaps it's something to do with being run from command line. Thanks. Regards. tourist26 -- Edit this bug report at http://bugs.php.net/?id=20980&edit=1
#20967 [Opn->Bgs]: LDAP_OPEN causes Segmentation Violation
ID: 20967 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: LDAP related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Combination of the user comments and backtrace leads me to believe the problem is that of PHP, but rather a bug in ldap. Therefor I am making this report as bogus. Previous Comments: [2002-12-12 13:56:12] [EMAIL PROTECTED] Thanks for your assistance so far. Your direction has helped me to determine that this looks like an openldap issue. Turns out ldapsearch also segfaults for some reason. I will investigate this more as an openldap on AIX issue. Thanks, Craig [2002-12-12 13:31:02] [EMAIL PROTECTED] When I recompile with only LDAP support the backtrace looks like the following. (gdb) bt #0 0xd36ed048 in ber_strdup () at memory.c:541 #1 0xd37000e0 in ldap_pvt_get_fqdn (name=0x2ff202d0 "nichols") at util-int.c:410 #2 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x200407b8) at init.c:483 #3 0xd36f6b40 in ldap_create (ldp=0x2ff204d0) at open.c:94 #4 0xd36f6d6c in ldap_initialize (ldp=0x2ff2052c, url=0x200bbc28 "ldap://icexch3.ic.ncs.com:389";) at open.c:192 #5 0x10170da8 in zif_ldap_connect () #6 0x1009018c in execute () #7 0x1007e9b8 in zend_execute_scripts () #8 0x10077728 in php_execute_script () #9 0x10179450 in apache_php_module_main () #10 0x10073e7c in send_php () #11 0x10073f18 in send_parsed_php () #12 0x10015ea4 in ap_invoke_handler () #13 0x1003e0f0 in process_request_internal () #14 0x1003e1b4 in ap_process_request () #15 0x10005d24 in child_main () #16 0x10005f50 in make_child () #17 0x1000618c in startup_children () #18 0x10006a88 in standalone_main () #19 0x100074ec in main () #20 0x1204 in __start () (gdb) [2002-12-12 13:04:45] [EMAIL PROTECTED] I reconfigured as follows. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap=/oracle/app/oracle/product/8.1.7 --with-apache=/home/mcnicr/apache_1.3.27 --with-debug and recieved the following error message. checking for LDAP support... yes configure: error: Cannot find ldap.h also I recalled that I have read of the Oracle LDAP issue and I tried compiling without Oracle or Sybase support and still failed on ldap_open. I will try again with only LDAP support after doing a make distclean and reconfigure. I'm using openldap 2.0.27. Is there something else I need to do to use the Oracle LDAP client to get rid of the above message ? Thanks, Craig [2002-12-12 11:48:03] [EMAIL PROTECTED] Try compiling PHP with --with-ldap=/oracle/app/oracle/product/8.1.7 (oracle has it's own ldap stuff in there..) [2002-12-12 11:33:29] [EMAIL PROTECTED] I have compiled 4.2.3 into my apache 1.3.27 executable with the following options. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap --with-apache=/home/mcnicr/apache_1.3.27 --with-debug ./configure --activate-module=src/modules/php4/libphp4.a --enable-module=rewrite --enable-module=headers --enable-module=so --prefix=/www-home Using the example code from the below mentioned web URL configured for our local LDAP server (MS exchange 5.5). http://www.php.net/manual/en/ref.ldap.php I get a segmentation fault everytime the ldap_open call is executed. I have enclosed the backtrace and any assistance would be greatly appreciated. Thanks Craig (gdb) bt #0 0x10003d2c in sig_coredump () #1 #2 0xd36ed048 in ber_strdup () at memory.c:541 #3 0xd37000e0 in ldap_pvt_get_fqdn (name=0x60017e05 ) at util-int.c:410 #4 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x) at init.c:483 #5 0xd36f6b40 in ldap_create (ldp=0x2ff20418) at open.c:94 #6 0xd36f6d6c in ldap_initialize (ldp=0x2ff20474, url=0x200bcc38 ) at open.c:192 #7 0x10170da8 in floatcheck () #8 0x1009018c in execute () #9 0x1007e9b8 in zend_execute_scripts () #10 0x10077728 in php_execute_script () #11 0x101792c0 in read_common () #12 0x10073e7c in send_php () #13 0x10073f18 in send_parsed_php () #14 0x10015ea4 in ap_invoke_handler () #15 0x1003e0f0 in process_request_internal () #16 0x1003e1b4 in ap_process_request () #17 0x10005d
#13373 [Opn->Csd]: imap_fetchstructure() does not return $struct->type for text types
ID: 13373
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: IMAP related
Operating System: FreeBSD 4.3
PHP Version: 4.3.0RC2
New Comment:
The last comment on 2181 indicated that it's fixed.
I verified that it works.
Consider the following part of var_dump output on an object that
contained text/plain part:
[snip]
["parts"]=>
array(2) {
[0]=>
object(stdClass)(12) {
["type"]=>
int(0)
["encoding"]=>
int(4)
["ifsubtype"]=>
int(1)
["subtype"]=>
string(5) "PLAIN"
["ifdescription"]=>
[snip]
Notice the int(0) for type.
Please, note that types > 7 will result in undefined value.
If you have further questions, please send me a copy of MIME header of
the email part in question (or, better, the whole message if it's not a
secret) and re-open this bug.
Previous Comments:
[2002-12-11 15:55:18] [EMAIL PROTECTED]
This is still an issue.
[2002-06-24 23:12:16] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- the problem
might already be fixed. Please download a new PHP
version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
[2001-09-21 07:42:48] [EMAIL PROTECTED]
Bug 2181 is marked closed, but last comment indicates it should be
re-opened (sorry, I'm not the opener of 2181). This would be what
$struct->type would normally be used for:
$types = array(
0 => "TEXT",
1 => "MULTIPART",
2 => "MESSAGE",
3 => "APPLICATION",
4 => "AUDIO",
5 => "IMAGE",
6 => "VIDEO",
7 => "OTHER"
);
if($struct->type) {
$type = $types[$struct->type];
} else {
$type = "UNKNOWN";
}
$struct->type will always evaluate as false, but you can see from
serializing the struct object that the type isn't being set at all.
This probably should be fixed either way.
On the other hand, can we always assume that if $struct->type is
false/null/whatever, it is a text part?
--
Edit this bug report at http://bugs.php.net/?id=13373&edit=1
#20980 [Fbk->Opn]: Strings stopped being read in at certain capital letters...
ID: 20980 User updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Strings related Operating System: Redhat Linux 8.0 PHP Version: 4.2.2 New Comment: new email address.. Previous Comments: [2002-12-12 21:27:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip If it still does not work, provide a short example of the actual PHP code that does not work. [2002-12-12 21:24:14] [EMAIL PROTECTED] I'm not sure if this is function specific but... I've written an IRC bot in php which runs from the command line. One of it's functions is to read in a message from a channel and to carry out the given command, ie: !privmsg #foo :hello people will send a message to the channel #foo saying "hello people". However, if you do: !privmsg #foo :ABCDEFGHIJKLMNOPQRSTUVWXYZ It will only send "ABCDEF". I have concluded from these tests that it 'doesn't like' the upper case letters : G I M P R S V. It just stops processing the string when it hits one of the above characters, so only this works: !privmsg #foo :ABCDEFgHiJKLmNOpQrsTUvWXYZ (all of the 'rogue' letters converted to lowercase ) I'm not sure if this is a general php bug, perhaps it's something to do with being run from command line. Thanks. Regards. tourist26 -- Edit this bug report at http://bugs.php.net/?id=20980&edit=1
#17958 [Com]: loses $_POST vars
ID: 17958 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Apache2 related Operating System: Linux 2.4.18 PHP Version: 4.2.3 New Comment: Use $_FILES to access the the file specs. Use $_POST for all others. -taken from phpinfo()-- $_POST["user"] (gives me) ryan $_FILES["userfile"] (gives me) Array ( [name] => Test.class [type] => application/octet-stream [tmp_name] => /tmp/phpyXUyr7 [error] => 0 [size] => 444 ) PHP Version 4.2.2 Apache/1.3.12 Hope this helps Previous Comments: [2002-10-14 19:26:51] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, 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". [2002-10-10 03:34:21] [EMAIL PROTECTED] Reproduced with snapshot of 2002-09-28. Didn't see any changes. [2002-09-26 04:31:07] [EMAIL PROTECTED] Tried snapshot from 2002-09-26. The Bug still appears, all post vars get lost. In addition sometimes only some of the vars get lost. file_uploads is set to "On". System: WinXP Pro Webserver: Apache/1.3.23 (Win32) PHP/4.3.0-dev mod_gzip/1.3.19.1a mod_ssl/2.8.6 OpenSSL/0.9.6c [2002-09-23 15:12:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip When trying to replicate this bug please make sure your file_uploads php.ini value is set to On. In some versions of PHP, POST vars would get lost on multipart forms when this option has a blank or Off value. [2002-09-19 00:54:26] [EMAIL PROTECTED] I am experiencing the same POST problem. I thought it might have been an HTMLENTITIES problem (which I posted an error) but after reading these bug reports, I get the same thing. I spent 3+ days programming around this. Very frustrating. 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/17958 -- Edit this bug report at http://bugs.php.net/?id=17958&edit=1
#20980 [Opn->Fbk]: Strings stopped being read in at certain capital letters...
ID: 20980 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Strings related Operating System: Redhat Linux 8.0 PHP Version: 4.2.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip If it still does not work, provide a short example of the actual PHP code that does not work. Previous Comments: [2002-12-12 21:24:14] [EMAIL PROTECTED] I'm not sure if this is function specific but... I've written an IRC bot in php which runs from the command line. One of it's functions is to read in a message from a channel and to carry out the given command, ie: !privmsg #foo :hello people will send a message to the channel #foo saying "hello people". However, if you do: !privmsg #foo :ABCDEFGHIJKLMNOPQRSTUVWXYZ It will only send "ABCDEF". I have concluded from these tests that it 'doesn't like' the upper case letters : G I M P R S V. It just stops processing the string when it hits one of the above characters, so only this works: !privmsg #foo :ABCDEFgHiJKLmNOpQrsTUvWXYZ (all of the 'rogue' letters converted to lowercase ) I'm not sure if this is a general php bug, perhaps it's something to do with being run from command line. Thanks. Regards. tourist26 -- Edit this bug report at http://bugs.php.net/?id=20980&edit=1
#20980 [NEW]: Strings stopped being read in at certain capital letters...
From: [EMAIL PROTECTED] Operating system: Redhat Linux 8.0 PHP version: 4.2.2 PHP Bug Type: Strings related Bug description: Strings stopped being read in at certain capital letters... I'm not sure if this is function specific but... I've written an IRC bot in php which runs from the command line. One of it's functions is to read in a message from a channel and to carry out the given command, ie: !privmsg #foo :hello people will send a message to the channel #foo saying "hello people". However, if you do: !privmsg #foo :ABCDEFGHIJKLMNOPQRSTUVWXYZ It will only send "ABCDEF". I have concluded from these tests that it 'doesn't like' the upper case letters : G I M P R S V. It just stops processing the string when it hits one of the above characters, so only this works: !privmsg #foo :ABCDEFgHiJKLmNOpQrsTUvWXYZ (all of the 'rogue' letters converted to lowercase ) I'm not sure if this is a general php bug, perhaps it's something to do with being run from command line. Thanks. Regards. tourist26 -- Edit bug report at http://bugs.php.net/?id=20980&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20980&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20980&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20980&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20980&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20980&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20980&r=support Expected behavior: http://bugs.php.net/fix.php?id=20980&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20980&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20980&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20980&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20980&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20980&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20980&r=isapi
#19724 [Asn->Csd]: Limited data size on read
ID: 19724 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: dBase related Operating System: All PHP Version: 4.2.3 Assigned To: vlad New Comment: I just bumped the number of fields to 1024 instead of 254 (which really should've been 255 in the first place). That *should* be the easy fix. I see some indication (like here: http://www.dts.nl/support/helpdesk/bde/025/B0007.htm) that dBase5 (at least for Windows) allows for 1024 fields. Finding real specs for dBase turns out to be pretty hard. If that doesn't fix your problem, tell me what database you are actually using and re-open the bug. Previous Comments: [2002-12-09 18:28:55] [EMAIL PROTECTED] didn't have time to look at PHP bugs for a while... The status: - No soul seems to know what 'padded field headers' - The only case when I can imagine it breaking is in dbase5 with [255...1024] fields ([EMAIL PROTECTED] did not prove or disprove that) - I do not want to remove that padding algorythm, because obviously it worked for somebody. The easy solution would be to just bump up the maximum number of fields. Memory consumption is not *that* much larger, it won't break anything, and, since dbase is dead, I am sure no-one will implement a version that has more than 1024 fields :) I will do that once a check out a fresh tree. I'll close the bug when I do that. [2002-10-27 19:10:11] [EMAIL PROTECTED] Setting to 'Open' to prevent automatic closing due the no-feedback.. Vlad, what is the status on this? [2002-10-08 12:28:50] [EMAIL PROTECTED] Actually, it seems to return only up to 254 fields, which is a bug on its own. I believe, there was a limit of 255 fields for dbase4 format. I do not believe this is the case with dbase5. This patch broke it: http://cvs.php.net/diff.php/php4/ext/dbase/dbf_head.c?login=2&r1=1.9&r2=1.10&ty=u The simpliest way to fix that would be just to increase the constant from 254 to 1024. The better way would be figure out what the author of the patch meant by 'padded field headers'. I'll look into that. [EMAIL PROTECTED], do you use dbase5? or something else? [2002-10-02 15:52:27] [EMAIL PROTECTED] When using dbase_get_record or dbase_get_record_with_names to read from a DBF file, it only returns a maximum of 255 fields now. It did not do this in previous versions. -- Edit this bug report at http://bugs.php.net/?id=19724&edit=1
#20979 [NEW]: sendmail_from,SMTP and other valuse in php.ini not being read...
From: [EMAIL PROTECTED]
Operating system: Windows XP Pro.
PHP version: 4CVS-2002-12-12 (dev)
PHP Bug Type: IIS related
Bug description: sendmail_from,SMTP and other valuse in php.ini not being read...
I know that this problem has been reported before...
in fact many many times before, but I have tried other peoples solutions
to it with no success.
I recently recieved this error from the "Phorm" Script, an excelent form
processor/result-emailing
script with tons of features:
here is a link to it on my server:
http://67.80.121.68:8001/feedback.htm
(this site is just a mock up desgin I made for a me and my friend's joke
company btw :)
ERROR
090 - There has been an error, and your information has not been sent.
Alerts:
105 - Mail function failed on user email for template
./feedbackemail.txt.
105P: "sendmail_from" not set in php.ini or custom "From:" header missing
111 - Mail function failed on sending alerts.
111P: "sendmail_from" not set in php.ini or custom "From:" header missing
after reading this is checked my php.ini file for my 'SMTP', and
'sendmail_from' settings:
they were correct plus the fact that the phorm script provides a from
address on its own.
so to amuse myself I simply retyped my SMTP and sendmail_from settings
then resaved the file.
I then restarted IIS' services and tried again and recieved the same
error.
next, restarted the whole machine tried again and got the same error.
at this point, somewhat annoyed, I made a file doh.php with being its only contents
browsed to it in my web browser:
http://67.80.121.68:8001/sharedocs/doh.php
and it shows that my path for php.ini is correct, but shows:
Directive | Local Value | Master Value
sendmail_from | no value | no value
SMTP | localhost | localhost
next as a test I added the following lines to doh.php:
ini_set("SMTP","mail-hub.optonline.net");
ini_set("sendmail_from","[EMAIL PROTECTED]");
mail("[EMAIL PROTECTED]","testing","testing");
this worked and I recieved an email... also phpinfo() showed the
following:
Directive | Local Value | Master Value
sendmail_from | [EMAIL PROTECTED] | no value
SMTP | mail-hub.optonline.net | localhost
At this point I have no idea what to do in order to not have to ad
ini_set() commands
to all of my emailing php scripts
any explanations would be extremely appreciated.
PS: i understand that this is a duplicate report and am sorry
also: i am running ASP, ActivePERL, and PHP under iis. as well as a mysql
server.
could something in that combo be causing this problem?
-best reguards
Andrew
--
Edit bug report at http://bugs.php.net/?id=20979&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20979&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20979&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20979&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20979&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20979&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20979&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20979&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20979&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20979&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20979&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20979&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20979&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20979&r=isapi
#20540 [Com]: PHP do not read PHP.INI
ID: 20540 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: i am having the exact problem with my php.ini settings under winxp pro w/iis ... the ini_set function does work to fix it but i really dont feel like editing all the configs for things like phpbb, phorm, my own scripts and such itts just oo much of a hassle... any other suggestions would be greatly appreciated. I am confident you guys will find the solution to this bug eventually. thanks Andrew. Previous Comments: [2002-12-01 18:56:41] [EMAIL PROTECTED] I've got an identical problem on php 4.2.3 (submitted as a new bug #20753) to make sure it returns to "open" status. [2002-12-01 16:48:20] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-11-21 16:41:21] [EMAIL PROTECTED] You are using a relatively dated PHP, upgrading to 4.2.3 or better yet stable snapshot (avaliable from http://snaps.php.net) may solve your problem. [2002-11-21 12:20:46] [EMAIL PROTECTED] Thanks a lot for your fast reply... But, I knew of course that phpinfo() shows the path... and the displayed path by phpinfo() is "c:\winxp\php.ini" This is where I put the php.ini, but whatever I'm modifying in it and even restarting Apache, it does not take the changes into account I do not understand why... Anyway I'm using a workaround until finding the reason based on ini_set() function... I have to harcode it in the source code, but it works... Please, if you have any idea tell me... I hate to not understand when I'm doing all what is requested :-) Regards, Jean-Frederic [2002-11-21 11:50:34] [EMAIL PROTECTED] Do this: a) load phpinfo(); b) It will tell you where your php.ini is or where it's looking for it. It will include the path and filename so: c:\foo\php.ini c) Not that (b) will not just be a path, it will include the filename too. Please confirm this. If just a path shows, put your php.ini in this directory. d) Edit this php.ini. If you are running php as a module, restart web server. e) For kicks, try changing some more common directives, such as register_globals Also, name it php.ini not PHP.ini although on windows this shouldn't matter but... 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/20540 -- Edit this bug report at http://bugs.php.net/?id=20540&edit=1
#20643 [Com]: long POST fields get truncated
ID: 20643
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: Windows NT
PHP Version: 4CVS-2002-11-26 (dev)
New Comment:
Indeed,
we changed our server into RedHat 8.0 (Apache 2.0, PHP 4.2.2).
PHP Code that worked fine on the old server doesn't work on the new
server. Post-method forms let some variables (small) pass without any
problem, but bigger vars got truncated and concatenated with the
original value.
Previous Comments:
[2002-11-27 03:38:19] [EMAIL PROTECTED]
I double checked it, found the file you mentioned twice, but both are
the same, new updated files.
So problem persists.
[2002-11-26 20:10:45] [EMAIL PROTECTED]
Are you sure you have replaced ALL the old files with the new ones
found in the package? Most important one being php4ts.dll (and also
make sure you don't have many copies of it!)
[2002-11-26 04:54:09] [EMAIL PROTECTED]
Long (>~3k) POSTED fields get truncated
Following test produces correct results (twice the same length) on
Linux + Apache + PHP, Windows NT + IIS + PHP,
but NOT on Windows NT + Apache + PHP.
In last case, back in PHP the length appears to be 4374
bytes. Making the fieldname longer or shorter affects
this length, adding more fields doesn't.
This behaviour looks very much like reported bug #18961,
which is closed. Today, I downloaded, the what I think is, the latest
version (4.4.0-dev). But problem still exists.
The apache server I use is Apache: 1.3.19.0.0a delivered with Oracle
Application Server 1.0.2.2.2a .
My test file:
Data length: " . strlen($_POST['data1']) .
"";
return;
}
?>
"; ?>
var data = document.getElementById("data1");
data.value = "";
alert("Datalength: " + data.value.length);
form.submit();
Thanks,
- Douwe Koops
--
Edit this bug report at http://bugs.php.net/?id=20643&edit=1
#20978 [NEW]: /opt/php-4.3/bin/pear installed as world writable
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.0RC3 PHP Bug Type: Unknown/Other Function Bug description: /opt/php-4.3/bin/pear installed as world writable I've configured php to be installed at /opt/php-4.3 after installation, I noticed that /opt/php-4.3/bin/pear was group/other writable. -- Edit bug report at http://bugs.php.net/?id=20978&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20978&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20978&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20978&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20978&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20978&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20978&r=support Expected behavior: http://bugs.php.net/fix.php?id=20978&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20978&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20978&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20978&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20978&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20978&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20978&r=isapi
#20977 [NEW]: Cannot compile both yaz and imap options
From: [EMAIL PROTECTED] Operating system: Solaris 2.9 PHP version: 4.3.0RC3 PHP Bug Type: Compile Failure Bug description: Cannot compile both yaz and imap options With php-4.3.0RC3 on Solaris 2.9, the 'imap' and 'yaz' extensions seem to have a conflict. That is, I get compilation errors after the following configure command: configure --with-imap --with-yaz The make fails with: /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/2.95.3 -L/usr/local/lib -R /usr/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/2.95.3 -R /usr/local/lib ext/ctype/ctype.lo ext/imap/php_imap.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.l /usr/local/lib/libyaz.a(unix.o): In function `unix_close': /usr/local/src/yaz/yaz-1.9.2/comstack/unix.c:565: multiple definition of `unix_close' /usr/local/lib/libc-client.a(unix.o):/usr/local/src/imap/imap-2002.RC2/c-client/unix.c:437: first defined here /usr/local/sparc-sun-solaris2.9/bin/ld: Warning: size of symbol `unix_close' changed from 124 to 100 in unix.o collect2: ld returned 1 exit status gmake: *** [sapi/cgi/php-cgi] Error 1 However, 'configure --with-imap' and 'configure --with-yaz' each build without errors. Similarly, php4.2.3 does not have this problem with configured with both imap and yaz. Thanks. -- Edit bug report at http://bugs.php.net/?id=20977&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20977&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20977&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20977&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20977&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20977&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20977&r=support Expected behavior: http://bugs.php.net/fix.php?id=20977&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20977&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20977&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20977&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20977&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20977&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20977&r=isapi
#19022 [Com]: PHP Warning: Failed to write session data (files)
ID: 19022
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:
You can work around this bug by changing the session saver to "mm"
(without the quotes).
There are no known solutions to this problem that I can see out there.
The only people with solutions are the windows people who didn't change
the php.ini file to have a windows path in it. FOr the Linux people,
this may well be a library compatibility problem, which is the best
guess so far but is probably wrong!
Previous Comments:
[2002-12-07 20:32:26] [EMAIL PROTECTED]
Okay, I think I solved this bug for me at least.
I would receive this error:
Failed to write session data (files). Please verify that the current
setting of session.save_path is correct (c:\windows\temp) in Unknown on
line 0
and I finally tracked it down to being I was sometimes setting the
session_id(""); to blank, aka, to nothing. That would cause it to fail.
I still think this is a bug, because you shouldn't be able to break it
by setting it to nothing.
The reason I was unable to track this down quicker was because I had no
idea I was passing a blank variable to the session_id. So I looked into
that, and it turns out PHP fails to delete cookies.
I think their is a bug with the delete cookie functions...you might
want to check into that. To solve this, instead of deleting the
cookies, I just set them to -1, and then checked if they were -1, and
if so, treated them as if they weren't there.
I hope this helps,
Nate
[2002-12-07 20:05:38] [EMAIL PROTECTED]
I receive this bug too...I have traced it back to breaking as soon as I
use session_id(); function, and then working fine again once use of
that function is removed.
[2002-11-12 14:33:57] [EMAIL PROTECTED]
Another data point. I've recently moved a system from a hosted server
running 4.06 to a server under my control running redhat 7.3 and php
4.2.3 Since the move I've been getting very occasional cases of users
logging in and receiving someone else's session. The session handling
is very simple.
On login
session_name($db_name);
session_start();
$user = new User($userid, $passwd);
session_register("user");
On return
session_name($db_name);
session_start();
I've tried various workarounds like
session.entropy_length= 512
session.entropy_file = /dev/urandom
in the belief that somehow the two people were getting the same ID and
hence temp file
But all this was just thrashing at the problem. Then I checked my own
cookies and discovered the same as
[EMAIL PROTECTED] The cookie contained two session IDs. So I deleted
all relevant cookies. Logged out and in and now I'm back to the
expected single ID in the cookie.
I have logging turned on but have not yet seen any errors.
[2002-11-11 03:12:24] [EMAIL PROTECTED]
I've seen this bug on FreeBSD since PHP4.0.* series. Now I use 4.2.2.
It happens rarely. I could not figure why - the probability is small.
[2002-10-22 08:45:42] [EMAIL PROTECTED]
I got this too and its on a low traffic dev server. This
started happening even with old sites. I use FreeBSD and
the latest of everything. I will not upgrade the PHP on my
prod servers until this is resolved. good luck.
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/19022
--
Edit this bug report at http://bugs.php.net/?id=19022&edit=1
#20976 [NEW]: rename openssl.cnf
From: [EMAIL PROTECTED] Operating system: windows systems PHP version: 4.3.0RC3 PHP Bug Type: Feature/Change Request Bug description: rename openssl.cnf Hi, thanks for your efforts to make openssl extension more easy to use. The note in the openssl/README-ssl.txt adresses cleanly the problem with speeddial-links on windows system. To give more comfort to end-users - ok, renaming in a dos-box works - I suggest to ship this file with an .conf or txt file extension. It doesnt harm, is easy to edit, and will avoid upcoming bug-reports(IMHO). In the tradition to make PHP as easy to use for the end users it would be very kind to rename this file to openssl.conf or openssl.txt. And users who would like to have it named openssl.cnf could easily achieve this by renaming this file through the explorer interface (after editing). Regards Friedhelm Betz -- Edit bug report at http://bugs.php.net/?id=20976&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20976&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20976&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20976&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20976&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20976&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20976&r=support Expected behavior: http://bugs.php.net/fix.php?id=20976&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20976&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20976&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20976&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20976&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20976&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20976&r=isapi
#20975 [Opn->Csd]: date("O") & date("r")
ID: 20975
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Date/time related
Operating System: win2000SP3
PHP Version: 4.2.3
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-12-12 16:57:10] [EMAIL PROTECTED]
When used for time zone that varies by the half hour rather than the
standard one hour from GMT (or 45 min - Nepal) will output combination
of hours and second as difference to Greenwich:
date("O"); will generate (date("r")) :
+052700 Nepal Standard Time(GMT+05:45)
-031800 Newfoundland Standard Time (GMT-03:30), etc.
PHP documentation:
O - Difference to Greenwich Time in hours; e.g. "+0200"
NOT in hours AND seconds...date("Z") works fine.
Peter
--
Edit this bug report at http://bugs.php.net/?id=20975&edit=1
#20975 [NEW]: date("O") & date("r")
From: [EMAIL PROTECTED]
Operating system: win2000SP3
PHP version: 4.2.3
PHP Bug Type: Date/time related
Bug description: date("O") & date("r")
When used for time zone that varies by the half hour rather than the
standard one hour from GMT (or 45 min - Nepal) will output combination of
hours and second as difference to Greenwich:
date("O"); will generate (date("r")) :
+052700 Nepal Standard Time(GMT+05:45)
-031800 Newfoundland Standard Time (GMT-03:30), etc.
PHP documentation:
O - Difference to Greenwich Time in hours; e.g. "+0200"
NOT in hours AND seconds...date("Z") works fine.
Peter
--
Edit bug report at http://bugs.php.net/?id=20975&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20975&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20975&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20975&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20975&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20975&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20975&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20975&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20975&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20975&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20975&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20975&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20975&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20975&r=isapi
#20838 [Opn->Csd]: Script hangs (endless loop) after shutdown
ID: 20838 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Output Control Operating System: Redhat Linux 7.1 PHP Version: 4.2.3 New Comment: See PR #12227 (http://bugs.php.net/12227) Previous Comments: [2002-12-11 13:10:15] [EMAIL PROTECTED] Haven't had time to test against the latest, but I have a simple testcase: -- basically, any modification to the incoming data in-place, instead of copying to a new variable causes a hang. [2002-12-05 15:29:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-05 15:22:41] [EMAIL PROTECTED] I think that Bug #11346 applies to 4.2.3 as well, and #17672 as well. I have a script using lots of output-buffer functions that seems to hang, eating 100% CPU, and occasionally truncates output. The error log shows: [Thu Dec 5 14:08:42 2002] [error] PHP Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0 for each process, and there are several HTTP processes running full-tilt, executing no system nor library calls. (strace and ltrace show nothing). Configure Command './configure' '--sysconfdir=/etc/httpd' '--with-mysql=/src/mysql/mysql-404-php' '--with-snmp' '--with-gd' '--with-jpeg-dir=/src/jpeg/jpeg-6b' '--with-png-dir=/src/png/libpng-1.0.12' '--with-zlib-dir=/src/zlib/zlib-1.1.3' '--with-gdbm' '--with-db3' '--enable-ftp' '--with-imap' '--enable-sockets' '--with-kerberos' '--with-imap-ssl' '--with-openssl' '--cache-file=/dev/null' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xmlrpc' -- Edit this bug report at http://bugs.php.net/?id=20838&edit=1
#20965 [Opn->Fbk]: Urgent - Users getting same session id?
ID: 20965 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 13:16:09] [EMAIL PROTECTED] I am running PHP version 4.2.3. [2002-12-12 11:15:06] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-12-12 10:38:30] [EMAIL PROTECTED] php session some times share the same session id with different users and this allows users to access another user's login and account info.. This is a serious security threat! Pls help. -- Edit this bug report at http://bugs.php.net/?id=20965&edit=1
#20974 [Opn->Csd]: imagepstext crashes, when size is not set
ID: 20974
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: Linux Slackware 8.1
PHP Version: 4.3.0RC3
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-12-12 14:35:59] [EMAIL PROTECTED]
OK, thanks for pointing out that size is not set...
Summary was changed. The font is from t1lib distribution.
[2002-12-12 14:32:56] [EMAIL PROTECTED]
Could you please provide a copy of the 'bchb.pfb' font file, I cannot
replicate the bug using the fonts I have on my system.
Also, what is the value of the $size variable?
[2002-12-12 14:13:17] [EMAIL PROTECTED]
Like summary says, I'm unable to draw with t1lib. My configure line is
./configure --with-t1lib --with-imagick --with-freetype-dir=/usr/local
--with-apache=../test_apache_1.3.26 --with-png-dir=/usr/local
--with-openssl --enable-bcmath --enable-calendar --enable-ftp
--enable-gd-imgstrttf --with-gd --with-jpeg-dir=/usr/local --with-imap
--with-mysql=/usr/local --enable-sockets --with-zlib
--enable-inline-optimization --enable-track-vars --enable-gd-native-ttf
--with-freetype --with-gettext --with-gdbm
GDB output is below
> gdb php
[version info snipped] GNU gdb 5.2
(gdb) set args bug.php
(gdb) run
Starting program: /usr/local/bin/php bug.php
Program received signal SIGSEGV, Segmentation fault.
T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
480 if (ipath->type==LINETYPE){
(gdb) bt
#0 T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
#1 0x400bb5df in T1_AAFillOutline (path=0x0, modflag=0) at
t1aaset.c:1494
#2 0x0809c78c in zif_imagepstext (ht=8, return_value=0x847d9dc,
this_ptr=0x0, return_value_used=0)
at /usr/src/php-4.3.0RC3/ext/gd/gd.c:3312
#3 0x0816999a in execute (op_array=0x837422c) at
/usr/src/php-4.3.0RC3/Zend/zend_execute.c:1598
#4 0x0815a708 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-4.3.0RC3/Zend/zend.c:864
#5 0x0813852f in php_execute_script (primary_file=0xb898) at
/usr/src/php-4.3.0RC3/main/main.c:1552
#6 0x08170454 in main (argc=2, argv=0xb914) at
/usr/src/php-4.3.0RC3/sapi/cli/php_cli.c:746
#7 0x401d517d in __libc_start_main (main=0x816fc80 , argc=2,
ubp_av=0xb914, init=0x8081784 <_init>,
fini=0x8241f30 <_fini>, rtld_fini=0x4000a534 <_dl_fini>,
stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:129
And the script is very simple:
It crashes both from command line and from Apache.
--
Edit this bug report at http://bugs.php.net/?id=20974&edit=1
#20551 [Opn]: Output compression causes segfaults (ob_gzhandler)
ID: 20551
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Output Control
+Bug Type: Apache related
Operating System: RedHat 7.2
-PHP Version: 4.3.0RC2
+PHP Version: 4.3.0RC3
New Comment:
Reclassifying since it is the Apache module code where the actual
segfaults occur.
Short version: SG(server_context) is not checked for null before
dereferencing it in sapi_apache_header_handler() while it is checked in
other functions.
Previous Comments:
[2002-12-06 09:30:55] [EMAIL PROTECTED]
Finally.
In file:
sapi/apache/mod_php4.c
The crash is in sapi_apache_header_handler(). This line is apparently
not guaranteed:
request_rec *r = (request_rec *) SG(server_context);
As r is dereferenced and not valid some small percent of the time. It
may be indicative of some other error. Further investigation as to why
needs to be done.
I added a few other checks while tracking this bug down. Here is the
function as I have it now. No more segfaults in the error_log. The line
to note is the check for !r. Also, I don't think it hurts to check for
null in other places (!sapi_header || !sapi_header->header).
/* {{{ sapi_apache_header_handler
*/
int sapi_apache_header_handler(sapi_header_struct *sapi_header,
sapi_headers_struct *sapi_headers TSRMLS_DC)
{
char *header_name, *header_content, *p;
request_rec *r = (request_rec *) SG(server_context);
if (!sapi_header) {
return 0;
}
if (!sapi_header->header) {
return 0;
}
header_name = sapi_header->header;
header_content = strchr(header_name, ':');
if (!header_content || !r) {
efree(sapi_header->header);
return 0;
}
header_name =
estrndup(header_name,header_content-header_name);
if (!header_name){
return 0;
}
do {
header_content++;
} while (*header_content==' ');
if (!strcasecmp(header_name, "Content-Type")) {
r->content_type = pstrdup(r->pool, header_content);
} else if (!strcasecmp(header_name, "Set-Cookie")) {
table_add(r->headers_out, header_name,
header_content);
} else if (sapi_header->replace) {
table_set(r->headers_out, header_name,
header_content);
} else {
table_add(r->headers_out, header_name,
header_content);
efree(header_name);
efree(sapi_header->header);
return 0; /* don't use the default SAPI mechanism, Apache
duplicates this functionality */
}
/* }}} */
[2002-12-05 18:34:16] [EMAIL PROTECTED]
OK, I was able to have gbb attach to one of the 500 children and wait
for a segault. This is version 4.2.3, as this is from our production
site (late at night I'll try and do the same for a full debug version
of 4.3RC2):
Program received signal SIGSEGV, Segmentation fault.
0x080a9b2c in sapi_apache_header_handler ()
(gdb) bt
#0 0x080a9b2c in sapi_apache_header_handler ()
#1 0x080af403 in sapi_add_header_ex ()
#2 0x080b5700 in zif_ob_gzhandler ()
#3 0x08124392 in call_user_function_ex ()
#4 0x080b20f9 in php_end_ob_buffer ()
#5 0x080b23bb in php_end_ob_buffers ()
#6 0x080ac0a7 in php_request_shutdown ()
#7 0x081530d8 in run_cleanups ()
#8 0x08151ec8 in ap_clear_pool ()
#9 0x08151f28 in ap_destroy_pool ()
#10 0x08151e9b in ap_clear_pool ()
#11 0x0815e92b in child_main ()
#12 0x0815ef0b in make_child ()
#13 0x0815f1e9 in perform_idle_server_maintenance ()
#14 0x0815f69a in standalone_main ()
#15 0x0815fc2c in main ()
[2002-12-04 17:59:13] [EMAIL PROTECTED]
status -> open, updated version.
(please, don't use 'Add Comment' when you edit your own submission..use
'Edit Submission')
[2002-12-04 11:36:49] [EMAIL PROTECTED]
Yes, the problem occurs without the Zend addon. Zend Accelerator won't
work with PHP 4.3 anyhow, so I turned it off. In the other message I
proved myself to be a bad typist. :( I meant to say _without_ Zend
Accelerator...
[2002-12-04 00:38:50] [EMAIL PROTECTED]
Does the crash still occur when you disable Zend Accelerator?
Derick
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/20551
--
Edit this bug report at http://bugs.php.net/?id=20551&edit=1
#20969 [Opn->Ver]: Bitwise NOT (~): wrong results on Linux
ID: 20969 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: *Math Functions Operating System: i386 Redhat Linux -PHP Version: 4.2.2 +PHP Version: 4CVS-20021213 New Comment: Although bitwise operators are not expected to use with float values, the reported behaviour is quite inconsistent. Possible documentation problem? Previous Comments: [2002-12-12 12:39:39] [EMAIL PROTECTED] The Bitwise NOT operator ~ doesn't fuinction correctly on the Linux system. Examples: ~-22 = 2147483647 ~4180982798 = 2147483647 But on a Windows 2000 Server it functions well: ~-22 = -2072745075 ~4180982798 = 113984497 On both systems PHP 4.2.2 is used. If that's a "feature" then PHP is not usable for any bitwise operation. -- Edit this bug report at http://bugs.php.net/?id=20969&edit=1
#20974 [Fbk->Opn]: imagepstext crashes, when size is not set
ID: 20974
User updated by: [EMAIL PROTECTED]
-Summary: imagepstext consistently crashes PHP
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Linux Slackware 8.1
PHP Version: 4.3.0RC3
New Comment:
OK, thanks for pointing out that size is not set...
Summary was changed. The font is from t1lib distribution.
Previous Comments:
[2002-12-12 14:32:56] [EMAIL PROTECTED]
Could you please provide a copy of the 'bchb.pfb' font file, I cannot
replicate the bug using the fonts I have on my system.
Also, what is the value of the $size variable?
[2002-12-12 14:13:17] [EMAIL PROTECTED]
Like summary says, I'm unable to draw with t1lib. My configure line is
./configure --with-t1lib --with-imagick --with-freetype-dir=/usr/local
--with-apache=../test_apache_1.3.26 --with-png-dir=/usr/local
--with-openssl --enable-bcmath --enable-calendar --enable-ftp
--enable-gd-imgstrttf --with-gd --with-jpeg-dir=/usr/local --with-imap
--with-mysql=/usr/local --enable-sockets --with-zlib
--enable-inline-optimization --enable-track-vars --enable-gd-native-ttf
--with-freetype --with-gettext --with-gdbm
GDB output is below
> gdb php
[version info snipped] GNU gdb 5.2
(gdb) set args bug.php
(gdb) run
Starting program: /usr/local/bin/php bug.php
Program received signal SIGSEGV, Segmentation fault.
T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
480 if (ipath->type==LINETYPE){
(gdb) bt
#0 T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
#1 0x400bb5df in T1_AAFillOutline (path=0x0, modflag=0) at
t1aaset.c:1494
#2 0x0809c78c in zif_imagepstext (ht=8, return_value=0x847d9dc,
this_ptr=0x0, return_value_used=0)
at /usr/src/php-4.3.0RC3/ext/gd/gd.c:3312
#3 0x0816999a in execute (op_array=0x837422c) at
/usr/src/php-4.3.0RC3/Zend/zend_execute.c:1598
#4 0x0815a708 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-4.3.0RC3/Zend/zend.c:864
#5 0x0813852f in php_execute_script (primary_file=0xb898) at
/usr/src/php-4.3.0RC3/main/main.c:1552
#6 0x08170454 in main (argc=2, argv=0xb914) at
/usr/src/php-4.3.0RC3/sapi/cli/php_cli.c:746
#7 0x401d517d in __libc_start_main (main=0x816fc80 , argc=2,
ubp_av=0xb914, init=0x8081784 <_init>,
fini=0x8241f30 <_fini>, rtld_fini=0x4000a534 <_dl_fini>,
stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:129
And the script is very simple:
It crashes both from command line and from Apache.
--
Edit this bug report at http://bugs.php.net/?id=20974&edit=1
#20974 [Opn->Fbk]: imagepstext consistently crashes PHP
ID: 20974
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Linux Slackware 8.1
PHP Version: 4.3.0RC3
New Comment:
Could you please provide a copy of the 'bchb.pfb' font file, I cannot
replicate the bug using the fonts I have on my system.
Also, what is the value of the $size variable?
Previous Comments:
[2002-12-12 14:13:17] [EMAIL PROTECTED]
Like summary says, I'm unable to draw with t1lib. My configure line is
./configure --with-t1lib --with-imagick --with-freetype-dir=/usr/local
--with-apache=../test_apache_1.3.26 --with-png-dir=/usr/local
--with-openssl --enable-bcmath --enable-calendar --enable-ftp
--enable-gd-imgstrttf --with-gd --with-jpeg-dir=/usr/local --with-imap
--with-mysql=/usr/local --enable-sockets --with-zlib
--enable-inline-optimization --enable-track-vars --enable-gd-native-ttf
--with-freetype --with-gettext --with-gdbm
GDB output is below
> gdb php
[version info snipped] GNU gdb 5.2
(gdb) set args bug.php
(gdb) run
Starting program: /usr/local/bin/php bug.php
Program received signal SIGSEGV, Segmentation fault.
T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
480 if (ipath->type==LINETYPE){
(gdb) bt
#0 T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
#1 0x400bb5df in T1_AAFillOutline (path=0x0, modflag=0) at
t1aaset.c:1494
#2 0x0809c78c in zif_imagepstext (ht=8, return_value=0x847d9dc,
this_ptr=0x0, return_value_used=0)
at /usr/src/php-4.3.0RC3/ext/gd/gd.c:3312
#3 0x0816999a in execute (op_array=0x837422c) at
/usr/src/php-4.3.0RC3/Zend/zend_execute.c:1598
#4 0x0815a708 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-4.3.0RC3/Zend/zend.c:864
#5 0x0813852f in php_execute_script (primary_file=0xb898) at
/usr/src/php-4.3.0RC3/main/main.c:1552
#6 0x08170454 in main (argc=2, argv=0xb914) at
/usr/src/php-4.3.0RC3/sapi/cli/php_cli.c:746
#7 0x401d517d in __libc_start_main (main=0x816fc80 , argc=2,
ubp_av=0xb914, init=0x8081784 <_init>,
fini=0x8241f30 <_fini>, rtld_fini=0x4000a534 <_dl_fini>,
stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:129
And the script is very simple:
It crashes both from command line and from Apache.
--
Edit this bug report at http://bugs.php.net/?id=20974&edit=1
#20971 [Opn->Bgs]: Notice: Undefined index: Submit in
ID: 20971 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: win 2k pro PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Previous Comments: [2002-12-12 13:46:38] [EMAIL PROTECTED] forgot, Apache HTTP Server Version 1.3 [2002-12-12 13:44:15] [EMAIL PROTECTED] Notice: Undefined index: Submit in c:\program files\apache group\apache\htdocs\webproyect\modulo_externo\include\ingreso.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=20971&edit=1
#20970 [Opn->Fbk]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line
ID: 20970 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Sun2.7 PHP Version: 4.2.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 13:33:57] [EMAIL PROTECTED] Execute http://testzone.net.com/php/run.php Output: No code submitted. Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 Iplanet webserver 4.2 used './configure' '--with-nsapi=/export/webtools/netscape/server4' '--enable-libgcc' -- Edit this bug report at http://bugs.php.net/?id=20970&edit=1
#20974 [NEW]: imagepstext consistently crashes PHP
From: [EMAIL PROTECTED]
Operating system: Linux Slackware 8.1
PHP version: 4.3.0RC3
PHP Bug Type: GD related
Bug description: imagepstext consistently crashes PHP
Like summary says, I'm unable to draw with t1lib. My configure line is
./configure --with-t1lib --with-imagick --with-freetype-dir=/usr/local
--with-apache=../test_apache_1.3.26 --with-png-dir=/usr/local
--with-openssl --enable-bcmath --enable-calendar --enable-ftp
--enable-gd-imgstrttf --with-gd --with-jpeg-dir=/usr/local --with-imap
--with-mysql=/usr/local --enable-sockets --with-zlib
--enable-inline-optimization --enable-track-vars --enable-gd-native-ttf
--with-freetype --with-gettext --with-gdbm
GDB output is below
> gdb php
[version info snipped] GNU gdb 5.2
(gdb) set args bug.php
(gdb) run
Starting program: /usr/local/bin/php bug.php
Program received signal SIGSEGV, Segmentation fault.
T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
480 if (ipath->type==LINETYPE){
(gdb) bt
#0 T1_ScaleOutline (path=0x0, scale=2) at t1outline.c:480
#1 0x400bb5df in T1_AAFillOutline (path=0x0, modflag=0) at
t1aaset.c:1494
#2 0x0809c78c in zif_imagepstext (ht=8, return_value=0x847d9dc,
this_ptr=0x0, return_value_used=0)
at /usr/src/php-4.3.0RC3/ext/gd/gd.c:3312
#3 0x0816999a in execute (op_array=0x837422c) at
/usr/src/php-4.3.0RC3/Zend/zend_execute.c:1598
#4 0x0815a708 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/src/php-4.3.0RC3/Zend/zend.c:864
#5 0x0813852f in php_execute_script (primary_file=0xb898) at
/usr/src/php-4.3.0RC3/main/main.c:1552
#6 0x08170454 in main (argc=2, argv=0xb914) at
/usr/src/php-4.3.0RC3/sapi/cli/php_cli.c:746
#7 0x401d517d in __libc_start_main (main=0x816fc80 , argc=2,
ubp_av=0xb914, init=0x8081784 <_init>,
fini=0x8241f30 <_fini>, rtld_fini=0x4000a534 <_dl_fini>,
stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:129
And the script is very simple:
It crashes both from command line and from Apache.
--
Edit bug report at http://bugs.php.net/?id=20974&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20974&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20974&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20974&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20974&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20974&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20974&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20974&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20974&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20974&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20974&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20974&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20974&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20974&r=isapi
#20973 [NEW]: configure fails with IMAP
From: [EMAIL PROTECTED]
Operating system: Sun Linux 7.0
PHP version: 4.3.0RC3
PHP Bug Type: *Compile Issues
Bug description: configure fails with IMAP
PHP4 up through versions 4.2.3 installed without incident on the same
hardware/software configuration. Imap version is 2000c-stackgaurdC3.
This is running on a Sun Cobalt RaQ550 server appliance, so upgrading the
installed version of imap is not a desirable option.
./configure --with-imap --with-imap-ssl
results in the following:
checking for IMAP support... yes
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... (cached) yes
checking whether SSL libraries are needed for c-client... /usr/lib
checking whether IMAP works... no
configure: error: build test failed. Please check the config.log for
details.
config.log shows the following:
configure:34447: checking for IMAP support
configure:34805: checking for pam_start in -lpam
configure:34824: gcc -o conftest -g -O2 conftest.c -lpam -lcrypt
-lresolv -lm -ldl -lnsl -lcrypt 1>&5
configure:34852: checking for crypt in -lcrypt
configure:35246: checking whether SSL libraries are needed for c-client
configure:35407: checking whether IMAP works
configure:35440: gcc -o conftest -g -O2 conftest.c -lcrypto -lssl
-lc-client -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lcrypt 1>&5
/usr/lib/libc-client.a(osdep.o): In function `ssl_onceonlyinit':
/usr/src/redhat/BUILD/imap-2000c/c-client/auth_ssl.c:153: the use of
`tmpnam' is dangerous, better use `mkstemp'
/usr/lib/libc-client.a(mail.o): In function `mm_cache':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:185: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_parameters':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:459: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:490: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:508: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net_parse':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:619: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o):/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:677:
more undefined references to `__canary_death_handler' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 35415 "configure"
#include "confdefs.h"
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char mail_open();
int main() {
mail_open(0,"",0);
return 0;
}
--
Edit bug report at http://bugs.php.net/?id=20973&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20973&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20973&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20973&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20973&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20973&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20973&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20973&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20973&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20973&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20973&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20973&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20973&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20973&r=isapi
#20967 [Opn]: LDAP_OPEN causes Segmentation Violation
ID: 20967 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: LDAP related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Thanks for your assistance so far. Your direction has helped me to determine that this looks like an openldap issue. Turns out ldapsearch also segfaults for some reason. I will investigate this more as an openldap on AIX issue. Thanks, Craig Previous Comments: [2002-12-12 13:31:02] [EMAIL PROTECTED] When I recompile with only LDAP support the backtrace looks like the following. (gdb) bt #0 0xd36ed048 in ber_strdup () at memory.c:541 #1 0xd37000e0 in ldap_pvt_get_fqdn (name=0x2ff202d0 "nichols") at util-int.c:410 #2 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x200407b8) at init.c:483 #3 0xd36f6b40 in ldap_create (ldp=0x2ff204d0) at open.c:94 #4 0xd36f6d6c in ldap_initialize (ldp=0x2ff2052c, url=0x200bbc28 "ldap://icexch3.ic.ncs.com:389";) at open.c:192 #5 0x10170da8 in zif_ldap_connect () #6 0x1009018c in execute () #7 0x1007e9b8 in zend_execute_scripts () #8 0x10077728 in php_execute_script () #9 0x10179450 in apache_php_module_main () #10 0x10073e7c in send_php () #11 0x10073f18 in send_parsed_php () #12 0x10015ea4 in ap_invoke_handler () #13 0x1003e0f0 in process_request_internal () #14 0x1003e1b4 in ap_process_request () #15 0x10005d24 in child_main () #16 0x10005f50 in make_child () #17 0x1000618c in startup_children () #18 0x10006a88 in standalone_main () #19 0x100074ec in main () #20 0x1204 in __start () (gdb) [2002-12-12 13:04:45] [EMAIL PROTECTED] I reconfigured as follows. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap=/oracle/app/oracle/product/8.1.7 --with-apache=/home/mcnicr/apache_1.3.27 --with-debug and recieved the following error message. checking for LDAP support... yes configure: error: Cannot find ldap.h also I recalled that I have read of the Oracle LDAP issue and I tried compiling without Oracle or Sybase support and still failed on ldap_open. I will try again with only LDAP support after doing a make distclean and reconfigure. I'm using openldap 2.0.27. Is there something else I need to do to use the Oracle LDAP client to get rid of the above message ? Thanks, Craig [2002-12-12 11:48:03] [EMAIL PROTECTED] Try compiling PHP with --with-ldap=/oracle/app/oracle/product/8.1.7 (oracle has it's own ldap stuff in there..) [2002-12-12 11:33:29] [EMAIL PROTECTED] I have compiled 4.2.3 into my apache 1.3.27 executable with the following options. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap --with-apache=/home/mcnicr/apache_1.3.27 --with-debug ./configure --activate-module=src/modules/php4/libphp4.a --enable-module=rewrite --enable-module=headers --enable-module=so --prefix=/www-home Using the example code from the below mentioned web URL configured for our local LDAP server (MS exchange 5.5). http://www.php.net/manual/en/ref.ldap.php I get a segmentation fault everytime the ldap_open call is executed. I have enclosed the backtrace and any assistance would be greatly appreciated. Thanks Craig (gdb) bt #0 0x10003d2c in sig_coredump () #1 #2 0xd36ed048 in ber_strdup () at memory.c:541 #3 0xd37000e0 in ldap_pvt_get_fqdn (name=0x60017e05 ) at util-int.c:410 #4 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x) at init.c:483 #5 0xd36f6b40 in ldap_create (ldp=0x2ff20418) at open.c:94 #6 0xd36f6d6c in ldap_initialize (ldp=0x2ff20474, url=0x200bcc38 ) at open.c:192 #7 0x10170da8 in floatcheck () #8 0x1009018c in execute () #9 0x1007e9b8 in zend_execute_scripts () #10 0x10077728 in php_execute_script () #11 0x101792c0 in read_common () #12 0x10073e7c in send_php () #13 0x10073f18 in send_parsed_php () #14 0x10015ea4 in ap_invoke_handler () #15 0x1003e0f0 in process_request_internal () #16 0x1003e1b4 in ap_process_request () #17 0x10005d24 in child_main () #18 0x10006074 in make_child () #19 0x1000653c in perform_idle_server_maintenance () #20 0x10006cd4 in standalone_main () #21 0x100074ec in main () #22 0x1204 in __start () -- Edit this bug report at http://bugs.php.net/?id=20967&edit=1
#20972 [Opn->Csd]: make fails during gd.c
ID: 20972 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux - 2.4.18 - SuSE 7.2 PHP Version: 4.3.0RC3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-12 13:46:02] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/ -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/apache2/php-4.3.0RC3/include -I/usr/local/src/apache2/php-4.3.0RC3/main -I/usr/local/src/apache2/php-4.3.0RC3 -I/usr/local/apache2/include -I/usr/local/src/apache2/php-4.3.0RC3/Zend -I/usr/local/ssl/include -I/usr/local/include -I/usr/local/src/gd-1.8.4/ -I/usr/include/mysql -I/usr/local/verisign/payflowpro/linux/lib -I/usr/local/src/apache2/php-4.3.0RC3/ext/xml/expat -I/usr/local/src/apache2/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) make: *** [ext/gd/gd.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=20972&edit=1
#20971 [Com]: Notice: Undefined index: Submit in
ID: 20971 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: win 2k pro PHP Version: 4.2.3 New Comment: forgot, Apache HTTP Server Version 1.3 Previous Comments: [2002-12-12 13:44:15] [EMAIL PROTECTED] Notice: Undefined index: Submit in c:\program files\apache group\apache\htdocs\webproyect\modulo_externo\include\ingreso.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=20971&edit=1
#20972 [NEW]: make fails during gd.c
From: [EMAIL PROTECTED] Operating system: Linux - 2.4.18 - SuSE 7.2 PHP version: 4.3.0RC3 PHP Bug Type: Compile Failure Bug description: make fails during gd.c /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/ -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/apache2/php-4.3.0RC3/include -I/usr/local/src/apache2/php-4.3.0RC3/main -I/usr/local/src/apache2/php-4.3.0RC3 -I/usr/local/apache2/include -I/usr/local/src/apache2/php-4.3.0RC3/Zend -I/usr/local/ssl/include -I/usr/local/include -I/usr/local/src/gd-1.8.4/ -I/usr/include/mysql -I/usr/local/verisign/payflowpro/linux/lib -I/usr/local/src/apache2/php-4.3.0RC3/ext/xml/expat -I/usr/local/src/apache2/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) make: *** [ext/gd/gd.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=20972&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20972&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20972&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20972&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20972&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20972&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20972&r=support Expected behavior: http://bugs.php.net/fix.php?id=20972&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20972&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20972&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20972&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20972&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20972&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20972&r=isapi
#20751 [Opn->Bgs]: Mail: undefined function
ID: 20751 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: Thanx for your help. This is actually a bug in autoconf-2.53, which was used to build RC2. RC3, which came out yesterday, doesn't have this problem. The problem only manifests itself, when sendmail is NOT in your path, because autoconf-2.53 generates the wrong shellcode. So a work-around, is to adjust your path, so that sendmail is in there. Previous Comments: [2002-12-08 14:30:59] [EMAIL PROTECTED] Hi. This works: export PROG_SENDMAIL="/var/qmail/bin/sendmail" (but it's a workaround) [2002-12-05 12:12:39] [EMAIL PROTECTED] Could you gzip config.log and configure and mail them to me? [2002-12-05 12:02:54] [EMAIL PROTECTED] Yes, it produces "yes" Andrea Busia [2002-12-03 08:53:15] [EMAIL PROTECTED] Yes, it produces "yes" Andrea Busia [2002-12-03 06:59:36] [EMAIL PROTECTED] I'll rephrase, y'honnor: Does: if test -f /usr/sbin/sendmail; then echo yes; fi Produce: "yes" Please note: /usr/sbin/sendmail - not /usr/bin/sendmail. 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/20751 -- Edit this bug report at http://bugs.php.net/?id=20751&edit=1
#20971 [NEW]: Notice: Undefined index: Submit in
From: [EMAIL PROTECTED] Operating system: win 2k pro PHP version: 4.2.3 PHP Bug Type: Session related Bug description: Notice: Undefined index: Submit in Notice: Undefined index: Submit in c:\program files\apache group\apache\htdocs\webproyect\modulo_externo\include\ingreso.php on line 3 -- Edit bug report at http://bugs.php.net/?id=20971&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20971&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20971&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20971&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20971&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20971&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20971&r=support Expected behavior: http://bugs.php.net/fix.php?id=20971&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20971&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20971&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20971&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20971&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20971&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20971&r=isapi
#20970 [NEW]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line
From: [EMAIL PROTECTED] Operating system: Sun2.7 PHP version: 4.2.2 PHP Bug Type: Compile Failure Bug description: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line Execute http://testzone.net.com/php/run.php Output: No code submitted. Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 Iplanet webserver 4.2 used './configure' '--with-nsapi=/export/webtools/netscape/server4' '--enable-libgcc' -- Edit bug report at http://bugs.php.net/?id=20970&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20970&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20970&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20970&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20970&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20970&r=support Expected behavior: http://bugs.php.net/fix.php?id=20970&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20970&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20970&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20970&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20970&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20970&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20970&r=isapi
#20967 [Opn]: LDAP_OPEN causes Segmentation Violation
ID: 20967 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: LDAP related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: When I recompile with only LDAP support the backtrace looks like the following. (gdb) bt #0 0xd36ed048 in ber_strdup () at memory.c:541 #1 0xd37000e0 in ldap_pvt_get_fqdn (name=0x2ff202d0 "nichols") at util-int.c:410 #2 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x200407b8) at init.c:483 #3 0xd36f6b40 in ldap_create (ldp=0x2ff204d0) at open.c:94 #4 0xd36f6d6c in ldap_initialize (ldp=0x2ff2052c, url=0x200bbc28 "ldap://icexch3.ic.ncs.com:389";) at open.c:192 #5 0x10170da8 in zif_ldap_connect () #6 0x1009018c in execute () #7 0x1007e9b8 in zend_execute_scripts () #8 0x10077728 in php_execute_script () #9 0x10179450 in apache_php_module_main () #10 0x10073e7c in send_php () #11 0x10073f18 in send_parsed_php () #12 0x10015ea4 in ap_invoke_handler () #13 0x1003e0f0 in process_request_internal () #14 0x1003e1b4 in ap_process_request () #15 0x10005d24 in child_main () #16 0x10005f50 in make_child () #17 0x1000618c in startup_children () #18 0x10006a88 in standalone_main () #19 0x100074ec in main () #20 0x1204 in __start () (gdb) Previous Comments: [2002-12-12 13:04:45] [EMAIL PROTECTED] I reconfigured as follows. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap=/oracle/app/oracle/product/8.1.7 --with-apache=/home/mcnicr/apache_1.3.27 --with-debug and recieved the following error message. checking for LDAP support... yes configure: error: Cannot find ldap.h also I recalled that I have read of the Oracle LDAP issue and I tried compiling without Oracle or Sybase support and still failed on ldap_open. I will try again with only LDAP support after doing a make distclean and reconfigure. I'm using openldap 2.0.27. Is there something else I need to do to use the Oracle LDAP client to get rid of the above message ? Thanks, Craig [2002-12-12 11:48:03] [EMAIL PROTECTED] Try compiling PHP with --with-ldap=/oracle/app/oracle/product/8.1.7 (oracle has it's own ldap stuff in there..) [2002-12-12 11:33:29] [EMAIL PROTECTED] I have compiled 4.2.3 into my apache 1.3.27 executable with the following options. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap --with-apache=/home/mcnicr/apache_1.3.27 --with-debug ./configure --activate-module=src/modules/php4/libphp4.a --enable-module=rewrite --enable-module=headers --enable-module=so --prefix=/www-home Using the example code from the below mentioned web URL configured for our local LDAP server (MS exchange 5.5). http://www.php.net/manual/en/ref.ldap.php I get a segmentation fault everytime the ldap_open call is executed. I have enclosed the backtrace and any assistance would be greatly appreciated. Thanks Craig (gdb) bt #0 0x10003d2c in sig_coredump () #1 #2 0xd36ed048 in ber_strdup () at memory.c:541 #3 0xd37000e0 in ldap_pvt_get_fqdn (name=0x60017e05 ) at util-int.c:410 #4 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x) at init.c:483 #5 0xd36f6b40 in ldap_create (ldp=0x2ff20418) at open.c:94 #6 0xd36f6d6c in ldap_initialize (ldp=0x2ff20474, url=0x200bcc38 ) at open.c:192 #7 0x10170da8 in floatcheck () #8 0x1009018c in execute () #9 0x1007e9b8 in zend_execute_scripts () #10 0x10077728 in php_execute_script () #11 0x101792c0 in read_common () #12 0x10073e7c in send_php () #13 0x10073f18 in send_parsed_php () #14 0x10015ea4 in ap_invoke_handler () #15 0x1003e0f0 in process_request_internal () #16 0x1003e1b4 in ap_process_request () #17 0x10005d24 in child_main () #18 0x10006074 in make_child () #19 0x1000653c in perform_idle_server_maintenance () #20 0x10006cd4 in standalone_main () #21 0x100074ec in main () #22 0x1204 in __start () -- Edit this bug report at http://bugs.php.net/?id=20967&edit=1
#20965 [Bgs->Opn]: Urgent - Users getting same session id?
ID: 20965 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: Linux -PHP Version: 4.2.1 +PHP Version: 4.2.3 New Comment: I am running PHP version 4.2.3. Previous Comments: [2002-12-12 11:15:06] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-12-12 10:38:30] [EMAIL PROTECTED] php session some times share the same session id with different users and this allows users to access another user's login and account info.. This is a serious security threat! Pls help. -- Edit this bug report at http://bugs.php.net/?id=20965&edit=1
#20960 [Opn->]: Checkdate very illogical
ID: 20960 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.3 New Comment: Nobody said Americans are logical people :). But there's no way this can be changed and not break a lot of scripts in the real world. Just get used to it. Previous Comments: [2002-12-12 09:43:22] [EMAIL PROTECTED] I' ve just spent several wasted hours looking for a blindingly obvious problem. Checkdate takes it's params in a very illogical way ie checkdate ( int month, int day, int year) Surely it should be checkdate ( int day, int month, int year) or even checkdate ( int year, int month, int day) why on earth month day year ? -- Edit this bug report at http://bugs.php.net/?id=20960&edit=1
#20967 [Fbk->Opn]: LDAP_OPEN causes Segmentation Violation
ID: 20967 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: I reconfigured as follows. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap=/oracle/app/oracle/product/8.1.7 --with-apache=/home/mcnicr/apache_1.3.27 --with-debug and recieved the following error message. checking for LDAP support... yes configure: error: Cannot find ldap.h also I recalled that I have read of the Oracle LDAP issue and I tried compiling without Oracle or Sybase support and still failed on ldap_open. I will try again with only LDAP support after doing a make distclean and reconfigure. I'm using openldap 2.0.27. Is there something else I need to do to use the Oracle LDAP client to get rid of the above message ? Thanks, Craig Previous Comments: [2002-12-12 11:48:03] [EMAIL PROTECTED] Try compiling PHP with --with-ldap=/oracle/app/oracle/product/8.1.7 (oracle has it's own ldap stuff in there..) [2002-12-12 11:33:29] [EMAIL PROTECTED] I have compiled 4.2.3 into my apache 1.3.27 executable with the following options. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap --with-apache=/home/mcnicr/apache_1.3.27 --with-debug ./configure --activate-module=src/modules/php4/libphp4.a --enable-module=rewrite --enable-module=headers --enable-module=so --prefix=/www-home Using the example code from the below mentioned web URL configured for our local LDAP server (MS exchange 5.5). http://www.php.net/manual/en/ref.ldap.php I get a segmentation fault everytime the ldap_open call is executed. I have enclosed the backtrace and any assistance would be greatly appreciated. Thanks Craig (gdb) bt #0 0x10003d2c in sig_coredump () #1 #2 0xd36ed048 in ber_strdup () at memory.c:541 #3 0xd37000e0 in ldap_pvt_get_fqdn (name=0x60017e05 ) at util-int.c:410 #4 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x) at init.c:483 #5 0xd36f6b40 in ldap_create (ldp=0x2ff20418) at open.c:94 #6 0xd36f6d6c in ldap_initialize (ldp=0x2ff20474, url=0x200bcc38 ) at open.c:192 #7 0x10170da8 in floatcheck () #8 0x1009018c in execute () #9 0x1007e9b8 in zend_execute_scripts () #10 0x10077728 in php_execute_script () #11 0x101792c0 in read_common () #12 0x10073e7c in send_php () #13 0x10073f18 in send_parsed_php () #14 0x10015ea4 in ap_invoke_handler () #15 0x1003e0f0 in process_request_internal () #16 0x1003e1b4 in ap_process_request () #17 0x10005d24 in child_main () #18 0x10006074 in make_child () #19 0x1000653c in perform_idle_server_maintenance () #20 0x10006cd4 in standalone_main () #21 0x100074ec in main () #22 0x1204 in __start () -- Edit this bug report at http://bugs.php.net/?id=20967&edit=1
#20969 [NEW]: Bitwise NOT (~): wrong results on Linux
From: [EMAIL PROTECTED] Operating system: i386 Redhat Linux PHP version: 4.2.2 PHP Bug Type: *Math Functions Bug description: Bitwise NOT (~): wrong results on Linux The Bitwise NOT operator ~ doesn't fuinction correctly on the Linux system. Examples: ~-22 = 2147483647 ~4180982798 = 2147483647 But on a Windows 2000 Server it functions well: ~-22 = -2072745075 ~4180982798 = 113984497 On both systems PHP 4.2.2 is used. If that's a "feature" then PHP is not usable for any bitwise operation. -- Edit bug report at http://bugs.php.net/?id=20969&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20969&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20969&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20969&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20969&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20969&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20969&r=support Expected behavior: http://bugs.php.net/fix.php?id=20969&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20969&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20969&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20969&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20969&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20969&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20969&r=isapi
#20968 [Fbk->Opn]: Session rewriter misses a case
ID: 20968 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: The cvs behaves differently but still the same error str += ""; It doesnt put quotes around the reptoc but it still puts bad quotes around the type="hidden" and others. Charles Previous Comments: [2002-12-12 11:49:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 11:42:10] [EMAIL PROTECTED] Whe html is written with javascript and trans sid is used, The javascript may get messed up. ie str += "
#20968 [Opn->Fbk]: Session rewriter misses a case
ID: 20968 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 11:42:10] [EMAIL PROTECTED] Whe html is written with javascript and trans sid is used, The javascript may get messed up. ie str += "
#20967 [Opn->Fbk]: LDAP_OPEN causes Segmentation Violation
ID: 20967 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: LDAP related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Try compiling PHP with --with-ldap=/oracle/app/oracle/product/8.1.7 (oracle has it's own ldap stuff in there..) Previous Comments: [2002-12-12 11:33:29] [EMAIL PROTECTED] I have compiled 4.2.3 into my apache 1.3.27 executable with the following options. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap --with-apache=/home/mcnicr/apache_1.3.27 --with-debug ./configure --activate-module=src/modules/php4/libphp4.a --enable-module=rewrite --enable-module=headers --enable-module=so --prefix=/www-home Using the example code from the below mentioned web URL configured for our local LDAP server (MS exchange 5.5). http://www.php.net/manual/en/ref.ldap.php I get a segmentation fault everytime the ldap_open call is executed. I have enclosed the backtrace and any assistance would be greatly appreciated. Thanks Craig (gdb) bt #0 0x10003d2c in sig_coredump () #1 #2 0xd36ed048 in ber_strdup () at memory.c:541 #3 0xd37000e0 in ldap_pvt_get_fqdn (name=0x60017e05 ) at util-int.c:410 #4 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x) at init.c:483 #5 0xd36f6b40 in ldap_create (ldp=0x2ff20418) at open.c:94 #6 0xd36f6d6c in ldap_initialize (ldp=0x2ff20474, url=0x200bcc38 ) at open.c:192 #7 0x10170da8 in floatcheck () #8 0x1009018c in execute () #9 0x1007e9b8 in zend_execute_scripts () #10 0x10077728 in php_execute_script () #11 0x101792c0 in read_common () #12 0x10073e7c in send_php () #13 0x10073f18 in send_parsed_php () #14 0x10015ea4 in ap_invoke_handler () #15 0x1003e0f0 in process_request_internal () #16 0x1003e1b4 in ap_process_request () #17 0x10005d24 in child_main () #18 0x10006074 in make_child () #19 0x1000653c in perform_idle_server_maintenance () #20 0x10006cd4 in standalone_main () #21 0x100074ec in main () #22 0x1204 in __start () -- Edit this bug report at http://bugs.php.net/?id=20967&edit=1
#16989 [Com]: Could not find/open font...
ID: 16989 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: GD related Operating System: WinNT PHP Version: 4.2.0 New Comment: I had the same problem and solved it using the path to the windows font folder (c:/WINDOWS/Fonts/arial.ttf). Strange isn't it ?? Arnaud Previous Comments: [2002-05-16 19:01:02] [EMAIL PROTECTED] See the last comment on http://bugs.php.net/bug.php?id=17192 [2002-05-16 18:39:37] [EMAIL PROTECTED] Same again in 4.2.1 Have tried all sorts of different methods to access font file name - including c:/, c:\ /, \ - also using realname() which was suggested on some mailing list somewhere. Win2K, Apache 1.3.24, GD2 Matt [2002-05-03 06:51:54] [EMAIL PROTECTED] Oops? php_gd2.dll brings out 'Could not find/open font...' on $array = @ImageTTFBBox($size,0,$font,$textstring). [$font is a ttf-file in the same directory9 php_gd.dll works fine with SAME configuration... Probably a bug in the [Win32]GD2? greets, Lars -- Edit this bug report at http://bugs.php.net/?id=16989&edit=1
#20924 [Com]: Functions inside declare(ticks=1) cannot be used prior to definition
ID: 20924
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.7-10
PHP Version: 4.3.0RC2
New Comment:
I just upgraded to version 4.3.0RC3 with the same
configure command, but the script gives the same message
as in the original posting.
This behavior is rather annoying, but a workaround is to
declare the troublesome procedure *outside* the scope of
the 'declare(ticks=1) {}' block. However, this does not
seem to help if the new syntax 'declare(ticks=1);' is used
to cover the entire script under the declare() scope.
Alex Villacis Lasso
[EMAIL PROTECTED]
Previous Comments:
[2002-12-10 13:38:41] [EMAIL PROTECTED]
My configuration (as reported by phpinfo()):
./configure --with-apxs=/opt/httpd/bin/apxs
--with-mysql=/usr --with-gd
--with-curl=/opt/curl-7.10.1/
--with-pdflib=/opt/pdflib/
--with-zlib --enable-inline-optimizations
--enable-pcntl --enable-dio --with-ncurses
--enable-sockets
What I did (filename 'ticks_bug_php'):
--- CUT HERE
#!/usr/local/bin/php
--- CUT HERE
What I expected:
[avillaci@srv64 practica]$ ./ticks_bug_php
Inside predefined_out()
Inside postdefined_out()
Inside predefined_in()
Inside postdefined_in()
[avillaci@srv64 practica]$
What I got instead:
[avillaci@srv64 practica]$ ./ticks_bug_php
Inside predefined_out()
Inside postdefined_out()
Inside predefined_in()
Fatal error: Call to undefined function: postdefined_in()
in /home/avillaci/programa/practica/ticks_bug_php on line
25
[avillaci@srv64 practica]$
PHP refuses to call postdefined_in() before its definition
inside the scope of 'declare(ticks=1){}', but has no problem
calling postdefined_out() before its definition, outside
the scope of 'declare(ticks=1){}'.
Any hints in solving this issue will be greatly appreciated.
Alex Villacis Lasso
[EMAIL PROTECTED]
--
Edit this bug report at http://bugs.php.net/?id=20924&edit=1
#20964 [Opn->Fbk]: Error when open timestamp field using sybase function
ID: 20964 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Windows PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2002-12-12 11:31:51] [EMAIL PROTECTED] I get http://snaps.php.net/win32/php4-win32-latest.zip but my problem with me :) [2002-12-12 11:14:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 10:37:28] [EMAIL PROTECTED] I have in db 2001-01-01 00:00:00.000 and in PHP i get "1 ‘_ç 2001 0:00" -- Edit this bug report at http://bugs.php.net/?id=20964&edit=1
#20968 [NEW]: Session rewriter misses a case
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.3 PHP Bug Type: Session related Bug description: Session rewriter misses a case Whe html is written with javascript and trans sid is used, The javascript may get messed up. ie str += "
#15209 [Ver]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
ID: 15209
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Scripting Engine problem
Operating System: RH Linux 7.2
PHP Version: 4.3.0-dev
New Comment:
I gave up on my patch. Too much work, not enought time, and
ultimately, I couldn't find a place in PHP land where PHP was still
running and Apache had closed the connection to put my hooks in. There
may be a way to tell Apache to close the connection through SAPI, but I
am not aware of it. (I'm not an apache hacker). Someone posted a way
to fork a process to the background, but it isn't a PHP land solution.
>From Carsten Gehling:
Maybe this is what you need?
http://www.naken.cc/mikehup.php
I use this on a CMS site, where the users upload imagefiles with ftp.
After
that, they use a php webinterface to start an importscript (written in
Perl). By doing this command in php:
system("/usr/local/bin/mikehup /usr/bin/perl
/www/servers/netlag/cronscripts/import_billede.pl &");
The importscript is started and executes in the background while the
php-script finishes execution.
Hope that helps
- Carsten
Previous Comments:
[2002-12-12 10:06:43] [EMAIL PROTECTED]
I copy my mail sent to the dev list here too, to make it more
noticable:
I know there was some hot discussion about this topic but I really need
to
get
this bug fixed. Even I'll make a patch with my zero knowledge of c if
no one
would like to make it, but please try to find a reasonable sollution
that
fits (almost) everyone's need.
I thought of one. I think a new function with the name
register_apache_shutdown_function (or somethink like this) might be
good.
It's name would say that it only works in apache, it could be
documented
that
it's the *only* function that closes the connection before the
registered
functions are handled. Or maybe a parameter could tell if the
connection
should be closed before the first registered function is started.
I'll hope there's some way to solve this problem, because it's not easy
to
tell every customer to use our patch (or use 4.0.6) before they are
staring
to use our programs that rely on this forgotten feature.
Thanks,
Arpi
[2002-12-11 08:30:38] [EMAIL PROTECTED]
Changing to 'Verified', since there is some disagreement on how this
function should operate.
[2002-10-12 10:21:46] [EMAIL PROTECTED]
Marking as critical since this worked at some point.
And there was also posting by [EMAIL PROTECTED] with a possible
fix on [EMAIL PROTECTED]
[2002-10-04 07:44:12] [EMAIL PROTECTED]
I grabbed a snapshot today (php4-200210040300). I jtate's script, and
still got the erroneous (IMO) behavior. My connection to the server
did not close until the shutdown function completed.
Looking at the suspect section of sapi_apache.c, I do not see any
changes. Not that I expected to see my patch verbatim, but I would
expect something in that vicinity to change.
[2002-10-02 10:33:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
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/15209
--
Edit this bug report at http://bugs.php.net/?id=15209&edit=1
#20967 [NEW]: LDAP_OPEN causes Segmentation Violation
From: [EMAIL PROTECTED] Operating system: AIX 4.3.3 PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: LDAP_OPEN causes Segmentation Violation I have compiled 4.2.3 into my apache 1.3.27 executable with the following options. ./configure --with-oci8=/oracle/app/oracle/product/8.1.7 --with-sybase=/sybase/v11.5.1 --with-ldap --with-apache=/home/mcnicr/apache_1.3.27 --with-debug ./configure --activate-module=src/modules/php4/libphp4.a --enable-module=rewrite --enable-module=headers --enable-module=so --prefix=/www-home Using the example code from the below mentioned web URL configured for our local LDAP server (MS exchange 5.5). http://www.php.net/manual/en/ref.ldap.php I get a segmentation fault everytime the ldap_open call is executed. I have enclosed the backtrace and any assistance would be greatly appreciated. Thanks Craig (gdb) bt #0 0x10003d2c in sig_coredump () #1 #2 0xd36ed048 in ber_strdup () at memory.c:541 #3 0xd37000e0 in ldap_pvt_get_fqdn (name=0x60017e05 ) at util-int.c:410 #4 0xd36ecddc in ldap_int_initialize (gopts=0xf0497958, dbglvl=0x) at init.c:483 #5 0xd36f6b40 in ldap_create (ldp=0x2ff20418) at open.c:94 #6 0xd36f6d6c in ldap_initialize (ldp=0x2ff20474, url=0x200bcc38 ) at open.c:192 #7 0x10170da8 in floatcheck () #8 0x1009018c in execute () #9 0x1007e9b8 in zend_execute_scripts () #10 0x10077728 in php_execute_script () #11 0x101792c0 in read_common () #12 0x10073e7c in send_php () #13 0x10073f18 in send_parsed_php () #14 0x10015ea4 in ap_invoke_handler () #15 0x1003e0f0 in process_request_internal () #16 0x1003e1b4 in ap_process_request () #17 0x10005d24 in child_main () #18 0x10006074 in make_child () #19 0x1000653c in perform_idle_server_maintenance () #20 0x10006cd4 in standalone_main () #21 0x100074ec in main () #22 0x1204 in __start () -- Edit bug report at http://bugs.php.net/?id=20967&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20967&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20967&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20967&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20967&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20967&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20967&r=support Expected behavior: http://bugs.php.net/fix.php?id=20967&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20967&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20967&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20967&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20967&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20967&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20967&r=isapi
#20964 [Fbk->Opn]: Error when open timestamp field using sybase function
ID: 20964 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Windows PHP Version: 4.2.3 New Comment: I get http://snaps.php.net/win32/php4-win32-latest.zip but my problem with me :) Previous Comments: [2002-12-12 11:14:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 10:37:28] [EMAIL PROTECTED] I have in db 2001-01-01 00:00:00.000 and in PHP i get "1 ‘_ç 2001 0:00" -- Edit this bug report at http://bugs.php.net/?id=20964&edit=1
#20953 [Opn->Fbk]: error when combing ?: and return by reference
ID: 20953 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows NT 5.1 build 2600 PHP Version: 4.4.0-dev New Comment: Just curious..exactly what practical use has this?? Could you give us some real world example instead..? Previous Comments: [2002-12-12 09:11:51] [EMAIL PROTECTED] I tried it - it does not work as well. [2002-12-12 05:52:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 04:29:28] [EMAIL PROTECTED] let the sample code say the problem '1'); $arr_bad =& Ref_Bad($arr); $arr_good =& Ref_Good($arr); $arr_bad['b'] = 2; $arr_good['c'] = 3; print_r($arr); ?> required result: Array ( [a] => 1 [b] => 2 [c] => 3 ) current result: Array ( [a] => 1 [c] => 3 ) -- Edit this bug report at http://bugs.php.net/?id=20953&edit=1
#20954 [Opn->Fbk]: Serious problem , unknown reason
ID: 20954 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: Try Apache 1.3.27..apache 2 is not ready for production.. Previous Comments: [2002-12-12 11:00:49] [EMAIL PROTECTED] More...If I access the page at the server, everything are fine, however, those alien words will only appears when I use other computers or through proxy to access it. [2002-12-12 10:36:19] [EMAIL PROTECTED] I try not to use sapi with php4apache2.dll if I use php.exe ---> same Error very interesting that if I use php-cgi.exe All are fine. [2002-12-12 07:37:28] [EMAIL PROTECTED] 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 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. It's segfaulting, better get that off, or Windows XP will be Windows ExPired pretty soon. [2002-12-12 05:45:52] [EMAIL PROTECTED] te apache version should 2.0.43 [2002-12-12 05:41:20] [EMAIL PROTECTED] I have install the newest version of apache 2 (should be 2.0.49) and 4.3.0 RC2, I just installed phpbb to test with, it give out a mess, and also the error is not constant, it changes every time I reload the page, it does not report any error code, however, giving out some alien chars, when I trace the code, some of them are showing my harddisk folders, some of them are showing the momery contents, some of them are showing some file contents in my harddisk, terribleevery time I reload the page, every time is different. I don't know much about php, but I use recommended isap settings in apache for running php. please go to have a look on the mess, http://phpbb.attosoft.myftp.org/faq.php -- Edit this bug report at http://bugs.php.net/?id=20954&edit=1
#20965 [Opn->Bgs]: Urgent - Users getting same session id?
ID: 20965 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.2.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2002-12-12 10:38:30] [EMAIL PROTECTED] php session some times share the same session id with different users and this allows users to access another user's login and account info.. This is a serious security threat! Pls help. -- Edit this bug report at http://bugs.php.net/?id=20965&edit=1
#20964 [Opn->Fbk]: Error when open timestamp field using sybase function
ID: 20964 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Windows PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 10:37:28] [EMAIL PROTECTED] I have in db 2001-01-01 00:00:00.000 and in PHP i get "1 ‘_ç 2001 0:00" -- Edit this bug report at http://bugs.php.net/?id=20964&edit=1
#20962 [Opn->Fbk]: ibase_query don't work with varchar character set win1251
ID: 20962 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: win 2000 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 10:14:28] [EMAIL PROTECTED] CREATE TABLE CATEGORIES ( CAT_ID INTEGER NOT NULL, CYR_TEXT VARCHAR (100) character set WIN1251); after executing this code Warning: InterBase: arithmetic exception, numeric overflow, or string truncation Cannot transliterate character between character sets -- Edit this bug report at http://bugs.php.net/?id=20962&edit=1
#20963 [Opn->Bgs]: Files Uploaded Using PHP almost double the size of original
ID: 20963 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Linux Redhat 8.0 PHP Version: 4.2.2 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2002-12-12 10:34:02] [EMAIL PROTECTED] I am trying to create a web-based upload/download center for our users using PHP 4.2.2 / RedHat 7.3 / Apache 2.0.40. All works well except when uploading files larger than approximately 1K. Larger files nearly double in size. For example, using the pages I am developing, a file uploaded from a win2k PC with the correct size of 700,416 bytes nearly doubles after upload to the server to 1,388,544 bytes. The file is then, of course, corrupted. This happens with all types of files (TXT, DOC, MDB, XLS, ZIP, etc). To check webserver/network functionality, I created a PERL 5.8.0 CGI script on the same webserver and uploaded the same file from the same win2k machine and file uploading works perfectly. No file size change or corruptions at all. Obviously, extra characters are being inserted somehow in the stream when using PHP, but from where and when I don't know. It may also be some type of improper CR/LF conversion during upload. I was even looking at the Character Sets defined in Apache, but the PERL 5.8.0 CGI script works correctly. Improper character translations by the Apache webserver should corrupt both PERL and PHP versions of the uploaded files shouldn't they? I am lost at this point. All help is greatly appreciated. Thanks. ## PHP Compiled Modules Running PHP 4.2.2 Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies [PHP Modules] yp xml wddx sysvshm sysvsem standard sockets shmop session pspell posix pcre openssl ncurses iconv gmp gettext gd ftp exif domxml dio dbx dba curl ctype calendar bz2 bcmath zlib [Zend Modules] ## END PHP Compiled Modules ## Apache Compiled Modules Compiled in modules: core.c prefork.c http_core.c mod_so.c ## END Apache Compiled Modules NOTE: PHP compiled as dynamic module -- Edit this bug report at http://bugs.php.net/?id=20963&edit=1
#20954 [Opn]: Serious problem , unknown reason
ID: 20954 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: More...If I access the page at the server, everything are fine, however, those alien words will only appears when I use other computers or through proxy to access it. Previous Comments: [2002-12-12 10:36:19] [EMAIL PROTECTED] I try not to use sapi with php4apache2.dll if I use php.exe ---> same Error very interesting that if I use php-cgi.exe All are fine. [2002-12-12 07:37:28] [EMAIL PROTECTED] 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 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. It's segfaulting, better get that off, or Windows XP will be Windows ExPired pretty soon. [2002-12-12 05:45:52] [EMAIL PROTECTED] te apache version should 2.0.43 [2002-12-12 05:41:20] [EMAIL PROTECTED] I have install the newest version of apache 2 (should be 2.0.49) and 4.3.0 RC2, I just installed phpbb to test with, it give out a mess, and also the error is not constant, it changes every time I reload the page, it does not report any error code, however, giving out some alien chars, when I trace the code, some of them are showing my harddisk folders, some of them are showing the momery contents, some of them are showing some file contents in my harddisk, terribleevery time I reload the page, every time is different. I don't know much about php, but I use recommended isap settings in apache for running php. please go to have a look on the mess, http://phpbb.attosoft.myftp.org/faq.php -- Edit this bug report at http://bugs.php.net/?id=20954&edit=1
#17606 [Csd]: File upload fails on large files
ID: 17606 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating System: RedHat 7.3 PHP Version: 4.2.1 New Comment: If want you can send me your php.ini to check if any variable is left to a default, otherway we are in a dead end; but believe me I been running my upload scripts in 3 diferent machines (2 Redhat, 1 Suse) and I have had no trouble with it. Also you can send me if you want your upload script. Previous Comments: [2002-12-12 10:35:37] [EMAIL PROTECTED] 1. The upload script is also identical on both machines and does not override any settings 2. There's some diff's in the conf files - but only around hostname etc. I actually ran one box as the other just to check (i.e. swapped httpd.conf and php.ini) 3. Not sure what command to run to check this? 4. php.ini is root.root 744 (i.e. -rw-r--r--) and is definitely being read (changing variables, restarting apache and then running phpinfo() script shows the changes) [2002-12-12 09:12:40] [EMAIL PROTECTED] It is very strange, I have been working OK uploading big files, also with the version you are using. I can only advice you 3 things more to check. 1.- Check that you dont override tmp dir and upload max file size on the script or includes of your problem machine. 2.- Diff the config files (you have already done this as you can swap them between machines) 3.- Check which files the httpd process and its children are using while uploading to see where it is stored tmp. 4.- Check that php.ini is readable. [2002-12-12 08:42:29] [EMAIL PROTECTED] One php.ini file in /usr/local/lib. Been through all that - removed all previous (redhat standard install) incarnations of php. Doing a line by line comparison on the two boxes using phpinfo() shows they are configured identically also. The one box will just not write to the upload_tmp_dir, even when I chmod that directory to 777. I've changed the apache user and group thinking it may have been a wierd permissions problem. Not much memory in the box, but it doesn't fill up and swap is basically unused. [2002-12-12 03:28:26] [EMAIL PROTECTED] Are you sure that both machines are using the equal compiled php version?, please double check with locate how many php.ini files do you have on the problem machine and to which is your php pointing at. [2002-12-11 14:29:44] [EMAIL PROTECTED] I think you closed this "bug" prematurely! I have two very similar machines - both running PHP 4.2.3 and apache 1.3.26 on Redhat Linux 2.4.7-10 (7.1). I have an upload script and can upload ANY size file to one machine, but am limited to about 9mb on the other box. The php.ini and httpd.conf files are identical (actually, I swapped them over just for the hell of it). I've even swapped the libphp4.so files in the apache libexec directory, between boxes! If this isn't a bug, why does the upload work flawlessly on one machine, but not the other? It will not write to the /tmp directory (or any directory, no matter what I set upload_tmp_dir to) on the one box, but does on the other. Permissions and apache user/group are identical across boxes. It has me stumped! It should either work on both, or neither! 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/17606 -- Edit this bug report at http://bugs.php.net/?id=17606&edit=1
#20965 [NEW]: Urgent - Users getting same session id?
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.1 PHP Bug Type: Session related Bug description: Urgent - Users getting same session id? php session some times share the same session id with different users and this allows users to access another user's login and account info.. This is a serious security threat! Pls help. -- Edit bug report at http://bugs.php.net/?id=20965&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20965&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20965&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20965&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20965&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20965&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20965&r=support Expected behavior: http://bugs.php.net/fix.php?id=20965&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20965&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20965&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20965&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20965&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20965&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20965&r=isapi
#20964 [NEW]: Error when open timestamp field using sybase function
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.3 PHP Bug Type: MSSQL related Bug description: Error when open timestamp field using sybase function I have in db 2001-01-01 00:00:00.000 and in PHP i get "1 ‘_ç 2001 0:00" -- Edit bug report at http://bugs.php.net/?id=20964&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20964&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20964&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20964&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20964&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20964&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20964&r=support Expected behavior: http://bugs.php.net/fix.php?id=20964&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20964&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20964&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20964&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20964&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20964&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20964&r=isapi
#20954 [Fbk->Opn]: Serious problem , unknown reason
ID: 20954 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: I try not to use sapi with php4apache2.dll if I use php.exe ---> same Error very interesting that if I use php-cgi.exe All are fine. Previous Comments: [2002-12-12 07:37:28] [EMAIL PROTECTED] 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 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. It's segfaulting, better get that off, or Windows XP will be Windows ExPired pretty soon. [2002-12-12 05:45:52] [EMAIL PROTECTED] te apache version should 2.0.43 [2002-12-12 05:41:20] [EMAIL PROTECTED] I have install the newest version of apache 2 (should be 2.0.49) and 4.3.0 RC2, I just installed phpbb to test with, it give out a mess, and also the error is not constant, it changes every time I reload the page, it does not report any error code, however, giving out some alien chars, when I trace the code, some of them are showing my harddisk folders, some of them are showing the momery contents, some of them are showing some file contents in my harddisk, terribleevery time I reload the page, every time is different. I don't know much about php, but I use recommended isap settings in apache for running php. please go to have a look on the mess, http://phpbb.attosoft.myftp.org/faq.php -- Edit this bug report at http://bugs.php.net/?id=20954&edit=1
#17606 [Com]: File upload fails on large files
ID: 17606 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating System: RedHat 7.3 PHP Version: 4.2.1 New Comment: 1. The upload script is also identical on both machines and does not override any settings 2. There's some diff's in the conf files - but only around hostname etc. I actually ran one box as the other just to check (i.e. swapped httpd.conf and php.ini) 3. Not sure what command to run to check this? 4. php.ini is root.root 744 (i.e. -rw-r--r--) and is definitely being read (changing variables, restarting apache and then running phpinfo() script shows the changes) Previous Comments: [2002-12-12 09:12:40] [EMAIL PROTECTED] It is very strange, I have been working OK uploading big files, also with the version you are using. I can only advice you 3 things more to check. 1.- Check that you dont override tmp dir and upload max file size on the script or includes of your problem machine. 2.- Diff the config files (you have already done this as you can swap them between machines) 3.- Check which files the httpd process and its children are using while uploading to see where it is stored tmp. 4.- Check that php.ini is readable. [2002-12-12 08:42:29] [EMAIL PROTECTED] One php.ini file in /usr/local/lib. Been through all that - removed all previous (redhat standard install) incarnations of php. Doing a line by line comparison on the two boxes using phpinfo() shows they are configured identically also. The one box will just not write to the upload_tmp_dir, even when I chmod that directory to 777. I've changed the apache user and group thinking it may have been a wierd permissions problem. Not much memory in the box, but it doesn't fill up and swap is basically unused. [2002-12-12 03:28:26] [EMAIL PROTECTED] Are you sure that both machines are using the equal compiled php version?, please double check with locate how many php.ini files do you have on the problem machine and to which is your php pointing at. [2002-12-11 14:29:44] [EMAIL PROTECTED] I think you closed this "bug" prematurely! I have two very similar machines - both running PHP 4.2.3 and apache 1.3.26 on Redhat Linux 2.4.7-10 (7.1). I have an upload script and can upload ANY size file to one machine, but am limited to about 9mb on the other box. The php.ini and httpd.conf files are identical (actually, I swapped them over just for the hell of it). I've even swapped the libphp4.so files in the apache libexec directory, between boxes! If this isn't a bug, why does the upload work flawlessly on one machine, but not the other? It will not write to the /tmp directory (or any directory, no matter what I set upload_tmp_dir to) on the one box, but does on the other. Permissions and apache user/group are identical across boxes. It has me stumped! It should either work on both, or neither! [2002-06-10 03:24:45] [EMAIL PROTECTED] Well, I have been doing more tests and it seems that the system memory that is being used is for the catching of the filesystem. I dont know if it is a good thing that so many memory is eaten just for file catching but this is an operating system issue and not php related bug so If everyone agrees I close the bug. Regarding last message from [EMAIL PROTECTED], did you double check the values for the php.ini file, related with post and file uploading? Remenber that post limit should be at least filesize+size of php script. memory_limit = ?? post_max_size = ?? file_uploads = On upload_max_filesize = ?? allow_url_fopen = On 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/17606 -- Edit this bug report at http://bugs.php.net/?id=17606&edit=1
#20963 [NEW]: Files Uploaded Using PHP almost double the size of original
From: [EMAIL PROTECTED] Operating system: Linux Redhat 8.0 PHP version: 4.2.2 PHP Bug Type: Filesystem function related Bug description: Files Uploaded Using PHP almost double the size of original I am trying to create a web-based upload/download center for our users using PHP 4.2.2 / RedHat 7.3 / Apache 2.0.40. All works well except when uploading files larger than approximately 1K. Larger files nearly double in size. For example, using the pages I am developing, a file uploaded from a win2k PC with the correct size of 700,416 bytes nearly doubles after upload to the server to 1,388,544 bytes. The file is then, of course, corrupted. This happens with all types of files (TXT, DOC, MDB, XLS, ZIP, etc). To check webserver/network functionality, I created a PERL 5.8.0 CGI script on the same webserver and uploaded the same file from the same win2k machine and file uploading works perfectly. No file size change or corruptions at all. Obviously, extra characters are being inserted somehow in the stream when using PHP, but from where and when I don't know. It may also be some type of improper CR/LF conversion during upload. I was even looking at the Character Sets defined in Apache, but the PERL 5.8.0 CGI script works correctly. Improper character translations by the Apache webserver should corrupt both PERL and PHP versions of the uploaded files shouldn't they? I am lost at this point. All help is greatly appreciated. Thanks. ## PHP Compiled Modules Running PHP 4.2.2 Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies [PHP Modules] yp xml wddx sysvshm sysvsem standard sockets shmop session pspell posix pcre openssl ncurses iconv gmp gettext gd ftp exif domxml dio dbx dba curl ctype calendar bz2 bcmath zlib [Zend Modules] ## END PHP Compiled Modules ## Apache Compiled Modules Compiled in modules: core.c prefork.c http_core.c mod_so.c ## END Apache Compiled Modules NOTE: PHP compiled as dynamic module -- Edit bug report at http://bugs.php.net/?id=20963&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20963&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20963&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20963&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20963&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20963&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20963&r=support Expected behavior: http://bugs.php.net/fix.php?id=20963&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20963&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20963&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20963&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20963&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20963&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20963&r=isapi
#20962 [NEW]: ibase_query don't work with varchar character set win1251
From: [EMAIL PROTECTED] Operating system: win 2000 PHP version: 4.2.3 PHP Bug Type: InterBase related Bug description: ibase_query don't work with varchar character set win1251 CREATE TABLE CATEGORIES ( CAT_ID INTEGER NOT NULL, CYR_TEXT VARCHAR (100) character set WIN1251); after executing this code Warning: InterBase: arithmetic exception, numeric overflow, or string truncation Cannot transliterate character between character sets -- Edit bug report at http://bugs.php.net/?id=20962&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20962&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20962&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20962&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20962&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20962&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20962&r=support Expected behavior: http://bugs.php.net/fix.php?id=20962&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20962&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20962&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20962&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20962&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20962&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20962&r=isapi
#15209 [Com]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
ID: 15209 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Scripting Engine problem Operating System: RH Linux 7.2 PHP Version: 4.3.0-dev New Comment: I copy my mail sent to the dev list here too, to make it more noticable: I know there was some hot discussion about this topic but I really need to get this bug fixed. Even I'll make a patch with my zero knowledge of c if no one would like to make it, but please try to find a reasonable sollution that fits (almost) everyone's need. I thought of one. I think a new function with the name register_apache_shutdown_function (or somethink like this) might be good. It's name would say that it only works in apache, it could be documented that it's the *only* function that closes the connection before the registered functions are handled. Or maybe a parameter could tell if the connection should be closed before the first registered function is started. I'll hope there's some way to solve this problem, because it's not easy to tell every customer to use our patch (or use 4.0.6) before they are staring to use our programs that rely on this forgotten feature. Thanks, Arpi Previous Comments: [2002-12-11 08:30:38] [EMAIL PROTECTED] Changing to 'Verified', since there is some disagreement on how this function should operate. [2002-10-12 10:21:46] [EMAIL PROTECTED] Marking as critical since this worked at some point. And there was also posting by [EMAIL PROTECTED] with a possible fix on [EMAIL PROTECTED] [2002-10-04 07:44:12] [EMAIL PROTECTED] I grabbed a snapshot today (php4-200210040300). I jtate's script, and still got the erroneous (IMO) behavior. My connection to the server did not close until the shutdown function completed. Looking at the suspect section of sapi_apache.c, I do not see any changes. Not that I expected to see my patch verbatim, but I would expect something in that vicinity to change. [2002-10-02 10:33:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-02 09:35:00] [EMAIL PROTECTED] Is this really a dupe of 14251? Maybe they involve some of the same code, but these are really two different issues. 14251 involves the fact that the shutdown function code gets a different working directory. 15209 concerns whether the shutdown function runs before or after the HTTP connection is closed. 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/15209 -- Edit this bug report at http://bugs.php.net/?id=15209&edit=1
#20961 [Opn->Fbk]: session_decode causes the script to crash
ID: 20961
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux/Windows
PHP Version: 4.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Previous Comments:
[2002-12-12 09:53:01] [EMAIL PROTECTED]
function get_session_decode($sessStr)
{
if ($sessStr) {
session_decode($sessStr);
unset($sessStr);
$vars = get_defined_vars();
return $vars;
} //if
} //func
The following function should return an array of session variables:
function get_session_decode($sessStr)
{
if ($sessStr) {
session_decode($sessStr);
unset($sessStr);
$vars = get_defined_vars();
return $vars;
} //if
} //func
print_r(get_session_decode('TEST|s:7:"testing";'));
however session_decode always crashes when you pass it a valid session
string. It does not crash if you pass it an invalid session string or
an empty/false string. I tried using the function by it self, but it
still crashes. No sessions where created at the time (which SHOULD NOT
be needed).
If you call session_start() first, it does not crash, but does not set
any variables.
--
Edit this bug report at http://bugs.php.net/?id=20961&edit=1
#20961 [NEW]: session_decode causes the script to crash
From: [EMAIL PROTECTED]
Operating system: Linux/Windows
PHP version: 4.2.3
PHP Bug Type: Reproducible crash
Bug description: session_decode causes the script to crash
function get_session_decode($sessStr)
{
if ($sessStr) {
session_decode($sessStr);
unset($sessStr);
$vars = get_defined_vars();
return $vars;
} //if
} //func
The following function should return an array of session variables:
function get_session_decode($sessStr)
{
if ($sessStr) {
session_decode($sessStr);
unset($sessStr);
$vars = get_defined_vars();
return $vars;
} //if
} //func
print_r(get_session_decode('TEST|s:7:"testing";'));
however session_decode always crashes when you pass it a valid session
string. It does not crash if you pass it an invalid session string or an
empty/false string. I tried using the function by it self, but it still
crashes. No sessions where created at the time (which SHOULD NOT be
needed).
If you call session_start() first, it does not crash, but does not set any
variables.
--
Edit bug report at http://bugs.php.net/?id=20961&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20961&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20961&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20961&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20961&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20961&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20961&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20961&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20961&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20961&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20961&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20961&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20961&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20961&r=isapi
#20960 [NEW]: Checkdate very illogical
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: Checkdate very illogical I' ve just spent several wasted hours looking for a blindingly obvious problem. Checkdate takes it's params in a very illogical way ie checkdate ( int month, int day, int year) Surely it should be checkdate ( int day, int month, int year) or even checkdate ( int year, int month, int day) why on earth month day year ? -- Edit bug report at http://bugs.php.net/?id=20960&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20960&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20960&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20960&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20960&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20960&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20960&r=support Expected behavior: http://bugs.php.net/fix.php?id=20960&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20960&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20960&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20960&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20960&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20960&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20960&r=isapi
#18600 [Com]: Unable to create Java Virtual Machine
ID: 18600 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Java related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Hi there, I'm confirming Cédric's knowledge - java is running correctly from within PHP on Apache only when PHP is running as a CGI and not as a SAPI module. When running PHP as Apache SAPI Module after the restart Apache only fist access to php page using java is running OK, all next reloads of this page caused "Fatal error: Unable to create Java Virtual Machine in ..." I think this could be still not solved bug. Thanks Alberto BTW I'm running on: OS:Win2000 Server SP2 Apache:1.3.27 PHP Version 4.3.0-dev (Build Date Dec 12 2002 10:14:28) Java version=1.4.1_01 Java vendor=Sun Microsystems Inc. Previous Comments: [2002-12-06 05:06:27] [EMAIL PROTECTED] Hi, using "cgi-bin instead of as a module" hm,isn't this a performance and computer resources issue ? Thx Alberto [2002-12-05 15:15:35] [EMAIL PROTECTED] I had the same bug but after having looking a lot, I find a solution. You just have to configure php as a cgi-bin instead of as a module and it works perfectly. Hoping it will help you to fix the bug in the module. Cédric. [2002-12-04 08:44:52] [EMAIL PROTECTED] Hi, many thanks Sebastian for the response. I've downloaded php4-win32-200212041130.zip from snaps.php.net, but after PHP update Apache didn't start and configuration test detected following problem: Syntax error on line 174 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf: Cannot load C:/PHP/sapi/php4apache2.dll into server: The specified procedure could not be found. httpd.conf has on the line 174: LoadModule php4_module c:/php/sapi/php4apache2.dll Question is what is the recomended version of Win32 Apache2 to work corectly with latest PHP 4.4.x-dev? Thank you, Alberto [2002-12-04 06:20:14] [EMAIL PROTECTED] I tried the php4-win32-STABLE-200212040930 snapshot, but I still got problems with a simple java program (the one in the docs). After some reloads I got a PHP has encountered an Access Violation at 77FCBEE8 After that: Fatal error: Unable to create Java Virtual Machine in c:\inetpub\wwwroot\estatisticos\admin\java.php on line 3 At least the problem occurs only to java applications, not all php pages. Nelio [2002-12-04 02:18:05] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. 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/18600 -- Edit this bug report at http://bugs.php.net/?id=18600&edit=1
#17606 [Csd]: File upload fails on large files
ID: 17606 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating System: RedHat 7.3 PHP Version: 4.2.1 New Comment: It is very strange, I have been working OK uploading big files, also with the version you are using. I can only advice you 3 things more to check. 1.- Check that you dont override tmp dir and upload max file size on the script or includes of your problem machine. 2.- Diff the config files (you have already done this as you can swap them between machines) 3.- Check which files the httpd process and its children are using while uploading to see where it is stored tmp. 4.- Check that php.ini is readable. Previous Comments: [2002-12-12 08:42:29] [EMAIL PROTECTED] One php.ini file in /usr/local/lib. Been through all that - removed all previous (redhat standard install) incarnations of php. Doing a line by line comparison on the two boxes using phpinfo() shows they are configured identically also. The one box will just not write to the upload_tmp_dir, even when I chmod that directory to 777. I've changed the apache user and group thinking it may have been a wierd permissions problem. Not much memory in the box, but it doesn't fill up and swap is basically unused. [2002-12-12 03:28:26] [EMAIL PROTECTED] Are you sure that both machines are using the equal compiled php version?, please double check with locate how many php.ini files do you have on the problem machine and to which is your php pointing at. [2002-12-11 14:29:44] [EMAIL PROTECTED] I think you closed this "bug" prematurely! I have two very similar machines - both running PHP 4.2.3 and apache 1.3.26 on Redhat Linux 2.4.7-10 (7.1). I have an upload script and can upload ANY size file to one machine, but am limited to about 9mb on the other box. The php.ini and httpd.conf files are identical (actually, I swapped them over just for the hell of it). I've even swapped the libphp4.so files in the apache libexec directory, between boxes! If this isn't a bug, why does the upload work flawlessly on one machine, but not the other? It will not write to the /tmp directory (or any directory, no matter what I set upload_tmp_dir to) on the one box, but does on the other. Permissions and apache user/group are identical across boxes. It has me stumped! It should either work on both, or neither! [2002-06-10 03:24:45] [EMAIL PROTECTED] Well, I have been doing more tests and it seems that the system memory that is being used is for the catching of the filesystem. I dont know if it is a good thing that so many memory is eaten just for file catching but this is an operating system issue and not php related bug so If everyone agrees I close the bug. Regarding last message from [EMAIL PROTECTED], did you double check the values for the php.ini file, related with post and file uploading? Remenber that post limit should be at least filesize+size of php script. memory_limit = ?? post_max_size = ?? file_uploads = On upload_max_filesize = ?? allow_url_fopen = On [2002-06-08 00:51:26] [EMAIL PROTECTED] I'm using debian with a packaged release of 4.2.1 I'm having the same problem with large uploads, 12 MB files. It will upload to the tmp directory, but fails to move it out of there to where I desire. It eats system memory as well. I've tried moving the uploaded file to a directory (checked the permissions so on and so forth) as well as moving the uploaded file into a mysql database as binary information. Nothing works. It uploads but wont do anything with it 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/17606 -- Edit this bug report at http://bugs.php.net/?id=17606&edit=1
#20953 [Fbk->Opn]: error when combing ?: and return by reference
ID: 20953 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows NT 5.1 build 2600 -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: I tried it - it does not work as well. Previous Comments: [2002-12-12 05:52:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 04:29:28] [EMAIL PROTECTED] let the sample code say the problem '1'); $arr_bad =& Ref_Bad($arr); $arr_good =& Ref_Good($arr); $arr_bad['b'] = 2; $arr_good['c'] = 3; print_r($arr); ?> required result: Array ( [a] => 1 [b] => 2 [c] => 3 ) current result: Array ( [a] => 1 [c] => 3 ) -- Edit this bug report at http://bugs.php.net/?id=20953&edit=1
#20957 [Opn->Fbk]: Random Corrupted Constants.
ID: 20957
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.7
PHP Version: 4.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Previous Comments:
[2002-12-12 08:28:57] [EMAIL PROTECTED]
Under heavy load, mod_php4 seems to corrupt constants, and fail to
require php file specified in a constant. It leaves the following error
message in apache error_log:
[Tue Nov 26 15:02:47 2002] [error] PHP Fatal error: Failed opening
required 'onmassdeletepost' (include_path='.:/usr/local/lib/php'
) in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:48 2002] [error] PHP Fatal error: Failed opening
required 'DB_ERROR_VALUE_COUNT_ON_ROW' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:49 2002] [error] PHP Fatal error: Failed opening
required '_PEAR_default_error_options' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
The relevant lines in common.php are:
33 require_once('/home/home/lib/common/config.php');
34 require_once('PEAR.php');
35 require_once('DB.php');
36 require_once(HUASING_LIB_ERROR);
37 require_once(HUASING_LIB_ENV);
After turning off KeepAlive in apache, and set MaxRequestsPerChild = 1
, this problem doesn't appear any more.
Configure:
'./configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local'
'--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local'
'--with-iconv=/usr/local' '--prefix=/usr/local'
'i386-portbld-freebsd4.6.2'
it runs on a Dual CPU server.
--
Edit this bug report at http://bugs.php.net/?id=20957&edit=1
#14391 [Com]: gmmktime, gmdate work incorrect
ID: 14391
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Date/time related
Operating System: Windows 2000 Server
PHP Version: 4.0.6
New Comment:
Same problem - runing at the same time 2 systems:
On Windows NT 5.0 build 2195 PHP 4.1.1 on GMT zone:
echo (gmdate("U") . ""); //1039704601
echo (date ("U") . ""); //1039704601
echo (mktime() . ""); //1039704601
echo (gmmktime() . ""); //1039701001
echo (time() . ""); //1039704601
On Linux webdev 2.4.19 #1 PHP 4.2.2 on EDT zone:
echo (gmdate("U") . ""); //1039704601
echo (date ("U") . ""); //1039704601
echo (mktime() . ""); //1039704601
echo (gmmktime() . ""); //1039686601
echo (time() . ""); //1039704601
Peter
Previous Comments:
[2002-08-04 01:00:10] [EMAIL PROTECTED]
No feedback was provided for this bug for over a month, 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".
[2002-07-03 19:54:16] [EMAIL PROTECTED]
Could you please retry with a current snapshot or CVS-checkout? There
have been changes to mktime, so this problem might be already fixed in
CVS.
Please reopen the case if the problem persists.
Thanks for helping!
[2002-07-03 15:21:20] [EMAIL PROTECTED]
Here's a different perspective: I've been duplicating examples in
Python, Perl, Tcl, and PHP, thinking my next book may be full of such.
One of my examples converts between an ASCII GMT representation and the
local machine's seconds since the epoch. I did the example in the
other languages before trying PHP. Tcl works "out of the box". In
Python and Perl, I found ways of getting the gmt-to-local time
differential and used that differential to adjust the result produced
by mktime to create something similar to PHP's mktime. (It's not well
tested but doesn't have the bug PHP's mktime has. I get correct
results for daylight and nondaylight local times.) In PHP, I can't
find tools sufficient to calculate that time differential. HERE's THE
POINT: All these languages seem to rely on the same basic C library.
If it can be done using those C library tools (however indirectly) in
some of them it ought to be possible in all.
J Adrian Zimmer
[2002-04-17 21:03:39] [EMAIL PROTECTED]
Hi,
This is my first post to PHP-DEV.
I was stuck too when I tried to get timezone by subtracting
the return value of mktime() from that of gmmktime().
I've inspected the codes, and I guess this may be a complicated
and weird bug produced by glibc, MS CRT library,
ext/standard/datetime.c.
/* -- */
#include
#include
int main( int argc, char **argv )
{
struct tm tm_d = { 0, 0, 0, 1, 0, 70, 0, 0, -1 };
int seconds;
int gmadjust;
int is_dst;
is_dst = tm_d.tm_isdst;
seconds = mktime( &tm_d );
gmadjust = -(is_dst ? timezone - 3600: timezone );
printf( "%d\n", seconds );
seconds += gmadjust;
printf( "%d %d\n", tm_d.tm_isdst, seconds );
}
/* -- */
I wrote this trivial program, and compiled and run
in two different ways.
[win32 - mingw(gcc 2.95.3) with msvcrt.dll under w2k]
c:\blah> gcc -o tztest.exe tztest.c
c:\blah> set TZ=JST-9:00
c:\blah> tztest.exe
-1
-1 35999
c:\blah> set TZ=PST+8:00
c:\blah> tztest.exe
28800
0 0
[linux - gcc 3.04 and glibc-2.2.4]
$ gcc -o tztest tztest.c
$ env TZ="JST -9:00" ./tzdiff
-32400
0 0
$ env TZ="PST +8:00" ./tzdiff
28800
0 0
[What those results mean]
(a) mktime() must return -1 if the specified broken-down time cannot
be
represented as calendar time according to its spec.
(b) When the given timezone is more eastward than GMT,
libc's mktime() should fail (and return -1)
when tm.tm_hour < ( -timezone / 3600 ) because of (a)
(c) glibc doesn't seem to comform to (b).
(d) MS's libc(msvcrt) does (b).
(e) If mktime() is called with tm.tm_isdst set to less than zero,
mktime() routine determines if DST is to be applied in the
specified
timezone, and should set tm_isdst to 1 (applied) or 0 (not
applied).
(f) glibc does (e) well.
(g) MS's libc(msvcrt) doesn't do (e) in case of (a) and leaves
tm.tm_isdst be.
(h) php_mktime() in ext/standard/datetime.c doesn't care about case
(b).
---
Sorry if this is not the point.
Moriyoshi Koizumi
--
#20887 [Ctl->Sus]: /php.ini
ID: 20887
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Suspended
Bug Type: Scripting Engine problem
Operating System: Mandrqke Linux 9.0
PHP Version: 4.3.0-dev
New Comment:
Suspending this bug since the descision made on this thread:
http://www.zend.com/lists/php-dev/200202/msg01325.html
was to keep CWD in php.ini search path, except for the CLI sapi. Since
apache does cd / on startup, php.ini in / will be read. Unless a new
decission is made on php-dev, this behaviour is not going to change.
Previous Comments:
[2002-12-11 23:46:25] [EMAIL PROTECTED]
While I could not duplicate the error on my system, I did notice
something interresting in my strace:
-- Launching php with:
-- #!sapi/cli/php
-- from php4 root
open("sapi/cli//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/local/lib/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("sapi/cli//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
Note the pair of forward slashes between the path to php and the
php.ini filenames?
So I tried something different:
-- Launching php with:
-- #!php
-- from sapi/cli in php4 root
open("php/php-cli.ini", O_RDONLY) = -1 ENOTDIR (Not a directory)
open("/usr/local/lib/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("php/php.ini", O_RDONLY) = -1 ENOTDIR (Not a directory)
Note this time, it treats the php executable as a path!
[2002-12-11 01:48:37] [EMAIL PROTECTED]
I just got bitten by this myself too. But it doesn't happen
with CLI for me, only with the Apache module.
[2002-12-09 23:39:28] [EMAIL PROTECTED]
I have now tried this using apache_1.3.27 + php-4.2.3 (from Mandrake
Cooker) and are experiencing the same thing. I have no idea how to
debug this further, all I can say is if /php.ini exists, values from
that one shows up from phpinfo() called from a php file. I just
stumbled upon this by accident.
[2002-12-08 22:14: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.
Thank you for your interest in PHP.
[2002-12-08 16:22:17] [EMAIL PROTECTED]
I can't see that /php.ini is used here, but php/php-cli.ini is used,
i.e. a file relative to the place from where PHP was started.
With PHPRC=/xizzy I get:
# strace -eopen php -r 'echo "bla";' 2>&1|grep ini
open("php/php-cli.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
open("/xizzy/php-cli.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
open("/usr/local/lib/php-cli.ini", O_RDONLY|O_LARGEFILE) = 3
open("/usr/local/lib/php/browscap/browscap.ini", O_RDONLY|O_LARGEFILE)
= 3
And if php/php-cli.ini is there, PHP only reads that one. This is with
4.3.0-cvs from today, and I don't have Mandrake here (once upon a time,
it was a SuSE Linux).
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/20887
--
Edit this bug report at http://bugs.php.net/?id=20887&edit=1
#20958 [Opn->Fbk]: PHP engine hangs
ID: 20958 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux, RedHat 7.x PHP Version: 4.2.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 08:45:11] [EMAIL PROTECTED] I am using PHP-4.2.0 engine. I am loading oci8.so and libphp_java.so objects through PHP. When I run a java file an exception is coming and PHP engine hangs. But, the exception vanishes when I don't load oci8.so. So it is clear that there is a conflict between oci8.so and lib_java.so. Please help me> Following is the command I run: >>php -f jver.php OUTPUT OFABOVE COMMAND: Java version=1.4.0_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.2.16-22 on i386 Sunday, September 01, 2002 at 8:13:56 AM Eastern Daylight Time An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x400097B8 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: Dynamic libraries: 08048000-08126000 r-xp 03:01 98662/usr/bin/php 08126000-08131000 rw-p 000dd000 03:01 98662/usr/bin/php 4000-40015000 r-xp 03:01 389177 /lib/ld- 2.2.so 40015000-40016000 rw-p 00014000 03:01 389177 /lib/ld- 2.2.so 40019000-4001c000 r-xp 03:01 148156 /usr/lib/20001222/libphp_java.so 4001c000-4001e000 rw-p 2000 03:01 148156 /usr/lib/20001222/libphp_java.so 4001f000-4002 r--p 03:01 34161/usr/lib/locale/en_US/LC_IDENTIFICATION 4002-40027000 r-xp 03:01 387152 /lib/libpam.so.0.72 40027000-40028000 rw-p 6000 03:01 387152 /lib/libpam.so.0.72 40028000-4002a000 r-xp 03:01 389182 /lib/libdl- 2.2.so 4002a000-4002b000 rw-p 1000 03:01 389182 /lib/libdl- 2.2.so 4002c000-40031000 r-xp 03:01 389181 /lib/libcrypt-2.2.so 40031000-40032000 rw-p 4000 03:01 389181 /lib/libcrypt-2.2.so 4005a000-40068000 r-xp 03:01 389196 /lib/libresolv-2.2.so 40068000-40069000 rw-p d000 03:01 389196 /lib/libresolv-2.2.so 4006c000-4008a000 r-xp 03:01 389183 /lib/libm- 2.2.so 4008a000-4008b000 rw-p 0001d000 03:01 389183 /lib/libm- 2.2.so 4008b000-4009f000 r-xp 03:01 389184 /lib/libnsl-2.2.so 4009f000-400a rw-p 00013000 03:01 389184 /lib/libnsl-2.2.so 400a2000-401bb000 r-xp 03:01 389180 /lib/libc- 2.2.so 401bb000-401c1000 rw-p 00118000 03:01 389180 /lib/libc- 2.2.so 401c5000-401df000 r--p 03:01 34160/usr/lib/locale/en_US/LC_CTYPE 401ed000-4073 r-xp 03:05 434607 /home/oracle/product/8.1.7/lib/libclntsh.so.8.0 4073-4074e000 rw-p 00542000 03:05 434607 /home/oracle/product/8.1.7/lib/libclntsh.so.8.0 4075e000-4075f000 r--p 03:01 34162/usr/lib/locale/en_US/LC_MEASUREMENT 4075f000-4076 r--p 03:01 34167/usr/lib/locale/en_US/LC_TELEPHONE 4076-40761000 r--p 03:01 34158/usr/lib/locale/en_US/LC_ADDRESS 40761000-40762000 r--p 03:01 34164/usr/lib/locale/en_US/LC_NAME 40762000-40763000 r--p 03:01 34166/usr/lib/locale/en_US/LC_PAPER 40763000-40764000 r--p 03:01 50034/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES 40764000-40765000 r--p 03:01 34163/usr/lib/locale/en_US/LC_MONETARY 40765000-40766000 r--p 03:01 34168/usr/lib/locale/en_US/LC_TIME 40766000-40767000 r--p 03:01 34165/usr/lib/locale/en_US/LC_NUMERIC 40767000-40776000 r-xp 03:01 389195 /lib/libpthread-0.9.so 40776000-4077d000 rw-p e000 03:01 389195 /lib/libpthread-0.9.so 4077d000-4079f000 r-xp 03:01 148139 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libjava.so 4079f000-407a1000 rw-p 00021000 03:01 148139 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libjava.so 407a3000-40c09000 r-xp 03:01 373895 /usr/java/j2sdk1.4.0_01/jre/lib/i386/server/libjv m.so 40c09000-40dc1000 rw-p 00465000 03:01 373895 /usr/java/j2sdk1.4.0_01/jre/lib/i386/server/libjv m.so 40dd6000-40de7000 r-xp 03:01 148151 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libverify.so 40de7000-40de9000 rw-p 0001 03:01 148151 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libverify.so 40de9000-40e1d000 r-xp 03:01 258230 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 40e1d000-40e29000 rw-p 00033000 03:01 258230 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 40e2b000-40e34000 r-xp 03:01 373891 /usr/java/j2sdk1.4.0_01/jre/lib/i386/native_th
#20956 [Opn->Csd]: lamba is spelled lambda
ID: 20956 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Output Control Operating System: any PHP Version: 4CVS-2002-12-12 (stable) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-12 08:28:01] [EMAIL PROTECTED] There is a typo in ext/standard/html.c. The greek letter lambda is spelled lambda, not lamda. Currently, when php htmlentities() some string containing that letter, the web browser will not be able to display it properly. Here's the diff: *** html.c.buggy2002-11-16 10:08:21.0 +0100 --- html.c 2002-12-12 15:23:59.0 +0100 *** *** 130,136 /* 938 - 944 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", ! "iota", "kappa", "lamda", "mu", "nu", "x1", "omicron", "p1", "rho", "sigmaf", "sigma", "tau", "upsilon", "ph1", "ch1", "ps1", "omega", /* 970 - 976 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, --- 130,136 /* 938 - 944 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", ! "iota", "kappa", "lambda", "mu", "nu", "x1", "omicron", "p1", "rho", "sigmaf", "sigma", "tau", "upsilon", "ph1", "ch1", "ps1", "omega", /* 970 - 976 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, -- Edit this bug report at http://bugs.php.net/?id=20956&edit=1
#20958 [NEW]: PHP engine hangs
From: [EMAIL PROTECTED] Operating system: Linux, RedHat 7.x PHP version: 4.2.0 PHP Bug Type: Scripting Engine problem Bug description: PHP engine hangs I am using PHP-4.2.0 engine. I am loading oci8.so and libphp_java.so objects through PHP. When I run a java file an exception is coming and PHP engine hangs. But, the exception vanishes when I don't load oci8.so. So it is clear that there is a conflict between oci8.so and lib_java.so. Please help me> Following is the command I run: >>php -f jver.php OUTPUT OFABOVE COMMAND: Java version=1.4.0_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.2.16-22 on i386 Sunday, September 01, 2002 at 8:13:56 AM Eastern Daylight Time An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x400097B8 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: Dynamic libraries: 08048000-08126000 r-xp 03:01 98662/usr/bin/php 08126000-08131000 rw-p 000dd000 03:01 98662/usr/bin/php 4000-40015000 r-xp 03:01 389177 /lib/ld- 2.2.so 40015000-40016000 rw-p 00014000 03:01 389177 /lib/ld- 2.2.so 40019000-4001c000 r-xp 03:01 148156 /usr/lib/20001222/libphp_java.so 4001c000-4001e000 rw-p 2000 03:01 148156 /usr/lib/20001222/libphp_java.so 4001f000-4002 r--p 03:01 34161/usr/lib/locale/en_US/LC_IDENTIFICATION 4002-40027000 r-xp 03:01 387152 /lib/libpam.so.0.72 40027000-40028000 rw-p 6000 03:01 387152 /lib/libpam.so.0.72 40028000-4002a000 r-xp 03:01 389182 /lib/libdl- 2.2.so 4002a000-4002b000 rw-p 1000 03:01 389182 /lib/libdl- 2.2.so 4002c000-40031000 r-xp 03:01 389181 /lib/libcrypt-2.2.so 40031000-40032000 rw-p 4000 03:01 389181 /lib/libcrypt-2.2.so 4005a000-40068000 r-xp 03:01 389196 /lib/libresolv-2.2.so 40068000-40069000 rw-p d000 03:01 389196 /lib/libresolv-2.2.so 4006c000-4008a000 r-xp 03:01 389183 /lib/libm- 2.2.so 4008a000-4008b000 rw-p 0001d000 03:01 389183 /lib/libm- 2.2.so 4008b000-4009f000 r-xp 03:01 389184 /lib/libnsl-2.2.so 4009f000-400a rw-p 00013000 03:01 389184 /lib/libnsl-2.2.so 400a2000-401bb000 r-xp 03:01 389180 /lib/libc- 2.2.so 401bb000-401c1000 rw-p 00118000 03:01 389180 /lib/libc- 2.2.so 401c5000-401df000 r--p 03:01 34160/usr/lib/locale/en_US/LC_CTYPE 401ed000-4073 r-xp 03:05 434607 /home/oracle/product/8.1.7/lib/libclntsh.so.8.0 4073-4074e000 rw-p 00542000 03:05 434607 /home/oracle/product/8.1.7/lib/libclntsh.so.8.0 4075e000-4075f000 r--p 03:01 34162/usr/lib/locale/en_US/LC_MEASUREMENT 4075f000-4076 r--p 03:01 34167/usr/lib/locale/en_US/LC_TELEPHONE 4076-40761000 r--p 03:01 34158/usr/lib/locale/en_US/LC_ADDRESS 40761000-40762000 r--p 03:01 34164/usr/lib/locale/en_US/LC_NAME 40762000-40763000 r--p 03:01 34166/usr/lib/locale/en_US/LC_PAPER 40763000-40764000 r--p 03:01 50034/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES 40764000-40765000 r--p 03:01 34163/usr/lib/locale/en_US/LC_MONETARY 40765000-40766000 r--p 03:01 34168/usr/lib/locale/en_US/LC_TIME 40766000-40767000 r--p 03:01 34165/usr/lib/locale/en_US/LC_NUMERIC 40767000-40776000 r-xp 03:01 389195 /lib/libpthread-0.9.so 40776000-4077d000 rw-p e000 03:01 389195 /lib/libpthread-0.9.so 4077d000-4079f000 r-xp 03:01 148139 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libjava.so 4079f000-407a1000 rw-p 00021000 03:01 148139 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libjava.so 407a3000-40c09000 r-xp 03:01 373895 /usr/java/j2sdk1.4.0_01/jre/lib/i386/server/libjv m.so 40c09000-40dc1000 rw-p 00465000 03:01 373895 /usr/java/j2sdk1.4.0_01/jre/lib/i386/server/libjv m.so 40dd6000-40de7000 r-xp 03:01 148151 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libverify.so 40de7000-40de9000 rw-p 0001 03:01 148151 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libverify.so 40de9000-40e1d000 r-xp 03:01 258230 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 40e1d000-40e29000 rw-p 00033000 03:01 258230 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 40e2b000-40e34000 r-xp 03:01 373891 /usr/java/j2sdk1.4.0_01/jre/lib/i386/native_threa ds/libhpi.so 40e34000-40e35000 rw-p 8000 03:01 373891 /usr/java/j2sdk1.4.0_01/jre/lib/i386/native_threa ds/libhpi.so 40e35000-40e49000 r-xp 03:01 148152 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libzip.so 40e49000-40e4c000 rw-p 00013000 03:01 148152 /usr/java/j2sdk1.4.0_01/jre/lib/i386/libzip.so 40e4c000-424c9000 r--s 03:01 132017 /usr/java/
#17606 [Com]: File upload fails on large files
ID: 17606 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating System: RedHat 7.3 PHP Version: 4.2.1 New Comment: One php.ini file in /usr/local/lib. Been through all that - removed all previous (redhat standard install) incarnations of php. Doing a line by line comparison on the two boxes using phpinfo() shows they are configured identically also. The one box will just not write to the upload_tmp_dir, even when I chmod that directory to 777. I've changed the apache user and group thinking it may have been a wierd permissions problem. Not much memory in the box, but it doesn't fill up and swap is basically unused. Previous Comments: [2002-12-12 03:28:26] [EMAIL PROTECTED] Are you sure that both machines are using the equal compiled php version?, please double check with locate how many php.ini files do you have on the problem machine and to which is your php pointing at. [2002-12-11 14:29:44] [EMAIL PROTECTED] I think you closed this "bug" prematurely! I have two very similar machines - both running PHP 4.2.3 and apache 1.3.26 on Redhat Linux 2.4.7-10 (7.1). I have an upload script and can upload ANY size file to one machine, but am limited to about 9mb on the other box. The php.ini and httpd.conf files are identical (actually, I swapped them over just for the hell of it). I've even swapped the libphp4.so files in the apache libexec directory, between boxes! If this isn't a bug, why does the upload work flawlessly on one machine, but not the other? It will not write to the /tmp directory (or any directory, no matter what I set upload_tmp_dir to) on the one box, but does on the other. Permissions and apache user/group are identical across boxes. It has me stumped! It should either work on both, or neither! [2002-06-10 03:24:45] [EMAIL PROTECTED] Well, I have been doing more tests and it seems that the system memory that is being used is for the catching of the filesystem. I dont know if it is a good thing that so many memory is eaten just for file catching but this is an operating system issue and not php related bug so If everyone agrees I close the bug. Regarding last message from [EMAIL PROTECTED], did you double check the values for the php.ini file, related with post and file uploading? Remenber that post limit should be at least filesize+size of php script. memory_limit = ?? post_max_size = ?? file_uploads = On upload_max_filesize = ?? allow_url_fopen = On [2002-06-08 00:51:26] [EMAIL PROTECTED] I'm using debian with a packaged release of 4.2.1 I'm having the same problem with large uploads, 12 MB files. It will upload to the tmp directory, but fails to move it out of there to where I desire. It eats system memory as well. I've tried moving the uploaded file to a directory (checked the permissions so on and so forth) as well as moving the uploaded file into a mysql database as binary information. Nothing works. It uploads but wont do anything with it [2002-06-06 05:58:13] [EMAIL PROTECTED] Yes, I am using php-4.2.1, I have been doing tests with very big files, my current parameters regarding uploads in php.ini are the following: memory_limit = 8M post_max_size = 700M file_uploads = On upload_max_filesize = 700M allow_url_fopen = On When I try to upload a 400M file the web server starts writing it in the tmp dir but it also eats the system memory in the same amount so it can only handle properly one big upload at a time. 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/17606 -- Edit this bug report at http://bugs.php.net/?id=17606&edit=1
#20957 [NEW]: Random Corrupted Constants.
From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.7
PHP version: 4.2.3
PHP Bug Type: Scripting Engine problem
Bug description: Random Corrupted Constants.
Under heavy load, mod_php4 seems to corrupt constants, and fail to require
php file specified in a constant. It leaves the following error message in
apache error_log:
[Tue Nov 26 15:02:47 2002] [error] PHP Fatal error: Failed opening
required 'onmassdeletepost' (include_path='.:/usr/local/lib/php'
) in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:48 2002] [error] PHP Fatal error: Failed opening
required 'DB_ERROR_VALUE_COUNT_ON_ROW' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:49 2002] [error] PHP Fatal error: Failed opening
required '_PEAR_default_error_options' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
The relevant lines in common.php are:
33 require_once('/home/home/lib/common/config.php');
34 require_once('PEAR.php');
35 require_once('DB.php');
36 require_once(HUASING_LIB_ERROR);
37 require_once(HUASING_LIB_ENV);
After turning off KeepAlive in apache, and set MaxRequestsPerChild = 1 ,
this problem doesn't appear any more.
Configure:
'./configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local'
'--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local'
'--with-iconv=/usr/local' '--prefix=/usr/local'
'i386-portbld-freebsd4.6.2'
it runs on a Dual CPU server.
--
Edit bug report at http://bugs.php.net/?id=20957&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20957&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20957&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20957&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20957&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20957&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20957&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20957&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20957&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20957&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20957&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20957&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20957&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20957&r=isapi
#20956 [NEW]: lamba is spelled lambda
From: [EMAIL PROTECTED] Operating system: any PHP version: 4CVS-2002-12-12 (stable) PHP Bug Type: Output Control Bug description: lamba is spelled lambda There is a typo in ext/standard/html.c. The greek letter lambda is spelled lambda, not lamda. Currently, when php htmlentities() some string containing that letter, the web browser will not be able to display it properly. Here's the diff: *** html.c.buggy2002-11-16 10:08:21.0 +0100 --- html.c 2002-12-12 15:23:59.0 +0100 *** *** 130,136 /* 938 - 944 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", ! "iota", "kappa", "lamda", "mu", "nu", "x1", "omicron", "p1", "rho", "sigmaf", "sigma", "tau", "upsilon", "ph1", "ch1", "ps1", "omega", /* 970 - 976 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, --- 130,136 /* 938 - 944 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", ! "iota", "kappa", "lambda", "mu", "nu", "x1", "omicron", "p1", "rho", "sigmaf", "sigma", "tau", "upsilon", "ph1", "ch1", "ps1", "omega", /* 970 - 976 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, -- Edit bug report at http://bugs.php.net/?id=20956&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20956&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20956&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20956&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20956&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20956&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20956&r=support Expected behavior: http://bugs.php.net/fix.php?id=20956&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20956&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20956&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20956&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20956&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20956&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20956&r=isapi
#20936 [Opn->Csd]: Patch for use of public keys
ID: 20936 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed -Bug Type: Feature/Change Request +Bug Type: OpenSSL related Operating System: Linux PHP Version: 4CVS-2002-12-11 (dev) New Comment: Verified the problem and the patch has gone into PHP 4.3. Thanks for your help :) Previous Comments: [2002-12-11 09:37:42] [EMAIL PROTECTED] the patch should go to [EMAIL PROTECTED], CC: [EMAIL PROTECTED] I was not able to download the patch from the URL you posted. [2002-12-11 09:36:53] [EMAIL PROTECTED] Please read the CODING_STANDARDS and README.SUBMITTING-PATCH files in the php4/ directory; mail the patch as a MIME attachment (give it a .txt extension if your mailer doesn't set the mime type correctly, as binary attachments are stripped from the list), and CC the patch to the maintainer (that's me, [EMAIL PROTECTED]). Please also describe in more detail what the patch changes and or fixes, with a couple of lines of sample code. [2002-12-11 08:51:13] [EMAIL PROTECTED] I required the use of public keys (not certificates) for a current project, so I patched ext/openssl/openssl.c to support public keys. The patch can be found at http://www.jeroenderks.com/php-4.4.0-dev-openssl.c.diff I tries to read a public key if reading a certificate failed in php_openssl_evp_from_zval(). Also a check was added to check whether a private key was requested and only a public key is available. -- Edit this bug report at http://bugs.php.net/?id=20936&edit=1
#20927 [Asn->Csd]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Strings related
Operating System: Red Hat Linux 8.0 on Intel
PHP Version: 4.3.0RC3
Assigned To: derick
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-12-12 00:24:30] [EMAIL PROTECTED]
Okay, now I could verify this (with 4.3.0RC3). Going to fix this
soonish.
[2002-12-11 20:15:23] [EMAIL PROTECTED]
A more dramatic example: The following script, under PHP 4.1.2,
prints:
Length of original string: 130
Length of break string: 11264
Length of wrapped string: 214127
Size allocated by 4.3.0RC2: 173596
BUFFER OVERFLOW by 40531 bytes!
With 4.3.0RC2, it segfaults.
--
David.
0) {
print ("BUFFER OVERFLOW by $overflow bytes!\n");
}
?>
[2002-12-11 15:01:15] [EMAIL PROTECTED]
Ah, the bug might not show up on Red Hat 7.1, probably because of glibc
differences. Anyway, here's my system:
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
$ ldd /usr/local/bin/php
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4002f000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4005d000)
libm.so.6 => /lib/i686/libm.so.6 (0x4006f000)
libdl.so.2 => /lib/libdl.so.2 (0x40091000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40094000)
libc.so.6 => /lib/i686/libc.so.6 (0x4200)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
$ rpm -q glibc
glibc-2.2.93-5
Regards,
David.
[2002-12-11 14:52:13] [EMAIL PROTECTED]
I'm running RedHat 7.1, and the last script still doesn't crash for me,
and no output from valgrind at all...
gcc = 2.96 (stock redhat 7.1)
What is your gcc version?
Derick
[2002-12-11 14:43:18] [EMAIL PROTECTED]
Are you running on Red Hat 8.0?
I consistently get a crash. It's also obvious that the buffer
allocated is 135 bytes, and the length of the wrapped string is 138.
So if you're not getting a crash, it's just luck. Try this script
instead:
That should exercise malloc() a lot more.
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/20927
--
Edit this bug report at http://bugs.php.net/?id=20927&edit=1
#20607 [Fbk->Opn]: function included from parent script gets lost
ID: 20607
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: red hat 7.2
PHP Version: 4.2.3
New Comment:
ok ill try a cvs snapshot,
btw the problem doesnt happen on our win2K test server (for once!
windows being nice??)
ill see if this also happens on our soon-to-be-live redhat dev-box, ill
be able to do lots more on that box than on the live one
Previous Comments:
[2002-12-04 18:19:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-25 00:32:34] [EMAIL PROTECTED]
it doesnt matter if I do
ini_set("error_reporting", "E_WARNING");
or
ini_set("error_reporting", "E_ALL");
or include_once / require_once
the site comes up with nothing when I set error_reporting
[2002-11-25 00:28:02] [EMAIL PROTECTED]
ok index.php now reads (on the live site):
";
require_once "it_functions/it_db.php";
$a = it_getnextid("table", "trjh");
?>
I dont get any msg at all now, but i should get an echo from
it_GetNextID ... ?
[2002-11-24 19:27:32] [EMAIL PROTECTED]
yep, will do that, but im using other files in the same directory. also
what is the function to get/set config options in php via the script?
[2002-11-24 12:36:08] [EMAIL PROTECTED]
Looks like the include is failing, but the error is not being shown,
could you increase your error level to display E_WARNING or change
include_once to require_once.
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/20607
--
Edit this bug report at http://bugs.php.net/?id=20607&edit=1
#20934 [Ver->Csd]: htmlspecialchars returns latin1 from UTF-8
ID: 20934 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Closed Bug Type: Strings related Operating System: Red hat linux 8.0 PHP Version: 4CVS-2002-12-11 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. It's fortunate that I managed to fix this before the release. Previous Comments: [2002-12-12 07:19:13] [EMAIL PROTECTED] Is this problem also in the PHP 4.3.0RC3? If so, this should be resolved before release. [2002-12-12 07:10:58] [EMAIL PROTECTED] Thanks for your effort again. Verified this behaviour. [2002-12-11 06:58:14] [EMAIL PROTECTED] I used the script bellow for testing (calling it from MS Internet Explorer to directly see the xml output). Calling it without parameters one should see a simple xml document showing a string in latin1. Calling it with "?charset=utf8", the script correctly converts the string from latin1 to UTF-8 but after using "htmlspecialchars" it goes back to latin1, and the xml becomes invalid. (put a comment on the "htmlspecialchars" line after the character conversion and the xml will show up in UTF-8 without problem). \n"; ?> -- Edit this bug report at http://bugs.php.net/?id=20934&edit=1
#20954 [Opn->Fbk]: Serious problem , unknown reason
ID: 20954 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: 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 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. It's segfaulting, better get that off, or Windows XP will be Windows ExPired pretty soon. Previous Comments: [2002-12-12 05:45:52] [EMAIL PROTECTED] te apache version should 2.0.43 [2002-12-12 05:41:20] [EMAIL PROTECTED] I have install the newest version of apache 2 (should be 2.0.49) and 4.3.0 RC2, I just installed phpbb to test with, it give out a mess, and also the error is not constant, it changes every time I reload the page, it does not report any error code, however, giving out some alien chars, when I trace the code, some of them are showing my harddisk folders, some of them are showing the momery contents, some of them are showing some file contents in my harddisk, terribleevery time I reload the page, every time is different. I don't know much about php, but I use recommended isap settings in apache for running php. please go to have a look on the mess, http://phpbb.attosoft.myftp.org/faq.php -- Edit this bug report at http://bugs.php.net/?id=20954&edit=1
#20934 [Ver]: htmlspecialchars returns latin1 from UTF-8
ID: 20934 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Strings related Operating System: Red hat linux 8.0 PHP Version: 4CVS-2002-12-11 (dev) New Comment: Is this problem also in the PHP 4.3.0RC3? If so, this should be resolved before release. Previous Comments: [2002-12-12 07:10:58] [EMAIL PROTECTED] Thanks for your effort again. Verified this behaviour. [2002-12-11 06:58:14] [EMAIL PROTECTED] I used the script bellow for testing (calling it from MS Internet Explorer to directly see the xml output). Calling it without parameters one should see a simple xml document showing a string in latin1. Calling it with "?charset=utf8", the script correctly converts the string from latin1 to UTF-8 but after using "htmlspecialchars" it goes back to latin1, and the xml becomes invalid. (put a comment on the "htmlspecialchars" line after the character conversion and the xml will show up in UTF-8 without problem). \n"; ?> -- Edit this bug report at http://bugs.php.net/?id=20934&edit=1
#20934 [Opn->Ver]: htmlspecialchars returns latin1 from UTF-8
ID: 20934 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Strings related Operating System: Red hat linux 8.0 PHP Version: 4CVS-2002-12-11 (dev) New Comment: Thanks for your effort again. Verified this behaviour. Previous Comments: [2002-12-11 06:58:14] [EMAIL PROTECTED] I used the script bellow for testing (calling it from MS Internet Explorer to directly see the xml output). Calling it without parameters one should see a simple xml document showing a string in latin1. Calling it with "?charset=utf8", the script correctly converts the string from latin1 to UTF-8 but after using "htmlspecialchars" it goes back to latin1, and the xml becomes invalid. (put a comment on the "htmlspecialchars" line after the character conversion and the xml will show up in UTF-8 without problem). \n"; ?> -- Edit this bug report at http://bugs.php.net/?id=20934&edit=1
#17996 [Com]: make fails with "image.c" , line 439.23: 1506-334 (S) Identifier uchar has
ID: 17996 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.3.0-dev New Comment: Ignore that last post, being a bit of a muppet, using the wrong version. Previous Comments: [2002-12-12 04:25:10] [EMAIL PROTECTED] I've exactly the same problem, same version of AIX etc. I have apache 2.0.43 installed and am using php 4.2.3. Is this a compiler issue? Or is it worth while trying 4.3.0RC3 I need to get this working fairly desperately. So any help is welcome. Thanks Julian [2002-08-08 13:07:58] [EMAIL PROTECTED] This is not a problem in PHP, but a problem with your (configuration of your) system. Please ask support questions on the appropriate mailinglist. [2002-08-08 12:54:33] [EMAIL PROTECTED] I would like to believe you but although it says "Target all is up to date" the file it is looking for (libs/libphp4.so) hasn't been created. [2002-08-08 11:58:16] [EMAIL PROTECTED] Glad to hear the bug is fixed, but your new problem is an end user problem, not a PHP bug. Please figure out your installation, and where you want things to go. If you still have trouble with that, ask on the php-general list for help. [2002-08-08 11:44:59] [EMAIL PROTECTED] Now, I does compile (with lots of Warning messages) and at the end lots of messages like : cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix cc: 1501-218 file ext/mbstring/mbfilter_ja.lo contains an incorrect file suffix but it fails on make install : Installing PHP SAPI module [activating module `php4' in /usr/local/apache_1.3.26/conf/httpd.conf] cp libs/libphp4.so /usr/local/apache_1.3.26/libexec/libphp4.so cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=1 make: 1254-004 The error code from the last command is 1. In libs I have only : libphp4.a and libphp4.la Thanks a lot for your help. 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/17996 -- Edit this bug report at http://bugs.php.net/?id=17996&edit=1
#20953 [Opn->Fbk]: error when combing ?: and return by reference
ID: 20953 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows NT 5.1 build 2600 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 04:29:28] [EMAIL PROTECTED] let the sample code say the problem '1'); $arr_bad =& Ref_Bad($arr); $arr_good =& Ref_Good($arr); $arr_bad['b'] = 2; $arr_good['c'] = 3; print_r($arr); ?> required result: Array ( [a] => 1 [b] => 2 [c] => 3 ) current result: Array ( [a] => 1 [c] => 3 ) -- Edit this bug report at http://bugs.php.net/?id=20953&edit=1
#19113 [Opn->Fbk]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-12 05:19:30] [EMAIL PROTECTED] I was now able reproduce this problem, but only in case when index.php was in DocumentRoot of first defined name-based virtual server (which is accepted as the default on that IP/port in such case), and index.php was the default script to execute (if there was something before index.php in DirectoryIndex and if it also existed in DocumentRoot of the default vhost, the bug did not apply). Therefore, i think it is really a php bug I reproduced this with Apache-1.3.26+php-4.1.2 on debian GNU/linux 3.0-woody and also Apache-1.3.27+php-4.2.3 on FreeBSD-4.6.2 [2002-12-03 10:01:43] [EMAIL PROTECTED] Hello, I also have problems with this. However, using apache-1.2.27+mod_ssl2.8.11 and php-4.2.3 i was not able to reproduce this problem with defined way. I think that is not php-related. [2002-11-20 07:41:09] [EMAIL PROTECTED] Reopening, on request of #20517. [2002-11-16 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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". [2002-10-31 11:39:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip 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/19113 -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#20954 [Opn]: Serious problem , unknown reason
ID: 20954 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: te apache version should 2.0.43 Previous Comments: [2002-12-12 05:41:20] [EMAIL PROTECTED] I have install the newest version of apache 2 (should be 2.0.49) and 4.3.0 RC2, I just installed phpbb to test with, it give out a mess, and also the error is not constant, it changes every time I reload the page, it does not report any error code, however, giving out some alien chars, when I trace the code, some of them are showing my harddisk folders, some of them are showing the momery contents, some of them are showing some file contents in my harddisk, terribleevery time I reload the page, every time is different. I don't know much about php, but I use recommended isap settings in apache for running php. please go to have a look on the mess, http://phpbb.attosoft.myftp.org/faq.php -- Edit this bug report at http://bugs.php.net/?id=20954&edit=1
#20954 [NEW]: Serious problem , unknown reason
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.3.0RC3 PHP Bug Type: Apache2 related Bug description: Serious problem , unknown reason I have install the newest version of apache 2 (should be 2.0.49) and 4.3.0 RC2, I just installed phpbb to test with, it give out a mess, and also the error is not constant, it changes every time I reload the page, it does not report any error code, however, giving out some alien chars, when I trace the code, some of them are showing my harddisk folders, some of them are showing the momery contents, some of them are showing some file contents in my harddisk, terribleevery time I reload the page, every time is different. I don't know much about php, but I use recommended isap settings in apache for running php. please go to have a look on the mess, http://phpbb.attosoft.myftp.org/faq.php -- Edit bug report at http://bugs.php.net/?id=20954&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20954&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20954&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20954&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20954&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20954&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20954&r=support Expected behavior: http://bugs.php.net/fix.php?id=20954&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20954&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20954&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20954&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20954&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20954&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20954&r=isapi
#19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: I was now able reproduce this problem, but only in case when index.php was in DocumentRoot of first defined name-based virtual server (which is accepted as the default on that IP/port in such case), and index.php was the default script to execute (if there was something before index.php in DirectoryIndex and if it also existed in DocumentRoot of the default vhost, the bug did not apply). Therefore, i think it is really a php bug I reproduced this with Apache-1.3.26+php-4.1.2 on debian GNU/linux 3.0-woody and also Apache-1.3.27+php-4.2.3 on FreeBSD-4.6.2 Previous Comments: [2002-12-03 10:01:43] [EMAIL PROTECTED] Hello, I also have problems with this. However, using apache-1.2.27+mod_ssl2.8.11 and php-4.2.3 i was not able to reproduce this problem with defined way. I think that is not php-related. [2002-11-20 07:41:09] [EMAIL PROTECTED] Reopening, on request of #20517. [2002-11-16 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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". [2002-10-31 11:39:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-03 13:56:31] [EMAIL PROTECTED] I'm using PHP 4.2.2 and Apache 1.3.26 on RedHat 7.1 I can't get it to act properly at all (renaming the index file didn't work) DirectoryIndex index.html index.php index.htm I have 5 files and 3 directories in the root directory, the only file that is an index is index.html. I tried renaming that to 2index.html , but the CONNECT request just returned a 404. $SERVER['REQUEST_METHOD'] was 'CONNECT' when it parsed index.html, if that's any help. Chris P.S. When I voted on this bug I accidentaly stated it was a different version of PHP when it was in fact the same version. 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/19113 -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#20953 [NEW]: error when combing ?: and return by reference
From: [EMAIL PROTECTED] Operating system: Windows NT 5.1 build 2600 PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: error when combing ?: and return by reference let the sample code say the problem '1'); $arr_bad =& Ref_Bad($arr); $arr_good =& Ref_Good($arr); $arr_bad['b'] = 2; $arr_good['c'] = 3; print_r($arr); ?> required result: Array ( [a] => 1 [b] => 2 [c] => 3 ) current result: Array ( [a] => 1 [c] => 3 ) -- Edit bug report at http://bugs.php.net/?id=20953&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20953&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20953&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20953&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20953&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20953&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20953&r=support Expected behavior: http://bugs.php.net/fix.php?id=20953&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20953&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20953&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20953&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20953&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20953&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20953&r=isapi
#17996 [Com]: make fails with "image.c" , line 439.23: 1506-334 (S) Identifier uchar has
ID: 17996 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.3.0-dev New Comment: I've exactly the same problem, same version of AIX etc. I have apache 2.0.43 installed and am using php 4.2.3. Is this a compiler issue? Or is it worth while trying 4.3.0RC3 I need to get this working fairly desperately. So any help is welcome. Thanks Julian Previous Comments: [2002-08-08 13:07:58] [EMAIL PROTECTED] This is not a problem in PHP, but a problem with your (configuration of your) system. Please ask support questions on the appropriate mailinglist. [2002-08-08 12:54:33] [EMAIL PROTECTED] I would like to believe you but although it says "Target all is up to date" the file it is looking for (libs/libphp4.so) hasn't been created. [2002-08-08 11:58:16] [EMAIL PROTECTED] Glad to hear the bug is fixed, but your new problem is an end user problem, not a PHP bug. Please figure out your installation, and where you want things to go. If you still have trouble with that, ask on the php-general list for help. [2002-08-08 11:44:59] [EMAIL PROTECTED] Now, I does compile (with lots of Warning messages) and at the end lots of messages like : cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix cc: 1501-218 file ext/mbstring/mbfilter_ja.lo contains an incorrect file suffix but it fails on make install : Installing PHP SAPI module [activating module `php4' in /usr/local/apache_1.3.26/conf/httpd.conf] cp libs/libphp4.so /usr/local/apache_1.3.26/libexec/libphp4.so cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=1 make: 1254-004 The error code from the last command is 1. In libs I have only : libphp4.a and libphp4.la Thanks a lot for your help. [2002-08-08 07:47:09] [EMAIL PROTECTED] This actually should be fixed in the latest CVS HEAD. So please try this snapshot again: http://snaps.php.net/php4-latest.tar.gz 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/17996 -- Edit this bug report at http://bugs.php.net/?id=17996&edit=1
