#18049 [Bgs->Csd]: LDAP over SSL (ldaps) not working
ID: 18049
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Closed
Bug Type: LDAP related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.2.1
Assigned To: edink
New Comment:
OK, since the dll is now compiled with ssl-support, PHP is not the
problem any longer.
Just one last question: Will the ssl-support for the win32-version be
integrated in future php-releases?
Previous Comments:
[2002-10-12 09:39:20] [EMAIL PROTECTED]
Why do you ask these questions here when you could have got the answers
simply by searching with some search engine?!
http://www.openldap.org/lists/openldap-software/200108/msg00043.html
Bogusing this bug report since this really IS NOT any bug in PHP.
[2002-10-12 05:35:08] [EMAIL PROTECTED]
In the last week I did some testing. I used PHP 4.2.3 with your
php_ldap.dll on Win2000 and Apache 1.3.26. The OpenLDAP-server (slapd)
was running on Linux and Win2000, but I get the same results on both
platforms. I created the configuration-file
"C:\OpenLDAP\sysconf\ldap.conf" (I saw that string in php_ldap.dll) on
the machine, where PHP is running. In this file I put the
TLS_REQCERT-directive and tested with all 4 possible values:
never, allow: seems to work
try, demand: does not work, PHP always sends a client certificate,
which the LDAP-server can't accept (see above).
But there is no client certificate configured!?
[2002-10-03 19:10:46] [EMAIL PROTECTED]
From: http://www.openldap.org/doc/admin/tls.html
"11.2.2.6. TLS_REQCERT { never | allow | try | demand }
This directive is equivalent to the server's TLSVerifyClient option.
However, for clients the default value is demand and there generally
is no good reason to change this setting."
(I don't have any server setup so I can't test this myself now)
[2002-10-03 07:27:12] [EMAIL PROTECTED]
Thank you for compiling the dll with ssl-support.
It seems to work so far.
But now I have the problem, that PHP always wants to send a client
certificate, even with "TLSVerifyClient never" in slapd.conf. In the
debug-console of the LDAP-server I can read:
TLS trace: SSL3 alert read:fatal:unknown
TLS trace: SSL_accept:failed in SSLv3 read client certificate A
TLS: can't accept
TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
s3_pkt.c:964
Where can I configure, that PHP should not send a client certificate,
or where do I have to put it?
[2002-10-02 20:11:46] [EMAIL PROTECTED]
Could you please try:
http://ftp.proventum.net/pub/php/win32/temp/php_4.2.x_ldap.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/18049
--
Edit this bug report at http://bugs.php.net/?id=18049&edit=1
#19033 [Com]: win32 snapshots broken / set_error_handler() to accepts object/method tuple
ID: 19033 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Program Execution Operating System: Windows PHP Version: 4.2.1 New Comment: I installed version from http://snaps.php.net/win32/php4-win32-latest.zip 2 minutes ago. Same thing. Sometimes it works, usually not. Few times it worked after apache restart, few times after changing list of function attributes... Previous Comments: [2002-10-12 10:01:27] [EMAIL PROTECTED] Reopen only if you can confirm something..this is closed. (most likely not using recent enough snapshot and has installed it wrong) [2002-10-12 09:44:35] [EMAIL PROTECTED] Reopening, status->critical. [2002-10-12 08:53:15] [EMAIL PROTECTED] Sorry to say, but it has to be reopened once more. This trunk works strange. Sometimes handler works, but in most situations it doesnt. I'm working with big part of code, and there i first time saw that sometimes handler doesnt work. Then i was trying to create tescase, and could not. Finaly i created test file, copied code from my comment and it's not working now. --- Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 8 AA Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 10 AA --- After Apache restart it worked once or twice. After few reloads bug appeard. Try to reproduce. Just reload part of code few times. PHP dev 4.3.0 Apache 2.43 Windows 2000 [2002-10-12 04:43:35] [EMAIL PROTECTED] Closing then. [2002-10-12 04:39:03] [EMAIL PROTECTED] Confirming. Newest Windows snapshot works OK. Thanks for fixing this bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19033 -- Edit this bug report at http://bugs.php.net/?id=19033&edit=1
#19879 [NEW]: Failed build with simple options for apache2
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux 3.0 PHP version: 4.3.0-pre1 PHP Bug Type: Compile Failure Bug description: Failed build with simple options for apache2 Hello, plain unzipped php4.3.0-pre1.tar.bz2 and did ./configure --with-apxs2=/usr/bin/apxs --prefix=/usr/local And it failed Here is the last bit of the compile -- /bin/sh libtool --silent --mode=compile gcc -Iext/standard/ -I/root/php-4.3.0pre1/ext/standard/ -DPHP_ATOM_INC -I/root/php-4.3.0pre1/include -I/root/php-4.3.0pre1/main -I/root/php-4.3.0pre1 -I/usr/include/apache2 -I/root/php-4.3.0pre1/Zend -I/root/php-4.3.0pre1/ext/xml/expat -D_REENTRANT -I/root/php-4.3.0pre1/TSRM -DTHREAD=1 -g -O2 -pthread -DZTS -prefer-pic -c /root/php-4.3.0pre1/ext/standard/formatted_print.c -o ext/standard/formatted_print.lo /root/php-4.3.0pre1/ext/standard/formatted_print.c: In function `php_sprintf_appenddouble': /root/php-4.3.0pre1/ext/standard/formatted_print.c:287: `tsrm_ls' undeclared (first use in this function) /root/php-4.3.0pre1/ext/standard/formatted_print.c:287: (Each undeclared identifier is reported only once /root/php-4.3.0pre1/ext/standard/formatted_print.c:287: for each function it appears in.) make: *** [ext/standard/formatted_print.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=19879&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19879&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19879&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19879&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19879&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19879&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19879&r=support Expected behavior: http://bugs.php.net/fix.php?id=19879&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19879&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19879&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19879&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19879&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19879&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19879&r=isapi
#19876 [Opn]: Problem with parse_url() function...
ID: 19876 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *URL Functions Operating System: Windows 2000 Pro (Sp3) PHP Version: 4CVS-2002-10-11 New Comment: The lack for formatting for phpinfo() when html_errors are Off is intentional. parse_url() was recently rewritten from scratch that probably introduced the bug you are seeing. I'll look into it in more detail. Previous Comments: [2002-10-11 23:26:58] [EMAIL PROTECTED] Here's a link to the phpinfo at my machine: http://onionman.homeip.net/phpinfo/ A weird thing i noticed is that if i have 'html_errors = Off' in my php.ini file, then phpinfo looses all it formatting and is unreadable... is it supposed to be like this? Anyway... i doublechecked the parse_url bug by going back to an older snapshot (2002-10-06), and there it works like expected... and then trying latest snap again (2002-10-12), and there it's the same result as before... so either something has introduced a bug there since last week... or my machine is behaving strange... ;) /OnionMan [2002-10-11 23:00:11] [EMAIL PROTECTED] The 1 comes from 'echo print_r' you do not need to echo print_r() it'll do it automatically. The missing letter is something I am unable to replicate on any of my machines. Could you please should output of phpinfo() on your system, maybe that'll yeild some clues. [2002-10-11 22:54:02] [EMAIL PROTECTED] Snapshot used: php4-win32-200210120200.zip This simple script parses an ftp-url: ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news";; $parts = parse_url($url); echo ''."\n"; echo print_r($parts)."\n"; echo ''."\n"; ?> When i run the script i get this output: Array ( [scheme] => ftp [host] => www.moria.com [user] => gandalf [pass] => mello [path] => /foo/bar/index.php [query] => page=news ) 1 Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour. BTW: What does the 1 that is output after the value pairs mean? -- Edit this bug report at http://bugs.php.net/?id=19876&edit=1
#19873 [NEW]: Unable to load dynamic library 'c:\php\php_interbase.dll' dialog box error.
From: [EMAIL PROTECTED] Operating system: Windows XP Professional PHP version: 4.2.3 PHP Bug Type: InterBase related Bug description: Unable to load dynamic library 'c:\php\php_interbase.dll' dialog box error. I'm trying to make a connection to an Interbase 5 database with the following code: email, "\n"; //} ibase_free_result($sth); ibase_close($dbh); ?> NOTE: The lines as comments are for testing purposes. My problem is I get a dialog box with the following error message: Unable to load dynamic library 'c:\php\php_interbase.dll'. I made sure the extensions path is correct and the php_interbase.dll line isn't commented in php.ini like this: extension_dir = c:\php\extensions\ extension=php_interbase.dll I have been looking for a way to fix this on the web but I haven't found anything. Does this only work with Interbase 6? -- Edit bug report at http://bugs.php.net/?id=19873&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19873&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19873&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19873&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19873&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19873&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19873&r=support Expected behavior: http://bugs.php.net/fix.php?id=19873&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19873&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19873&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19873&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19873&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19873&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19873&r=isapi
#19876 [Opn->Fbk]: Problem with parse_url() function...
ID: 19876 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *URL Functions Operating System: Windows 2000 Pro (Sp3) PHP Version: 4CVS-2002-10-11 New Comment: Please wait until the next developer snapshot is generated and try again. Previous Comments: [2002-10-11 23:31:53] [EMAIL PROTECTED] The lack for formatting for phpinfo() when html_errors are Off is intentional. parse_url() was recently rewritten from scratch that probably introduced the bug you are seeing. I'll look into it in more detail. [2002-10-11 23:26:58] [EMAIL PROTECTED] Here's a link to the phpinfo at my machine: http://onionman.homeip.net/phpinfo/ A weird thing i noticed is that if i have 'html_errors = Off' in my php.ini file, then phpinfo looses all it formatting and is unreadable... is it supposed to be like this? Anyway... i doublechecked the parse_url bug by going back to an older snapshot (2002-10-06), and there it works like expected... and then trying latest snap again (2002-10-12), and there it's the same result as before... so either something has introduced a bug there since last week... or my machine is behaving strange... ;) /OnionMan [2002-10-11 23:00:11] [EMAIL PROTECTED] The 1 comes from 'echo print_r' you do not need to echo print_r() it'll do it automatically. The missing letter is something I am unable to replicate on any of my machines. Could you please should output of phpinfo() on your system, maybe that'll yeild some clues. [2002-10-11 22:54:02] [EMAIL PROTECTED] Snapshot used: php4-win32-200210120200.zip This simple script parses an ftp-url: ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news";; $parts = parse_url($url); echo ''."\n"; echo print_r($parts)."\n"; echo ''."\n"; ?> When i run the script i get this output: Array ( [scheme] => ftp [host] => www.moria.com [user] => gandalf [pass] => mello [path] => /foo/bar/index.php [query] => page=news ) 1 Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour. BTW: What does the 1 that is output after the value pairs mean? -- Edit this bug report at http://bugs.php.net/?id=19876&edit=1
#19655 [Fbk]: Using MM session handler, Apache crashs at child death.
ID: 19655 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: 2.2.20 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-10-01 13:14:42] [EMAIL PROTECTED] I tested the php4-200209300600 snap. I still have apache segfaulting : #0 ps_mm_destroy (data=0x83f26a8) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:241 241 next = sd->next; (gdb) bt #0 ps_mm_destroy (data=0x83f26a8) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:241 #1 0x8135606 in zm_shutdown_ps_mm (type=1, module_number=18) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:293 #2 0x81348c4 in zm_shutdown_session (type=1, module_number=18) at /space/build/apache/php4-200209300600/ext/session/session.c:1511 #3 0x80e880f in module_destructor (module=0x83e2518) at /space/build/apache/php4-200209300600/Zend/zend_API.c:1128 #4 0x80e9e47 in zend_hash_apply_deleter (ht=0x839d460, p=0x83e24e8) at /space/build/apache/php4-200209300600/Zend/zend_hash.c:598 #5 0x80e9f59 in zend_hash_graceful_reverse_destroy (ht=0x839d460) at /space/build/apache/php4-200209300600/Zend/zend_hash.c:664 #6 0x80e62dc in zend_shutdown () at /space/build/apache/php4-200209300600/Zend/zend.c:512 #7 0x80cae93 in php_module_shutdown () at /space/build/apache/php4-200209300600/main/main.c:1193 #8 0x80cae74 in php_module_shutdown_wrapper (sapi_globals=0x835b520) at /space/build/apache/php4-200209300600/main/main.c:1170 #9 0x80c1540 in apache_php_module_shutdown_wrapper () #10 0x81966ce in run_cleanups () #11 0x8194db4 in ap_clear_pool () #12 0x8194e29 in ap_destroy_pool () #13 0x8194d8c in ap_clear_pool () #14 0x8194e29 in ap_destroy_pool () #15 0x81a38c2 in clean_parent_exit () #16 0x81a6593 in standalone_main () #17 0x81a6a93 in main () [2002-09-29 20:03:03] [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 I meant all the libraries you link with PHP and apache with. But please try the snapshot, it's more likely not related to SSL anyway and there were some fixes in CVS just today which should prevent this. [2002-09-29 17:40:18] [EMAIL PROTECTED] > and are you 100% sure you're really compiling with 0.9.6g ? Yes, Apache+mod_ssl are linked with a just "untagzip'ed and compiled" openssl-0.9.6g ... > And that ALL your software is linked with it? Why would other software be linked with it ? We're only takking about a httpd process, not the whole of the system. > Best way to be sure about it is to first remove all binaries > compiled with openssl and all old openssl libraries from your system > and compile the latest from scratch. Why would I do that ? I am sure the steps I made : it is an Apache+0.9.6g (as shown in headers) and it is crashed by the worm code :( Georges [2002-09-29 17:33:36] [EMAIL PROTECTED] Please, don't sign your comments..and are you 100% sure you're really compiling with 0.9.6g ? And that ALL your software is linked with it? Best way to be sure about it is to first remove all binaries compiled with openssl and all old openssl libraries from your system and compile the latest from scratch. [2002-09-29 16:45:14] [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I feel like sure ( :-) ) that Apache/OpenSSL 0.9.6g is still vulnerable to a Slapper worm attack ... I downloaded "Slapper worm like" code - available "for testing prupose only" - from somewhere on the Internet, modified it to ensure it will only attack my server when launched, and then launched it ... Everything occured normally, the virus didn't infect my computer, the same behaviour as the very first attacks. I used my httpd server and segfaulted it by doing it ... I have gdb'ed my httpd+core, and arrived on the same place in source code as mentioned in first first gdb log. The worm-like had crashed my apache. I checked logged and was the only one to attack the computer. That means that OpenSSL 0.9.6g is not safe right now ... I retried several times again but failed to reproduce the crash ... That's why I "feel like sure" :-) Anyway - and perhaps because of my parano. :) - I have closed my 443 window and wait for a better weather outside ;-) openssl-0.9.6h.tar.gz ? :) An
#19876 [Fbk->Opn]: Problem with parse_url() function...
ID: 19876 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *URL Functions Operating System: Windows 2000 Pro (Sp3) PHP Version: 4CVS-2002-10-11 New Comment: Here's a link to the phpinfo at my machine: http://onionman.homeip.net/phpinfo/ A weird thing i noticed is that if i have 'html_errors = Off' in my php.ini file, then phpinfo looses all it formatting and is unreadable... is it supposed to be like this? Anyway... i doublechecked the parse_url bug by going back to an older snapshot (2002-10-06), and there it works like expected... and then trying latest snap again (2002-10-12), and there it's the same result as before... so either something has introduced a bug there since last week... or my machine is behaving strange... ;) /OnionMan Previous Comments: [2002-10-11 23:00:11] [EMAIL PROTECTED] The 1 comes from 'echo print_r' you do not need to echo print_r() it'll do it automatically. The missing letter is something I am unable to replicate on any of my machines. Could you please should output of phpinfo() on your system, maybe that'll yeild some clues. [2002-10-11 22:54:02] [EMAIL PROTECTED] Snapshot used: php4-win32-200210120200.zip This simple script parses an ftp-url: ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news";; $parts = parse_url($url); echo ''."\n"; echo print_r($parts)."\n"; echo ''."\n"; ?> When i run the script i get this output: Array ( [scheme] => ftp [host] => www.moria.com [user] => gandalf [pass] => mello [path] => /foo/bar/index.php [query] => page=news ) 1 Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour. BTW: What does the 1 that is output after the value pairs mean? -- Edit this bug report at http://bugs.php.net/?id=19876&edit=1
#19716 [Fbk]: imap_headers() returns wrong number of items
ID: 19716
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: IMAP 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-10-03 01:08:36] [EMAIL PROTECTED]
I installed c-client from IMAP 2002 RC6.
[2002-10-02 10:50:02] [EMAIL PROTECTED]
What c-client version you have?
[2002-10-02 08:26:09] [EMAIL PROTECTED]
We are using Lotus Domino 5.0.11 as our IMAP server and it seems to
work all right with other clients (like Mozilla).
However when we run the script below it only returns correctly 7 oldest
messages. All other messages get the following error message: Bad
message number in /home/httpd/html/mail/messages.php
count returns 61 messages. It happens in other folders than INBOX too.
PHP was compiled using the following parameters:
./configure --with-mysql --with-apxs=/usr/sbin/apxs --with-imap
--enable-exif --with-kerberos --with-zlib --with-zlib-dir=/usr/lib
";
$link=imap_open("{localhost/imap}INBOX",$_SERVER['PHP_AUTH_USER'],$_SERVER['PHP_AUTH_PW']);
$sorted_array=imap_sort($link,SORTDATE,1);
$headers=imap_headers($link);
echo "Your messages (".count($sorted_array).")";
for ($x = 1;$x < count($sorted_array); $x++) {
$msgnum=next($sorted_array);
$header=imap_header($link,$msgnum, 80,80);
echo "$header->fromaddress:
".$header->subject." (ID: $msgnum)";
}
imap_close($link);
?>
--
Edit this bug report at http://bugs.php.net/?id=19716&edit=1
#19807 [Opn->Ctl]: math.c: In function `_php_math_zvaltobase' [...] `HUGE_VAL' undeclared
ID: 19807 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Compile Failure Operating System: Solaris 8 Sparc PHP Version: 4.2.3 -Assigned To: +Assigned To: edink New Comment: Marking as critical and assigning to Edin who put that code in math.c as fix for other bug: http://bugs.php.net/bug.php?id=14807 Previous Comments: [2002-10-08 01:14:45] [EMAIL PROTECTED] OK, so it's not x86 (the manpages on my system have no reference whatsoever to anything called HUGE_VAL, though) But why do dozens of other packages (including php 4.22) compile corrrectly? Is it just bad luck then ...? (btw. I had googled up the same page, but couldn't find out if and how the problem was solved there) [2002-10-07 21:20:07] [EMAIL PROTECTED] btw. Some man pages for solaris 8 also mention HUGE_VAL..so it's NOT x86 specific. [2002-10-07 21:19:29] [EMAIL PROTECTED] Did some creative searches with google and came across this: http://archives.postgresql.org/pgsql-admin/2001-04/msg00155.php I think you just have done something wrong or haven't installed some necessary package.. [2002-10-07 20:12:31] [EMAIL PROTECTED] Well, upgrading to gcc3.2 didn't help. HUGE_VAL ist still not defined in math.h. Isn't this a ix86 feature? [2002-10-07 19:00:56] [EMAIL PROTECTED] can someone on a Sparc try this on PHP4.3.0 ? 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/19807 -- Edit this bug report at http://bugs.php.net/?id=19807&edit=1
#19650 [Opn->Fbk]: 4.2.3 (!) "include" operator mistake
ID: 19650
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
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-10-07 12:18:47] [EMAIL PROTECTED]
Wow... I'm a fool, I have tested wrong PHP version! Error is still
actual.
But now I think I have found the bug place.
File main/fopen_wrappers.c, in function php_fopen_with_path, we can see
a piece of code:
if (IS_ABSOLUTE_PATH(filename, filename_length)) {
if ((php_check_safe_mode_include_dir(filename TSRMLS_CC)) == 0)
/* filename is in safe_mode_include_dir (or subdir) */
return php_fopen_and_set_opened_path(filename, mode, opened_path
TSRMLS_CC);
if (PG(safe_mode) && (!php_checkuid(filename, mode,
CHECKUID_CHECK_MODE_PARAM)))
return NULL;
return php_fopen_and_set_opened_path(filename, mode, opened_path
TSRMLS_CC);
}
/* else start to glue path from include_path */
...
Under Windows IS_ABSOLUTE_PATH is:
#define IS_ABSOLUTE_PATH(path, len) \
(len >= 2 && isalpha(path[0]) && path[1] == ':')
Of course, when Apache's mod_php4 makes "include" request for
"/home/localhost/www/phpinfo.php", program DOES NOT get into "if"
statement! And we get pathes something like
".//home/localhost/www/phpinfo.php" and
"c:/php/pear//home/localhost/www/phpinfo.php" when
include_path=".;c:/php/pear" (I have dumped "path" argument of
virtual_fopen function [tsrm_virtual-cwd.c] to watch such pathes).
We cannot modify IS_ABSOLUTE_PATH macro, because there is #define
COPY_WHEN_ABSOLUTE 2 before it, and core always think that "absolute"
part contains 2 characters - we'd like to thank developers of windows
port for that :-(. Path "/some/path" contains NONE "absolute"
characters ("z:/some/path" contains two - "z:").
But, if we patch:
- if (IS_ABSOLUTE_PATH(filename, filename_length)) {
+ if (IS_ABSOLUTE_PATH(filename, filename_length)
+ || IS_SLASH(*filename)) {
PHP begins to work!
I don't know would it cause a security problem with safe_mode. Code is
too tangled and duplicated (somebody likes "copy+paste" technique of
programming, I suppose).
Please correct this bug in next PHPs. Now I will patch it "by hands",
but I don't want our users to cry when they would install newer version
and it begin to trash.
[2002-10-05 18:49:02] [EMAIL PROTECTED]
Of course, not OK (-;
File c:\t.php:
File c:\test.php:
c:\php> php.exe -q < c:\t.php
Warning: Failed opening '/test.php' for inclusion
(include_path='.;c:\php4\pear') in - on line 2
c:\php> php.exe -q c:\t.php
!
Strange, isn't it?..
Good "/test.php", or not good, when I write
DocumentRoot /home/localhost/www
in httpd.conf, and then
GET /phpinfo.php HTTP/1.1
Apache calls /home/localhost/www/phpinfo.php, but not
./home/localhost/www (-; Well, 4.2.3 processes it correctly (and we may
close this bug report), but...
I meant that PHP 4.2.3 still have something wrong in its code, because
absolute-slashed pathes do not work sometimes (like in "< script",
maybe somewhere else?). Here, in Russia, we saying in such cases: "Heh,
something's wrong in Danish kingdom". (-; Today I tried to debug it,
but have not found a bug place. Maybe next time.
Good luck.
[2002-10-05 16:07:37] [EMAIL PROTECTED]
is not good
this is better:
ok?
[2002-10-05 15:35:28] [EMAIL PROTECTED]
New information about this bug.
1. Since version PHP 4.2.3 bug is "changed":
File /t.php AND ./t.php (identical):
Tests:
a) > php.exe c:\t.php - works
b) > php.exe \t.php - works
c) > php.exe /t.php - works
d) > php.exe
^Z
- DOES NOT work.
In version 4.1.2...4.2.2 a, b & c are not working.
2. Versions <= 4.1.1 work correctly.
So, I think there is only an error if PHP.exe v4.2.3+ gets program from
STDIN. Previous versions (<4.2.3) do not work with command-line
filename too.
[2002-10-01 10:49:52] [EMAIL PROTECTED]
A) same problem b) same submitter -> bogus
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/19650
--
Edit this bug report at http://bugs.php.net/?id=19650&edit=1
#16880 [Opn->Ctl]: max_execution_time affects large uploads
ID: 16880 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Scripting Engine problem Operating System: Windows 98 PHP Version: 4.2.0 New Comment: This should be fixed.. Previous Comments: [2002-10-04 08:20:06] [EMAIL PROTECTED] I have the same problem running Php 4.2 on IIS on a W2K server machine [2002-07-19 12:23:28] [EMAIL PROTECTED] I have the same problem running Php 4.2.1 on Apache on a win NT server machine [2002-06-16 00:25:53] [EMAIL PROTECTED] Yes, Apache 1.3.xx [2002-06-16 00:09:44] [EMAIL PROTECTED] Which webserver? Apache 1.3.xx? [2002-04-30 14:05:58] [EMAIL PROTECTED] Will this bug be fixed on PHP 4.2.1? It makes huge uploads impossible without basically making the max_execution_time setting useless and I'm sure most hosts will refuse to set this setting to 10 minutes :( Someone reported having the same problem under Windows 2000 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/16880 -- Edit this bug report at http://bugs.php.net/?id=16880&edit=1
#19730 [Opn->Fbk]: PHP --with-mysql reports the wrong client API version
ID: 19730
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
-Bug Type: Apache related
+Bug Type: MySQL related
Operating System: debian linux potato
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
Even as I'm pretty sure this is some problem in your system or an user
error..
Previous Comments:
[2002-10-04 19:21:39] [EMAIL PROTECTED]
yes, it does. Both the binary build and the apache module were built on
October 2, 2002, and they both show the correct build date.
[2002-10-04 18:29:07] [EMAIL PROTECTED]
Can you check what the build-date is in the phpinfo output where the
incorrect mysql version is shown?
(2nd line, iirc)
Does it match the date you build it?
[2002-10-04 13:08:36] [EMAIL PROTECTED]
Additionally, as I stated earlier, the PHP binary and the PHP Apache
modules are being compiled on the same server, with the same configure
options (except --with-apache).
Nothing on the server was changed between building the binary and the
module. They both used clean source trees (freshly untarred, even). The
binary reports the correct version, the module does not. The module
also does not report the version of the included MySQL libs, instead it
reports a version of MySQL that has never been installed on the server.
[2002-10-03 20:01:10] [EMAIL PROTECTED]
with regards to the beta string, I have known about the development
life cycle, and the alpha, beta, gamma, and release phases of
development for many years. MySQL 4 is doing wonderfully in production,
and we put each release through rigorous testing in house before
implementing it. You should try it out sometime.
With regards to the version string, there are no files on the
filesystem that match 3.23.35.
Have you tried to build it yet using the build method I sent? If so,
what were the results?
[2002-10-03 19:27:21] [EMAIL PROTECTED]
I hope you're aware that the 'beta' text in that version for mysql
really means that it's not ready for production..
Anyway, the api version shown in phpinfo() output comes from
mysql function called 'mysql_get_client_info()' and that is provided by
the mysql client libs and in the bundled mysql lib sources it's like
this:
mysql_get_client_info(void)
{
return (char*) MYSQL_SERVER_VERSION;
}
Try grepping your whole system for that incorrect version and you'll
find where it's defined..
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/19730
--
Edit this bug report at http://bugs.php.net/?id=19730&edit=1
#15209 [Opn->Ctl]: 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: Open +Status: Critical Bug Type: Scripting Engine problem Operating System: RH Linux 7.2 -PHP Version: 4.1.x - 4.2.1 +PHP Version: 4.3.0-dev New Comment: Marking as critical since this worked at some point. And there was also posting by [EMAIL PROTECTED] with a possible fix on [EMAIL PROTECTED] Previous Comments: [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. [2002-10-01 06:04:16] [EMAIL PROTECTED] Dup of #14251 [2002-08-19 14:01:08] [EMAIL PROTECTED] I am using AIX 4.3.3, Apache 1.3.26, mod_perl 1.26 and PHP 4.2.2 This problem is one of 2 that are causing compilation failures for me. The other is that the LARGE_FILE definition (in mod_perl's ap_config_auto.h) is causing "conflicting type" errors for mmap64 when compiling sapi_apache.c (I will raise a seperate bug report for this second problem) 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
#19833 [Com]: parse error
ID: 19833 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: SuSE Linux 7.1/8.0 PHP Version: 4.2.3 New Comment: Still not working. Is there a connection to http://bugs.php.net/bug.php?id=4839? Previous Comments: [2002-10-10 06:01:36] [EMAIL PROTECTED] sorry, I forgot one configuration-option: --with-fdftk=/usr/local/fdftk [2002-10-09 14:58:15] [EMAIL PROTECTED] all the same with SuSE 8.0 [2002-10-09 11:48:12] [EMAIL PROTECTED] tried with http://snaps.php.net/php4-latest.tar.gz and the same configuration as shown above. That's what i get after typing make: ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /usr/local/src/php4-200210090600/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' [2002-10-09 10:19:32] [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-09 10:18:38] [EMAIL PROTECTED] wrote a better summary 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/19833 -- Edit this bug report at http://bugs.php.net/?id=19833&edit=1
#19317 [Opn->Ctl]: cosmetic problem on line 308 in var_unserializer.c
ID: 19317 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Compile Warning Operating System: RedHat Linux 7.3 PHP Version: 4.2.3 Previous Comments: [2002-10-12 09:59:36] [EMAIL PROTECTED] Furthermore, this breaks build with gcc-3.2, so I don't think it is so smart to keep ignoring this. [2002-09-09 10:14:08] [EMAIL PROTECTED] There is a comparison (yych <= '\277') on line 308 in file /ext/standard/var_unserializer.c, which is never true (appeared first in "1.6.2.1 by stas"). I suppose that "goto yy15;" is correct, but the comparison is not OK. -- Edit this bug report at http://bugs.php.net/?id=19317&edit=1
#19033 [Ctl->Csd]: win32 snapshots broken / set_error_handler() to accepts object/method tuple
ID: 19033 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed Bug Type: Program Execution Operating System: Windows PHP Version: 4.2.1 Assigned To: edink New Comment: Closing then. Previous Comments: [2002-10-12 04:39:03] [EMAIL PROTECTED] Confirming. Newest Windows snapshot works OK. Thanks for fixing this bug. [2002-10-11 08:22:26] [EMAIL PROTECTED] Windows build was broken since Oct 7, so no new snapshots were generated. Now that has been fixed, so could you please try the latest snapshot? [2002-10-10 17:50:12] [EMAIL PROTECTED] Making this critical and assigned to edin. [2002-10-10 11:00:07] [EMAIL PROTECTED] OS update. [2002-10-10 10:55:56] [EMAIL PROTECTED] Verified: linux works Win32 snapshot from snaps.php.net seems to be b0rked. Can't check out CVS HEAD and test (besides that it's currently broken because of some recent changes). Reopening and thanks for insisting it doesn't work ;-) 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/19033 -- Edit this bug report at http://bugs.php.net/?id=19033&edit=1
#19324 [Ctl->Fbk]: show PHP source on client's browser
ID: 19324 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 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-09-30 06:18:43] [EMAIL PROTECTED] 3. showing source code 4. showing source code 5. showing source code 6. no source code 7. showing source code [2002-09-30 05:53:45] [EMAIL PROTECTED] 3 and 4 with the "php_engine = on" directive please (explicit). Derick [2002-09-30 05:50:54] [EMAIL PROTECTED] Hi , I have a small question to this bug, because I have the same problem. >1. stop apache >2. start apache in single process mode like: > /path/to/apache/httpd -X >3. Request a page from a vhost/directory where PHP is enabled >4. Do that again :) >5. Request a page from a vhost/directory where PHP is disabled >6. Request a page from a vhost/directory where PHP is enabled (but not >explicit with php_engine = on, just the 'default') >7. Request a page from a vhost/directory where PHP is enabled (implicit >wirth php_engine = on) >Please tell us when you see the source and when not. Test 3 and 4 with explicit php_engine directive or not (the same as 6)? However, with php_engine=on in a and also a concurrently php_engine off directive in another , Apache results always the source code on my virtualhost with php_engine=on. Regards, -- Steve [2002-09-30 03:27:58] [EMAIL PROTECTED] Will it fixed at next version? [2002-09-30 00:27:36] [EMAIL PROTECTED] Did you do the tests I asked you to do? 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/19324 -- Edit this bug report at http://bugs.php.net/?id=19324&edit=1
#18697 [Fbk->Opn]: HTTPS POST crashing
ID: 18697 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: Tried CVS snapshop but got exactly the same crash: (gdb) run -X Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 Previous Comments: [2002-10-12 02:21:37] [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-12 02:10:12] [EMAIL PROTECTED] For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-09-09 05:35:46] [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. [2002-09-09 05:31:19] [EMAIL PROTECTED] Well, just try it without... 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/18697 -- Edit this bug report at http://bugs.php.net/?id=18697&edit=1
#17826 [Com]: PHP 4.2.1 Apache SAPI is not compatible with Apache 2.0.39
ID: 17826 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.2.1 Assigned To: edink New Comment: I confirm that Apache 2.0.43 and latest PHP4 php4apache2.dll works perfectly. However, I haven't heard about php4ts.dll ? What for is that ? P.S. getting Tomcat 4.11 + Apache 2.0.43 + MySQL + PHP4 working together seems to be even more painfull that getting Apache 2 and PHP4 working together : ) Jari Previous Comments: [2002-10-11 14:17:54] [EMAIL PROTECTED] The problem with this message: "Cannot load C:/php4/sapi/php4apache2.dll into server: The specified module could not be found." Should be addressed as: 1. Install PHP/Apache 2. Copy required files from c:\php\dlls\ to c:\winnt\system32\ 3. Grab the latest php snapSnap (http://snaps.php.net/win32/) 4. Copy php4apache2.dll from the snap to c:php\sapi\ 5. Copy php4ts.dll from the snap c:winnt\system32 6. Edit Apache's configuration file and add: LoadModule php4_module c:/php/sapi/php4apache2.dll AddType application/x-httpd-php .php .phtml That's it (probably many are just missing the php4ts.dll part) [2002-10-11 08:37:20] [EMAIL PROTECTED] PHP will work with whatever is current Apache version at the time of its release. Newer versions of Apache2 often break backwards compatibility so php4apache2.dll will not work with them. So either use the version of Apache that is supported by that PHP release, or use (almost) always current snapshot from http://snaps.php.net/win32/ [2002-10-11 07:01:27] [EMAIL PROTECTED] Thank you for all the Help Its working perfect with the php4apache2.dll from the Prerelease PHP Version 4.2.4 from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip But it take alot of time to find this Bugreport. If you would add a little link from the Downloadpage of PHP to this Page, it would help many scared php-newbies like me ;) Thanks for all the help Chojin [2002-10-05 10:58:07] [EMAIL PROTECTED] after having some trouble with this myself on both apache 2.0.42 and 2.0.43 and finding this thread, i used just the php4apache2.dll file from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip with the rest of the files being php 4.2.3 ones, and it works perfectly now. havent seen any bugs so far. hope this helps someone :) [2002-10-04 00:30:50] [EMAIL PROTECTED] Hello. I figured this out. There is no other way than using a 2.0.36 version and apache2filter.dll ! That seems to work perfectly. Only problem is that where from you can find 2.0.36 version of the Apache. Here is location where from I downloaded it: http://apache.kr.net/dist/ I have now PHP 4.2.3, MySQL and Apache 2.0.36 up and running. I have done quite a few tests and I didn't face problems. In httpd.conf you need just following lines: LoadModule php4_module c:/www/bin/php4/experimental/apache2filter.dll DirectoryIndex index.php index.html index.html.var index.htm index.phtml index.php3 default.htm AddType application/x-httpd-php .php .php3 .phtml .php4 That all you need. Apache2filter.dll might be also problematic to find, but I found it from older PHP distributions (4.2.0, see http://ftp.proventum.net/pub/php/win32/) Greetings, Jari Hiltunen, aka OH4BC 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/17826 -- Edit this bug report at http://bugs.php.net/?id=17826&edit=1
#19876 [Opn->Fbk]: Problem with parse_url() function...
ID: 19876 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *URL Functions Operating System: Windows 2000 Pro (Sp3) PHP Version: 4CVS-2002-10-11 New Comment: The 1 comes from 'echo print_r' you do not need to echo print_r() it'll do it automatically. The missing letter is something I am unable to replicate on any of my machines. Could you please should output of phpinfo() on your system, maybe that'll yeild some clues. Previous Comments: [2002-10-11 22:54:02] [EMAIL PROTECTED] Snapshot used: php4-win32-200210120200.zip This simple script parses an ftp-url: ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news";; $parts = parse_url($url); echo ''."\n"; echo print_r($parts)."\n"; echo ''."\n"; ?> When i run the script i get this output: Array ( [scheme] => ftp [host] => www.moria.com [user] => gandalf [pass] => mello [path] => /foo/bar/index.php [query] => page=news ) 1 Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour. BTW: What does the 1 that is output after the value pairs mean? -- Edit this bug report at http://bugs.php.net/?id=19876&edit=1
#19033 [Com]: win32 snapshots broken / set_error_handler() to accepts object/method tuple
ID: 19033 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Program Execution Operating System: Windows PHP Version: 4.2.1 Assigned To: edink New Comment: Confirming. Newest Windows snapshot works OK. Thanks for fixing this bug. Previous Comments: [2002-10-11 08:22:26] [EMAIL PROTECTED] Windows build was broken since Oct 7, so no new snapshots were generated. Now that has been fixed, so could you please try the latest snapshot? [2002-10-10 17:50:12] [EMAIL PROTECTED] Making this critical and assigned to edin. [2002-10-10 11:00:07] [EMAIL PROTECTED] OS update. [2002-10-10 10:55:56] [EMAIL PROTECTED] Verified: linux works Win32 snapshot from snaps.php.net seems to be b0rked. Can't check out CVS HEAD and test (besides that it's currently broken because of some recent changes). Reopening and thanks for insisting it doesn't work ;-) [2002-10-10 10:44:30] [EMAIL PROTECTED] works fine for me with a 2 days old HEAD. you're doing something wrong. roman@freepuppy ~ 1005:0 > php -v PHP 4.4.0-dev (cli), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies roman@freepuppy ~ 1006:1 > tmp/scratch2 Notice: Undefined variable: fafa in /usr/home/roman/tmp/scratch2 on line 13 AAError Handled roman@freepuppy ~ 1007:0 > uname -sr FreeBSD 4.7-RC roman@freepuppy ~ 1008:0 > < tmp/scratch2 #!/usr/bin/env php 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/19033 -- Edit this bug report at http://bugs.php.net/?id=19033&edit=1
#19033 [Ctl->Csd]: win32 snapshots broken / set_error_handler() to accepts object/method tuple
ID: 19033 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed Bug Type: Program Execution Operating System: Windows PHP Version: 4.2.1 New Comment: Reopen only if you can confirm something..this is closed. (most likely not using recent enough snapshot and has installed it wrong) Previous Comments: [2002-10-12 09:44:35] [EMAIL PROTECTED] Reopening, status->critical. [2002-10-12 08:53:15] [EMAIL PROTECTED] Sorry to say, but it has to be reopened once more. This trunk works strange. Sometimes handler works, but in most situations it doesnt. I'm working with big part of code, and there i first time saw that sometimes handler doesnt work. Then i was trying to create tescase, and could not. Finaly i created test file, copied code from my comment and it's not working now. --- Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 8 AA Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 10 AA --- After Apache restart it worked once or twice. After few reloads bug appeard. Try to reproduce. Just reload part of code few times. PHP dev 4.3.0 Apache 2.43 Windows 2000 [2002-10-12 04:43:35] [EMAIL PROTECTED] Closing then. [2002-10-12 04:39:03] [EMAIL PROTECTED] Confirming. Newest Windows snapshot works OK. Thanks for fixing this bug. [2002-10-11 08:22:26] [EMAIL PROTECTED] Windows build was broken since Oct 7, so no new snapshots were generated. Now that has been fixed, so could you please try the latest snapshot? 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/19033 -- Edit this bug report at http://bugs.php.net/?id=19033&edit=1
#19877 [NEW]: Apache segmentation faults
From: [EMAIL PROTECTED] Operating system: RH Linux 7.2 PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: Apache segmentation faults I was using Apache 1.3.26 with PHP 4.2.1 for about 3 months with no problems, then one day I discovered unable to access certain PHP pages (IE would give me a Cannot Find Server error). In my error logs I get lines like this: [Fri Oct 11 21:10:55 2002] [notice] Apache/1.3.26 (Unix) PHP/4.2.1 configured -- resuming normal operations [Fri Oct 11 21:10:55 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) [Fri Oct 11 21:10:59 2002] [notice] child pid 1226 exit signal Segmentation fault (11) [Fri Oct 11 21:15:18 2002] [notice] caught SIGTERM, shutting down [Fri Oct 11 23:32:27 2002] [notice] Apache/1.3.27 (Unix) PHP/4.2.3 configured -- resuming normal operations [Fri Oct 11 23:32:27 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) [Fri Oct 11 23:32:41 2002] [notice] child pid 12347 exit signal Segmentation fault (11) [Fri Oct 11 23:32:41 2002] [notice] child pid 12345 exit signal Segmentation fault (11) [Fri Oct 11 23:32:42 2002] [notice] child pid 12348 exit signal Segmentation fault (11) [Fri Oct 11 23:32:42 2002] [notice] child pid 12346 exit signal Segmentation fault (11) I tried restarting apache (using both restart and stop/start), then rebooting my server, then recompiling and reinstalling both PHP and Apache (you can see in the error log how the version changes from 1.3.26/4.2.1 to 1.3.27/4.2.3) but nothing seemed to work. Other PHP scripts (including phpMyAdmin) work fine. The only difference I can see between the "offending" script and my functional ones is the broken one uses session_decode() and header(). As far as I know, everything was working fine until today. The only change was about a month ago, when I recompiled PHP and added in support for GD, Jpeg-6b, zlib and ldap. Could one of those be the source of error? My configure line is: ./configure --with-mysql --with-jpeg-dir=/root/jpeg-6b --with-gd --with-zlib --with-ldap --with-apache=/root/apache_1.3.27 --enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp --enable-debug --enable-sockets I tried diagnosing the problem using gdb but this is all I got: (gdb) run -X Starting program: /www/bin/httpd -X Program received signal SIGTRAP, Trace/breakpoint trap. 0x40001e90 in _start () at rtld.c:160 160 rtld.c: No such file or directory. in rtld.c (gdb) Nothing came up when I accessed the "culprit" scripts. The one error that I can see there occured immediately at the start and in both versions of Apache/PHP. -- Edit bug report at http://bugs.php.net/?id=19877&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19877&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19877&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19877&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19877&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19877&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19877&r=support Expected behavior: http://bugs.php.net/fix.php?id=19877&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19877&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19877&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19877&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19877&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19877&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19877&r=isapi
#19876 [NEW]: Problem with parse_url() function...
From: [EMAIL PROTECTED] Operating system: Windows 2000 Pro (Sp3) PHP version: 4CVS-2002-10-11 PHP Bug Type: *URL Functions Bug description: Problem with parse_url() function... Snapshot used: php4-win32-200210120200.zip This simple script parses an ftp-url: ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news";; $parts = parse_url($url); echo ''."\n"; echo print_r($parts)."\n"; echo ''."\n"; ?> When i run the script i get this output: Array ( [scheme] => ftp [host] => www.moria.com [user] => gandalf [pass] => mello [path] => /foo/bar/index.php [query] => page=news ) 1 Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour. BTW: What does the 1 that is output after the value pairs mean? -- Edit bug report at http://bugs.php.net/?id=19876&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19876&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19876&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19876&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19876&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19876&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19876&r=support Expected behavior: http://bugs.php.net/fix.php?id=19876&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19876&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19876&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19876&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19876&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19876&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19876&r=isapi
#19317 [Com]: cosmetic problem on line 308 in var_unserializer.c
ID: 19317 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Warning Operating System: RedHat Linux 7.3 PHP Version: 4.2.3 New Comment: Furthermore, this breaks build with gcc-3.2, so I don't think it is so smart to keep ignoring this. Previous Comments: [2002-09-09 10:14:08] [EMAIL PROTECTED] There is a comparison (yych <= '\277') on line 308 in file /ext/standard/var_unserializer.c, which is never true (appeared first in "1.6.2.1 by stas"). I suppose that "goto yy15;" is correct, but the comparison is not OK. -- Edit this bug report at http://bugs.php.net/?id=19317&edit=1
#19879 [Opn->Csd]: Failed build with simple options for apache2
ID: 19879
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: Debian GNU/Linux 3.0
PHP Version: 4.3.0-pre1
New Comment:
This is fixed in CVS. Would you be so kind to add the following line
after line 287:
TSRMLS_FETCH();
the code looks like this then:
{
char numbuf[NUM_BUF_SIZE];
char *cvt;
register int i = 0, j = 0;
int sign, decpt;
char decimal_point = EG(float_separator)[0];
TSRMLS_FETCH();
PRINTF_DEBUG(("sprintf: appenddouble(%x, %x, %x, %f, %d, '%c', %d,
%c)\n",
*buffer, pos, size, number, width, padding,
alignment, fmt));
regards,
Derick
Previous Comments:
[2002-10-12 03:32:38] [EMAIL PROTECTED]
Hello, plain unzipped php4.3.0-pre1.tar.bz2 and did ./configure
--with-apxs2=/usr/bin/apxs --prefix=/usr/local
And it failed
Here is the last bit of the compile
--
/bin/sh libtool --silent --mode=compile gcc -Iext/standard/
-I/root/php-4.3.0pre1/ext/standard/ -DPHP_ATOM_INC
-I/root/php-4.3.0pre1/include -I/root/php-4.3.0pre1/main
-I/root/php-4.3.0pre1 -I/usr/include/apache2 -I/root/php-4.3.0pre1/Zend
-I/root/php-4.3.0pre1/ext/xml/expat -D_REENTRANT
-I/root/php-4.3.0pre1/TSRM -DTHREAD=1 -g -O2 -pthread -DZTS
-prefer-pic -c /root/php-4.3.0pre1/ext/standard/formatted_print.c -o
ext/standard/formatted_print.lo
/root/php-4.3.0pre1/ext/standard/formatted_print.c: In function
`php_sprintf_appenddouble':
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: `tsrm_ls'
undeclared (first use in this function)
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: (Each
undeclared identifier is reported only once
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: for each
function it appears in.)
make: *** [ext/standard/formatted_print.lo] Error 1
--
Edit this bug report at http://bugs.php.net/?id=19879&edit=1
#19874 [NEW]: Case-insensitive strpos()
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.3.0-pre1 PHP Bug Type: Feature/Change Request Bug description: Case-insensitive strpos() Maybe I'm missing something, but a case-insensitive strpos() would be handy. Yeah, there's obvious ways around it, but a native function would be great. Regards, Hans -- Edit bug report at http://bugs.php.net/?id=19874&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19874&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19874&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19874&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19874&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19874&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19874&r=support Expected behavior: http://bugs.php.net/fix.php?id=19874&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19874&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19874&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19874&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19874&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19874&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19874&r=isapi
#19804 [Opn->Bgs]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: mcrypt related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: yes, it's perfectly safe. Previous Comments: [2002-10-09 11:22:54] [EMAIL PROTECTED] Re-opening bug cause I'm waiting for a response to the last comment I posted. Then you can close the bug after that. [2002-10-08 12:56:35] [EMAIL PROTECTED] Since the php.ini does nothing, I did find something interesting. When I changed the file path in php.ini to the open-source libmcrypt-2.5.3 that had been untarred but not configured or compiled. Here's what I did ... --clip-- mcrypt.algorithms_dir = /usr/local/src3/libmcrypt-2.5.3/modules/algorithms mcrypt.modes_dir = /usr/local/src3/libmcrypt-2.5.3/modules/modes --clip-- This fix my problem with the mcrypt stuffs. So, I looked into the files and saw bunch of files that end with *.c and *.h. So, why does it work with the open source files but not with the *.la or *.a files in /usr/local/lib/libmcrypt??? Do you have an explanation or an answer to this??? I would appreciate it. I want to know is is it safe for me to use the open source files?? Thanks! [2002-10-08 09:27:59] [EMAIL PROTECTED] I have this code in php.ini and it does nothing! --clip-- mcrypt.algorithms_dir = /usr/local/lib/libmcrypt mcrypt.modes_dir = /usr/local/lib/libmcrypt --clip-- [2002-10-08 09:25:45] [EMAIL PROTECTED] Again, this is NOT a bug. Just set the correct paths in php.ini mcrypt.modules_dir AND mcrypt.algorithms_dir are where your ciphers and modules are. As you already pasted in your first bugreport, this is "/usr/local/lib/libmcrypt". You see those files with ls -l ? That are your ciphers and modes. Derick [2002-10-08 09:21:58] [EMAIL PROTECTED] Re-opening the bug I tried many different ways as the PHP Manual stated and I still get the error messasges, 'Warning: mcrypt module initialization failed in '. When PHP manual stated about "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '')" I still get the error, so I tried the other examples. "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '/usr/lib/mcrypt-modes')" I still get the error message. Problme is I have no such directory as "mcrypt-modes" on the server. I also assumed that the 2nd parament refer to "mcrypt-algorithms" since the PHP Manual didn't anything about the 2nd parameter. I checked the PHP Info on the server, the 1st clipping showed the actual result before I add the two lines of code to php.ini. The 2nd clipping showed the actual result of hte 2nd line of codes. (mcrypt directory). --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt mcrypt.modes_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt --clip-- This still does not solve my problem. So, I did hte google search and came upon someone's PHP Info website and found this if their encryption function work. --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersarcfour blowfish-compat blowfish cast-128 cast-256 des enigma gost loki97 panama rc2 rijndael-128 rijndael-192 rijndael-256 safer-sk128 safer-sk64 saferplus serpent threeway tripledes twofish wake xtea Supported modescbc cfb ecb ncfb nofb ofb stream DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- Since mine still have no supported ciphers, so it explain why the php-mycrypt function don't work at all. I was trying to say that I have been working on it for almost a week and I can tell that PHP ./configure didn't find it and when compiling PHP, PHP does not take in hte libmcrypt algorithm. It only take in libmcrypt but not the algorithm or modes. So, I believe I stand correct on this php bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19804 -- Edit this bug report at http://bugs.php.net/?id=19804&edit=1
#19796 [Opn->Fbk]: Oracle query in array, returned by function: memory leak (no more high CPU load)
ID: 19796 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Performance problem Operating System: Digital Unix V4.0F 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-10-10 15:52:18] [EMAIL PROTECTED] With 4.2.3, the link with Oracle seems to have some problems as the server looks less responsive and with many queries, I have "arithmeric exceptions" in error_log of httpd so I'm going back to 4.0.4pl1 and its high CPU load... [2002-10-09 13:11:15] [EMAIL PROTECTED] What I'm wondering is wheter the memory is going to be given back to the system if it needs it ? With 4.0.4pl1, the VSZ/RSS numbers were above 150 M and never shrunk, which worried the system maintenance staff. I know such memory readings have to be carefully interpreted but it's still troubling... [2002-10-09 11:18:34] [EMAIL PROTECTED] Does this 'latest' version fix some items that could be related to my problems? [2002-10-09 09:38:30] [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-09 04:43:15] [EMAIL PROTECTED] I have compiled PHP 4.2.3 (was 4.0.4pl1) and tested my code: the high CPU load after code execution is no more there, but there is still memory leak: before: nobody19621 0.0 0.0 14.3M 560K ?? S16:32:09 0:00.00 /www/bin/httpd after: nobody19621 0.0 0.9 50.3M 37M ?? S16:32:09 0:33.91 /www/bin/httpd ^ ^^^ If I comment out "$retval[$key][$col_name]= $value", then I have: nobody20871 0.0 0.0 14.8M 1.9M ?? S17:24:49 0:00.03 /www/bin/httpd 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/19796 -- Edit this bug report at http://bugs.php.net/?id=19796&edit=1
#19875 [Bgs]: date/strtotime fails around time change
ID: 19875
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Date/time related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
strtotime is ok, mktime is affected... use gmmktime.
Derick
Previous Comments:
[2002-10-12 00:19:29] [EMAIL PROTECTED]
I know it's daylight savings time, but why doesn't
strtotime deal with it properly?
[2002-10-11 21:53:26] [EMAIL PROTECTED]
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
[2002-10-11 21:37:26] [EMAIL PROTECTED]
Updated summary line.
[2002-10-11 21:36:26] [EMAIL PROTECTED]
Here is a short script:
\n";
$okday = mktime(0,0,0,10,27,2002);
$oksun = strtotime("Sun",$okday);
$badmon = strtotime("Mon",$okday);
$okdif = $badmon - $oksun;
$oksunstr = date("Ymd.Hi",$oksun);
$badmonstr = date("Ymd.Hi",$badmon);
print "$okday $okdif $oksunstr $badmonstr \n";
echo "PHP version " . phpversion() . " \n";
?>
The output of the script is this:
1035097200 86400 20021020. 20021021.
1035702000 86400 20021027. 20021027.2300
PHP version 4.2.3
Although the difference between Sunday (Oct 27) and Monday is 24 hours,
the output from date shows it to be only 23.
--
Edit this bug report at http://bugs.php.net/?id=19875&edit=1
#19846 [Opn->Bgs]: FATAL: emalloc(): Unable to allocate 170864426 bytes when using imap function
ID: 19846 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: HP-UX 11.11 PHP Version: 4.2.2 New Comment: Compile the exts into PHP itself. ie. don't use phpize to compile such core extensions. You're obviously doing something wrong when linking and haven't even linked all necessary libs with them.. reopen if imap extension does not work when configured as normal extension. (and not as shared!) Previous Comments: [2002-10-10 09:24:35] [EMAIL PROTECTED] Mayby dumm question, hove do i load a static-module ? By the way i do not have a core ! Jesper [2002-10-10 08:48:04] [EMAIL PROTECTED] What exactly do you mean with 'linked by hand' ? You're very likely doing something that your shouldn't be doing..why don't you compile it as static extension? [2002-10-10 08:26:13] [EMAIL PROTECTED] Before try to get backtrace, please try cvs version also. [2002-10-10 08:24:53] [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. [2002-10-10 06:57:08] [EMAIL PROTECTED] Using pre-compiled apache 1.3.26 and php 4.2.2 as module from HP. Made imap extension with hp-ansi/c compiler CFLAGS=-Ae +DA1.1 +DS2.0 +z cd /opt/php-4.2.2/ext/imap phpize ./configure --with-imap=/opt/imap-2002.RC7/c-client --with-imap-ssl=/opt/apache/ssl make linked by hand with c-client "ld -b -o imap.sl *.o" Moved imap.sl to /opt/apache/php/lib/php/extension/imap.sl I get following error in apache error_log: FATAL: emalloc(): Unable to allocate 170864426 bytes when i try to use imap-functions, and no result in th ebrowser ! I have build other extension like oci8.sl, gd.sl, calendar.sl and ftp.sl that works the same way ! Hope sombody can help mee with this, i can se in the bug-database that there have been simmular problems in Windows erlier ? I have tryed the same with php 4.2.3 and with older c-clients but same error. Best regards Jesper Sivertsen -- Edit this bug report at http://bugs.php.net/?id=19846&edit=1
#19860 [Opn->Bgs]: Calling certain COM Objects causes PHP/Apache to hang
ID: 19860
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: COM related
Operating System: Windows 2000/SP3
PHP Version: 4.2.3
New Comment:
1.) if apache is running under a different user (system, apache,
whatever ...) outlook will run as that user and therefor might run the
first time for that user prompting for user input (creating an email
account and so on)
2.) doing UI things as a server is not a good thing(tm) because you
don't see what's going on
if php also hangs when you execute your script from the command line
then reopen this report.
harald
Previous Comments:
[2002-10-11 05:48:30] [EMAIL PROTECTED]
When calling certain com objects, like Outlook.Application, or my own
custom ones compiled in Visual basic, the webserver (Apache 1.3) will
hang, and needs to be restarted.
The code used was:
$myItem = new COM("Outlook.Application")l
$myItem = $objApp->CreateItem(olMailItem);
$a=$myItem->Recipients->Add("[EMAIL PROTECTED]");
$myItem->Subject="Subject";
$myItem->Body="This is a Body Section now.!";
$myItem->Display();
outlook.exe did load (appeared on the process list).
but that is where it stopped.
--
Edit this bug report at http://bugs.php.net/?id=19860&edit=1
#18697 [Fbk]: HTTPS POST crashing
ID: 18697 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: Compile curl also with debug symbols enabled.. Previous Comments: [2002-10-12 09:46:19] [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. As you can see, the bug is in curl itself. [2002-10-12 03:05:22] [EMAIL PROTECTED] Tried CVS snapshop but got exactly the same crash: (gdb) run -X Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-10-12 02:21:37] [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-12 02:10:12] [EMAIL PROTECTED] For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. 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/18697 -- Edit this bug report at http://bugs.php.net/?id=18697&edit=1
#18697 [Opn->Fbk]: HTTPS POST crashing
ID: 18697 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 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. As you can see, the bug is in curl itself. Previous Comments: [2002-10-12 03:05:22] [EMAIL PROTECTED] Tried CVS snapshop but got exactly the same crash: (gdb) run -X Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-10-12 02:21:37] [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-12 02:10:12] [EMAIL PROTECTED] For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-09-09 05:35:46] [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. 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/18697 -- Edit this bug report at http://bugs.php.net/?id=18697&edit=1
#19033 [Csd->Ctl]: win32 snapshots broken / set_error_handler() to accepts object/method tuple
ID: 19033 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Critical Bug Type: Program Execution Operating System: Windows PHP Version: 4.2.1 New Comment: Reopening, status->critical. Previous Comments: [2002-10-12 08:53:15] [EMAIL PROTECTED] Sorry to say, but it has to be reopened once more. This trunk works strange. Sometimes handler works, but in most situations it doesnt. I'm working with big part of code, and there i first time saw that sometimes handler doesnt work. Then i was trying to create tescase, and could not. Finaly i created test file, copied code from my comment and it's not working now. --- Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 8 AA Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 10 AA --- After Apache restart it worked once or twice. After few reloads bug appeard. Try to reproduce. Just reload part of code few times. PHP dev 4.3.0 Apache 2.43 Windows 2000 [2002-10-12 04:43:35] [EMAIL PROTECTED] Closing then. [2002-10-12 04:39:03] [EMAIL PROTECTED] Confirming. Newest Windows snapshot works OK. Thanks for fixing this bug. [2002-10-11 08:22:26] [EMAIL PROTECTED] Windows build was broken since Oct 7, so no new snapshots were generated. Now that has been fixed, so could you please try the latest snapshot? [2002-10-10 17:50:12] [EMAIL PROTECTED] Making this critical and assigned to edin. 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/19033 -- Edit this bug report at http://bugs.php.net/?id=19033&edit=1
#19833 [Opn->Bgs]: parse error
ID: 19833 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: SuSE Linux 7.1/8.0 PHP Version: 4.2.3 New Comment: The warning about `tempnam' is harmless. If your compiler treats warninsg as errors, that's too bad, but it's not bug in PHP anyway. Previous Comments: [2002-10-12 04:53:41] [EMAIL PROTECTED] Still not working. Is there a connection to http://bugs.php.net/bug.php?id=4839? [2002-10-10 06:01:36] [EMAIL PROTECTED] sorry, I forgot one configuration-option: --with-fdftk=/usr/local/fdftk [2002-10-09 14:58:15] [EMAIL PROTECTED] all the same with SuSE 8.0 [2002-10-09 11:48:12] [EMAIL PROTECTED] tried with http://snaps.php.net/php4-latest.tar.gz and the same configuration as shown above. That's what i get after typing make: ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /usr/local/src/php4-200210090600/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' [2002-10-09 10:19:32] [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/19833 -- Edit this bug report at http://bugs.php.net/?id=19833&edit=1
#15912 [Fbk->Csd]: thttpd: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Other web server Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: Closing. Previous Comments: [2002-10-12 09:41:11] [EMAIL PROTECTED] It seams to work now, thanks! I have lost the password for this bug :( [2002-10-03 22:50:57] [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-04-04 07:22:47] [EMAIL PROTECTED] updated subject. [2002-04-04 07:22:20] [EMAIL PROTECTED] So this was thttpd specific? Reclassified. [2002-03-27 13:33:26] [EMAIL PROTECTED] Tried the CVS version of today (20002-03-27) and the bug is still there. But I think it only happens when useing thttpd as SAPI. There is some code in sapi/thttpd/thttpd.c around line 195 that is suppose to fixit. 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/15912 -- Edit this bug report at http://bugs.php.net/?id=15912&edit=1
#15912 [Com]: thttpd: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Other web server Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: It seams to work now, thanks! I have lost the password for this bug :( Previous Comments: [2002-10-03 22:50:57] [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-04-04 07:22:47] [EMAIL PROTECTED] updated subject. [2002-04-04 07:22:20] [EMAIL PROTECTED] So this was thttpd specific? Reclassified. [2002-03-27 13:33:26] [EMAIL PROTECTED] Tried the CVS version of today (20002-03-27) and the bug is still there. But I think it only happens when useing thttpd as SAPI. There is some code in sapi/thttpd/thttpd.c around line 195 that is suppose to fixit. [2002-03-07 17:21:09] [EMAIL PROTECTED] The CVS version from yesterday (2002-03-06) 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/15912 -- Edit this bug report at http://bugs.php.net/?id=15912&edit=1
#18049 [Opn->Bgs]: LDAP over SSL (ldaps) not working
ID: 18049
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: LDAP related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.2.1
Assigned To: edink
New Comment:
Why do you ask these questions here when you could have got the answers
simply by searching with some search engine?!
http://www.openldap.org/lists/openldap-software/200108/msg00043.html
Bogusing this bug report since this really IS NOT any bug in PHP.
Previous Comments:
[2002-10-12 05:35:08] [EMAIL PROTECTED]
In the last week I did some testing. I used PHP 4.2.3 with your
php_ldap.dll on Win2000 and Apache 1.3.26. The OpenLDAP-server (slapd)
was running on Linux and Win2000, but I get the same results on both
platforms. I created the configuration-file
"C:\OpenLDAP\sysconf\ldap.conf" (I saw that string in php_ldap.dll) on
the machine, where PHP is running. In this file I put the
TLS_REQCERT-directive and tested with all 4 possible values:
never, allow: seems to work
try, demand: does not work, PHP always sends a client certificate,
which the LDAP-server can't accept (see above).
But there is no client certificate configured!?
[2002-10-03 19:10:46] [EMAIL PROTECTED]
From: http://www.openldap.org/doc/admin/tls.html
"11.2.2.6. TLS_REQCERT { never | allow | try | demand }
This directive is equivalent to the server's TLSVerifyClient option.
However, for clients the default value is demand and there generally
is no good reason to change this setting."
(I don't have any server setup so I can't test this myself now)
[2002-10-03 07:27:12] [EMAIL PROTECTED]
Thank you for compiling the dll with ssl-support.
It seems to work so far.
But now I have the problem, that PHP always wants to send a client
certificate, even with "TLSVerifyClient never" in slapd.conf. In the
debug-console of the LDAP-server I can read:
TLS trace: SSL3 alert read:fatal:unknown
TLS trace: SSL_accept:failed in SSLv3 read client certificate A
TLS: can't accept
TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
s3_pkt.c:964
Where can I configure, that PHP should not send a client certificate,
or where do I have to put it?
[2002-10-02 20:11:46] [EMAIL PROTECTED]
Could you please try:
http://ftp.proventum.net/pub/php/win32/temp/php_4.2.x_ldap.zip
[2002-10-01 20:48:07] [EMAIL PROTECTED]
Assigning to Edin, so he remembers to look into enabling the ssl
support for snapshots/releases.
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/18049
--
Edit this bug report at http://bugs.php.net/?id=18049&edit=1
#19868 [Opn->Fbk]: Libtool has to be called with 'libtool --finish' or apache2 will crash with php
ID: 19868 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: *Compile Issues +Bug Type: Apache2 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 This really shouldn't be necessary, please give the snapshot a try..(and don't do that libtool --finish when you test it :) Previous Comments: [2002-10-11 11:30:02] [EMAIL PROTECTED] Libtool has to be called with 'libtool --finish' or apache2 will crash with php. Which will confuse a LOT of users, it would be better to do this from the configure script right before the 'make install' goes to work. The cure for this would be to call 'libtool --finish' from the main directory where php has been unextracted and install the files after that. Just a thought... Let me know if this is going to be changed, I have to use the command manually before php will work with apache2. -- Edit this bug report at http://bugs.php.net/?id=19868&edit=1
#19857 [Opn->Fbk]: wddx_deserialize Does Not Work Properly with Complex Data Types
ID: 19857 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: WDDX related Operating System: Win XP Pro 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-10-11 00:56:04] [EMAIL PROTECTED] // Here is a valid WDDX packet with "layers" of PHP objects: $oItem= 'COptionhttp://localhost/Delisma/Menu/00.0825http://localhost/Delisma/Menu/00.0825 what size do you want22315.025.355good good stuffgood stuffpizza1coptionhttp://localhost/Delisma/Menu/00.0825 what size do you want22315.025.355good good stuffgood stuffsalad2coptionHello?223012185'Da bomb is hear again! This is a friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky Burger 60' ; // attempt to deserialize the WDDX packet: $oItem= wddx_deserialize( $oItem ) ; print_r( $oItem ) ; /* this will result in the following output; notice that fields, like $oItem->aoSuboptions[0]->iID do not get set in the deserialized version, even though they are contained in the original WDDX packet: ( [aoImages] => Array ( ) [aoSuboptions] => Array ( [0] => coption Object ( [aoImages] => [aoSuboptions] => [sConstructionErrors] => [iNumber] => [iPosition] => [oOptionSuboptions] => [oOptionTaxes] => [oOptionDiscounts] => [oOptionImages] => [aoOptionMenues] => [oItemCategories] => [iID] => [sName] => [sBriefDesc] => [sDetailedDesc] => [iTimesAvailable] => [fRetailPrice] => [fWholesalePrice] => [bTaxable] => [bDiscounted] => [bActive] => [iMinNumFreeSuboptions] => [iMaxNumFreeSuboptions] => [iMinNumPaidSuboptions] => [iMaxNumPaidSuboptions] => [sQuestion] => [sScriptRoot] => http://localhost/Delisma/Menu/ [fDiscountRate] => 0 [fTaxRate] => 0.0825 ) [1] => coption Object ( [aoImages] => [aoSuboptions] => [sConstructionErrors] => [iNumber] => [iPosition] => [oOptionSuboptions] => [oOptionTaxes] => [oOptionDiscounts] => [oOptionImages] => [aoOptionMenues] => [oItemCategories] => [iID] => [sName] => [sBriefDesc] => [sDetailedDesc] => [iTimesAvailable] => [fRetailPrice] => [fWholesalePrice] => [bTaxable] => [bDiscounted] => [bActive] => [iMinNumFreeSuboptions] => [iMaxNumFreeSuboptions] => [iMinNumPaidSuboptions] => [iMaxNumPaidSuboptions] => [sQuestion] => [sScriptRoot] => http://localhost/Delisma/Menu/ [fDiscountRate] => 0 [fTaxRate] => 0.0825 ) ) [sConstructionErrors] => [iNumber] => 55 [iPosition] => 0 [oOptionSuboptions] => [oOptionTaxes] => [oOptionDiscounts] => [oOptionImages] => [aoOptionMenues] => [oItemCategories] => [iID] => 0 [sName] => Wacky Burger 6 [sBriefDesc] => 'Dis Shit is Wack! [sDetailedDesc] => 'Da bomb is hear again! This is a friggin' quarter pound of good, good stuff! [iTimesAvailable] => 5 [fRetailPrice] => 18 [fWholesalePrice] => 12 [bTaxable] => 1 [bDiscounted] => [bActive] => 1 [iMinNumFreeSuboptions] => 0 [iMaxNumFreeSuboptions] => 3 [iMinNumPaidSuboptions] => 2 [iMaxNumPaidSuboptions] => 2 [sQuestion] => Hello? [sScriptRoot] => http://localhost/Delisma/Menu/ [fDiscountRate] => 0 [fTaxRate] => 0.0825 ) */ -- Edit this bug report at http://bugs.php.net/
#19867 [Opn->Fbk]: extract function and null values
ID: 19867 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Arrays related Operating System: Linux 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 And if the snapshot doesn't do what you expect, please add a short, self-contained example script here which shows the possible bug clearly. Previous Comments: [2002-10-11 11:20:18] [EMAIL PROTECTED] In earlier versions of PHP ... when looping through a set of database data, for example, and "extract"ing on each loop -- the extract function would overwrite the variable with the previous value, even if it was NULL. I just recently switched servers that had a more recent version of PHP. Now extract behaves differently. On the next pass through, the variable is not overwritten if the new value is NULL. This requires the use of "unset" on each loop for each variable that could have NULL values. I see nothing in the changelog about this, so I'm trying to determine if it's a bug, or was changed on purpose. If it's a change, I'm not sure I understand why, since it would seem to be much more useful to have it overwritten with the NULL value. -- Edit this bug report at http://bugs.php.net/?id=19867&edit=1
#18049 [Fbk->Opn]: LDAP over SSL (ldaps) not working
ID: 18049
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.2.1
Assigned To: edink
New Comment:
In the last week I did some testing. I used PHP 4.2.3 with your
php_ldap.dll on Win2000 and Apache 1.3.26. The OpenLDAP-server (slapd)
was running on Linux and Win2000, but I get the same results on both
platforms. I created the configuration-file
"C:\OpenLDAP\sysconf\ldap.conf" (I saw that string in php_ldap.dll) on
the machine, where PHP is running. In this file I put the
TLS_REQCERT-directive and tested with all 4 possible values:
never, allow: seems to work
try, demand: does not work, PHP always sends a client certificate,
which the LDAP-server can't accept (see above).
But there is no client certificate configured!?
Previous Comments:
[2002-10-03 19:10:46] [EMAIL PROTECTED]
From: http://www.openldap.org/doc/admin/tls.html
"11.2.2.6. TLS_REQCERT { never | allow | try | demand }
This directive is equivalent to the server's TLSVerifyClient option.
However, for clients the default value is demand and there generally
is no good reason to change this setting."
(I don't have any server setup so I can't test this myself now)
[2002-10-03 07:27:12] [EMAIL PROTECTED]
Thank you for compiling the dll with ssl-support.
It seems to work so far.
But now I have the problem, that PHP always wants to send a client
certificate, even with "TLSVerifyClient never" in slapd.conf. In the
debug-console of the LDAP-server I can read:
TLS trace: SSL3 alert read:fatal:unknown
TLS trace: SSL_accept:failed in SSLv3 read client certificate A
TLS: can't accept
TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
s3_pkt.c:964
Where can I configure, that PHP should not send a client certificate,
or where do I have to put it?
[2002-10-02 20:11:46] [EMAIL PROTECTED]
Could you please try:
http://ftp.proventum.net/pub/php/win32/temp/php_4.2.x_ldap.zip
[2002-10-01 20:48:07] [EMAIL PROTECTED]
Assigning to Edin, so he remembers to look into enabling the ssl
support for snapshots/releases.
[2002-07-22 12:05:54] [EMAIL PROTECTED]
Is really noone able to compile this dll with ssl-support?
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/18049
--
Edit this bug report at http://bugs.php.net/?id=18049&edit=1
#19292 [Ctl]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux -PHP Version: 4.2.3 +PHP Version: 4.3.0-dev,4.2.3 New Comment: update version info. Previous Comments: [2002-10-11 23:48:57] [EMAIL PROTECTED] I notice the same problem with an earlier version (4.1.2-5) on a Debian 3.0 system running Apache 1.3.26. Hope that provides aid in tracking this down. The script used to reproduce this is simply phpinfo(); [2002-10-11 13:15:49] [EMAIL PROTECTED] I can confirm the message from [EMAIL PROTECTED] Same problem here on several linux boxes that servers a nummer of virtual host. On some vhosts we have these error on every 2nd hit. There is a chance that these kind of error not effected is to the first vhost. I have made a test with the latest 'php4-20021010' with shows the same behavior. Realy weird is that the unkown error messages shows the WRONG settings (open_basedir) for that vhosts. Screenshot: http://sgi.takenet.de/~beh/error.gif They are 2 other things out there that apps that using pear(cache) shows open_basedir restrictions too. But the pear directory is always allowed. The make install prozess from the php latest and php-4.3rc1 shows both tng-web:/usr/src/php-4.3.0pre1 # make install Installing PHP SAPI module [activating module `php4' in /usr/apache/conf/httpd.conf] cp libs/libphp4.so /usr/apache/libexec/libphp4.so chmod 755 /usr/apache/libexec/libphp4.so cp /usr/apache/conf/httpd.conf /usr/apache/conf/httpd.conf.bak cp /usr/apache/conf/httpd.conf.new /usr/apache/conf/httpd.conf rm /usr/apache/conf/httpd.conf.new Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20020429/ Installing PHP CLI binary:/usr/bin/ Installing PEAR environment: /usr/lib/php/ Warning: file_exists() [http://www.php.net/function.file-exists]: SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /root owned by uid 0 in /daten/src/php-4.3.0pre1/pear/PEAR/Config.php on line 282 a lot of more warnings. Screenshot: http://sgi.takenet.de/~beh/error2.gif We are not using any kind of caching software or other 3rd party modules. And yes.. switching back to 4.2.1 solves all the problems without making any changes on configfiles (php.ini , httpd.conf) [2002-10-10 08:43:37] [EMAIL PROTECTED] Keep this at 'Critical' status. ([EMAIL PROTECTED]: Can you be a bit more specific? And did you test with PHP 4.3.0-dev there?) [2002-10-10 05:05:17] [EMAIL PROTECTED] Same here, yet only on one of four production boxes. Error randomly pops up, and is gone after reloading (seems to be only one apache child at a time is effected). Seems like the error occurs for all functions using file i/o, mainly include() in our case. [2002-10-09 13:13:09] [EMAIL PROTECTED] Could someone please check if this is still a problem in current CVS? 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#19878 [Opn->Bgs]: exec() function failed to execute win32 EXE programs
ID: 19878 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows 2000 Adv. Server 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-10-12 00:22:52] [EMAIL PROTECTED] I seem to have a problem running the exec() function. I created a php program that when user uploads a file it will automatically open an anti-virus program and check the specific file, but the execution didn't occur at all. Nothing happened. So I was wondering if exec will ever work if you run any win32 executable programs using exec(). Pease fix the bug please please. If you can give me a solution on how to resolve such problem, please let me know. Thanks, Jon -- Edit this bug report at http://bugs.php.net/?id=19878&edit=1
#18697 [Opn->Fbk]: HTTPS POST crashing
ID: 18697 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: cURL 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-10-12 02:10:12] [EMAIL PROTECTED] For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-09-09 05:35:46] [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. [2002-09-09 05:31:19] [EMAIL PROTECTED] Well, just try it without... Derick [2002-09-09 05:29:24] [EMAIL PROTECTED] I also have Zend Optimizer v2.0.0 installed - maybe this could be causing problems? 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/18697 -- Edit this bug report at http://bugs.php.net/?id=18697&edit=1
#19877 [Opn->Fbk]: Apache segmentation faults
ID: 19877 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: RH Linux 7.2 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 Try first the snapshot. If it crashes too: Just in case you didn't read this: http://bugs.php.net/bugs-generating-backtrace.php (add --enable-debug to your configure line) Also, did you update your php.ini at any time? And could you please add the shortest possible example script here which can be used to reproduce this problem.. Previous Comments: [2002-10-11 23:33:30] [EMAIL PROTECTED] I was using Apache 1.3.26 with PHP 4.2.1 for about 3 months with no problems, then one day I discovered unable to access certain PHP pages (IE would give me a Cannot Find Server error). In my error logs I get lines like this: [Fri Oct 11 21:10:55 2002] [notice] Apache/1.3.26 (Unix) PHP/4.2.1 configured -- resuming normal operations [Fri Oct 11 21:10:55 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) [Fri Oct 11 21:10:59 2002] [notice] child pid 1226 exit signal Segmentation fault (11) [Fri Oct 11 21:15:18 2002] [notice] caught SIGTERM, shutting down [Fri Oct 11 23:32:27 2002] [notice] Apache/1.3.27 (Unix) PHP/4.2.3 configured -- resuming normal operations [Fri Oct 11 23:32:27 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) [Fri Oct 11 23:32:41 2002] [notice] child pid 12347 exit signal Segmentation fault (11) [Fri Oct 11 23:32:41 2002] [notice] child pid 12345 exit signal Segmentation fault (11) [Fri Oct 11 23:32:42 2002] [notice] child pid 12348 exit signal Segmentation fault (11) [Fri Oct 11 23:32:42 2002] [notice] child pid 12346 exit signal Segmentation fault (11) I tried restarting apache (using both restart and stop/start), then rebooting my server, then recompiling and reinstalling both PHP and Apache (you can see in the error log how the version changes from 1.3.26/4.2.1 to 1.3.27/4.2.3) but nothing seemed to work. Other PHP scripts (including phpMyAdmin) work fine. The only difference I can see between the "offending" script and my functional ones is the broken one uses session_decode() and header(). As far as I know, everything was working fine until today. The only change was about a month ago, when I recompiled PHP and added in support for GD, Jpeg-6b, zlib and ldap. Could one of those be the source of error? My configure line is: ./configure --with-mysql --with-jpeg-dir=/root/jpeg-6b --with-gd --with-zlib --with-ldap --with-apache=/root/apache_1.3.27 --enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp --enable-debug --enable-sockets I tried diagnosing the problem using gdb but this is all I got: (gdb) run -X Starting program: /www/bin/httpd -X Program received signal SIGTRAP, Trace/breakpoint trap. 0x40001e90 in _start () at rtld.c:160 160 rtld.c: No such file or directory. in rtld.c (gdb) Nothing came up when I accessed the "culprit" scripts. The one error that I can see there occured immediately at the start and in both versions of Apache/PHP. -- Edit this bug report at http://bugs.php.net/?id=19877&edit=1
#19870 [Opn->Bgs]: Assertion failure in mips_emit_delays at ./config/tc-mips.c line 2231.
ID: 19870 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: LInux 4 Cobalt RAQ2 PHP Version: 4.2.3 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. Update your previous report about the SAME issue!! http://bugs.php.net/bug.php?edit=2&id=19854 Previous Comments: [2002-10-11 13:21:12] [EMAIL PROTECTED] hi, After getting latest php from CVS i still get same Attention message after running ./configure. CONFIGURE: './configure' '--with-apxs' '--with-mysql' '--with-gettext' '--with-xml' '--with-imap' '--enable-ftp' CC: gcc CFLAGS: -g -O2 CPPFLAGS:-D_XPG_IV -DCOBALT_RAQ_LED -DLINUX=2 CXX: CXXFLAGS: INCLUDES: -I$(top_builddir)/Zend -I/usr/local/include LDFLAGS: -Wl,-rpath,/usr/local/lib -L/usr/local/lib LIBS: -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lcrypt DLIBS: -lc-client SAPI: apache PHP_RPATHS: /usr/local/lib uname -a: Linux piper.remixnetworks.com 2.0.34C52_SK #1 Tue Nov 30 18:14:40 PST 1999 mips unknown gcc -o conftest -g -O2 -D_XPG_IV -DCOBALT_RAQ_LED -DLINUX=2 -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lcrypt 1>&5 /tmp/cca09867.s: Assembler messages: /tmp/cca09867.s:72: Internal error! Assertion failure in mips_emit_delays at ./config/tc-mips.c line 2231. Please report this bug. -- Edit this bug report at http://bugs.php.net/?id=19870&edit=1
#19878 [NEW]: exec() function failed to execute win32 EXE programs
From: [EMAIL PROTECTED] Operating system: Windows 2000 Adv. Server PHP version: 4.2.3 PHP Bug Type: IIS related Bug description: exec() function failed to execute win32 EXE programs I seem to have a problem running the exec() function. I created a php program that when user uploads a file it will automatically open an anti-virus program and check the specific file, but the execution didn't occur at all. Nothing happened. So I was wondering if exec will ever work if you run any win32 executable programs using exec(). Pease fix the bug please please. If you can give me a solution on how to resolve such problem, please let me know. Thanks, Jon -- Edit bug report at http://bugs.php.net/?id=19878&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19878&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19878&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19878&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19878&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19878&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19878&r=support Expected behavior: http://bugs.php.net/fix.php?id=19878&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19878&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19878&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19878&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19878&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19878&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19878&r=isapi
#19033 [Com]: win32 snapshots broken / set_error_handler() to accepts object/method tuple
ID: 19033 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Program Execution Operating System: Windows PHP Version: 4.2.1 New Comment: Sorry to say, but it has to be reopened once more. This trunk works strange. Sometimes handler works, but in most situations it doesnt. I'm working with big part of code, and there i first time saw that sometimes handler doesnt work. Then i was trying to create tescase, and could not. Finaly i created test file, copied code from my comment and it's not working now. --- Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 8 AA Notice: Undefined variable: fafa in E:\server\www\sports\futur\test.phtml on line 10 AA --- After Apache restart it worked once or twice. After few reloads bug appeard. Try to reproduce. Just reload part of code few times. PHP dev 4.3.0 Apache 2.43 Windows 2000 Previous Comments: [2002-10-12 04:43:35] [EMAIL PROTECTED] Closing then. [2002-10-12 04:39:03] [EMAIL PROTECTED] Confirming. Newest Windows snapshot works OK. Thanks for fixing this bug. [2002-10-11 08:22:26] [EMAIL PROTECTED] Windows build was broken since Oct 7, so no new snapshots were generated. Now that has been fixed, so could you please try the latest snapshot? [2002-10-10 17:50:12] [EMAIL PROTECTED] Making this critical and assigned to edin. [2002-10-10 11:00:07] [EMAIL PROTECTED] OS update. 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/19033 -- Edit this bug report at http://bugs.php.net/?id=19033&edit=1
#19875 [Com]: date/strtotime fails around time change
ID: 19875
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Date/time related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
I know it's daylight savings time, but why doesn't
strtotime deal with it properly?
Previous Comments:
[2002-10-11 21:53:26] [EMAIL PROTECTED]
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
[2002-10-11 21:37:26] [EMAIL PROTECTED]
Updated summary line.
[2002-10-11 21:36:26] [EMAIL PROTECTED]
Here is a short script:
\n";
$okday = mktime(0,0,0,10,27,2002);
$oksun = strtotime("Sun",$okday);
$badmon = strtotime("Mon",$okday);
$okdif = $badmon - $oksun;
$oksunstr = date("Ymd.Hi",$oksun);
$badmonstr = date("Ymd.Hi",$badmon);
print "$okday $okdif $oksunstr $badmonstr \n";
echo "PHP version " . phpversion() . " \n";
?>
The output of the script is this:
1035097200 86400 20021020. 20021021.
1035702000 86400 20021027. 20021027.2300
PHP version 4.2.3
Although the difference between Sunday (Oct 27) and Monday is 24 hours,
the output from date shows it to be only 23.
--
Edit this bug report at http://bugs.php.net/?id=19875&edit=1
#18697 [NoF->Opn]: HTTPS POST crashing
ID: 18697 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 Previous Comments: [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-09-09 05:35:46] [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. [2002-09-09 05:31:19] [EMAIL PROTECTED] Well, just try it without... Derick [2002-09-09 05:29:24] [EMAIL PROTECTED] I also have Zend Optimizer v2.0.0 installed - maybe this could be causing problems? [2002-09-09 03:31:01] [EMAIL PROTECTED] This is still happening with 4.2.3. However, it only seems to occur when posting to HTTPS URL's. I am using libcurl 7.9.8 (SSL 0.9.3) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18697 -- Edit this bug report at http://bugs.php.net/?id=18697&edit=1
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.3.0-dev,4.2.3 New Comment: i habve the same problems also with 4.30.pre1! Previous Comments: [2002-10-12 02:24:17] [EMAIL PROTECTED] update version info. [2002-10-11 23:48:57] [EMAIL PROTECTED] I notice the same problem with an earlier version (4.1.2-5) on a Debian 3.0 system running Apache 1.3.26. Hope that provides aid in tracking this down. The script used to reproduce this is simply phpinfo(); [2002-10-11 13:15:49] [EMAIL PROTECTED] I can confirm the message from [EMAIL PROTECTED] Same problem here on several linux boxes that servers a nummer of virtual host. On some vhosts we have these error on every 2nd hit. There is a chance that these kind of error not effected is to the first vhost. I have made a test with the latest 'php4-20021010' with shows the same behavior. Realy weird is that the unkown error messages shows the WRONG settings (open_basedir) for that vhosts. Screenshot: http://sgi.takenet.de/~beh/error.gif They are 2 other things out there that apps that using pear(cache) shows open_basedir restrictions too. But the pear directory is always allowed. The make install prozess from the php latest and php-4.3rc1 shows both tng-web:/usr/src/php-4.3.0pre1 # make install Installing PHP SAPI module [activating module `php4' in /usr/apache/conf/httpd.conf] cp libs/libphp4.so /usr/apache/libexec/libphp4.so chmod 755 /usr/apache/libexec/libphp4.so cp /usr/apache/conf/httpd.conf /usr/apache/conf/httpd.conf.bak cp /usr/apache/conf/httpd.conf.new /usr/apache/conf/httpd.conf rm /usr/apache/conf/httpd.conf.new Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20020429/ Installing PHP CLI binary:/usr/bin/ Installing PEAR environment: /usr/lib/php/ Warning: file_exists() [http://www.php.net/function.file-exists]: SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /root owned by uid 0 in /daten/src/php-4.3.0pre1/pear/PEAR/Config.php on line 282 a lot of more warnings. Screenshot: http://sgi.takenet.de/~beh/error2.gif We are not using any kind of caching software or other 3rd party modules. And yes.. switching back to 4.2.1 solves all the problems without making any changes on configfiles (php.ini , httpd.conf) [2002-10-10 08:43:37] [EMAIL PROTECTED] Keep this at 'Critical' status. ([EMAIL PROTECTED]: Can you be a bit more specific? And did you test with PHP 4.3.0-dev there?) [2002-10-10 05:05:17] [EMAIL PROTECTED] Same here, yet only on one of four production boxes. Error randomly pops up, and is gone after reloading (seems to be only one apache child at a time is effected). Seems like the error occurs for all functions using file i/o, mainly include() in our case. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
