#18404 [Com]: Session data being lost
ID: 18404 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.2 PHP Version: 4.3.0-dev New Comment: This sounds a lot like 20449? It's happening to me too by the way, same circumstances etc. Previous Comments: [2002-11-05 22:48:41] [EMAIL PROTECTED] that should be 200211030600 [2002-11-05 22:47:10] [EMAIL PROTECTED] It still happens with snapshot 20011030600 [2002-10-14 19:26:52] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-09-26 20:24:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-19 13:20:03] [EMAIL PROTECTED] just a side question, does this happen with PHP 4.2.3? There is a minor change between the two that makes a big difference between the way the two 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/18404 -- Edit this bug report at http://bugs.php.net/?id=18404&edit=1
#20808 [NEW]: configure script has a lines joined
From: [EMAIL PROTECTED] Operating system: Solaris 2.6 sparc PHP version: 4.3.0RC2 PHP Bug Type: *Compile Issues Bug description: configure script has a lines joined The area round line 53644 in configure looks like: #include #ifdef __cplusplus extern "C" #endif Unfortunately the #ifdef line is joined with the extern line with 70 spaces or so, so that it wraps nicely and hides this. This was already there in 4.2.3 (as I discovered today). Paul Slootman -- Edit bug report at http://bugs.php.net/?id=20808&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20808&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20808&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20808&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20808&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20808&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20808&r=support Expected behavior: http://bugs.php.net/fix.php?id=20808&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20808&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20808&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20808&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20808&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20808&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20808&r=isapi
#20808 [Fbk->Opn]: configure script has a lines joined
ID: 20808 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Solaris 2.6 sparc PHP Version: 4.3.0RC2 New Comment: No, the snapshot still has the problem. I found another place where it's wrong: besides line 53644, also on line 56677. Previous Comments: [2002-12-04 17:51:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-04 07:53:01] [EMAIL PROTECTED] The area round line 53644 in configure looks like: #include #ifdef __cplusplus extern "C" #endif Unfortunately the #ifdef line is joined with the extern line with 70 spaces or so, so that it wraps nicely and hides this. This was already there in 4.2.3 (as I discovered today). Paul Slootman -- Edit this bug report at http://bugs.php.net/?id=20808&edit=1
#20808 [Bgs]: configure script has a lines joined
ID: 20808 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Solaris 2.6 sparc PHP Version: 4.3.0RC2 New Comment: I checked the configure from the freshly unpacked tarball, md5sum: bc06e58150282fbd031abd662df8b1e1 configure $ grep -n '#ifdef __cplusplus *extern "C"$' configure 53644:#ifdef __cplusplus extern "C" 56677:#ifdef __cplusplus extern "C" Please look carefully, turn off line wrapping in your editor. Previous Comments: [2002-12-05 09:22:44] [EMAIL PROTECTED] I just checked the latest snapshot and the configure is just fine in it. If you're generating configure yourself, it's not our problem if your autoconf is broken. [2002-12-05 04:04:52] [EMAIL PROTECTED] No, the snapshot still has the problem. I found another place where it's wrong: besides line 53644, also on line 56677. [2002-12-04 17:51:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-04 07:53:01] [EMAIL PROTECTED] The area round line 53644 in configure looks like: #include #ifdef __cplusplus extern "C" #endif Unfortunately the #ifdef line is joined with the extern line with 70 spaces or so, so that it wraps nicely and hides this. This was already there in 4.2.3 (as I discovered today). Paul Slootman -- Edit this bug report at http://bugs.php.net/?id=20808&edit=1
#20808 [Com]: configure script has a lines joined
ID: 20808 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Solaris 2.6 sparc PHP Version: 4.3.0RC2 New Comment: Digging into the freshly unpacked source some more, I get the same line in different places: $ find php-4.3.0RC2 -type f | xargs grep -n '#ifdef __cplusplus *extern "C"$' /dev/null php-4.3.0RC2/ext/mysql/libmysql/acinclude.m4:230:#ifdef __cplusplus extern "C" php-4.3.0RC2/autom4te-2.53.cache/output.0:53644:#ifdef __cplusplus extern "C" php-4.3.0RC2/autom4te-2.53.cache/output.0:56677:#ifdef __cplusplus extern "C" php-4.3.0RC2/configure:53644:#ifdef __cplusplus extern "C" php-4.3.0RC2/configure:56677:#ifdef __cplusplus extern "C" (Here multiple spaces between the __cplusplus and the extern removed as the textarea input wrapping didn't display it correctly.) Especially the ext/mysql/libmysql/acinclude.m4 looks to me to be the real culprit. Previous Comments: [2002-12-05 09:29:36] [EMAIL PROTECTED] I checked the configure from the freshly unpacked tarball, md5sum: bc06e58150282fbd031abd662df8b1e1 configure $ grep -n '#ifdef __cplusplus *extern "C"$' configure 53644:#ifdef __cplusplus extern "C" 56677:#ifdef __cplusplus extern "C" Please look carefully, turn off line wrapping in your editor. [2002-12-05 09:22:44] [EMAIL PROTECTED] I just checked the latest snapshot and the configure is just fine in it. If you're generating configure yourself, it's not our problem if your autoconf is broken. [2002-12-05 04:04:52] [EMAIL PROTECTED] No, the snapshot still has the problem. I found another place where it's wrong: besides line 53644, also on line 56677. [2002-12-04 17:51:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-04 07:53:01] [EMAIL PROTECTED] The area round line 53644 in configure looks like: #include #ifdef __cplusplus extern "C" #endif Unfortunately the #ifdef line is joined with the extern line with 70 spaces or so, so that it wraps nicely and hides this. This was already there in 4.2.3 (as I discovered today). Paul Slootman -- Edit this bug report at http://bugs.php.net/?id=20808&edit=1
#9294 [Com]: File uploads take ~70 times longer than downloading files on Apache/PHP.
ID: 9294 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Performance problem Operating System: Solaris 2.6, 7, 8 and Windows 20 PHP Version: 4.0.2 New Comment: Retested with all versions of PHP 4.0.x and it still failed - super slow. However with version PHP 4.2.3 it works like a charm. A 200MB file uploads in 3-4 minutes when the client and server are on the same windows 2000 server - if uploading from a separate client (machine), to a separate server (apache web server on W2K), it takes about 30-40 seconds. Very good! Previous Comments: [2001-04-29 13:18:34] [EMAIL PROTECTED] Please try PHP 4.0.4pl1 or 4.0.5 which is due out tomorrow and open a new bug report if this still happens. [2001-02-16 03:59:04] [EMAIL PROTECTED] Sorry - I'm also using code like this to do the upload: Send this file: [2001-02-16 03:57:16] [EMAIL PROTECTED] When performing a file upload, PHP runs the CPU to 100% and takes 3.5-4 minutes on a Pentium III 850MHz CPU to upload a 10MB file when downloading the same file on Apache/PHP only takes 3 seconds on the same host and client. It appears the file is being parsed when being uploaded. Is there an option to tell PHP to upload the data and nothing else? Otherwise, it is roughly 70 times slower to upload a file than to download one. I'm using Nusphere's CD when installing the software. -- Edit this bug report at http://bugs.php.net/?id=9294&edit=1
Bug #16593: x^y gives unusual results
From: [EMAIL PROTECTED] Operating system: Win XP PHP version: 4.1.2 PHP Bug Type: *Math Functions Bug description: x^y gives unusual results x^y should always yield a positive number, however when doing -2^2 and (-2)^2, I get a result of -4! Surely this aint right? -- Edit bug report at http://bugs.php.net/?id=16593&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16593&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16593&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16593&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16593&r=support Expected behavior: http://bugs.php.net/fix.php?id=16593&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16593&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16593&r=submittedtwice
Bug #16767: session_start with mod_gzip issue
From: [EMAIL PROTECTED] Operating system: Redhat Linux 7.2 PHP version: 4.1.2 PHP Bug Type: Session related Bug description: session_start with mod_gzip issue Not sure if this is a bug in PHP, but it after some of the symptoms I've experienced, this is all I think it could be. With a server running Apache 1.3.24 (also tried 1.3.22 and 1.3.20) and mod_gzip/1.3.19.1a and PHP 4.2.0 (also tried 4.1.2), PHP pages that do not utilize the session_start command will load fine. However, the moment I put in the session_start command while using mod_gzip, the site will no longer load properly in Netscape 4.x and ONLY Netscape 4.x. It still works in all other browsers. Perhaps this is too trivial, and perhaps it's not PHP, but I want it to work! -- Edit bug report at http://bugs.php.net/?id=16767&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16767&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16767&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16767&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16767&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16767&r=support Expected behavior: http://bugs.php.net/fix.php?id=16767&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16767&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16767&r=submittedtwice
Bug #16767 Updated: session_start with mod_gzip issue
ID: 16767 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Redhat Linux 7.2 PHP Version: 4.1.2 New Comment: I just want to make this clear that all other files work fine with mod_gzip and PHP files that DON'T create user sessions work fine. It is when I begin to work with user sessions (i.e. call 'session_start()') that things stop working fine. Previous Comments: [2002-04-23 15:21:55] [EMAIL PROTECTED] Not sure if this is a bug in PHP, but it after some of the symptoms I've experienced, this is all I think it could be. With a server running Apache 1.3.24 (also tried 1.3.22 and 1.3.20) and mod_gzip/1.3.19.1a and PHP 4.2.0 (also tried 4.1.2), PHP pages that do not utilize the session_start command will load fine. However, the moment I put in the session_start command while using mod_gzip, the site will no longer load properly in Netscape 4.x and ONLY Netscape 4.x. It still works in all other browsers. Perhaps this is too trivial, and perhaps it's not PHP, but I want it to work! -- Edit this bug report at http://bugs.php.net/?id=16767&edit=1
Bug #16767 Updated: session_start with mod_gzip issue
ID: 16767 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Redhat Linux 7.2 PHP Version: 4.1.2 New Comment: I'm going to attribute this to a bug with Netscape and mod_gzip and cookies. Case closed. Previous Comments: [2002-04-23 15:42:13] [EMAIL PROTECTED] I just want to make this clear that all other files work fine with mod_gzip and PHP files that DON'T create user sessions work fine. It is when I begin to work with user sessions (i.e. call 'session_start()') that things stop working fine. [2002-04-23 15:21:55] [EMAIL PROTECTED] Not sure if this is a bug in PHP, but it after some of the symptoms I've experienced, this is all I think it could be. With a server running Apache 1.3.24 (also tried 1.3.22 and 1.3.20) and mod_gzip/1.3.19.1a and PHP 4.2.0 (also tried 4.1.2), PHP pages that do not utilize the session_start command will load fine. However, the moment I put in the session_start command while using mod_gzip, the site will no longer load properly in Netscape 4.x and ONLY Netscape 4.x. It still works in all other browsers. Perhaps this is too trivial, and perhaps it's not PHP, but I want it to work! -- Edit this bug report at http://bugs.php.net/?id=16767&edit=1
#19473 [NEW]: httpd segfaults
0x81dafc3 in main () #6 0x40473c6f in __libc_start_main () from /lib/libc.so.6 Any clues as to what might be wrong??? For reference, the fs is reiserfs, with a couple of mount points using ext3. Many thanks, Paul J -- Edit bug report at http://bugs.php.net/?id=19473&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19473&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19473&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19473&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19473&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19473&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19473&r=support Expected behavior: http://bugs.php.net/fix.php?id=19473&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19473&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19473&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19473&r=globals
#19473 [Fbk->Csd]: httpd segfaults
ID: 19473
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Apache related
Operating System: Linux 2.4.17 SMP (SuSE 7.2)
PHP Version: 4.2.3
New Comment:
My bad. I have found the cause of the problem.
Cheers,
Paul
Previous Comments:
[2002-09-18 18:59:22] [EMAIL PROTECTED]
It's obviously some clash with SSL. Are you sure you have linked every
library which you're compiling PHP with, with the SAME ssl libs? For
example Curl?
You should try configuring PHP first with minimal amount of
configure options and then try and add them one by one to see which one
causes this.
--Jani
[2002-09-18 05:40:18] [EMAIL PROTECTED]
Dear PHP,
I have just encountered the following problem when attempting to build
a large RPM of apache, mod_ssl, mod_auth_kerb and mod_php. The final
product will be a static build of apache with the modules listed.
Within the spec file I am configure php in the following manner:
./configure \
--prefix=%{_usr} \
--bindir=%{_bindir} \
--libdir=%{_libdir} \
--with-config-file-path=%{sysconfdir} \
--with-apache=../%{name_apache} \
--disable-rpath \
--with-pgsql=/usr \
--with-xml \
--enable-debug \
--enable-safe-mode \
--enable-memory-limit \
--with-kerberos \
--with-imap \
--with-imap-ssl \
--enable-versioning \
--with-gd \
--with-jpeg-dir=/usr \
--enable-xslt --with-xslt-sablot \
--enable-sysvshm --enable-sysvsem --with-regex=php \
--with-sockets \
--with-png-dir=/usr \
--with-zlib-dir=/usr \
--without-mysql \
--with-xpm-dir=/usr/X11R6 \
--with-curl
** NOTE: I removed --with-openssl in accordance with the solution
[EMAIL PROTECTED] provided for a similar looking bug with ENOTTY.
Apache configuration:
env \
'LIBS=-L/usr/kerberos/lib -lkrb5 -lk5crypto -lcom_err' \
'INCLUDES=-I/usr/include/openssl -I/usr/kerberos/include' \
'SSL_BASE=SYSTEM' \
'LDFLAGS=-L/usr/X11R6/lib' \
'-DKRB5 -DKRB_DEF_REALM=\\\"DOC.IC.AC.UK\\\"
-DSSL_EXPERIMENTAL_PERDIRCA_IGNORE' \
./configure \
--prefix=%{datadir} \
--bindir=%{_bindir} \
--sbindir=%{_sbindir} \
--datadir=%{datadir} \
--sysconfdir=%{sysconfdir} \
--mandir=%{_mandir} \
--logfiledir=%{logdir} \
--localstatedir=%{_var} \
--runtimedir=%{_var}/run \
--libexecdir=%{_libdir}/%{name} \
--proxycachedir=%{_var}/cache/http \
--includedir=%{includedir} \
--verbose \
--enable-module=info \
--enable-module=rewrite \
--enable-module=digest \
--enable-module=proxy \
--enable-module=auth_dbm \
--enable-module=ssl \
--enable-rule=SSL_SDBM \
--enable-rule=SSL_EXPERIMENTAL \
--add-module=src/modules/kerberos/mod_auth_kerb.c \
--with-perl=`which perl` \
--server-uid=%{apache_user} \
--server-gid=%{apache_group} \
--enable-suexec \
--suexec-logfile=/export/logs/suexec_log \
--activate-module=src/modules/php4/libphp4.a
strace on the httpd binary gives:
open("./php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/php.ini", O_RDONLY)= 3
getcwd("/usr/sbin", 4095) = 10
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=5566, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=205, ...}) = 0
lstat64("/etc/httpd/php.ini", {st_mode=S_IFREG|0400, st_size=2907,
...}) = 0
brk(0x8346000) = 0x8346000
ioctl(3, TCGETS, 0xb2ac)= -1 ENOTTY (Inappropriate
ioctl for dev
ice)
fstat64(3, {st_mode=S_IFREG|0400, st_size=2907, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0
x40018000
read(3, ";***"..., 8192) = 2907
read(3, "", 4096) = 0
brk(0x8347000) = 0x8347000
read(3, "", 8192) = 0
ioctl(3, TCGETS, 0xbfffe708)= -1 ENOTTY (Inappropriate
ioctl for dev
ice)
close(3)= 0
munmap(0x40018000, 4096)= 0
brk(0x8348000) = 0x8348000
brk(0x8349000) = 0x8349000
brk(0x834a000) = 0x834a000
brk(0x834b000) = 0x834b000
brk(0x834c000) = 0x834c000
brk(0x834d000) = 0x834d000
brk(0x834e000) = 0x834e000
brk(0x834f000) = 0x834f000
brk(0x835) = 0x835
brk(0x8351000) = 0x8351000
brk(0x8352000) = 0x8352000
brk(0x835300
#19473 [Bgs]: httpd segfaults
ID: 19473
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Apache related
Operating System: Linux 2.4.17 SMP (SuSE 7.2)
PHP Version: 4.2.3
New Comment:
Sure!!
Rather embarrassingly it was an error in my httpd.conf file. Basically,
we used to dynamically load php, mod_perl and all the apache modules
via httpd.conf. When building this new statically compiled server, I
simply copied across the old httpd.conf without thinking to remove the
LoadModule and AddModule lines. It turns out the presence of the
addmodule lines was sufficient to cause apache to segfault just around
the time strace reported it to be loading the php.ini file. Hence the
confusion :-)
Cheers,
Paul
Previous Comments:
[2002-09-19 05:07:15] [EMAIL PROTECTED]
Just in case someone else might have same problem, could
you please tell us what the problem was?
--Jani
[2002-09-19 04:06:58] [EMAIL PROTECTED]
user error -> not a bug
[2002-09-19 03:35:30] [EMAIL PROTECTED]
My bad. I have found the cause of the problem.
Cheers,
Paul
[2002-09-18 18:59:22] [EMAIL PROTECTED]
It's obviously some clash with SSL. Are you sure you have linked every
library which you're compiling PHP with, with the SAME ssl libs? For
example Curl?
You should try configuring PHP first with minimal amount of
configure options and then try and add them one by one to see which one
causes this.
--Jani
[2002-09-18 05:40:18] [EMAIL PROTECTED]
Dear PHP,
I have just encountered the following problem when attempting to build
a large RPM of apache, mod_ssl, mod_auth_kerb and mod_php. The final
product will be a static build of apache with the modules listed.
Within the spec file I am configure php in the following manner:
./configure \
--prefix=%{_usr} \
--bindir=%{_bindir} \
--libdir=%{_libdir} \
--with-config-file-path=%{sysconfdir} \
--with-apache=../%{name_apache} \
--disable-rpath \
--with-pgsql=/usr \
--with-xml \
--enable-debug \
--enable-safe-mode \
--enable-memory-limit \
--with-kerberos \
--with-imap \
--with-imap-ssl \
--enable-versioning \
--with-gd \
--with-jpeg-dir=/usr \
--enable-xslt --with-xslt-sablot \
--enable-sysvshm --enable-sysvsem --with-regex=php \
--with-sockets \
--with-png-dir=/usr \
--with-zlib-dir=/usr \
--without-mysql \
--with-xpm-dir=/usr/X11R6 \
--with-curl
** NOTE: I removed --with-openssl in accordance with the solution
[EMAIL PROTECTED] provided for a similar looking bug with ENOTTY.
Apache configuration:
env \
'LIBS=-L/usr/kerberos/lib -lkrb5 -lk5crypto -lcom_err' \
'INCLUDES=-I/usr/include/openssl -I/usr/kerberos/include' \
'SSL_BASE=SYSTEM' \
'LDFLAGS=-L/usr/X11R6/lib' \
'-DKRB5 -DKRB_DEF_REALM=\\\"DOC.IC.AC.UK\\\"
-DSSL_EXPERIMENTAL_PERDIRCA_IGNORE' \
./configure \
--prefix=%{datadir} \
--bindir=%{_bindir} \
--sbindir=%{_sbindir} \
--datadir=%{datadir} \
--sysconfdir=%{sysconfdir} \
--mandir=%{_mandir} \
--logfiledir=%{logdir} \
--localstatedir=%{_var} \
--runtimedir=%{_var}/run \
--libexecdir=%{_libdir}/%{name} \
--proxycachedir=%{_var}/cache/http \
--includedir=%{includedir} \
--verbose \
--enable-module=info \
--enable-module=rewrite \
--enable-module=digest \
--enable-module=proxy \
--enable-module=auth_dbm \
--enable-module=ssl \
--enable-rule=SSL_SDBM \
--enable-rule=SSL_EXPERIMENTAL \
--add-module=src/modules/kerberos/mod_auth_kerb.c \
--with-perl=`which perl` \
--server-uid=%{apache_user} \
--server-gid=%{apache_group} \
--enable-suexec \
--suexec-logfile=/export/logs/suexec_log \
--activate-module=src/modules/php4/libphp4.a
strace on the httpd binary gives:
open("./php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/php.ini", O_RDONLY)= 3
getcwd("/usr/sbin", 4095) = 10
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=5566, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=205, ...}) = 0
lstat64("/etc/httpd/php.ini", {st_mode=S_IFREG|0400, st_size=2907,
...}) = 0
brk(0x8346000) = 0x8346000
ioctl(3, TCGETS, 0xb2ac)= -1 ENOTTY (Inappropriate
ioctl for dev
ice)
fstat64(3, {st_mode=S_IFREG|0400, st_size=2907, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0
x40018000
read(3, ";*
#19909 [NEW]: No PCRE support for mbstring
From: [EMAIL PROTECTED] Operating system: any PHP version: 4.3.0-pre1 PHP Bug Type: mbstring related Bug description: No PCRE support for mbstring Mbstring doesn't provide support for PCRE. This is unfortunate since there is (experimental) UTF-8 support in PCRE which is as simple to turn on as flipping a compile flag and specifying an option to pcre_compile() -- Edit bug report at http://bugs.php.net/?id=19909&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19909&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19909&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19909&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19909&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19909&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19909&r=support Expected behavior: http://bugs.php.net/fix.php?id=19909&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19909&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19909&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19909&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19909&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19909&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19909&r=isapi
#20088 [NEW]: Custom authentication mechanism
From: [EMAIL PROTECTED]
Operating system: SuSE Linux 7.2
PHP version: 4.2.3
PHP Bug Type: Unknown/Other Function
Bug description: Custom authentication mechanism
The following code:
You have entered this username: $PHP_AUTH_USER
You have entered this password: $PHP_AUTH_PW
The authorization type is: $PHP_AUTH_TYPE
";
}
?>
fails. I believe the reason for this is that I have made the following
change to the PHP source:
--- php/sapi/apache/mod_php4.c.paj00Tue Sep 10 13:59:06 2002
+++ php/sapi/apache/mod_php4.c Tue Sep 10 13:59:17 2002
@@ -434,7 +434,7 @@
authorization = table_get(r->headers_in,
"Authorization");
}
if (authorization
-/* && !auth_type(r) */
+ && !auth_type(r)
&& !strcasecmp(getword(r->pool, &authorization, ' '),
"Basic")) {
tmp = uudecode(r->pool, authorization);
SG(request_info).auth_user = getword_nulls_nc(r->pool,
&tmp, ':');
I have made this change because of Bug #18391. However, custom
authentication methods, an example of which is entered above, now fail. I
would imagine that the two are linked.
As we use mod_auth_kerb I will not remove this patch because otherwise we
leave ourselves quite open to attack from the inside. Any suggestions on
how to get custom authentication working alongside the increased kerberos
security?
Thanks,
Paul
--
Edit bug report at http://bugs.php.net/?id=20088&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20088&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20088&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20088&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20088&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20088&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20088&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20088&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20088&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20088&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20088&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20088&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20088&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20088&r=isapi
#20088 [Fbk->Opn]: Custom authentication mechanism
ID: 20088
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: SuSE Linux 7.2
PHP Version: 4.2.3
New Comment:
Yes, register_globals is on. Did your test system have similar modules
(eg mod_auth_kerb etc) installed?
Previous Comments:
[2002-10-25 12:44:04] [EMAIL PROTECTED]
Works fine here. Do you have 'register_globals=On' ??
[2002-10-25 10:36:35] [EMAIL PROTECTED]
The following code:
You have entered this username: $PHP_AUTH_USER
You have entered this password: $PHP_AUTH_PW
The authorization type is: $PHP_AUTH_TYPE
";
}
?>
fails. I believe the reason for this is that I have made the
following change to the PHP source:
--- php/sapi/apache/mod_php4.c.paj00Tue Sep 10 13:59:06 2002
+++ php/sapi/apache/mod_php4.c Tue Sep 10 13:59:17 2002
@@ -434,7 +434,7 @@
authorization = table_get(r->headers_in,
"Authorization");
}
if (authorization
-/* && !auth_type(r) */
+ && !auth_type(r)
&& !strcasecmp(getword(r->pool, &authorization, ' '),
"Basic")) {
tmp = uudecode(r->pool, authorization);
SG(request_info).auth_user = getword_nulls_nc(r->pool,
&tmp, ':');
I have made this change because of Bug #18391. However, custom
authentication methods, an example of which is entered above, now fail.
I would imagine that the two are linked.
As we use mod_auth_kerb I will not remove this patch because otherwise
we leave ourselves quite open to attack from the inside. Any
suggestions on how to get custom authentication working alongside the
increased kerberos security?
Thanks,
Paul
--
Edit this bug report at http://bugs.php.net/?id=20088&edit=1
#20088 [Bgs]: Custom authentication mechanism
ID: 20088
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: HTTP related
Operating System: SuSE Linux 7.2
PHP Version: 4.2.3
New Comment:
The patch I applied to the source was on the recommendation of php.net
developers who said that the exact same patch would soon make it into
the main tree. Therefore I assumed they recognised the original
behaviour with revelation of kerberos passwords as a genuine bug.
Hence, with the patch applied I am now reporting that the custom
authentication method fails.
Sorry for being thick, but have I missed something?
Previous Comments:
[2002-10-27 21:25:19] [EMAIL PROTECTED]
Err, you have created a bug by modifying the PHP source, trying to fix
another bug? Why did you report this bug - anyhow, its marked bogus :)
[2002-10-27 10:49:56] [EMAIL PROTECTED]
Yes, register_globals is on. Did your test system have similar modules
(eg mod_auth_kerb etc) installed?
[2002-10-25 12:44:04] [EMAIL PROTECTED]
Works fine here. Do you have 'register_globals=On' ??
[2002-10-25 10:36:35] [EMAIL PROTECTED]
The following code:
You have entered this username: $PHP_AUTH_USER
You have entered this password: $PHP_AUTH_PW
The authorization type is: $PHP_AUTH_TYPE
";
}
?>
fails. I believe the reason for this is that I have made the
following change to the PHP source:
--- php/sapi/apache/mod_php4.c.paj00Tue Sep 10 13:59:06 2002
+++ php/sapi/apache/mod_php4.c Tue Sep 10 13:59:17 2002
@@ -434,7 +434,7 @@
authorization = table_get(r->headers_in,
"Authorization");
}
if (authorization
-/* && !auth_type(r) */
+ && !auth_type(r)
&& !strcasecmp(getword(r->pool, &authorization, ' '),
"Basic")) {
tmp = uudecode(r->pool, authorization);
SG(request_info).auth_user = getword_nulls_nc(r->pool,
&tmp, ':');
I have made this change because of Bug #18391. However, custom
authentication methods, an example of which is entered above, now fail.
I would imagine that the two are linked.
As we use mod_auth_kerb I will not remove this patch because otherwise
we leave ourselves quite open to attack from the inside. Any
suggestions on how to get custom authentication working alongside the
increased kerberos security?
Thanks,
Paul
--
Edit this bug report at http://bugs.php.net/?id=20088&edit=1
#20088 [Fbk->Csd]: Custom authentication mechanism
ID: 20088 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: HTTP related Operating System: SuSE Linux 7.2 PHP Version: 4.2.3 New Comment: Jani, Many thanks. Following on from your suggestion, I checked out the path from .htaccess to httpd.conf. Sure enough, as a globally set parameter in httpd.conf in a style config directive we have the following: AuthType KerberosV5 which I would imagine is causing the problem. Many thanks for your time, Paul Previous Comments: [2002-10-28 04:51:43] [EMAIL PROTECTED] Nevermind Sterling, he just wasn't aware of the patch..which btw. is in 4.3.0-dev already. Anyway, I'm still unable to reproduce this. I don't have time to install mod_auth_kerb right now. But the problem might be configuration related..are you sure you're not using the mod_auth_kerb within the same vhost/directory (not sure how it can be configured) as you're trying to run that php code in? --Jani [2002-10-28 04:04:17] [EMAIL PROTECTED] The patch I applied to the source was on the recommendation of php.net developers who said that the exact same patch would soon make it into the main tree. Therefore I assumed they recognised the original behaviour with revelation of kerberos passwords as a genuine bug. Hence, with the patch applied I am now reporting that the custom authentication method fails. Sorry for being thick, but have I missed something? [2002-10-27 21:25:19] [EMAIL PROTECTED] Err, you have created a bug by modifying the PHP source, trying to fix another bug? Why did you report this bug - anyhow, its marked bogus :) [2002-10-27 10:49:56] [EMAIL PROTECTED] Yes, register_globals is on. Did your test system have similar modules (eg mod_auth_kerb etc) installed? [2002-10-25 12:44:04] [EMAIL PROTECTED] Works fine here. Do you have 'register_globals=On' ?? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20088 -- Edit this bug report at http://bugs.php.net/?id=20088&edit=1
Bug #14883 Updated: Remote vulnerability allows access to ALL files on webserver
ID: 14883 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Windows NT (all Win32) PHP Version: 4.1.1 New Comment: Actually, this exploit allows anyone to gain root access to the Machine and so the severity should be ugraded to High. Previous Comments: [2002-01-06 02:12:42] [EMAIL PROTECTED] Report yesterday (4 Jan 02) at http://www.securiteam.com/windowsntfocus/5ZP030U60U.html outlines the security hole. I have tested it on NT4, Apache 1.3.9, PHP 4.0.4 and then upgraded to NT4, Apache 1.3.22, PHP 4.1.1 and the problem remains. I've been monitoring the PHP newsgroups (announcements and Windows user lists) since the vulnerability was announced and searched the buglist but haven't found mention of it anywhere. -- Edit this bug report at http://bugs.php.net/?id=14883&edit=1
#20596 [NEW]: date function gives wrong result for format 't'
From: [EMAIL PROTECTED] Operating system: WIN 2000 PHP version: 4.2.1 PHP Bug Type: Date/time related Bug description: date function gives wrong result for format 't' -- Edit bug report at http://bugs.php.net/?id=20596&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20596&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20596&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20596&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20596&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20596&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20596&r=support Expected behavior: http://bugs.php.net/fix.php?id=20596&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20596&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20596&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20596&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20596&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20596&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20596&r=isapi
Bug #16702: Apache Child Segfault (11) with null custom session_id
_process_request #12 0x663c in child_main #13 0x68ac in make_child #14 0x6bfc in perform_idle_server_maintenance #15 0x7180 in standalone_main #16 0x7840 in main #17 0x26e4 in _start #18 0x2514 in start PPC Thread State: srr0: 0x00f979a8 srr1: 0x0200f030vrsave: 0x xer: 0x0008 lr: 0x01049154 ctr: 0x0104be84 mq: 0x r0: 0x01049154 r1: 0xbfffd660 r2: 0xbfffdb70 r3: 0x001e0430 r4: 0xbfffd6ec r5: 0xbfffd6f0 r6: 0xbfffd6f4 r7: 0x r8: 0xbfffd6e8 r9: 0x001eccd0 r10: 0x00055140 r11: 0x00055178 r12: 0x0104be84 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x0000 r23: 0x r24: 0x r25: 0x r26: 0xbfffd6e8 r27: 0xbfffd6ec r28: 0xbfffd6f0 r29: 0xbfffd6ec r30: 0x276e6f27 r31: 0x0104909c ** Thanks. Let me know if I can provide further information. Paul -- Edit bug report at http://bugs.php.net/?id=16702&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16702&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16702&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16702&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16702&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16702&r=support Expected behavior: http://bugs.php.net/fix.php?id=16702&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16702&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16702&r=submittedtwice
#19386 [Fbk->Opn]: crash at if (preg_match('/(.|[\r\n])+/', $x)):
ID: 19386 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: * PHP Version: 4.2.3, 4.3.0-dev New Comment: Tests of different lengths of string '$x' show that if strlen($x) > 4040 the crash occurs i.e. with the last text is 'Randomized-Controlled-Trial' php will crash. A shorter script as requested is: $len\n"; } ?> Previous Comments: [2002-09-13 12:31:15] [EMAIL PROTECTED] I can reproduce the crash on Linux too. But could you try shortening the example script to something bit smaller? [2002-09-13 09:53:19] [EMAIL PROTECTED] By php version 4.3.1 I mean 4.2.1 of course ;-) [2002-09-13 07:20:54] [EMAIL PROTECTED] Crash also occurred with php version 4.3.1. Binary windows version was used in both cases. Doe not occur for all values of $x (probably only for very long strings ?). -- Edit this bug report at http://bugs.php.net/?id=19386&edit=1
#19386 [Fbk->Opn]: crash at if (preg_match('/(.|[\r\n])+/', $x)):
ID: 19386 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: * PHP Version: 4.2.3, 4.3.0-dev New Comment: I've reproduced this using the php4-win32-latest snapshot. The only difference is that it crashes at char 3915 instead of 4041. Sorry, but not gdb hence no backtrace. Previous Comments: [2002-09-17 07:56:38] [EMAIL PROTECTED] And I can still reproduce it with the short script and using latest CVS. (which has the new pcre lib) [2002-09-17 07:10:20] [EMAIL PROTECTED] I didn't see that Jani reproduced this. FWIW, I can not reproduce using current CVS or with PHP 4.2.1 (the oldest version I had to hand just now) using the short script that you provided. [2002-09-17 07:03:48] [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. Could you supply a backtrace? Also, could you try with a non-stable snapshot from the last couple of days as the PCRE library was updated recently. [2002-09-17 05:22:14] [EMAIL PROTECTED] Tests of different lengths of string '$x' show that if strlen($x) > 4040 the crash occurs i.e. with the last text is 'Randomized-Controlled-Trial' php will crash. A shorter script as requested is: $len\n"; } ?> [2002-09-13 12:31:15] [EMAIL PROTECTED] I can reproduce the crash on Linux too. But could you try shortening the example script to something bit smaller? 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/19386 -- Edit this bug report at http://bugs.php.net/?id=19386&edit=1
#17915 [Com]: cannot compile php with openldap support
ID: 17915 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.2.1 New Comment: This is still a problem on the latest STABLE snapshot from php4-STABLE-200209230900. Adding the TSRMLS_FETCH(); just before line 2030 in ldap.c does indeed resolve the problem on Solaris 2.8 (SPARC) w/gcc-3.1 in 64-bit mode. Previous Comments: [2002-06-21 18:23:28] [EMAIL PROTECTED] This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. The proper fix is to call TSRMLS_FETCH(); right after the variable decelartions in _ldap_rebind_proc [2002-06-21 18:12:19] [EMAIL PROTECTED] PHP 4.2.1 cannot be compiled with openldap support. Compilation fails on ext/ldap/ldap.c, producing error in line 2030: ldap.c:2030: `tsrm_ls' undeclared (first use in this function) Line 2030 uses TSRMLS_CC, which is defined in TSRM/TSRM.h to be #define TSRMLS_Ctsrm_ls #define TSRMLS_CC , TSRMLS_C But, tsrm_ls has never been defined ! Although TSRMLS_CC has been used in other places in ldap.c, only in line 2030 it creates problem. It looks that source of the problem is that function is defined as: int _ldap_rebind_proc ... so it is not PHP function, and tsrm_ls is not implicitly defined. Adding following line in ldap.c, just before line 2030: void ***tsrm_ls; /* Added by [EMAIL PROTECTED] */ fixes the problem. Regards, Sasa Milic -- Edit this bug report at http://bugs.php.net/?id=17915&edit=1
Bug #15998: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
From: [EMAIL PROTECTED] Operating system: Linux/Unix Redhat PHP version: 4.1.2 PHP Bug Type: Mail related Bug description: Difference in mail() function in PHP 4.1.2, causes delay in sending mail. There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit bug report at http://bugs.php.net/?id=15998&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15998&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15998&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15998&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15998&r=support Expected behavior: http://bugs.php.net/fix.php?id=15998&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15998&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15998&r=submittedtwice
Bug #15998 Updated: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
ID: 15998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Mail related Operating System: Linux/Unix Redhat PHP Version: 4.1.2 New Comment: The servers are responding fine. Sendmail was working fine from the command line, before AND after the PHP upgrade, but the php mail() command was taking a VERY long time until I added all the IP details to /etc/hosts. Now it works fine. Previous Comments: [2002-03-11 11:00:05] [EMAIL PROTECTED] There were no code changes to the mail() function code between 4.1.0 and 4.1.2. And even if there was, all mail() does is open a pipe to your sendmail or equivalent mail delivery program. PHP does not try to do any domain name resolution on the addresses so this DNS delay you are experiencing can not possibly be PHP related as the DNS resolution is done by the external mail delivery program. You probably changed something else on your system. Check your /etc/resolv.conf and make sure the DNS servers listed there are responding quickly. [2002-03-11 10:36:47] [EMAIL PROTECTED] There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit this bug report at http://bugs.php.net/?id=15998&edit=1
Bug #61599 [Com]: Wrong Day of Week
Edit report at https://bugs.php.net/bug.php?id=61599&edit=1
ID: 61599
Comment by: paul at paul-robinson dot us
Reported by:grom358_spamkill at yahoo dot com dot au
Summary:Wrong Day of Week
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I can confirm this bug, which I originally thought was in Wikimedia.
";
$h = mktime(0, 0, 0, 1, 1, 1599);
$d = date("F dS, Y", $h) ;
$w= date("l", $h) ;
Echo "$d is on a $w";
?>
Returns:
January 01st, 1600 is on a Saturday
January 01st, 1599 is on a Saturday
January 1, 1599 was a Friday.
I did a few other tests for Wikimedia, you can see how they show up there.
http://en.wikipedia.org/w/index.php?title=Template:X8&oldid=557212409
Another version:
";
$h = mktime(0, 0, 0, 1, 1, 1599);
$d = date("F dS, Y", $h) ;
$w= date("l", $h) ;
Echo "$d is on a $w, ";
$h = mktime(0, 0, 0, 1, 1, 1598);
$d = date("F dS, Y", $h) ;
$w= date("l", $h) ;
Echo "$d is on a $w";
?>
Results:
May 28th, 2013 is on a Tuesday, January 01st, 2013 is on a Tuesday, January
01st, 1901 is on a Tuesday, January 01st, 1900 is on a Monday, January 01st,
1601 is on a Monday, January 01st, 1600 is on a Saturday
January 01st, 1599 is on a Saturday, January 01st, 1598 is on a Friday
Today, 2013, 1901, 1900, 1601 and 1600 are correct.
1599 and 1598 are incorrect. 1599 was a Friday, 1598 was a Thursday.
Previous Comments:
[2012-05-13 22:29:02] grom358_spamkill at yahoo dot com dot au
Just to make it clearer, run the following:
setDate(1599, 12, 31);
echo $date->format('l, jS F Y') . PHP_EOL;
$date->setDate(1600, 1, 1);
echo $date->format('l, jS F Y') . PHP_EOL;
You will see there is two saturdays in a row :O
[2012-05-12 23:57:26] grom358_spamkill at yahoo dot com dot au
@zhanglijiu it should return Friday so your results confirm this bug
[2012-05-11 15:54:22] zhanglijiu at gmail dot com
According to your code,my results is "Saturday, 15th October 1582 Saturday,
31st
December 1599", there is nothing wrong.
My system is Mac 10.6.8 PHP 5.3.1
[2012-04-02 06:08:04] grom358_spamkill at yahoo dot com dot au
Description:
The 15th October 1582 is a Friday (see
http://en.wikipedia.org/wiki/Gregorian_calendar). Testing with Python and Java
confirms this as well. Also checked the Gnome calendar.
The Proleptic Gregorian Calendar (see
http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar) just extends the
Gregorian calendar backwards. I'm assuming PHP is using proleptic calendar,
which
would make 4th october 1582 a monday. But again DateTime gets it wrong.
I made a script to find the breaking point, and it occurs at 31st December
1599.
It returns it as a Saturday when in fact its a Friday.
Test script:
---
setDate(1582, 10, 15);
echo $date->format('l, jS F Y') . PHP_EOL;
$date->setDate(1599, 12, 31);
echo $date->format('l, jS F Y') . PHP_EOL;
Expected result:
Friday, 15th October 1582
Friday, 31st December 1599
Actual result:
--
Saturday, 15th October 1582
Saturday, 31st December 1599
--
Edit this bug report at https://bugs.php.net/bug.php?id=61599&edit=1
Bug #61599 [Com]: Wrong Day of Week
Edit report at https://bugs.php.net/bug.php?id=61599&edit=1
ID: 61599
Comment by: paul at paul-robinson dot us
Reported by:grom358_spamkill at yahoo dot com dot au
Summary:Wrong Day of Week
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
This was reported (in error) to Wikimedia for their Wikipedia software, the bug
number is 48907:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48907
Previous Comments:
[2013-05-28 19:47:06] paul at paul-robinson dot us
I can confirm this bug, which I originally thought was in Wikimedia.
";
$h = mktime(0, 0, 0, 1, 1, 1599);
$d = date("F dS, Y", $h) ;
$w= date("l", $h) ;
Echo "$d is on a $w";
?>
Returns:
January 01st, 1600 is on a Saturday
January 01st, 1599 is on a Saturday
January 1, 1599 was a Friday.
I did a few other tests for Wikimedia, you can see how they show up there.
http://en.wikipedia.org/w/index.php?title=Template:X8&oldid=557212409
Another version:
";
$h = mktime(0, 0, 0, 1, 1, 1599);
$d = date("F dS, Y", $h) ;
$w= date("l", $h) ;
Echo "$d is on a $w, ";
$h = mktime(0, 0, 0, 1, 1, 1598);
$d = date("F dS, Y", $h) ;
$w= date("l", $h) ;
Echo "$d is on a $w";
?>
Results:
May 28th, 2013 is on a Tuesday, January 01st, 2013 is on a Tuesday, January
01st, 1901 is on a Tuesday, January 01st, 1900 is on a Monday, January 01st,
1601 is on a Monday, January 01st, 1600 is on a Saturday
January 01st, 1599 is on a Saturday, January 01st, 1598 is on a Friday
Today, 2013, 1901, 1900, 1601 and 1600 are correct.
1599 and 1598 are incorrect. 1599 was a Friday, 1598 was a Thursday.
[2012-05-13 22:29:02] grom358_spamkill at yahoo dot com dot au
Just to make it clearer, run the following:
setDate(1599, 12, 31);
echo $date->format('l, jS F Y') . PHP_EOL;
$date->setDate(1600, 1, 1);
echo $date->format('l, jS F Y') . PHP_EOL;
You will see there is two saturdays in a row :O
[2012-05-12 23:57:26] grom358_spamkill at yahoo dot com dot au
@zhanglijiu it should return Friday so your results confirm this bug
[2012-05-11 15:54:22] zhanglijiu at gmail dot com
According to your code,my results is "Saturday, 15th October 1582 Saturday,
31st
December 1599", there is nothing wrong.
My system is Mac 10.6.8 PHP 5.3.1
[2012-04-02 06:08:04] grom358_spamkill at yahoo dot com dot au
Description:
The 15th October 1582 is a Friday (see
http://en.wikipedia.org/wiki/Gregorian_calendar). Testing with Python and Java
confirms this as well. Also checked the Gnome calendar.
The Proleptic Gregorian Calendar (see
http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar) just extends the
Gregorian calendar backwards. I'm assuming PHP is using proleptic calendar,
which
would make 4th october 1582 a monday. But again DateTime gets it wrong.
I made a script to find the breaking point, and it occurs at 31st December
1599.
It returns it as a Saturday when in fact its a Friday.
Test script:
---
setDate(1582, 10, 15);
echo $date->format('l, jS F Y') . PHP_EOL;
$date->setDate(1599, 12, 31);
echo $date->format('l, jS F Y') . PHP_EOL;
Expected result:
Friday, 15th October 1582
Friday, 31st December 1599
Actual result:
--
Saturday, 15th October 1582
Saturday, 31st December 1599
--
Edit this bug report at https://bugs.php.net/bug.php?id=61599&edit=1
#22065 [NEW]: file() function
From: [EMAIL PROTECTED]
Operating system: Windows 2000 server
PHP version: 4.3.0
PHP Bug Type: Filesystem function related
Bug description: file() function
Error log fills with warnings abount the file() function.
Apache 2.0/34
Using php module version 4.3.0 rather than cgi.
Errors.log shows:-
[05-Feb-2003 08:33:45] PHP Warning: file(d:/temp/ht1/050203.ht1) [function.file]: failed to
create stream: Permission denied in d:\Apache
Group\Apache2\htdocs\fa_tools_ht.php on line 103
Code:-
if(file_exists($file1)==FALSE) die("File1 does not exist");
if(is_readable($file1)==FALSE) die("File1 not readable");
// parse files into arrays
$file_array1=file($file1); //WARNING HERE
if($file_array1==null) die("Permission denied to open file");
--
Edit bug report at http://bugs.php.net/?id=22065&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22065&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22065&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22065&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22065&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22065&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22065&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22065&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22065&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22065&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22065&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22065&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22065&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22065&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22065&r=gnused
#22065 [Fbk->Opn]: file() function
ID: 22065
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows 2000 server
PHP Version: 4.3.0
New Comment:
safe_mode = Off
;open_basedir =
Previous Comments:
[2003-02-05 10:41:21] [EMAIL PROTECTED]
Do you have open_basedir or safe_mode enabled?
[2003-02-05 02:48:23] [EMAIL PROTECTED]
Error log fills with warnings abount the file() function.
Apache 2.0/34
Using php module version 4.3.0 rather than cgi.
Errors.log shows:-
[05-Feb-2003 08:33:45] PHP Warning: file(d:/temp/ht1/050203.ht1) [function.file]: failed to
create stream: Permission denied in d:\Apache
Group\Apache2\htdocs\fa_tools_ht.php on line 103
Code:-
if(file_exists($file1)==FALSE) die("File1 does not exist");
if(is_readable($file1)==FALSE) die("File1 not readable");
// parse files into arrays
$file_array1=file($file1); //WARNING HERE
if($file_array1==null) die("Permission denied to open file");
--
Edit this bug report at http://bugs.php.net/?id=22065&edit=1
#22065 [Fbk->Opn]: file() function
ID: 22065
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows 2000 server
PHP Version: 4.3.0
New Comment:
The file must exist to continue in the code:-
if(file_exists($file1)==FALSE) die("File1 does not exist");
The file is everybody full control.
What would have if the file was in use by another server (updating) ?
Can php detect this condition ?
Previous Comments:
[2003-02-06 08:45:38] [EMAIL PROTECTED]
Does the file exist?
What are the permissions for it?
(I think it's is_readable() that does not work correctly
on windows)
[2003-02-06 01:52:50] [EMAIL PROTECTED]
safe_mode = Off
;open_basedir =
[2003-02-05 10:41:21] [EMAIL PROTECTED]
Do you have open_basedir or safe_mode enabled?
[2003-02-05 02:48:23] [EMAIL PROTECTED]
Error log fills with warnings abount the file() function.
Apache 2.0/34
Using php module version 4.3.0 rather than cgi.
Errors.log shows:-
[05-Feb-2003 08:33:45] PHP Warning: file(d:/temp/ht1/050203.ht1) [function.file]: failed to
create stream: Permission denied in d:\Apache
Group\Apache2\htdocs\fa_tools_ht.php on line 103
Code:-
if(file_exists($file1)==FALSE) die("File1 does not exist");
if(is_readable($file1)==FALSE) die("File1 not readable");
// parse files into arrays
$file_array1=file($file1); //WARNING HERE
if($file_array1==null) die("Permission denied to open file");
--
Edit this bug report at http://bugs.php.net/?id=22065&edit=1
#26917 [NEW]: Incorrect date returned by date()
From: paul at mileham dot net
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: Date/time related
Bug description: Incorrect date returned by date()
Description:
date() returns Saturday 27th March 2004 instead of Sunday 28th March 2004.
mktime is OK.We have a diary with two consecutive Saturdays - hoorah!
Reproduce code:
---
// this proves there's a bug in php dates!!
for($i=1;$i<32;$i++) {
$monnum=3;
$year=2004;
$date2= date('D jS F Y',mktime(0,0,0,$monnum,$i,$year));
$d3=mktime(0,0,0,$monnum,$i,$year);
echo "".$date2;
echo $d3;
}
Expected result:
Each date correct
Actual result:
--
Two Saturdays and no Sunday
--
Edit bug report at http://bugs.php.net/?id=26917&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26917&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26917&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26917&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26917&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26917&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26917&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26917&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26917&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26917&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26917&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26917&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26917&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26917&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26917&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26917&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26917&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26917&r=float
#24248 [Com]: .htaccess php var overides not being cleared between page requests
ID: 24248 Comment by: paul at vanbrouwershaven dot com Reported By: dkh-php at nighttide dot net Status: Bogus Bug Type: PHP options/info functions Operating System: multiple PHP Version: 4.3.3RC2-dev/4.3.4/5.0.0b1/5.0.0b3 New Comment: Same problem with apache 2.0.48 and PHP 4.3.4 We "solved" the problem by downgrading tot PHP 4.3.1 Previous Comments: [2004-01-11 07:29:28] d dot mekic-php at interlize dot net The solution seems to be to enable SAFE_MODE for the sites which uses (in .htaccess or httpd.conf) the prepend command. [2004-01-11 07:14:23] d dot mekic-php at interlize dot net We've got the same problem with Apache 2.0.48 and PHP 4.3.4 running under RedHat 9.0. [2003-12-30 20:02:45] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Same as bug #25753 [2003-12-22 17:10:18] dkh-php at nighttide dot net This is also a problem with 5.0.0b3. One new item, I notice that the include path is also not being reset in these instances. The local value sticks. This is not a problem for things like magic_quotes_gps wich only effects the correct local value. [2003-12-22 16:17:47] dkh-php at nighttide dot net 4.3.4 with Apach 2.0.48 on FreeBSD 4.9-STABLE still seeing this problem. Default php.ini files. htaccess files described previously. I've seen a number of comments regarding this problem now coming from Linux users as well. php config info below: CPPFLAGS="-I/usr/local/include/pth" \ ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-tsrm-pth=/usr/local/lib/pth \ --with-zlib \ --with-bz2 \ --with-openssl \ --with-pspell \ --with-curl \ --with-gdbm \ --with-ndbm \ --with-gettext \ --with-mcrypt \ --with-pear \ --with-gd \ --enable-magic-quotes \ --enable-bcmath \ --enable-ftp \ --enable-memory-limit \ --enable-dba \ --with-flatfile \ --with-mime-magic \ --with-ncurses \ --with-exif \ --with-dom \ --with-dom-xslt \ --with-dom-exslt \ --with-freetype-dir=/usr/local/lib \ --enable-gd-native-ttf \ --with-wddx 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/24248 -- Edit this bug report at http://bugs.php.net/?id=24248&edit=1
#25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files
ID: 25753 Comment by: paul at vanbrouwershaven dot com Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: * PHP Version: 4CVS, 5CVS New Comment: Same problem with apache 2.0.48 and PHP 4.3.4 We "solved" the problem by downgrading tot PHP 4.3.1 Previous Comments: [2004-01-07 07:34:20] [EMAIL PROTECTED] Installing the patch resulted in a massive amount of errors from apache, all looking like: [notice] child pid 10072 exit signal Segmentation fault (11) ... about 10 of these per. second Eventually resulting in the apache server crashing. Requesting revised patch :) [2004-01-07 07:11:27] [EMAIL PROTECTED] Regarding Bug #26810 We are currently testing the suggested patch on two of our "troubled" servers to see if it resolves our problem. However the only way to get results from our tests is if our customers do not report more errors, so I'll report back in a week or so :) We are using Apache 1.3.28 and Apache 1.3.29 on the two servers, see more in Bug #26810 [2003-12-22 17:47:26] dkh-php at nighttide dot net This appears suspiciously similar to the bug I opened in 24248, only mention it here so that it can be included at the list of related reports. [2003-12-04 15:49:20] [EMAIL PROTECTED] Try the following patch: http://bb.prohost.org/ap_bug.txt [2003-10-30 09:35:44] fs at nessus dot at no thats false. this bug occours on apache 1.3.x too (tested it with 1.3.27). i think thats very essential... greetings, Florian Schicker www.nessus.at 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/25753 -- Edit this bug report at http://bugs.php.net/?id=25753&edit=1
#22787 [Com]: Make fails after upgrading to mysql v4.0.12
ID: 22787 Comment by: paul at rydell dot com Reported By: gregory dot fennell at am dot sony dot com Status: Bogus Bug Type: MySQL related Operating System: RedHat v8.0 PHP Version: 4.3.1 Assigned To: sniper New Comment: PHP 4.3.1 works for me with MySQL 4.0.12. I have the RPMs of MySQL installed and I compiled PHP 4.3.1 from source. No problems. Maybe your --with-mysql path is wrong. Previous Comments: [2003-03-21 13:39:45] gregory dot fennell at am dot sony dot com I find this really hard to believe since this has happened on several of our test machines. I am using the RPM distro of MySQL and simple configs for PHP as you can see above. So to call this ticket "bogus" I think is premature, but your call. Hope you don't see any more of these issues in the future! p.s.: I am not an amature in the Linux world and I know how to configure a system so the statement "if everything is installed correctly" wasn't really necessary. I posted this to be a help, not to be belittled. [2003-03-20 17:04:54] [EMAIL PROTECTED] Just tested this myself, if everything is installed correctly, PHP 4.3.x compiles and works fine with Mysql 4.0.x. [2003-03-20 08:45:47] gregory dot fennell at am dot sony dot com Since MySQL has made the 4.0.12 it production version, how far behind is PHP v5.x? It kind of makes MySQL v4.x usless to PHP websites until PHP has the capability to support MySQL v4.x, since alot of sites use PHP + MySQL. Any idea when PHP will have a version that will support MySQL v4.x? -Greg [2003-03-19 11:07:42] [EMAIL PROTECTED] And the (new) mysqli extension requires MySQL 4.1 anyway... -Tal [2003-03-19 11:02:55] [EMAIL PROTECTED] OTOH, it should be possible to use the mysql 4.0.12 too.. I'm checking this out. 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/22787 -- Edit this bug report at http://bugs.php.net/?id=22787&edit=1
#22092 [Com]: Strange warning and no functionality in imagettfbbox and imagettftext
ID: 22092 Comment by: paul at thewall dot de Reported By: davidl at tocquigny dot com Status: No Feedback Bug Type: GD related Operating System: Redhat 7.1 PHP Version: 4.3.0 New Comment: I can confirm this bug, it still persist. A Full path did not help, as well as renaming the font file and cutting off the extension (which is reported to work). I have tried GD extension versions 1 and 2, same result. PHP Version is 4.2.3. Previous Comments: [2003-04-10 08:51:29] kadlcakd at yahoo dot com I have the same problem with 4.3.1 I have GD 2.0.4 compiled with TTF support, php 4.3.1 compiled --with-gd --with-ttf --with-freetype-dir ImageTTFBBox( 18, 0, "fonts/times.ttf", "Hello" ); Gives an error: Warning: imagettfbbox() [function.imagettfbbox]: Could not find/open font in /usr2/accnts/theuser/www/tests/button.php Dave. [2003-03-13 14:00:41] FR at ncis dot ca We also have this bug with 4.3.1 [2003-02-20 08:08:16] [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. [2003-02-08 13:13:08] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Also, try specifying the full path to the font, by doing realpath() on the font path before passing it to imagettfbox(). [2003-02-06 15:15:28] davidl at tocquigny dot com Also, it won't accept spaces in the font file name, if I have no spaces (ie arial.ttf) it works, with spaces (ie "futura bold.ttf") generates: Could not find/open font in /xxx/xxx/xxx/test2.php on line 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/22092 -- Edit this bug report at http://bugs.php.net/?id=22092&edit=1
#30946 [NEW]: Cant rename directories across partitions
From: paul at paulbaranowski dot org Operating system: Redhat Enterprise Linux v3.0 PHP version: 4.3.8 PHP Bug Type: Directory function related Bug description: Cant rename directories across partitions Description: The rename function says that renaming across partitions was fixed in 4.3.3, but it appears that it is broken in 4.3.8. I have three partitions on my system: / /dev/shm /tmp I'm not sure if it matters, but the disk is mirrored with RAID level 1. Trying to rename a directory that resides in "/tmp" to the "/" file system results in: "Warning: rename(, ): Is a directory in
#30946 [Fbk->Opn]: Cant rename directories across partitions
ID: 30946 User updated by: paul at paulbaranowski dot org Reported By: paul at paulbaranowski dot org -Status: Feedback +Status: Open Bug Type: Directory function related Operating System: Redhat Enterprise Linux v3.0 PHP Version: 4.3.8 New Comment: I tried it with that snapshot and the problem is still there. Previous Comments: [2004-11-30 19:12:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-11-30 19:06:57] paul at paulbaranowski dot org Description: The rename function says that renaming across partitions was fixed in 4.3.3, but it appears that it is broken in 4.3.8. I have three partitions on my system: / /dev/shm /tmp I'm not sure if it matters, but the disk is mirrored with RAID level 1. Trying to rename a directory that resides in "/tmp" to the "/" file system results in: "Warning: rename(, ): Is a directory in
#30946 [Fbk->Opn]: Cant rename directories across partitions
ID: 30946
User updated by: paul at paulbaranowski dot org
Reported By: paul at paulbaranowski dot org
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Redhat Enterprise Linux v3.0
PHP Version: 4.3.8
New Comment:
# mkdir /tmp/test
# touch /tmp/test/foo.txt
# emacs test.php
# /usr/local/php-4.3.8/bin/php test.php
Warning: rename(/tmp/test,/root/test): Is a directory in /root/test.php
on line 2.
(A empty file "test" has now been created in /root directory)
# rm test
# mkdir /root/test
# touch /root/test/foo.txt
# emacs test.php
# /usr/local/php-4.3.8/bin/php test.php
( "/root/test" directory renamed to "/root/test2")
# emacs test.php
# /usr/local/php-4.3.8/bin/php test.php
("/tmp/test" directory renamed to "/tmp/test2")
Previous Comments:
[2004-11-30 21:52:20] [EMAIL PROTECTED]
Please, provide a reproduce code so we can reproduce it ourselves.
----
[2004-11-30 21:37:21] paul at paulbaranowski dot org
I tried it with that snapshot and the problem is still there.
[2004-11-30 19:12:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
----
[2004-11-30 19:06:57] paul at paulbaranowski dot org
Description:
The rename function says that renaming across partitions was fixed in
4.3.3, but it appears that it is broken in 4.3.8.
I have three partitions on my system:
/
/dev/shm
/tmp
I'm not sure if it matters, but the disk is mirrored with RAID level
1.
Trying to rename a directory that resides in "/tmp" to the "/" file
system results in:
"Warning: rename(, ): Is a directory in
#28076 [NEW]: BUG 27810 NOT SOLVED !!!!
From: paul at vanbrouwershaven dot com Operating system: Linux PHP version: 4.3.6 PHP Bug Type: Apache2 related Bug description: BUG 27810 NOT SOLVED Description: BUG 27810 NOT SOLVED -- Edit bug report at http://bugs.php.net/?id=28076&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28076&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28076&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28076&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28076&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28076&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28076&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28076&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28076&r=support Expected behavior: http://bugs.php.net/fix.php?id=28076&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28076&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28076&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28076&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28076&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28076&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28076&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28076&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28076&r=float
#28076 [Bgs->Opn]: BUG 27810 NOT SOLVED !!!!
ID: 28076 User updated by: paul at vanbrouwershaven dot com Reported By: paul at vanbrouwershaven dot com -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.6 New Comment: Please reopen this bug: 27810 There are many comments in the bug 27810 but it's still closed. Previous Comments: [2004-04-20 16:31:17] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. DO NOT REFILE OLD BUGS [2004-04-20 13:20:27] paul at vanbrouwershaven dot com Description: BUG 27810 NOT SOLVED -- Edit this bug report at http://bugs.php.net/?id=28076&edit=1
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810
Comment by: paul at vanbrouwershaven dot com
Reported By: renato at galle dot com dot br
Status: Closed
Bug Type: Apache2 related
Operating System: FreeBSD-5.2.1-RELEASE-p4
PHP Version: 4.3.5
New Comment:
Same problem here with the lasted stable release PHP 4.3.6
Previous Comments:
[2004-04-19 19:09:19] renato at galle dot com dot br
Here is the patch to fix it on php-4.3.6:
--- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004
+++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004
@@ -106,15 +106,6 @@
REGISTER_LONG_CONSTANT("PREG_SPLIT_DELIM_CAPTURE",
PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PREG_SPLIT_OFFSET_CAPTURE",
PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PREG_GREP_INVERT", PREG_GREP_INVERT, CONST_CS
| CONST_PERSISTENT);
-
- pcre_malloc = php_pcre_malloc;
- pcre_free = php_pcre_free;
-
-#ifdef NO_RECURSE
- pcre_stack_malloc = php_pcre_malloc;
- pcre_stack_free = php_pcre_free;
-#endif
-
return SUCCESS;
}
/* }}} */
@@ -130,6 +121,16 @@
}
/* }}} */
+/* {{{ PHP_RINIT_FUNCTION(pcre) */
+static PHP_RINIT_FUNCTION(pcre)
+{
+ pcre_malloc = php_pcre_malloc;
+ pcre_free = php_pcre_free;
+
+ return SUCCESS;
+}
+/* }}} */
+
/* {{{ pcre_get_compiled_regex
*/
PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra,
int *preg_options) {
@@ -1527,7 +1528,7 @@
pcre_functions,
PHP_MINIT(pcre),
PHP_MSHUTDOWN(pcre),
- NULL,
+ PHP_RINIT(pcre),
NULL,
PHP_MINFO(pcre),
NO_VERSION_YET,
[2004-04-19 19:09:19] renato at galle dot com dot br
Here is the patch to fix it on php-4.3.6:
--- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004
+++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004
@@ -106,15 +106,6 @@
REGISTER_LONG_CONSTANT("PREG_SPLIT_DELIM_CAPTURE",
PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PREG_SPLIT_OFFSET_CAPTURE",
PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PREG_GREP_INVERT", PREG_GREP_INVERT, CONST_CS
| CONST_PERSISTENT);
-
- pcre_malloc = php_pcre_malloc;
- pcre_free = php_pcre_free;
-
-#ifdef NO_RECURSE
- pcre_stack_malloc = php_pcre_malloc;
- pcre_stack_free = php_pcre_free;
-#endif
-
return SUCCESS;
}
/* }}} */
@@ -130,6 +121,16 @@
}
/* }}} */
+/* {{{ PHP_RINIT_FUNCTION(pcre) */
+static PHP_RINIT_FUNCTION(pcre)
+{
+ pcre_malloc = php_pcre_malloc;
+ pcre_free = php_pcre_free;
+
+ return SUCCESS;
+}
+/* }}} */
+
/* {{{ pcre_get_compiled_regex
*/
PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra,
int *preg_options) {
@@ -1527,7 +1528,7 @@
pcre_functions,
PHP_MINIT(pcre),
PHP_MSHUTDOWN(pcre),
- NULL,
+ PHP_RINIT(pcre),
NULL,
PHP_MINFO(pcre),
NO_VERSION_YET,
[2004-04-19 18:40:56] remco at linux-adept dot nl
Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl
graceful'. Which is a kill for logrotation! Everything was fine untill
4.3.5 came along. Changing back to 4.3.4 solves the problem.
I have tried recompiling apache etc. Nothing helps.
Gracefully restarting apache gives the following in the error-logs:
[Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing
restart
[Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error
detected in the parent process
And apache has to be restarted once more to get it running.
[2004-04-16 11:28:38] noackjr at alumni dot rice dot edu
Bless you -- the FreeBSD port works flawlessly for me now.
[2004-04-16 07:46:13] ale at FreeBSD dot org
Hopefully fixed in php port with this patch:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3apcre%3a%3aphp_pcre.c?rev=1.1&content-type=text/x-cvsweb-markup
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/27810
--
Edit this bug report at http://bugs.php.net/?id=27810&edit=1
#28076 [Bgs->Csd]: BUG 27810 NOT SOLVED !!!!
ID: 28076 User updated by: paul at vanbrouwershaven dot com Reported By: paul at vanbrouwershaven dot com -Status: Bogus +Status: Closed Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.6 New Comment: closed Previous Comments: [2004-04-20 17:21:40] [EMAIL PROTECTED] No someta por favor el mismo informe más de una vez. Por favor não submeta o mesmo relatório mais de uma vez. Veuillez ne pas soumettre le même rapport plus d'une fois. Bitte reichen Sie nicht den gleichen Report mehr als einmal ein. Gelieve te leggen meer dan eens niet het zelfde rapport voor. Non presenti prego più di una volta lo stesso rapporto. 一度同じレポートをもっとより堤出してはいけない。 请不要递交同样报告更比一次。 동일한 보고를 좀더 보다는 한 번 복종시키지 말라. Пожалуйста не представляйте такой же рапорт больше чем раз. [2004-04-20 16:40:25] paul at vanbrouwershaven dot com Please reopen this bug: 27810 There are many comments in the bug 27810 but it's still closed. [2004-04-20 16:31:17] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. DO NOT REFILE OLD BUGS [2004-04-20 13:20:27] paul at vanbrouwershaven dot com Description: BUG 27810 NOT SOLVED -- Edit this bug report at http://bugs.php.net/?id=28076&edit=1
#29878 [Com]: ImageCreateFromJpeg returns 'not a valid jpeg file'
ID: 29878 Comment by: paul at gslip dot com Reported By: cyleriggs at kc dot rr dot com Status: Bogus Bug Type: GD related Operating System: Linux 2.6.8.1 PHP Version: 5.0.1 Assigned To: pajoye New Comment: Has anyone at php verified that the images are corrupt? In what way are they corrupt? Here's what I know: 1- These images were supported with no issues whatsoever before I 'upgraded' to php 5.x 2- Every other piece of software I own, including Windows Image Viewer, Photoshop, Paint, IE, Netscape, Imagemagick, etc. open the files with no complaint. 3- A visual inspection of the files on the byte level show nothing out of the ordinary. That all leads me to believe that the images are not corrupt and that PHP or GD has a bug. Please, stop being so stubborn and at least look at the problem. I can show you hundreds of examples of where this is happening on the web. Just do a google search for 'is not a valid JPEG file in' to see for yourselves how many sites are having this issue. I suspect there's some new twist on the JPEG format that new digital cameras are using ,or something along those lines, that GD and PHP just aren't yet up to speed with. Let's get this solved folks. Previous Comments: [2004-10-07 09:12:21] [EMAIL PROTECTED] Corrupted files are invalid, and may crash an application if attempted to use. That's why we will not implement that. (Actually, it's not a PHP issue either, it has to do with how libgd handles opening files). [2004-10-07 03:18:23] cyleriggs at kc dot rr dot com Okay, so how about a feature suggestion than, i think that there should be the option in GD that allows you to try and open images that have a few corrupted bytes. If other programs can open them just fine what would be the harm in allowing programmers to choose to live with the corruptions? [2004-10-05 09:33:47] [EMAIL PROTECTED] PHP only reads non-coprrupted files - there is no bug here. [2004-10-05 04:34:39] cyleriggs at kc dot rr dot com After playing around with the images themselves i have found that converting them from jpeg to png then back to jpeg fixed the problem and yielded no quality loss. I used the linux tool set called ImageMagick to do this. I wrote a short perl script to go through all my images and fix them. Other than this i have found no other way of stopping this. one interesting fact though is that while converting the images with the imagemagick utility it complained about some corruptions, however it was still able to open them fine and convert them. Maybe PHP is being too picky about the images that it opens as despite a few corrupted bytes EVERYthing was able to open these images except for PHP. ---- [2004-09-30 21:05:50] paul at gslip dot com I disagree. I have used my code successfully on montypics.com until the upgrade to php 5.0.1. I now get exactly the same results as the original poster. Images that worked fine on previous versions now do not. I have a sample image that can be provided. I also have code I can share with the PHP team although I cannot post it here as it is lengthy and copyrighted. 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/29878 -- Edit this bug report at http://bugs.php.net/?id=29878&edit=1
#29878 [Com]: ImageCreateFromJpeg returns 'not a valid jpeg file'
ID: 29878 Comment by: paul at gslip dot com Reported By: cyleriggs at kc dot rr dot com Status: Bogus Bug Type: GD related Operating System: Linux 2.6.8.1 PHP Version: 5.0.1 Assigned To: pajoye New Comment: I disagree. I have used my code successfully on montypics.com until the upgrade to php 5.0.1. I now get exactly the same results as the original poster. Images that worked fine on previous versions now do not. I have a sample image that can be provided. I also have code I can share with the PHP team although I cannot post it here as it is lengthy and copyrighted. Previous Comments: [2004-08-29 12:22:14] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Your jpeg file is not valid. PHP could not take care of each possible failures in image files. Desktop softwares could. Fix your image and replace it. --Pierre [2004-08-28 23:00:25] cyleriggs at kc dot rr dot com Description: When calling ImageCreateFromJPEG() on a valid jpeg file it fails and i get errors such as the following in my php error log: [28-Aug-2004 05:21:29] PHP Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '/usr/local/apache2/htdocs/pictures/Before Dad Went to Iraq/IMGP0008.JPG' is not a valid JPEG file in /home/www/pictures/index.php on line 43 however as can be seen through this link the file is a valid jpeg file: http://cyle.dyndns.org/pictures/Before Dad Went to Iraq/IMGP0008.JPG Also i have a memory_limit of 25mb so this cannot be the issue. Something that might help: http://cyle.dyndns.org/phpinfo.php I am writing this code for a picture gallery browser, while most pictures load, about 10% of my pictures cannot be opened through ImageCreateFromJpeg(), however it is always the same pictures that cannot be opened. The only trend i can see is that this does not appear to be happening on small jpegs. The page that I am having problems with is http://cyle.dyndns.org/pictures/index.php. The source code for this is at http://cyle.dyndns.org/pictures/index.phps. Expected result: The image would be loaded and code continue to execute and i get the error message described above. Actual result: -- Sometimes images load sometimes images cannot be opened. -- Edit this bug report at http://bugs.php.net/?id=29878&edit=1
#31875 [NEW]: get_defined_functions includes functiions that are disabled
From: paul at quakenet dot org Operating system: Freebsd PHP version: 4.3.10 PHP Bug Type: Feature/Change Request Bug description: get_defined_functions includes functiions that are disabled Description: get_defined_functions() returns a list of defined functions. This includes functions that have been disabled through the use of disable_functions, and therefore function_exists() returns as not being defined. get_definited_functions should only return the list of functions that are defined (and enabled) for users to use. -- Edit bug report at http://bugs.php.net/?id=31875&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31875&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31875&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31875&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31875&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31875&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31875&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31875&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31875&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31875&r=support Expected behavior: http://bugs.php.net/fix.php?id=31875&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31875&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31875&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31875&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31875&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31875&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31875&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31875&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31875&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31875&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31875&r=mysqlcfg
#32162 [NEW]: dirname returning \ for root entries
From: paul at wavebreaks dot com
Operating system: Windows XP SP2
PHP version: 5.0.3
PHP Bug Type: Directory function related
Bug description: dirname returning \ for root entries
Description:
This is probably the same or related to
http://bugs.php.net/bug.php?id=25450 and
http://bugs.php.net/bug.php?id=18710 but since they are for Win 2k and/or
closed, I thought the best bet was to open a new one.
When a path-like-string is passed to dirname, if, and only if, the last
entity (file, dir) is on the root (ie: only one / in the string) then
dirname returns a backslash instead of a forward slash.
There doesn't appear to be a config to tell PHP which part seperator to
use, thus the dirname function is pointlessly broken unless you can
guarentee it will never be given a root level entry.
This, also, breaks your example in the documentation for header() for
Location: header types.
Reproduce code:
---
print (dirname('/foo')."\n");
print (dirname('/foo/bar')."\n");
Expected result:
/
/foo
Actual result:
--
\
/foo
You might argue it's not a bug since Windows is meant to handle both types
of path seperator, but a URI does not, and this is you main audience.
This issue has been around for way past way too long.
--
Edit bug report at http://bugs.php.net/?id=32162&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32162&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32162&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32162&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32162&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32162&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32162&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32162&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32162&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32162&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32162&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32162&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32162&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32162&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32162&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32162&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32162&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32162&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32162&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32162&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32162&r=mysqlcfg
#32405 [NEW]: mysqli->fetch() is returning bad data
From: paul at thehedron dot com
Operating system: Linux (fedora core 3)
PHP version: 5.0.3
PHP Bug Type: MySQLi related
Bug description: mysqli->fetch() is returning bad data
Description:
mysqli->fetch() is returning bad data on int columns. I saw this listed,
then closed as bogus (29002). I just hit it today and assure you it is
not bogus.
Here is my full setup:
---
CPU: AMD64
OS: Fedora Core 3 (2.6.9-1.667)
PHP: 5.0.3
libmcrypt-2.5.7
mcrypt-2.6.4
mhash-0.9.2
Apache: 1.3.33
mod_ssl-2.8.22-1.3.33
openssl-0.9.7e
MySQL: 4.1.10
GCC: 3.4.2
---
PHP configuration:
./configure \
--with-apxs=/www/bin/apxs \
--with-mysql=/usr/local/mysql \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--with-mcrypt=/shared/LAMP/PHP5/libmcrypt-2.5.7 \
--enable-ftp \
--enable-trans-sid
Reproduce code:
---
CREATE TABLE users (
user_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
lastname VARCHAR(50) NOT NULL,
PRIMARY KEY(user_id));
---
prepare("SELECT user_id, lastname FROM users")) {
$stmt->execute();
$stmt->bind_result($col1, $col2);
while ($stmt->fetch()) {
printf("%s %s ", $col1, $col2);
}
$stmt->close();
}
$mysqli->close();
?>
Expected result:
Expected results:
1 Peterson
2 Asenbach
Actual result:
--
Actual results:
32199691940659210 Peterson
32199691940659211 Asenbach
--
Edit bug report at http://bugs.php.net/?id=32405&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32405&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32405&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32405&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32405&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32405&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32405&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32405&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32405&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32405&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32405&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32405&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32405&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32405&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32405&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32405&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32405&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32405&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32405&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32405&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32405&r=mysqlcfg
#32405 [Fbk->Opn]: mysqli->fetch() is returning bad data
ID: 32405
User updated by: paul at thehedron dot com
Reported By: paul at thehedron dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Linux (fedora core 3)
PHP Version: 5.0.3
New Comment:
Pulled down the recommended CVS snapshot, compiled and installed. Info
shows PHP Version 5.0.4RC2-dev.
Ran the same code and got the same result.
Previous Comments:
[2005-03-22 00:10:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-03-22 00:06:09] paul at thehedron dot com
Description:
mysqli->fetch() is returning bad data on int columns. I saw this
listed, then closed as bogus (29002). I just hit it today and assure
you it is not bogus.
Here is my full setup:
---
CPU: AMD64
OS: Fedora Core 3 (2.6.9-1.667)
PHP: 5.0.3
libmcrypt-2.5.7
mcrypt-2.6.4
mhash-0.9.2
Apache: 1.3.33
mod_ssl-2.8.22-1.3.33
openssl-0.9.7e
MySQL: 4.1.10
GCC: 3.4.2
---
PHP configuration:
./configure \
--with-apxs=/www/bin/apxs \
--with-mysql=/usr/local/mysql \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--with-mcrypt=/shared/LAMP/PHP5/libmcrypt-2.5.7 \
--enable-ftp \
--enable-trans-sid
Reproduce code:
---
CREATE TABLE users (
user_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
lastname VARCHAR(50) NOT NULL,
PRIMARY KEY(user_id));
---
prepare("SELECT user_id, lastname FROM users")) {
$stmt->execute();
$stmt->bind_result($col1, $col2);
while ($stmt->fetch()) {
printf("%s %s ", $col1, $col2);
}
$stmt->close();
}
$mysqli->close();
?>
Expected result:
Expected results:
1 Peterson
2 Asenbach
Actual result:
--
Actual results:
32199691940659210 Peterson
32199691940659211 Asenbach
--
Edit this bug report at http://bugs.php.net/?id=32405&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: porn off http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ Previous Comments: [2005-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: porn compares to http://porn.bashkiria.ru/"; target=_blank>porn and see yourself. http://porn.bashkiria.ru/ Previous Comments: [2005-04-14 00:36:20] paul at hotmail dot com porn off http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: porn http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ Previous Comments: [2005-04-14 00:36:29] paul at hotmail dot com porn compares to http://porn.bashkiria.ru/"; target=_blank>porn and see yourself. http://porn.bashkiria.ru/ [2005-04-14 00:36:20] paul at hotmail dot com porn off http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: The arguments would all have to admit that porn and search for http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ Previous Comments: [2005-04-14 00:36:38] paul at hotmail dot com porn http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:29] paul at hotmail dot com porn compares to http://porn.bashkiria.ru/"; target=_blank>porn and see yourself. http://porn.bashkiria.ru/ [2005-04-14 00:36:20] paul at hotmail dot com porn off http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: porn but if http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ Previous Comments: [2005-04-14 00:36:47] paul at hotmail dot com The arguments would all have to admit that porn and search for http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:38] paul at hotmail dot com porn http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:29] paul at hotmail dot com porn compares to http://porn.bashkiria.ru/"; target=_blank>porn and see yourself. http://porn.bashkiria.ru/ [2005-04-14 00:36:20] paul at hotmail dot com porn off http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: porn but with none of http://porn.bashkiria.ru/"; target=_blank>porn! http://porn.bashkiria.ru/ Previous Comments: [2005-04-14 00:37:02] paul at hotmail dot com porn but if http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:47] paul at hotmail dot com The arguments would all have to admit that porn and search for http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:38] paul at hotmail dot com porn http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:29] paul at hotmail dot com porn compares to http://porn.bashkiria.ru/"; target=_blank>porn and see yourself. http://porn.bashkiria.ru/ [2005-04-14 00:36:20] paul at hotmail dot com porn off http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ 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/31981 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: paul at hotmail dot com Reported By: asmi at owear dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: Find porn http://porn.bashkiria.ru/"; target=_blank>porn! http://porn.bashkiria.ru/ Previous Comments: [2005-04-14 00:37:17] paul at hotmail dot com porn but with none of http://porn.bashkiria.ru/"; target=_blank>porn! http://porn.bashkiria.ru/ [2005-04-14 00:37:02] paul at hotmail dot com porn but if http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:47] paul at hotmail dot com The arguments would all have to admit that porn and search for http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:38] paul at hotmail dot com porn http://porn.bashkiria.ru/"; target=_blank>porn. http://porn.bashkiria.ru/ [2005-04-14 00:36:29] paul at hotmail dot com porn compares to http://porn.bashkiria.ru/"; target=_blank>porn and see yourself. http://porn.bashkiria.ru/ 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/31981 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113
Comment by: paul at pizza dot org
Reported By: php_new at jdc dot parodius dot com
Status: Bogus
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.3.2-dev
New Comment:
Same problem Linux Mandrake 9.0 Apache 1.3.27 PHP 4.3.2.
Previous Comments:
[2003-06-24 02:00:53] dortega at telenium dot es
I've got the same problem with Solaris 2.8/Apache1.3.23/php-4.1.2
[2003-06-19 20:10:30] fallenmatt at yahoo dot com
this is my temporally fix:
i put it in an include file with a nice body (coppied from apache
response to connect) and include it on top of index.php files for each
virtual server:
you should probably use $_SERVER[] instead... and no empty lines in
your include file, otherwise header() gets confused
[2003-06-19 09:47:51] fallenmatt at yahoo dot com
i found this bug affecting my servers too.
the severity of it is that spammers scan for open proxies and then
don't check that they get smtp connection back, anything that's
succesfull request puts the address on their proxy list.
the result: i've got basically denial of service attack. My server was
getting thousands of requests ("connect x.x.x.x:25) per hours,
sometimes hundreds per minute. SInce it does a lot of mysql querries my
database gaved up and started throwing can't connect to database
errors.
it is still a persistent problem. for a time being i check my counters
and whenever i get large number of requests from same ip address i just
ban it on my firewall.
that is not a good sollution so still looking for a way to really fix
it.
[2003-06-08 14:20:34] kustosz at bv dot pl
apache 1.3.27, php 4.3.1 (LoadModule), the problem of bad 200 response
code exist.
according to the first email, the known (for me) solution for this
problem is to create index.html page and in this page redirect to
index.php, then the response code id 405.
[2003-06-03 22:47:22] php_new at jdc dot parodius dot com
I don't use mod_perl. The only third-party module I use besides
mod_php is mod_watch, which is not the core of the problem (I've tried
removing it; same result).
Without mod_php installed, this problem disappears.
List of modules loaded:
Loaded Modules mod_watch, mod_php4, mod_setenvif, mod_so,
mod_usertrack, mod_headers, mod_expires, mod_auth_db, mod_auth,
mod_access, mod_alias, mod_userdir, mod_actions, mod_cgi, mod_dir,
mod_autoindex, mod_include, mod_mime, mod_log_config, mod_env,
mod_mmap_static, http_core
SERVER_SOFTWARE Apache/1.3.27 (Unix) mod_watch/3.17 PHP/4.3.2RC4
If I open up an Apache bug report, there is going to be a lot of
finger-pointing. Are we sure we want to do this? Is it at all
possible to get the PHP developers to open a report about this problem
rather than the end-user?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19113
--
Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#28365 [Com]: make install-pear fails, segmentation faut
ID: 28365 Comment by: paul at vanbrouwershaven dot com Reported By: php dot wayne at ptaff dot ca Status: Open Bug Type: Zend Engine 2 problem Operating System: GNU/Linux Mandrake Cooker PHP Version: 4.3.6 New Comment: Same problem with PHP 4.3.7 Fedora C1 kernel 2.4.22 gcc 3.3.2 Previous Comments: [2004-05-12 07:34:22] php dot wayne at ptaff dot ca Description: Downloaded php-4.3.6, un-tarred, ./configure, make, make install. Tried with the latest snapshot, same result, failure on "make install" The make install fails on PEAR installation: Installing PEAR environment: /usr/local/stow/php-4.3.6//lib/php/ make[1]: *** [install-pear-installer] Segmentation fault (core dumped) The command producing the segfault is: /home/ptaff/src/php/php4-STABLE-200405120430/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 /home/ptaff/src/php/php4-STABLE-200405120430/pear/install-pear.php -d /usr/local/stow/php-4.3.6//lib/php -b /usr/local/stow/php-4.3.6//bin /home/ptaff/src/php/php4-STABLE-200405120430/pear/package-Archive_Tar.xml backtracing, we have: [Thread debugging using libthread_db enabled] [New Thread 1084061408 (LWP 7178)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1084061408 (LWP 7178)] 0x0823200d in call_overloaded_function (T=0x67b9e57c, arg_count=1, return_value=0x8376684) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend_execute.c:990 990 ce = Z_OBJCE_P(T->EA.data.overloaded_element.object); (gdb) bt #0 0x0823200d in call_overloaded_function (T=0x67b9e57c, arg_count=1, return_value=0x8376684) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend_execute.c:990 #1 0x0823566b in execute (op_array=0x853444c) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend_execute.c:1701 #2 0x082353e0 in execute (op_array=0x8538cec) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend_execute.c:1679 #3 0x082353e0 in execute (op_array=0x8374fe4) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend_execute.c:1679 #4 0x08222c31 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend.c:886 #5 0x081ee00d in php_execute_script (primary_file=0xbfffea50) at /home/ptaff/src/php/php4-STABLE-200405120430/main/main.c:1731 #6 0x08248cfc in main (argc=12, argv=0xbfffeb14) at /home/ptaff/src/php/php4-STABLE-200405120430/sapi/cli/php_cli.c:822 (gdb) frame 1 #1 0x0823566b in execute (op_array=0x853444c) at /home/ptaff/src/php/php4-STABLE-200405120430/Zend/zend_execute.c:1701 1701 call_overloaded_function(&EX(Ts)[EX(fbc)->overloaded_function.var], EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr TSRMLS_CC); I tried a clean ./configure (without any options), a clean CFLAGS, still I get the same error. I also tried --disable-overload as a wild guess. Versions used: gcc: 3.3.2 glibc: 2.3.3 (NPTL) kernel: 2.6.5 I'm out of ideas here, what should I try next? -- Edit this bug report at http://bugs.php.net/?id=28365&edit=1
#7641 [Com]: cgi binary with "enable-discard-path" fails with empty doc_root value
ID: 7641 Comment by: paul at boxedart dot com Reported By: ugb-listen at gmx dot de Status: Closed Bug Type: *Web Server problem Operating System: Linux 2.2.16 i686 PHP Version: 4.0 Latest CVS (04/11/2000) New Comment: problem occurs with FC1 php SRPM , changed spec added --enable-fastcgi and got this error. Can reproduce easily. SRPM from Fedora is php-4.3.6-1.3.src.rpm and it does include the discard path option in the spec file. I will try setting php.ini option and also recompiling without --enable-discard-path Previous Comments: [2004-05-14 22:18:32] ftrudeau at zesolution dot com Problem still occuring with PHP 4.3.5, might as well reopen this bug case. [2002-01-10 02:06:00] [EMAIL PROTECTED] No feedback. Closing. [2001-12-20 09:48:50] [EMAIL PROTECTED] Any luck with the testing? PHP 4.1.0 might be a wise choice as well. R. [2001-08-20 12:28:41] ugb-listen at gmx dot de Unfortunately, I am currently not able to test it due to time limitation. Please do not close the bug report yet, I might have time to test ist in the next couple of weeks (this report is 8 months old anyway). [2001-08-19 02:53:39] [EMAIL PROTECTED] Does this happen with latest CVS snapshot: http://snaps.php.net/ 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/7641 -- Edit this bug report at http://bugs.php.net/?id=7641&edit=1
#7641 [Com]: cgi binary with "enable-discard-path" fails with empty doc_root value
ID: 7641 Comment by: paul at boxedart dot com Reported By: ugb-listen at gmx dot de Status: Closed Bug Type: *Web Server problem Operating System: Linux 2.2.16 i686 PHP Version: 4.0 Latest CVS (04/11/2000) New Comment: Setting doc_root in php gives the message "No input file specified." I'll post back in a few with what happens with i compile without the discard option. Previous Comments: [2004-06-11 06:39:33] paul at boxedart dot com problem occurs with FC1 php SRPM , changed spec added --enable-fastcgi and got this error. Can reproduce easily. SRPM from Fedora is php-4.3.6-1.3.src.rpm and it does include the discard path option in the spec file. I will try setting php.ini option and also recompiling without --enable-discard-path [2004-05-14 22:18:32] ftrudeau at zesolution dot com Problem still occuring with PHP 4.3.5, might as well reopen this bug case. [2002-01-10 02:06:00] [EMAIL PROTECTED] No feedback. Closing. [2001-12-20 09:48:50] [EMAIL PROTECTED] Any luck with the testing? PHP 4.1.0 might be a wise choice as well. R. [2001-08-20 12:28:41] ugb-listen at gmx dot de Unfortunately, I am currently not able to test it due to time limitation. Please do not close the bug report yet, I might have time to test ist in the next couple of weeks (this report is 8 months old anyway). 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/7641 -- Edit this bug report at http://bugs.php.net/?id=7641&edit=1
#24864 [Com]: Kludge Resolution
ID: 24864 Comment by: paul at boxedart dot com Reported By: tom at minnesota dot com Status: Bogus Bug Type: CGI related Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4.3.2 New Comment: Does the same thing to me also. Using FC1 and Zeus web server. Any ideas? Previous Comments: [2003-07-30 02:04:04] [EMAIL PROTECTED] Works fine here. Must be your configuration that is borked. (httpd.conf / php.ini / configure options..) [2003-07-30 01:55:57] tom at minnesota dot com If I change the php cgi file: cat /usr/local/libexec/cgi-bin/php --- #!/bin/sh export SCRIPT_FILENAME=$PATH_TRANSLATED /usr/local_install/php-4-200307300130-cgi/bin/php --- Then now it displays the phpinfo page properly. Some notes I found relating to this problem in previous PHP versions: --- It appears that when Apache executes the RedHat php cgi it passes SCRIPT_FILENAME as /var/www/cgi-bin/php and PATH_TRANSLATED is the name of the php script /var/www/maplab/htdocs/index.phtml. The php cgi on the other hand does not execute against PATH_TRANSLTED it executes against SCRIPT_FILENAME. The result is if you use the RedHat Apache/Php-CGI in the default configuration, every time the Php CGI executes, it uses itself (a binary file) as the input file to translate. And then it spews garbage because it is trying to parse a binary file. --- [2003-07-30 01:21:48] tom at minnesota dot com I should also note that accessing the phpinfo.phtml page via shell and php (cgi) directly works fine. It shows that error when accessing the script with php cgi through Apache. [2003-07-30 01:18:14] tom at minnesota dot com Description: When accessing a simple page with via the browser and php (cgi): I get: --- Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Parse error: parse error in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 --- Works fine with apache module and older 4.3.1 cgi. Reproduce code: --- Expected result: Show the phpinfo page. -- Edit this bug report at http://bugs.php.net/?id=24864&edit=1
[PHP-BUG] Bug #60733 [NEW]: strtotime bug in php 5.3.9
From:
Operating system: linux(debian)-64bit
PHP version: 5.3.9
Package: Reproducible crash
Bug Type: Bug
Bug description:strtotime bug in php 5.3.9
Description:
Since upgrading [using dotdeb.org compiled version of php] from php 5.3.8
to php 5.3.9, strtotime appears to crash. This occurs for me on 2 VM's,
minimised to 1 line of php.
Valgrind/GDB output attached
Test script:
---
echo strtotime('2011-01-1 00:00 UTC');
Actual result:
--
valgrind /usr/bin/php test.php
==25725== Memcheck, a memory error detector
==25725== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==25725== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==25725== Command: /usr/bin/php test.php
==25725==
129384==25725== Invalid read of size 8
==25725==at 0x45D494: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcf90 is 0 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4A8: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcfb0 is 32 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4BE: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcfb8 is 40 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4D4: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcfc0 is 48 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25
Bug #60733 [Opn->Csd]: strtotime bug in php 5.3.9
Edit report at https://bugs.php.net/bug.php?id=60733&edit=1
ID: 60733
User updated by:paul at minimoo dot org
Reported by:paul at minimoo dot org
Summary:strtotime bug in php 5.3.9
-Status: Open
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: linux(debian)-64bit
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
This is looking like it may be an issue with the dotdeb.org build of 5.3.9 -
have had 3-4 people confirm that this code breaks with the .deb files at
http://dotdeb.mirror.somersettechsolutions.co.uk/dists/stable/php5/binary-amd64/
and 2 people unable to reproduce from a build from latest svn
Previous Comments:
[2012-01-12 21:29:59] paul at minimoo dot org
Description:
Since upgrading [using dotdeb.org compiled version of php] from php 5.3.8 to
php 5.3.9, strtotime appears to crash. This occurs for me on 2 VM's, minimised
to 1 line of php.
Valgrind/GDB output attached
Test script:
---
echo strtotime('2011-01-1 00:00 UTC');
Actual result:
--
valgrind /usr/bin/php test.php
==25725== Memcheck, a memory error detector
==25725== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==25725== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==25725== Command: /usr/bin/php test.php
==25725==
129384==25725== Invalid read of size 8
==25725==at 0x45D494: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcf90 is 0 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4A8: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcfb0 is 32 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4BE: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725== Address 0x8bdcfb8 is 40 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4D4: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in
#48534 [NEW]: Infinite loop with: log_errors+display_startup_errors+no timezone
From: paul at mantisforge dot org Operating system: Windows 32bit PHP version: 5.3.0RC3 PHP Bug Type: *Configuration Issues Bug description: Infinite loop with: log_errors+display_startup_errors+no timezone Description: Calling php from command line with (for example): c:\php\php -c "c:\php\foo.ini" -i Results in an infinite logging loop if a) display_startup_errors is on b) no timezone has been set in php.ini c) error logging to file is on Reproduce code: --- PHP.ini: log_errors = On error_log = "c:\temp\php.log" display_startup_errors = On Expected result: phpinfo(); is displayed Actual result: -- *snip* ctype ctype functions => enabled date date/time support => enabled "Olson" Timezone Database Version => 2009.9 Timezone Database => internal Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 ... .. . -- Edit bug report at http://bugs.php.net/?id=48534&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48534&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48534&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48534&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48534&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48534&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48534&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48534&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48534&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48534&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48534&r=support Expected behavior: http://bugs.php.net/fix.php?id=48534&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48534&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48534&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48534&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48534&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48534&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48534&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48534&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48534&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48534&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48534&r=mysqlcfg
#48652 [NEW]: PHP6 Snaps - Invalid CRT parameters detected
From: paul at mantisforge dot org Operating system: Vista32bit PHP version: 6CVS-2009-06-22 (snap) PHP Bug Type: Compile Failure Bug description: PHP6 Snaps - Invalid CRT parameters detected Description: PHP6 windows snapshots builds Invalid CRT when including a file library issue? Reproduce code: --- PHP 6.0.0-dev (cli) (built: Jun 20 2009 12:21:26) Copyright (c) 1997-2009 The PHP Group Zend Engine v3.0.0-dev, Copyright (c) 1998-2009 Zend Technologies c:\php6>type 1.php c:\php6>type 2.php c:\php6>php 1.php Expected result: moo Actual result: -- Warning: Invalid CRT parameters detected in C:\php6\1.php on line 1 Warning: Invalid CRT parameters detected in C:\php6\1.php on line 1 Warning: Invalid CRT parameters detected in C:\php6\1.php on line 1 moo -- Edit bug report at http://bugs.php.net/?id=48652&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48652&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48652&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48652&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48652&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48652&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48652&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48652&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48652&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48652&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48652&r=support Expected behavior: http://bugs.php.net/fix.php?id=48652&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48652&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48652&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48652&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48652&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48652&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48652&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48652&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48652&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48652&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48652&r=mysqlcfg
#48498 [Com]: COM object instantiation throws 'Invalid Syntax' exception
ID: 48498
Comment by: paul at mantisforge dot org
Reported By: will at flourishlib dot com
Status: Open
Bug Type: COM related
Operating System: Windows XP SP3
PHP Version: 5.2.10RC1
New Comment:
This functionality seems to work fine in the 5.3.0 rc builds ( PHP
5.3.0RC5-dev (cli) (built: Jun 27 2009 00:33:01) (DEBUG)).
The following script appears to work for me against most of the
capicom.utilities functions:
getMessage() . "\n";
echo 'exception initialising com object... terminating...';
}
$string = 'foo';
$encoded = $util->Base64Encode($string); /* encoded string is \r\n
terminated */
echo $encoded . ' is base 64 encoded string:' . $util-
>Base64Decode($encoded) . "\n";
echo "\n\n";
$hex = $util->BinaryToHex($string);
echo "BinaryToHex: " . $util->BinaryToHex($string) . "\n";
echo "hextobinary: " . $util->HexToBinary($hex) . "\n";
define( 'CAPICOM_ENCODE_BASE64', 0 );
echo "Random Number: " . $util->GetRandom(10, CAPICOM_ENCODE_BASE64) .
"\n";
$variant = $util->BinaryStringToByteArray($string);
$i = 0;
foreach( $variant as $v) {
echo "Byte(" . $i++ . "): " . $v . "\n";
}
Outputing:
ZgBvAG8A
is base 64 encoded string:foo
BinaryToHex: 66006F006F00
hextobinary: foo
Random Number: PiMSnPtckiHFCQ==
Byte(0): 102
Byte(1): 0
Byte(2): 111
Byte(3): 0
Byte(4): 111
Byte(5): 0
--
1) It might be worth trying a newer version of php
2) it might be worth checking that the com object is registered
correctly by attempting to access it from a vbscript
Previous Comments:
[2009-06-08 18:05:57] will at flourishlib dot com
Description:
In previous versions of PHP it was possible to create a COM object for
CAPICOM to generate random data. I'm not sure at what version it broke,
but now trying to instantiate the COM object, an exception is thrown
with the message "Failed to create COM object 'CAPICOM.Utilities.1':
Invalid syntax".
This behavior seem to be present on both 5.2.9-2 and 5.2.10RC1.
I've been unable to figure out what this error really means. The ProgID
I'm specifying is valid according to Microsoft -
http://msdn.microsoft.com/en-us/library/aa388176(VS.85).aspx.
Any sort of direction would be useful in trying to solve this issue.
Reproduce code:
---
new COM('CAPICOM.Utilities.1');
Expected result:
A COM object that can be used.
Actual result:
--
An exception with the message:
Failed to create COM object 'CAPICOM.Utilities.1': Invalid syntax
--
Edit this bug report at http://bugs.php.net/?id=48498&edit=1
#48534 [Ver]: Infinite loop with: log_errors+display_startup_errors+no timezone
ID: 48534 User updated by: paul at mantisforge dot org Reported By: paul at mantisforge dot org Status: Verified Bug Type: PHP options/info functions Operating System: Windows 32bit PHP Version: 5.3.0RC3 Assigned To: derick New Comment: Jom, You should only get this behaviour if you do not specifiy a timezone in php.ini. In addition, display_startup_errors should normally be OFF for a production site, which seemed to be one of the requirements to actually hit this issue. NOTE: if your running fastcgi and edit the relevant php.ini, you may need to restart the application pool for the change to take effect. Paul Previous Comments: [2009-07-05 19:01:02] jom at grosjo dot net No, this is the ACTUAL bug: *Whatever* timezone you define or not in php.ini, php launch the loop above. Php 5,30 is just unusable in the current status. Maybe you consider this not critical, but it makes the complete work on 5.3 useless, because we can not use it ! [2009-07-05 18:36:20] paj...@php.net This issue was not critical enough to be a stopping point. It is easily fixable by actually doing the right thing: Set a correct timezone in your php.ini. [2009-07-05 14:26:03] jom at grosjo dot net So there are no reason to *release" 5.3 when it is so full of bugs [2009-07-05 12:51:29] paj...@php.net Instead of being loud or use a keyboard with a broken caps lock, can you please read carefully what I wrote earlier last month? "Will be fixed after 5.3.0" I think it is clear. [2009-07-05 12:47:32] jom at grosjo dot net This bug STILL EXISTS IN THE RELEASED VERSION (5.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/48534 -- Edit this bug report at http://bugs.php.net/?id=48534&edit=1
#49816 [NEW]: output corruption using flush
From: paul at wcclan dot net Operating system: FreeBSD 7.2-RELEASE-p4 PHP version: 5.2.11 PHP Bug Type: Output Control Bug description: output corruption using flush Description: Looping through the output of a process opened with popen while using flush return "garbage" in the browser. Using telnet the intended output can be seen in (likely corrupted) chuncked encoding. Commenting out the flush() in below code fixes the problem. Reproduce code: --- \r\n"; flush(); } pclose($handle); } ?> Expected result: the output of the command whois php.net Actual result: -- seemingly random garbage in browser. Above script available through: http://ipv6.wcclan.net/test.php -- Edit bug report at http://bugs.php.net/?id=49816&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49816&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49816&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49816&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49816&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49816&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49816&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49816&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49816&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49816&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49816&r=support Expected behavior: http://bugs.php.net/fix.php?id=49816&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49816&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49816&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49816&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49816&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49816&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49816&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49816&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49816&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49816&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49816&r=mysqlcfg
#49816 [Com]: output corruption using flush
ID: 49816 Comment by: paul at wcclan dot net Reported By: paul at wcclan dot net Status: Feedback Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: Thanks for the response. As far as I know I didn't make any changes to the compression settings. Anything specific I should look at? The request and headers are as follows: GET /ipinfo HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, */* Accept-Language: nl User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC1; .NET CLR 3.5.30729; .NET CLR 3.0.30729) UA-CPU: AMD64 Accept-Encoding: gzip, deflate Host: ipv6.wcclan.net Connection: Keep-Alive With flush in code (broken output): HTTP/1.1 200 OK Date: Thu, 08 Oct 2009 20:58:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 664 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Without flush in code (correct output): HTTP/1.1 200 OK Date: Thu, 08 Oct 2009 20:59:19 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 750 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Your hint about compression is correct. Both the requests are handled with compression. The code using flush returns "garbage" the code not using flush returns correct output. Previous Comments: [2009-10-08 20:44:01] sjo...@php.net Thank you for bug report. The garbage data you see in the browser is the correct page, but compressed. The data is probably automatically compressed by Apache or PHP, without setting the correct headers. Because the headers are not set, the browser does not uncompress the page. Please check your server settings and confirm this is the problem. There may still be a bug here, in that flush() breaks gzip compression. In that case we need some more information on how the compression is configured. [2009-10-08 20:06:52] paul at wcclan dot net Description: Looping through the output of a process opened with popen while using flush return "garbage" in the browser. Using telnet the intended output can be seen in (likely corrupted) chuncked encoding. Commenting out the flush() in below code fixes the problem. Reproduce code: --- \r\n"; flush(); } pclose($handle); } ?> Expected result: the output of the command whois php.net Actual result: -- seemingly random garbage in browser. Above script available through: http://ipv6.wcclan.net/test.php -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#49816 [Fbk->Opn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net Reported By: paul at wcclan dot net -Status: Feedback +Status: Open Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: possibly interresting php.ini setting: zlib.output_compression = On Previous Comments: [2009-10-08 21:05:50] paul at wcclan dot net Thanks for the response. As far as I know I didn't make any changes to the compression settings. Anything specific I should look at? The request and headers are as follows: GET /ipinfo HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, */* Accept-Language: nl User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC1; .NET CLR 3.5.30729; .NET CLR 3.0.30729) UA-CPU: AMD64 Accept-Encoding: gzip, deflate Host: ipv6.wcclan.net Connection: Keep-Alive With flush in code (broken output): HTTP/1.1 200 OK Date: Thu, 08 Oct 2009 20:58:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 664 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Without flush in code (correct output): HTTP/1.1 200 OK Date: Thu, 08 Oct 2009 20:59:19 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 750 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Your hint about compression is correct. Both the requests are handled with compression. The code using flush returns "garbage" the code not using flush returns correct output. [2009-10-08 20:44:01] sjo...@php.net Thank you for bug report. The garbage data you see in the browser is the correct page, but compressed. The data is probably automatically compressed by Apache or PHP, without setting the correct headers. Because the headers are not set, the browser does not uncompress the page. Please check your server settings and confirm this is the problem. There may still be a bug here, in that flush() breaks gzip compression. In that case we need some more information on how the compression is configured. [2009-10-08 20:06:52] paul at wcclan dot net Description: Looping through the output of a process opened with popen while using flush return "garbage" in the browser. Using telnet the intended output can be seen in (likely corrupted) chuncked encoding. Commenting out the flush() in below code fixes the problem. Reproduce code: --- \r\n"; flush(); } pclose($handle); } ?> Expected result: the output of the command whois php.net Actual result: -- seemingly random garbage in browser. Above script available through: http://ipv6.wcclan.net/test.php -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#49816 [Opn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net Reported By: paul at wcclan dot net Status: Open Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: setting zlib.output_compression to Off fixes the problem. I have no output handlers defined. Is there anything more that might of interrest? Previous Comments: [2009-10-08 21:12:05] paul at wcclan dot net possibly interresting php.ini setting: zlib.output_compression = On [2009-10-08 21:05:50] paul at wcclan dot net Thanks for the response. As far as I know I didn't make any changes to the compression settings. Anything specific I should look at? The request and headers are as follows: GET /ipinfo HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, */* Accept-Language: nl User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC1; .NET CLR 3.5.30729; .NET CLR 3.0.30729) UA-CPU: AMD64 Accept-Encoding: gzip, deflate Host: ipv6.wcclan.net Connection: Keep-Alive With flush in code (broken output): HTTP/1.1 200 OK Date: Thu, 08 Oct 2009 20:58:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 664 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Without flush in code (correct output): HTTP/1.1 200 OK Date: Thu, 08 Oct 2009 20:59:19 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 750 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Your hint about compression is correct. Both the requests are handled with compression. The code using flush returns "garbage" the code not using flush returns correct output. [2009-10-08 20:44:01] sjo...@php.net Thank you for bug report. The garbage data you see in the browser is the correct page, but compressed. The data is probably automatically compressed by Apache or PHP, without setting the correct headers. Because the headers are not set, the browser does not uncompress the page. Please check your server settings and confirm this is the problem. There may still be a bug here, in that flush() breaks gzip compression. In that case we need some more information on how the compression is configured. [2009-10-08 20:06:52] paul at wcclan dot net Description: Looping through the output of a process opened with popen while using flush return "garbage" in the browser. Using telnet the intended output can be seen in (likely corrupted) chuncked encoding. Commenting out the flush() in below code fixes the problem. Reproduce code: --- \r\n"; flush(); } pclose($handle); } ?> Expected result: the output of the command whois php.net Actual result: -- seemingly random garbage in browser. Above script available through: http://ipv6.wcclan.net/test.php -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#49816 [Opn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net Reported By: paul at wcclan dot net Status: Open Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. Previous Comments: [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 [2009-10-19 15:08:38] j...@php.net What was the last PHP version it worked with..? (try with same libs!) [2009-10-15 20:28:03] radek at pinkbike dot com I have the same problem on Centos 5.2, php 5.2.11 Encoding bug using flush with zlib output handler. To reproduce... Turn on zlib.output_compression = On and load a page containing the following with a browser. the result is garbled up ��*I-.���ÿÿ� ~Ø��� If you dont use flush() works correctly. If you dont turn on zlib.output_compression works correctly. Note that it's not simply user config error as it works correctly without flush(). [2009-10-10 16:57:40] alec at alec dot pl Same here on Gentoo. Nothing was changed in configuration only PHP has been updated to 5.2.11 and my scripts stops working. zlib.output_compression=Off fixes issue, but also disables compression. Maybe important, I've got updated zlib library to version 1.2.3 in the same time. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49816 -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#49816 [Opn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net Reported By: paul at wcclan dot net Status: Open Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. Previous Comments: [2009-10-22 19:27:53] paul at wcclan dot net To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 [2009-10-19 15:08:38] j...@php.net What was the last PHP version it worked with..? (try with same libs!) [2009-10-15 20:28:03] radek at pinkbike dot com I have the same problem on Centos 5.2, php 5.2.11 Encoding bug using flush with zlib output handler. To reproduce... Turn on zlib.output_compression = On and load a page containing the following with a browser. the result is garbled up ��*I-.���ÿÿ� ~Ø��� If you dont use flush() works correctly. If you dont turn on zlib.output_compression works correctly. Note that it's not simply user config error as it works correctly without flush(). 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#49816 [Asn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net Reported By: paul at wcclan dot net Status: Assigned Bug Type: Apache2 related Operating System: * PHP Version: 5.* Assigned To: jani New Comment: I might be reading this wrong, but aren't you just opting not to compress with this code? If so, how do you explain that compression worked fine before 5.2.11? If I am reading it wrong, great job on the fix :) Previous Comments: [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) [2009-11-14 22:28:40] j...@php.net Caused by fixing bug #49248 and does not happen with HEAD. [2009-10-26 13:05:08] j...@php.net At least you can disable zlib compression in script now.. :/ See bug #49248, fix for that borked the compression on Apache if you use flush(). [2009-10-25 02:28:44] magnusf at users dot sourceforge dot net Confirmed problem on Solaris 10 X86_64, PHP 5.2.11, Apache 2.2.13. Disabling zlib output compression or reverting to 5.2.9 solves the problem. See application specific issue http://www.sugarcrm.com/forums/showthread.php?t=52694 when using 5.2.11 and flush. Problem with Apache 2.2.11 and PHP 5.2.11 so seems to be PHP issue, quote forum: "and the problem seems to rely on a change/bugfix? of the authentication/encryption mechanism in the latest 5.2.x and 5.3.x versions." [2009-10-24 00:21:21] j...@php.net Apparently Apache2 is special. See bug #27424 (thanks Scott..) 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#41770 [Com]: SSL: fatal protocol error due to buffer issues
ID: 41770
Comment by: paul at cynergydata dot com
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.3
Assigned To: iliaa
New Comment:
I'm using PHP 5.1.4 on a Windows XP Laptop running Apache 2.0 and I get
the error when using SoapClient. Here is my code:
$url =
"https://payments.cynergydata.com/SmartPayments/transact2.asmx?WSDL";;
$client = new SoapClient($url);
-- a pretty simple example going against an IIS server. I will try
other methods as I need to find a workaround for a client ASAP.
Previous Comments:
[2007-07-25 13:31:41] johnw at sussex dot ac dot uk
I get this bug too,using fsockopen('ssl://...') followed by fgets()
I'm using PHP 5.2.1 on Solaris 9 using OpenSSL/0.9.7b.
If I call @fgets(...) my application seems to work but it would be
better if the bug was fixed properly!
The ssl server I'm connecting to is an IIS one.
[2007-07-13 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-07-05 20:36:18] [EMAIL PROTECTED]
I am unable to reproduce the bug with 4 different HTTPS hosts and the
provided code. Do you have a particular URL/host that can be used to
reproduce the described issue.
[2007-07-02 16:50:24] [EMAIL PROTECTED]
iliaa: All you did is make the warning not appear with that commit. You
didn't fix the underlying issue with the connection. It still closes the
connection and now it will just mysteriously start failing rather then
giving a warning about why it's failing.
I would revert your commit and not mark this as fixed.
[2007-07-02 16:42:17] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
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/41770
--
Edit this bug report at http://bugs.php.net/?id=41770&edit=1
#47390 [NEW]: odbc_fetch_into - BC in php 5.3.0
From: paul at quakenet dot org
Operating system: NA
PHP version: 5.3.0beta1
PHP Bug Type: ODBC related
Bug description: odbc_fetch_into - BC in php 5.3.0
Description:
odbc_fetch_into reuses objects in php 5.3.0
The repro code belows works correctly with PHP 5.2.3, 5.2.5, 5.2.8,
5.2.9rc
And behaves 'incorrectly' in PHP 5.3a2, 5.3b1, 5.3a3.
This issue was spotted whilst investigating why an application utilising
the adodb db abstraction library started behaving incorrectly when using
php 5.3
Reproduce code:
---
odbc = odbc_connect($g_hostname,$dbuser,$dbpass);
$res = odbc_exec($this->odbc, $metaTablesSQL);
$foo = array();
echo "First Set (these should match 2nd set):\n";
while (odbc_fetch_into($res, $this->fields)) {
//var_dump($this->fields);die;
$foo[] = $this->fields;
echo $this->fields[0] . "\n";
}
echo "Second Set (should match 1st set):\n";
foreach($foo as $bar) {
echo $bar[0] . "\n";
}
}
}
$f = new testcase();
Expected result:
table1
table2
table3
---
table1
table2
table3
Actual result:
--
table1
table2
table3
table3
table3
table3
--
Edit bug report at http://bugs.php.net/?id=47390&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47390&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47390&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47390&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47390&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47390&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47390&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47390&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47390&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47390&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47390&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47390&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47390&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47390&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47390&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47390&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47390&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47390&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47390&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47390&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47390&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47390&r=mysqlcfg
#37527 [Com]: Crash - odbc_exec on closed pconnect
ID: 37527
Comment by: paul at quakenet dot org
Reported By: bhines at alumni dot ucsd dot edu
Status: Open
Bug Type: ODBC related
Operating System: Windows XP
PHP Version: 5.1.6
New Comment:
Felipe,
I can reproduce this (5.3 branch) and the patch attached does't
appear to fix this issue.
This issue only seems to occur when returning $mydb. If the
odbc_pconnect is moved outside of pdb_Connect or the code function
definition is changed to function &pdb_Connect(), the issue does not
occur.
With:
$mydb = pdb_Connect();
odbc_close_all();
var_dump($mydb);
Output is: resource(5) of type (odbc link persistent)
Changing the code to not return $mydb e.g. call odbc_pconnect within
printPage, result of the var_dump is: resource(5) of type (Unknown)
Previous Comments:
[2008-10-21 22:32:07] fel...@php.net
Well, I can't reproduce it.
[2008-10-21 11:38:01] j...@php.net
Was that fix applied? Does this bug exist in PHP_5_2 branch still? If
so, please update the version..
[2008-02-17 17:22:46] fel...@php.net
Possible fix:
http://felipe.ath.cx/diff/bug37527.diff
[2007-09-25 13:21:33] alexandra at zend dot com
Hi
There is a simple work-around to make this script work - there is a
problem with the fact that you declared the $mydb var global in one
function but not the other.
You can change the printPage() function to solve this issue.
function printPage()
{
global $mydb;
$mydb = pdb_Connect();
odbc_close($mydb);
print "Possibly Crashing now... ";
$results = odbc_exec($mydb, 'SELECT * FROM _PDB_Access');
}
[2006-09-29 23:22:16] bhines at alumni dot ucsd dot edu
Still occurs in 5.1.6
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/37527
--
Edit this bug report at http://bugs.php.net/?id=37527&edit=1
#47701 [NEW]: print_r sends output when $return set to true if memory limit is reached
From: paul at paulmcgarry dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: print_r sends output when $return set to true if memory limit is reached Description: This relates to Bug #47020 which I believe has incorrectly set to bogus. I have been using print_r() while processing $errcontext in an error handling function, ie one registered with set_error_handler() It seems that when print_r() hits the memory limit it exposes my entire error context to the user. print_r having a failure mode where it exposes potentially private data to the user is a security issue. If it can't be fixed easily then it should be documented. -- Edit bug report at http://bugs.php.net/?id=47701&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47701&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47701&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47701&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47701&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47701&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47701&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47701&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47701&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47701&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47701&r=support Expected behavior: http://bugs.php.net/fix.php?id=47701&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47701&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47701&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47701&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47701&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47701&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47701&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47701&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47701&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47701&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47701&r=mysqlcfg
#47701 [Bgs]: print_r sends output when $return set to true if memory limit is reached
ID: 47701 User updated by: paul at paulmcgarry dot com Reported By: paul at paulmcgarry dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 5.2.9 New Comment: I mentioned 47020 in the first sentence of my initial report so referring me to it is hardly enlightening or productive and pretty much indicates you didn't bother to read the report at all (we are all no doubt time poor, so I understand the temptation!). If this is bogus then please explain why. Personally I cannot see how a failure mode that potentially exposes private data to the user can not be a genuine issue. Previous Comments: [2009-03-18 23:25:30] fel...@php.net Please, see bug #47020. Thanks. [2009-03-18 12:08:43] scott...@php.net Martin, where exactly is this fix? I looked through the NEWS file and saw no entries. [2009-03-18 11:06:36] mmcnicklebugs at googlemail dot com This has been fixed in CVS. -- Martin McNickle [2009-03-18 02:37:31] paul at paulmcgarry dot com Description: This relates to Bug #47020 which I believe has incorrectly set to bogus. I have been using print_r() while processing $errcontext in an error handling function, ie one registered with set_error_handler() It seems that when print_r() hits the memory limit it exposes my entire error context to the user. print_r having a failure mode where it exposes potentially private data to the user is a security issue. If it can't be fixed easily then it should be documented. -- Edit this bug report at http://bugs.php.net/?id=47701&edit=1
#47701 [Bgs]: print_r sends output when $return set to true if memory limit is reached
ID: 47701 User updated by: paul at paulmcgarry dot com Reported By: paul at paulmcgarry dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 5.2.9 New Comment: I didn't submit the other bug and don't have a CVS account. As far as I can see that means I can't "Add your comments to bug #47020" so telling me to do so is pointless. The original reporter of that bug _did_ add further detail and yet that bug still sits as bogus. If this is bogus then please explain why. Don't just point to another bug that was marked as bogus with no reason given. I'm sure you are busy, but this is all very disheartening from a bug reporters perspective. Previous Comments: [2009-03-21 23:14:37] j...@php.net Uh..disregard my previous comment. This is still bogus. Add your comments to bug #47020 instead of reporting same thing twice.. [2009-03-21 23:12:32] j...@php.net FYI: print_f / var_dump are for debugging ONLY.. [2009-03-21 23:11:32] j...@php.net Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. [2009-03-19 01:20:12] fel...@php.net My mistake, Paul. Sorry. ---- [2009-03-18 23:37:10] paul at paulmcgarry dot com I mentioned 47020 in the first sentence of my initial report so referring me to it is hardly enlightening or productive and pretty much indicates you didn't bother to read the report at all (we are all no doubt time poor, so I understand the temptation!). If this is bogus then please explain why. Personally I cannot see how a failure mode that potentially exposes private data to the user can not be a genuine issue. 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/47701 -- Edit this bug report at http://bugs.php.net/?id=47701&edit=1
Bug #49816 [Bgs]: output corruption using flush
Edit report at http://bugs.php.net/bug.php?id=49816&edit=1 ID: 49816 User updated by:paul at wcclan dot net Reported by:paul at wcclan dot net Summary:output corruption using flush Status: Bogus Type: Bug Package:Apache2 related Operating System: * PHP Version:5.* Block user comment: N New Comment: with php 5.3.3 the "just don't compress" solution seems to be in place so at least it doesn't cause any problems. However, shouldn't flush() also work when applying compression? Previous Comments: [2010-08-07 13:26:52] johan...@php.net The new output buffering is in trunk, it won't be ported to 5.3. [2010-01-30 15:39:16] ben at xnode dot org Still experiencing this issue with PHP 5.3.1 and Apache 2.2.14. Quite annoying as it means either not being able to use Flush (which isn't an option for some apps) or not being able to use compression. [2009-11-19 15:59:01] j...@php.net Unfortunately flush() with apache2handler SAPI will also disable compression. Like I've said in the commit it's temporary "fix" to at least keep things working. The real fix requires doing MFH of new output buffering code where this works fine. Johannes, please reply, I've asked you several times now whether I can merge the new and working output buffering code from HEAD (like I already suggested before 5.3.0 was released!). ---- [2009-11-18 21:19:12] paul at wcclan dot net I might be reading this wrong, but aren't you just opting not to compress with this code? If so, how do you explain that compression worked fine before 5.2.11? If I am reading it wrong, great job on the fix :) [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) 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/bug.php?id=49816 -- Edit this bug report at http://bugs.php.net/bug.php?id=49816&edit=1
#50811 [NEW]: mssql_bind fails to bind parameters greater than 256 characters long
From: paul at dezinnia dot com
Operating system: Windows Vista
PHP version: 5.2.12
PHP Bug Type: MSSQL related
Bug description: mssql_bind fails to bind parameters greater than 256
characters long
Description:
using the mssql database extension, i am attempting to bind a parameter
of type nvarchar(1999) to a stored procedure. Everything works as
expected except when the length of the parameter exceeds 256 chracters.
In the case of a parameter length in excess of 256 characters the
following message is returned by the DB server. "Procedure or function
'FunctionName' expects parameter '@ParameterName', which was not
supplied."
Reproduce code:
---
---
>From manual page: function.mssql-bind
---
this code won't reproduce the bug since you don't have access to my
database...but i'm including it here so you you can be sure i'm not just
getting a syntax error...
$sp = mssql_init("dbo.AddSnippet", $db);
$b = mssql_bind($sp, "@SnippetName", $snippetName, SQLVARCHAR, false,
false, 120);
$b = mssql_bind($sp, "@SnippetDescription", $snippetDescription,
SQLVARCHAR, false, false, 480);
$b = mssql_bind($sp, "@SnippetContent", $snippetContent, SQLVARCHAR,
false, false, 1999);
$b = mssql_bind($sp, "@tagstring", $tagstring, SQLVARCHAR, false, false,
1999);
$b = mssql_bind($sp, "@TagUserID", $tagUserID, SQLINT4);
mssql_execute($sp);
Expected result:
The stored procedure should add a record to the database and is designed
to store nvarchar values of lengths up to 1999 characters.
Actual result:
--
When the parameter length exceeds 256 characters, an error occurs.
When the parameter length is <=256 characters, no error occurs.
--
Edit bug report at http://bugs.php.net/?id=50811&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50811&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50811&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50811&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50811&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50811&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50811&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50811&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50811&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50811&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50811&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50811&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50811&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50811&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50811&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50811&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50811&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50811&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50811&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50811&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50811&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50811&r=mysqlcfg
Bug #50829 [Com]: php.ini directive pdo_mysql.default_socket is ignored
Edit report at http://bugs.php.net/bug.php?id=50829&edit=1
ID: 50829
Comment by: paul at boxuk dot com
Reported by: giovanni at giacobbi dot net
Summary: php.ini directive pdo_mysql.default_socket is ignored
Status: Closed
Type: Bug
Package: PDO related
Operating System: Linux
PHP Version: 5.3.2RC1
New Comment:
this, or a problem relating to this fix appears to be seg-faulting the
pdo_mysql
module on startup in ZTS mode
bug #51216 is related
commenting out REGISTER_INI_ENTRIES() in ext/pdo_mysql/pdo_mysql.c:68
php
startup prevents the seg-fault
configure line
--
./configure --enable-maintainer-zts --with-mysql --with-mysqli=mysqlnd
--enable-
pdo --with-pdo-mysql
gdb output
--
gdb sapi/cli/php
GNU gdb Fedora (6.8-37.el5)
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run
Starting program: /php-5.3.2/sapi/cli/php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f776c0 (LWP 491)]
[New Thread 0xb7d0db90 (LWP 494)]
[Thread 0xb7d0db90 (LWP 494) exited]
Program received signal SIGSEGV, Segmentation fault.
0x08347ff5 in zend_startup_module_ex (module=0x98d2720,
tsrm_ls=0x98b7050)
at /opt/BoxUK/install/php-5.3.2/Zend/zend_API.c:1618
1618EG(current_module) = NULL;
module->name at this point is "pdo_mysql"
Previous Comments:
[2010-02-03 21:00:21] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=294469
Log: Fixed bug #50829 (php.ini directive pdo_mysql.default_socket is
ignored)
[2010-01-26 13:15:59] il...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-01-26 13:15:57] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=294040
Log: Fixed bug #50829 (php.ini directive pdo_mysql.default_socket is
ignored)
[2010-01-24 14:03:53] giovanni at giacobbi dot net
Description:
The php.ini pdo_mysql.default_socket seems to be ignored.
see related (closed) bug #49306
Reproduce code:
---
php -d pdo_mysql.default_socket=ciao -r
'var_dump(ini_get("pdo_mysql.default_socket"));'
Expected result:
string(4) "ciao"
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50829&edit=1
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=1 ID: 51216 Comment by: paul at boxuk dot com Reported by: dtm2mcs at gmail dot com Summary: Segmentation fault when compiling PHP with PHAR Status: Open Type: Bug Package: PHAR related Operating System: Ubuntu 6.04 + CentOS 5.4 PHP Version: 5.3.2 New Comment: i can also reproduce this, i believe it's something to do with the fix for bug #50829 amended that bug with the details Previous Comments: [2010-03-22 11:32:02] creatorbri at gmail dot com I have the same problem when attempting to compile PHP 5.3.2. Details: PHP Version: PHP 5.3.2 - I downloaded the "stable" release dated "04 Mar 2010" directly from one of the usual php.net mirrors Platform: Ubuntu 9.10 Karmic Koala x64 [Asus G60Jx-RBBx05 - Core i5-430 2.26 GHz 4.0 GB RAM] Configure Options: ./configure --prefix=PREFIX --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr -- with-mysqli=/usr/bin/mysql_config --with-pgsql=/usr --with-tidy=/usr --with- curl=/usr/bin --with-curlwrappers --with-openssl-dir=/usr --with-zlib-dir=/usr - -enable-mbstring --with-xpm-dir=/usr --with-pdo-pgsql=/usr --with-pdo-mysql=/usr --with-xsl=/usr --with-ldap --with-xmlrpc --with-iconv-dir=/usr --with-snmp=/usr --enable-exif --enable-calendar --with-bz2=/usr --with-mcrypt=/usr --with-gd -- with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-freetype- dir=/usr --enable-mbstring --enable-zip --with-pear ERROR: ext/sqlite3/libsqlite/.libs/sqlite3.o: In function `memset': /usr/include/bits/string3.h:82: warning: memset used with constant zero length parameter; this could be due to transposed parameters Generating phar.php Segmentation fault make: *** [ext/phar/phar.php] Error 139 [2010-03-16 16:22:12] vnegrier at optilian dot com Not PHAR related, this is actually the php-cli binary segfaulting during the make process. Here is a trace : 0x0839c8f4 in zend_startup_module_ex (module=0x8732210, tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_API.c:1618 1618EG(current_module) = NULL; (gdb) where #0 0x0839c8f4 in zend_startup_module_ex (module=0x8732210, tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_API.c:1618 #1 0x083a177a in zend_hash_apply (ht=0x8711460, apply_func=0x839c850 , tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_hash.c:673 #2 0x0839c75a in zend_startup_modules (tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_API.c:1662 #3 0x083372f0 in php_module_startup (sf=0x86f82c0, additional_modules=0x0, num_additional_modules=0) at /usr/src/php-5.3.2/main/main.c:2022 #4 0x084299f1 in php_cli_startup (sapi_module=0x86f82c0) at /usr/src/php-5.3.2/sapi/cli/php_cli.c:401 #5 0x0842a32c in main (argc=1, argv=0xbfffcf74) at /usr/src/php-5.3.2/sapi/cli/php_cli.c:775 This was reproduced on debian 5.0.4 x86 [2010-03-12 11:39:22] jedibc at free dot fr Same issue on debian lenny x86 : Generating phar.php /bin/sh: line 1: 16624 Segmentation fault ` if test -x "/root/php-5.3.2/sapi/cli/php"; then /root/php-5.3.2/build/shtool echo -n -- "/root/php-5.3.2/sapi/cli/php -n"; if test "x" != "x"; then /root/php-5.3.2/build/shtool echo -n -- " -d extension_dir=/root/php-5.3.2/modules"; for i in bz2 zlib phar; do if test -f "/root/php-5.3.2/modules/$i.la"; then . /root/php-5.3.2/modules/$i.la; /root/php-5.3.2/build/shtool echo -n -- " -d extension=$dlname"; fi; done; fi; else /root/php-5.3.2/build/shtool echo -n -- "/root/php-5.3.2/sapi/cli/php"; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /root/php-5.3.2/ext/phar/build_precommand.php > ext/phar/phar.php make: *** [ext/phar/phar.php] Error 139 [2010-03-10 12:38:52] fsk141 at gmail dot com I'm having the same issue trying to compile on Arch Linux on the ARM platform... :( make: *** [ext/phar/phar.php] Error 139 [2010-03-06 11:34:55] dtm2mcs at gmail dot com Since i can't compile it on CentOS 5.4 either, it does not seem to be a problem of this older Ubuntu release. 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/bug.php?id=51216 -- Edit this bug report at http://bugs.php.net/bug.php?id=51216&edit=1
Bug #50977 [Com]: imap_headerinfo Address buffer overflow
Edit report at http://bugs.php.net/bug.php?id=50977&edit=1 ID: 50977 Comment by: paul at fubra dot com Reported by:lokitek at gmail dot com Summary:imap_headerinfo Address buffer overflow Status: Feedback Type: Bug Package:IMAP related Operating System: CentOS 5.4 PHP Version:5.2.12 Block user comment: N New Comment: I'm also experiencing this error with CentOS release 5.3 (Final). yum list libc-client libc-client.i386 2004g-2.2.1 Previous Comments: [2010-04-25 20:06:28] fel...@php.net Any news? [2010-02-20 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-02-10 20:26:50] lokitek at gmail dot com drop centOS isn't all that easy - What would you recommend instead? ;) I'll update c-client and will let you know. Thanks! [2010-02-10 16:24:41] paj...@php.net Yes, or you may drop centos as well, known to have outdated versions of everything. Please let us know if it still happens once you have a decent version if c-client. [2010-02-10 16:06:17] lokitek at gmail dot com The c-client library is: libc-client 2004g-2.2.1 2004 sounds somewhat old, should I try to find an upgrade for it? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50977 -- Edit this bug report at http://bugs.php.net/bug.php?id=50977&edit=1
#45271 [NEW]: php gives negative memory error with memory limit at 2 gig
From: paul at paulscripts dot nl Operating system: Linux PHP version: 5.2.6 PHP Bug Type: Reproducible crash Bug description: php gives negative memory error with memory limit at 2 gig Description: php gives the next fatal error: Fatal error: Allowed memory size of -2147483648 bytes exhausted (tried to allocate 2147221481 bytes) in /root/convert.php on line 6 when trying to use a script with a memory limit of 2gig. Reproduce code: --- http://bugs.php.net/?id=45271&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45271&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45271&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45271&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45271&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45271&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45271&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45271&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45271&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45271&r=support Expected behavior:http://bugs.php.net/fix.php?id=45271&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45271&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45271&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45271&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45271&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45271&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45271&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45271&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45271&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45271&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45271&r=mysqlcfg
#35091 [NEW]: SoapClient leaks memory
From: paul at paulbutcher dot com Operating system: All PHP version: 5.0.5 PHP Bug Type: SOAP related Bug description: SoapClient leaks memory Description: SoapClient doesn't seem to clean up after itself when garbage collected. It leaks something around 4K each time. Tested on both Windows and Linux. Reproduce code: --- Expected result: Assuming that I understand the PHP Garbage Collector (and it's possible that I don't - I'm struggling to find any good documentation on exactly how I should expect it to behave - any pointers very welcome!), I would expect the memory usage of this script to be constant. Actual result: -- The memory usage increases very quickly (growing to several hundred megabytes in less than a minute). -- Edit bug report at http://bugs.php.net/?id=35091&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35091&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35091&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35091&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35091&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35091&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35091&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35091&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35091&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35091&r=support Expected behavior: http://bugs.php.net/fix.php?id=35091&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35091&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35091&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35091&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35091&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35091&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35091&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35091&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35091&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35091&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35091&r=mysqlcfg
#35091 [Fbk->Opn]: SoapClient leaks memory
ID: 35091 User updated by: paul at paulbutcher dot com Reported By: paul at paulbutcher dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: * PHP Version: 5.0.5 New Comment: Same result (on Windows - haven't tried it on Linux yet) Previous Comments: [2005-11-03 21:42:36] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-11-03 19:52:18] paul at paulbutcher dot com Description: SoapClient doesn't seem to clean up after itself when garbage collected. It leaks something around 4K each time. Tested on both Windows and Linux. Reproduce code: --- Expected result: Assuming that I understand the PHP Garbage Collector (and it's possible that I don't - I'm struggling to find any good documentation on exactly how I should expect it to behave - any pointers very welcome!), I would expect the memory usage of this script to be constant. Actual result: -- The memory usage increases very quickly (growing to several hundred megabytes in less than a minute). -- Edit this bug report at http://bugs.php.net/?id=35091&edit=1
#35091 [Bgs->Opn]: SoapClient leaks memory
ID: 35091
User updated by: paul at paulbutcher dot com
Reported By: paul at paulbutcher dot com
-Status: Bogus
+Status: Open
Bug Type: SOAP related
Operating System: *
PHP Version: 5.0.5
New Comment:
Sorry - I don't understand. Your example repeatedly appends to a
string, which of course will legitimately increase the size of the
string until it eventually fills memory.
I don't understand how this is the same as repeatedly allocating an
object. My example doesn't maintain a reference to the object, so
surely it should be garbage collected immediately?
In fact, if I replace SoapClient with an object of my own making then
memory usage remains constant:
What am I missing?
Thanks!
Previous Comments:
[2005-11-04 09:28:48] [EMAIL PROTECTED]
Ah, I should get glasses. You can also get all memory used with
something like this:
while (1) { $foo.= "bar"; }
Not bug but expected behaviour. Just don't do that!
----
[2005-11-04 00:36:03] paul at paulbutcher dot com
Same result (on Windows - haven't tried it on Linux yet)
[2005-11-03 21:42:36] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
----
[2005-11-03 19:52:18] paul at paulbutcher dot com
Description:
SoapClient doesn't seem to clean up after itself when garbage
collected. It leaks something around 4K each time. Tested on both
Windows and Linux.
Reproduce code:
---
Expected result:
Assuming that I understand the PHP Garbage Collector (and it's possible
that I don't - I'm struggling to find any good documentation on exactly
how I should expect it to behave - any pointers very welcome!), I would
expect the memory usage of this script to be constant.
Actual result:
--
The memory usage increases very quickly (growing to several hundred
megabytes in less than a minute).
--
Edit this bug report at http://bugs.php.net/?id=35091&edit=1
#42092 [NEW]: Unable to open xml via SimpleXML
From: paul at christianpatriot dot us
Operating system: Linux
PHP version: 5.2.3
PHP Bug Type: SimpleXML related
Bug description: Unable to open xml via SimpleXML
Description:
Attempting to append child/attributes to an existing xml file using post
data from an html form. Post data gets passed fine, but it seems the xml
file is never opened or loaded.
Since I don't think the file is ever opened, I am unable to (attempt to)
write the new data to the file.
Reproduce code:
---
processgb.php
addChild('entry');
$entry->addAttribute('date',date("Y-m-d"));
$entry->addChild('name',$_POST["name"]);
$entry->addChild('email',$_POST["email"]);
$entry->addChild('homepage',$_POST["homepage"]);
$entry->addChild('country',$_POST["country"]);
$entry->addChild('comment',$_POST["comment"]);
$result=file_put_contents($sxe,"gbook.xml"); if ($result<1 or
result==false): echo 'error writing: '.$result;
endif;
?>
XML structure:
Expected result:
The new data is added to the xml file.
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message 'String
could not be parsed as XML' in
/usr/local/apache2/htdocs/ssa/9112001/guestbook/processgb.php:9 Stack
trace: #0 /usr/local/apache2/htdocs/ssa/9112001/guestbook/processgb.php(9):
SimpleXMLElement->__construct('') #1 {main} thrown in
/usr/local/apache2/htdocs/ssa/9112001/guestbook/processgb.php on line 9
--
Edit bug report at http://bugs.php.net/?id=42092&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42092&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42092&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42092&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42092&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42092&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42092&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42092&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42092&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42092&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42092&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42092&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42092&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42092&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42092&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42092&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42092&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42092&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42092&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42092&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42092&r=mysqlcfg
#42105 [NEW]: CLI binary segfaults on ldap_bind(), Apache module works fine
From: paul at moonkhan dot org
Operating system: RHEL4
PHP version: 5.2.3
PHP Bug Type: CGI related
Bug description: CLI binary segfaults on ldap_bind(), Apache module works fine
Description:
ldap_bind(), whether anonymous or not, produces a Segfault when run from
the command line. This is occurring on 5.2.3 (and I can reproduce it on
5.2.1). Please note that 5.1.6 does not have this problem.
Reproduce code:
---
$ds = ldap_connect("ldaps://ldap.example.com");
if($ds) {
echo "Connected\n";
// Anonymous bind
$br = ldap_bind($ds);
// Use this for authenticated binds
//$br = ldap_bind($ds, $argv[1], $argv[2]);
echo "Bind result: $br\n";
}
Expected result:
Connected
Bind result: 1
Actual result:
--
Connected
Bind result: 1
Segmentation fault
Backtrace:
(gdb) bt
#0 0x005c5140 in ASN1_primitive_free () from /lib/libcrypto.so.4
#1 0x005c518a in ASN1_primitive_free () from /lib/libcrypto.so.4
#2 0x005c521d in ASN1_primitive_free () from /lib/libcrypto.so.4
#3 0x005c545d in ASN1_template_free () from /lib/libcrypto.so.4
#4 0x005c5383 in ASN1_primitive_free () from /lib/libcrypto.so.4
#5 0x005c545d in ASN1_template_free () from /lib/libcrypto.so.4
#6 0x005c5383 in ASN1_primitive_free () from /lib/libcrypto.so.4
#7 0x005c5493 in ASN1_item_free () from /lib/libcrypto.so.4
#8 0x005c05d1 in X509_free () from /lib/libcrypto.so.4
#9 0x003e9712 in ssl_sess_cert_free () from /lib/libssl.so.4
#10 0x003ea4b9 in SSL_SESSION_free () from /lib/libssl.so.4
#11 0x003e825b in SSL_free () from /lib/libssl.so.4
#12 0x00a57b13 in ldap_pvt_tls_init () from /usr/lib/libldap-2.2.so.7
#13 0x002f5726 in ber_sockbuf_remove_io () from /usr/lib/liblber-
2.2.so.7
#14 0x002f57d6 in ber_int_sb_destroy () from /usr/lib/liblber-2.2.so.7
#15 0x002f586d in ber_sockbuf_free () from /usr/lib/liblber-2.2.so.7
#16 0x00a418e8 in ldap_ld_free () from /usr/lib/libldap-2.2.so.7
#17 0x00a41b16 in ldap_unbind_ext () from /usr/lib/libldap-2.2.so.7
#18 0x00a41c60 in ldap_unbind_s () from /usr/lib/libldap-2.2.so.7
#19 0x0812099f in _close_ldap_link (rsrc=0xb7fab080) at /usr/src/php-
5.2.3/ext/ldap/ldap.c:200
#20 0x08290781 in list_entry_destructor (ptr=0xb7fab080) at
/usr/src/php-5.2.3/Zend/zend_list.c:184
#21 0x0828e409 in zend_hash_del_key_or_index (ht=0x84066e0, arKey=0x0,
nKeyLength=0, h=4, flag=1)
at /usr/src/php-5.2.3/Zend/zend_hash.c:497
#22 0x0829051c in _zend_list_delete (id=4) at /usr/src/php-
5.2.3/Zend/zend_list.c:58
#23 0x08279799 in _zval_ptr_dtor (zval_ptr=0xb7faa128) at
/usr/src/php-5.2.3/Zend/zend_variables.h:35
#24 0x0828f750 in zend_hash_apply_deleter (ht=0x8406650, p=0xb7faa11c)
at /usr/src/php-5.2.3/Zend/zend_hash.c:611
#25 0x0828f7eb in zend_hash_graceful_reverse_destroy (ht=0x8406650) at
/usr/src/php-5.2.3/Zend/zend_hash.c:646
#26 0x08279dfa in shutdown_executor () at /usr/src/php-
5.2.3/Zend/zend_execute_API.c:239
#27 0x08286354 in zend_deactivate () at /usr/src/php-
5.2.3/Zend/zend.c:860
#28 0x0824f058 in php_request_shutdown (dummy=0x0) at /usr/src/php-
5.2.3/main/main.c:1317
#29 0x08300b5f in main (argc=2, argv=0xbfe04c74) at /usr/src/php-
5.2.3/sapi/cli/php_cli.c:1319
--
Edit bug report at http://bugs.php.net/?id=42105&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42105&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42105&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42105&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42105&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42105&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42105&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42105&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42105&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42105&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42105&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42105&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42105&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42105&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42105&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42105&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42105&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42105&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42105&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42105&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42105&r=mysqlcfg
#42105 [Fbk->Opn]: CLI binary segfaults on ldap_bind(), Apache module works fine
ID: 42105
User updated by: paul at moonkhan dot org
Reported By: paul at moonkhan dot org
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: RHEL4
PHP Version: 5.2CVS-2007-07-26
New Comment:
Here is the configure line:
Configure Command => './configure'
'--with-apxs2=/usr/local/httpd-2.2.4/bin/apxs'
'--prefix=/usr/local/php-5.2.1' '--sysconfdir=/usr/local/etc/php'
'--with-config-file-path=/usr/local/etc/php' '--with-gd'
'--with-zlib-dir=/usr' '--with-jpeg-dir=/usr' '--with-ldap'
'--with-mcrypt' '--with-mhash' '--with-curl' '--with-openssl'
'--with-xsl' '--with-libxml' '--with-pear=/usr/local/pear'
'--with-mysql' '--with-oci8=instantclient,/usr/src/instantclient_10_2'
'--with-sigchild' '--with-custom-odbc=/usr/local/odbc32v52' '--with-ttf'
'--with-freetype-dir=/usr'
Just ignore the weird --prefix - I had no intention of doing a make
install on this compile :) Also, on the snapshot configure, it
mentioned that --with-libxml and --with-sigchild are not real options
anymore but I just left them in there anyways.
Thanks,
-Paul
Previous Comments:
----
[2007-07-26 15:29:31] [EMAIL PROTECTED]
What was the full configure line used? (check from CLI php with -i
option :)
[2007-07-26 14:09:39] paul at moonkhan dot org
The CVS snapshot didn't fix the segfaulting when using the command line
binary.
[2007-07-25 19:52:02] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-07-25 16:19:09] paul at moonkhan dot org
Description:
ldap_bind(), whether anonymous or not, produces a Segfault when run
from
the command line. This is occurring on 5.2.3 (and I can reproduce it on
5.2.1). Please note that 5.1.6 does not have this problem.
Reproduce code:
---
$ds = ldap_connect("ldaps://ldap.example.com");
if($ds) {
echo "Connected\n";
// Anonymous bind
$br = ldap_bind($ds);
// Use this for authenticated binds
//$br = ldap_bind($ds, $argv[1], $argv[2]);
echo "Bind result: $br\n";
}
Expected result:
Connected
Bind result: 1
Actual result:
--
Connected
Bind result: 1
Segmentation fault
Backtrace:
(gdb) bt
#0 0x005c5140 in ASN1_primitive_free () from /lib/libcrypto.so.4
#1 0x005c518a in ASN1_primitive_free () from /lib/libcrypto.so.4
#2 0x005c521d in ASN1_primitive_free () from /lib/libcrypto.so.4
#3 0x005c545d in ASN1_template_free () from /lib/libcrypto.so.4
#4 0x005c5383 in ASN1_primitive_free () from /lib/libcrypto.so.4
#5 0x005c545d in ASN1_template_free () from /lib/libcrypto.so.4
#6 0x005c5383 in ASN1_primitive_free () from /lib/libcrypto.so.4
#7 0x005c5493 in ASN1_item_free () from /lib/libcrypto.so.4
#8 0x005c05d1 in X509_free () from /lib/libcrypto.so.4
#9 0x003e9712 in ssl_sess_cert_free () from /lib/libssl.so.4
#10 0x003ea4b9 in SSL_SESSION_free () from /lib/libssl.so.4
#11 0x003e825b in SSL_free () from /lib/libssl.so.4
#12 0x00a57b13 in ldap_pvt_tls_init () from /usr/lib/libldap-2.2.so.7
#13 0x002f5726 in ber_sockbuf_remove_io () from /usr/lib/liblber-
2.2.so.7
#14 0x002f57d6 in ber_int_sb_destroy () from /usr/lib/liblber-2.2.so.7
#15 0x002f586d in ber_sockbuf_free () from /usr/lib/liblber-2.2.so.7
#16 0x00a418e8 in ldap_ld_free () from /usr/lib/libldap-2.2.so.7
#17 0x00a41b16 in ldap_unbind_ext () from /usr/lib/libldap-2.2.so.7
#18 0x00a41c60 in ldap_unbind_s () from /usr/lib/libldap-2.2.so.7
#19 0x0812099f in _close_ldap_link (rsrc=0xb7fab080) at /usr/src/php-
5.2.3/ext/ldap/ldap.c:200
#20 0x08290781 in list_entry_destructor (ptr=0xb7fab080) at
/usr/src/php-5.2.3/Zend/zend_list.c:184
#21 0x0828e409 in zend_hash_del_key_or_index (ht=0x84066e0, arKey=0x0,
nKeyLength=0, h=4, flag=1)
at /usr/src/php-5.2.3/Zend/zend_hash.c:497
#22 0x0829051c in _zend_list_delete (id=4) at /usr/src/php-
5.2.3/Zend/zend_list.c:58
#23 0x08279799 in _zval_ptr_dtor (zval_ptr=0xb7faa128) at
/usr/src/php-5.2.3/Zend/zend_variables.h:35
#24 0x0828f750 in zend_hash_apply_deleter (ht=0x8406650, p=0xb7faa11c)
at /usr/src/php-5.2.3/Zend/zend_hash.c:611
#25 0x0828f7eb in zend_hash_graceful_reverse_destroy (ht=0x8406650) at
/usr/src/php-5.2.3/Zend/zend_hash.c:646
#26 0x08279dfa in shutdown_executor
#42105 [Fbk->Opn]: CLI binary segfaults on ldap_bind(), Apache module works fine
ID: 42105
User updated by: paul at moonkhan dot org
Reported By: paul at moonkhan dot org
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: RHEL4
PHP Version: 5.2.3
New Comment:
The CVS snapshot didn't fix the segfaulting when using the command line
binary.
Previous Comments:
[2007-07-25 19:52:02] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-07-25 16:19:09] paul at moonkhan dot org
Description:
ldap_bind(), whether anonymous or not, produces a Segfault when run
from
the command line. This is occurring on 5.2.3 (and I can reproduce it on
5.2.1). Please note that 5.1.6 does not have this problem.
Reproduce code:
---
$ds = ldap_connect("ldaps://ldap.example.com");
if($ds) {
echo "Connected\n";
// Anonymous bind
$br = ldap_bind($ds);
// Use this for authenticated binds
//$br = ldap_bind($ds, $argv[1], $argv[2]);
echo "Bind result: $br\n";
}
Expected result:
Connected
Bind result: 1
Actual result:
--
Connected
Bind result: 1
Segmentation fault
Backtrace:
(gdb) bt
#0 0x005c5140 in ASN1_primitive_free () from /lib/libcrypto.so.4
#1 0x005c518a in ASN1_primitive_free () from /lib/libcrypto.so.4
#2 0x005c521d in ASN1_primitive_free () from /lib/libcrypto.so.4
#3 0x005c545d in ASN1_template_free () from /lib/libcrypto.so.4
#4 0x005c5383 in ASN1_primitive_free () from /lib/libcrypto.so.4
#5 0x005c545d in ASN1_template_free () from /lib/libcrypto.so.4
#6 0x005c5383 in ASN1_primitive_free () from /lib/libcrypto.so.4
#7 0x005c5493 in ASN1_item_free () from /lib/libcrypto.so.4
#8 0x005c05d1 in X509_free () from /lib/libcrypto.so.4
#9 0x003e9712 in ssl_sess_cert_free () from /lib/libssl.so.4
#10 0x003ea4b9 in SSL_SESSION_free () from /lib/libssl.so.4
#11 0x003e825b in SSL_free () from /lib/libssl.so.4
#12 0x00a57b13 in ldap_pvt_tls_init () from /usr/lib/libldap-2.2.so.7
#13 0x002f5726 in ber_sockbuf_remove_io () from /usr/lib/liblber-
2.2.so.7
#14 0x002f57d6 in ber_int_sb_destroy () from /usr/lib/liblber-2.2.so.7
#15 0x002f586d in ber_sockbuf_free () from /usr/lib/liblber-2.2.so.7
#16 0x00a418e8 in ldap_ld_free () from /usr/lib/libldap-2.2.so.7
#17 0x00a41b16 in ldap_unbind_ext () from /usr/lib/libldap-2.2.so.7
#18 0x00a41c60 in ldap_unbind_s () from /usr/lib/libldap-2.2.so.7
#19 0x0812099f in _close_ldap_link (rsrc=0xb7fab080) at /usr/src/php-
5.2.3/ext/ldap/ldap.c:200
#20 0x08290781 in list_entry_destructor (ptr=0xb7fab080) at
/usr/src/php-5.2.3/Zend/zend_list.c:184
#21 0x0828e409 in zend_hash_del_key_or_index (ht=0x84066e0, arKey=0x0,
nKeyLength=0, h=4, flag=1)
at /usr/src/php-5.2.3/Zend/zend_hash.c:497
#22 0x0829051c in _zend_list_delete (id=4) at /usr/src/php-
5.2.3/Zend/zend_list.c:58
#23 0x08279799 in _zval_ptr_dtor (zval_ptr=0xb7faa128) at
/usr/src/php-5.2.3/Zend/zend_variables.h:35
#24 0x0828f750 in zend_hash_apply_deleter (ht=0x8406650, p=0xb7faa11c)
at /usr/src/php-5.2.3/Zend/zend_hash.c:611
#25 0x0828f7eb in zend_hash_graceful_reverse_destroy (ht=0x8406650) at
/usr/src/php-5.2.3/Zend/zend_hash.c:646
#26 0x08279dfa in shutdown_executor () at /usr/src/php-
5.2.3/Zend/zend_execute_API.c:239
#27 0x08286354 in zend_deactivate () at /usr/src/php-
5.2.3/Zend/zend.c:860
#28 0x0824f058 in php_request_shutdown (dummy=0x0) at /usr/src/php-
5.2.3/main/main.c:1317
#29 0x08300b5f in main (argc=2, argv=0xbfe04c74) at /usr/src/php-
5.2.3/sapi/cli/php_cli.c:1319
--
Edit this bug report at http://bugs.php.net/?id=42105&edit=1
#39713 [NEW]: Static variables defined in static methods duplicated in derived classes
From: paul at digitalbacon dot us Operating system: Linux, Mac OS X 10.4, Windows XP PHP version: 5.2.0 PHP Bug Type: Scripting Engine problem Bug description: Static variables defined in static methods duplicated in derived classes Description: When using a static variable defined inside a parent class's static method block, different outcomes can occur depending on the scope name used when calling. The effect is that a non-overridden method in the child class is allocated a completely separate static variable... not how it works in C or C++, which I know PHP is not. I encountered this problem implementing a singleton pattern in a parent class. I apologize for the reproduction code, but it does illustrate my perceived problem. The closest bugs I found, relate to static class attributes, not regular static variables. Reproduce code: --- Expected result: My intuition tells me that the parent's static variable should be used regardless of the scope name used... unless it's actually redefined in the child class. In this example, I expect the output to be: $a1: 1 $a2: $b1: $b2: Is local static method data not shared? Actual result: -- $a1: 1 $a2: $b1: 1 $b2: -- Edit bug report at http://bugs.php.net/?id=39713&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39713&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39713&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39713&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39713&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39713&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39713&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39713&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39713&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39713&r=support Expected behavior:http://bugs.php.net/fix.php?id=39713&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39713&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39713&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39713&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39713&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39713&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39713&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39713&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39713&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39713&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39713&r=mysqlcfg
#39713 [Bgs]: Static variables defined in static methods duplicated in derived classes
ID: 39713 User updated by: paul at digitalbacon dot us Reported By: paul at digitalbacon dot us Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux, Mac OS X 10.4, Windows XP PHP Version: 5.2.0 New Comment: >From the manual: ...A static variable exists only in a local function scope, but it does not lose its value when program execution leaves this scope. I don't see why the use of the scope resolution operator (::) should change a static method's local function scope. Can a single static method really have multiple local scopes if using inheritance? Previous Comments: [2006-12-02 11:49:09] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2006-12-02 04:24:04] paul at digitalbacon dot us Description: When using a static variable defined inside a parent class's static method block, different outcomes can occur depending on the scope name used when calling. The effect is that a non-overridden method in the child class is allocated a completely separate static variable... not how it works in C or C++, which I know PHP is not. I encountered this problem implementing a singleton pattern in a parent class. I apologize for the reproduction code, but it does illustrate my perceived problem. The closest bugs I found, relate to static class attributes, not regular static variables. Reproduce code: --- Expected result: My intuition tells me that the parent's static variable should be used regardless of the scope name used... unless it's actually redefined in the child class. In this example, I expect the output to be: $a1: 1 $a2: $b1: $b2: Is local static method data not shared? Actual result: -- $a1: 1 $a2: $b1: 1 $b2: -- Edit this bug report at http://bugs.php.net/?id=39713&edit=1
#40713 [Com]: set_magic_quotes_runtime(0) causes Fatal Error
ID: 40713 Comment by: paul at phpbbservice dot nl Reported By: spam02 at pornel dot net Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 6CVS-2007-03-03 (snap) New Comment: phpBB2 doesn't support php5 official, so php6 is a complete no ;) phpBB3 support php6 perfect, there are special for php6 checks in common.php Previous Comments: [2007-03-03 20:56:15] spam02 at pornel dot net Description: It's great that PHP6 dropped support for magic_quotes, but I don't see a reason to trigger fatal error when set_magic_quotes_runtime(0) is executed (note the argument value). I think it's completly harmless if application attempts to *disable* magic_quotes in PHP6 and error should be thrown only on attempts to enable magic_quotes. In practicular this affects PHPBB, which won't run under PHP6 because of this. Reproduce code: --- http://bugs.php.net/?id=40713&edit=1
#39162 [NEW]: register_shuwdown_function calls not when trigger_error is used
From: paul at profielland dot nl Operating system: WIN32 PHP version: 5.1.6 PHP Bug Type: Unknown/Other Function Bug description: register_shuwdown_function calls not when trigger_error is used Description: When you register a shutdown function with register_shutdown_function, and using trigger_error to give a error to the user, the function registered by register_shutdown_function isn't called. Reproduce code: --- Expected result: Fatal error: Error here in /var/www/error.php on line 11 blabla Actual result: -- Fatal error: Error here in /var/www/error.php on line 11 -- Edit bug report at http://bugs.php.net/?id=39162&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39162&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39162&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39162&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39162&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39162&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39162&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39162&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39162&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39162&r=support Expected behavior:http://bugs.php.net/fix.php?id=39162&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39162&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39162&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39162&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39162&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39162&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39162&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39162&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39162&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39162&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39162&r=mysqlcfg
#39162 [Fbk->Csd]: register_shuwdown_function calls not when trigger_error is used
ID: 39162 User updated by: paul at profielland dot nl Reported By: paul at profielland dot nl -Status: Feedback +Status: Closed Bug Type: Unknown/Other Function Operating System: WIN32 PHP Version: 5.1.6 New Comment: My mistake, has forgot to call a function in my class. Previous Comments: [2006-10-15 17:12:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Can't reproduce. [2006-10-15 17:03:19] paul at profielland dot nl Description: When you register a shutdown function with register_shutdown_function, and using trigger_error to give a error to the user, the function registered by register_shutdown_function isn't called. Reproduce code: --- Expected result: Fatal error: Error here in /var/www/error.php on line 11 blabla Actual result: -- Fatal error: Error here in /var/www/error.php on line 11 -- Edit this bug report at http://bugs.php.net/?id=39162&edit=1
#39302 [NEW]: integer/datatype error
From: paul at takizo dot com
Operating system: FreeBSD 6.1 Released
PHP version: 5.1.6
PHP Bug Type: Math related
Bug description: integer/datatype error
Description:
I wrote a function to match a number and return result. But it seem like
not working then certain integer is assigned.
It should return "hello world" When the loop value match 0.06, but it
doesn't. But it works is other value assigned. For ecample 0.01, 0.02,
0.10 and etc.
Reproduce code:
---
function testing($selection = 0)
{
for ($i = 0; $i <= 0.20; $i = $i + 0.01)
{
if($i == $selection)
{
echo 'hello world';
}
}
}
testing(0.06);
Expected result:
hello world
--
Edit bug report at http://bugs.php.net/?id=39302&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39302&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39302&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39302&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39302&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39302&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39302&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39302&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39302&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39302&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39302&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39302&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39302&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39302&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39302&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39302&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39302&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39302&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39302&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39302&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39302&r=mysqlcfg
#37366 [Com]: IIS 6.0 w3wp process crash with PHP 5.1.4
ID: 37366 Comment by: paul at routingcore dot com Reported By: chris dot schreiber at fast4gl dot com Status: Open Bug Type: Reproducible crash Operating System: Windows 2003 Server PHP Version: 5.1.4 New Comment: I get the same thing. I hadn't updated since 5.0.4, which works fine for me. As soon as I drop 5.1.4 in I get the application errors for w3wp.exe. I set IIS to recycle the worker threads every couple of minutes to see if the frequency of the errors would increase, and they did. Previous Comments: [2006-05-08 15:48:22] gravityworksllc at hotmail dot com I can validate this error. I get this along with the pool process crashing. This was fine in version 5.12. If you need more information on the errors please let me know. Kind regards, Mynd www.myndpollution.com [2006-05-08 14:07:47] chris dot schreiber at fast4gl dot com Description: This problem occurs using the newest builds of PHP, both 5.1.3 and 5.1.4. This did not happen with 5.1.2 or earlier versions. Running IIS 6.0 on Windows 2003 Server Enterprise. Running PHP in ISAPI mode. w3wp.exe processes crash throughout the day, about 20-30 times. Several process instances will usually crash together at the same time, and then be ok for a couple of hours until happening again. Error is: w3wp.exe - Application Error : The instruction at "0x01b55c80" referenced memory at "0x01b55c80". The memory could not be "read". The memory address is always either "0x01b55c80" or "0x01b55c90". Here is a link to my PHPinfo(): http://mail.fast4gl.net/phpinfo.php Reproduce code: --- Running vBulletin (3.5.4). Can't track down any code which produces the crash. -- Edit this bug report at http://bugs.php.net/?id=37366&edit=1
