#21425 [NEW]: rename() - interesting behaviour
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux PHP version: 4.3.0 PHP Bug Type: Filesystem function related Bug description: rename() - interesting behaviour it's an interesting thing about the rename() function: the code which doesn't work: and which works (if the script is in the same dir): error message for the first code: Warning: rename(/home/phanatic/temp/users,/home/phanatic/temp/userdata) [http://www.php.net/function.rename]: No such file or directory in /home/phanatic/temp/test_rename.php on line 8 my configure line: ./configure --with-layout=GNU --with-mysql=shared --with-pgsql=shared --with-gd=shared --with-gd2 --enable-ftp --with-calendar --with-posix -- enable-sockets --enable-cli --enable-cgi --enable-pcntl --with-bz2=shared --with-zlib-dir=/usr/include/ --prefix=/usr --sysconfdir=/etc/php hope i could provide all the infos needed to fix this problem... -- Edit bug report at http://bugs.php.net/?id=21425&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21425&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21425&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21425&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21425&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21425&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21425&r=support Expected behavior: http://bugs.php.net/fix.php?id=21425&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21425&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21425&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21425&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21425&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21425&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21425&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21425&r=gnused
#21425 [Bgs->Opn]: rename() - interesting behaviour
ID: 21425 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Filesystem function related Operating System: Debian GNU/Linux PHP Version: 4.3.0 New Comment: the file is there, i'm sure about it... and the script itself is in '/home/phanatic/temp', too!!! so it's not a bogus in my opinion... just test it yourself. Previous Comments: [2003-01-05 07:13:40] [EMAIL PROTECTED] The error is clear it can't find /home/phanatic/temp/users, probably because of permissions or probably because it's NOT the good directory. Are you sure ./ is /home/phanatic/temp/? Anyway this is bogus, if you need any help please take a look at http://www.php.net/support.php . Thank you for your report. [2003-01-05 05:16:29] [EMAIL PROTECTED] it's an interesting thing about the rename() function: the code which doesn't work: and which works (if the script is in the same dir): error message for the first code: Warning: rename(/home/phanatic/temp/users,/home/phanatic/temp/userdata) [http://www.php.net/function.rename]: No such file or directory in /home/phanatic/temp/test_rename.php on line 8 my configure line: ./configure --with-layout=GNU --with-mysql=shared --with-pgsql=shared --with-gd=shared --with-gd2 --enable-ftp --with-calendar --with-posix -- enable-sockets --enable-cli --enable-cgi --enable-pcntl --with-bz2=shared --with-zlib-dir=/usr/include/ --prefix=/usr --sysconfdir=/etc/php hope i could provide all the infos needed to fix this problem... -- Edit this bug report at http://bugs.php.net/?id=21425&edit=1
#21425 [Fbk->Opn]: rename() - interesting behaviour
ID: 21425 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Debian GNU/Linux PHP Version: 4.3.0 New Comment: perms of the file: -rw-r--r--1 phanatic phanatic 99 Jan 5 10:36 users perms of the dir: drwxr-xr-x5 phanatic phanatic 4096 Jan 5 12:06 temp but in my opinion, if this happens because of the permissions, then why does the second script work? thanx in advance... Previous Comments: [2003-01-05 07:24:20] [EMAIL PROTECTED] Can you please show us the permission of the directory and of the files please? It looks I really CAN NOT reproduce it there... Thank you. [2003-01-05 07:21:23] [EMAIL PROTECTED] the file is there, i'm sure about it... and the script itself is in '/home/phanatic/temp', too!!! so it's not a bogus in my opinion... just test it yourself. [2003-01-05 07:13:40] [EMAIL PROTECTED] The error is clear it can't find /home/phanatic/temp/users, probably because of permissions or probably because it's NOT the good directory. Are you sure ./ is /home/phanatic/temp/? Anyway this is bogus, if you need any help please take a look at http://www.php.net/support.php . Thank you for your report. [2003-01-05 05:16:29] [EMAIL PROTECTED] it's an interesting thing about the rename() function: the code which doesn't work: and which works (if the script is in the same dir): error message for the first code: Warning: rename(/home/phanatic/temp/users,/home/phanatic/temp/userdata) [http://www.php.net/function.rename]: No such file or directory in /home/phanatic/temp/test_rename.php on line 8 my configure line: ./configure --with-layout=GNU --with-mysql=shared --with-pgsql=shared --with-gd=shared --with-gd2 --enable-ftp --with-calendar --with-posix -- enable-sockets --enable-cli --enable-cgi --enable-pcntl --with-bz2=shared --with-zlib-dir=/usr/include/ --prefix=/usr --sysconfdir=/etc/php hope i could provide all the infos needed to fix this problem... -- Edit this bug report at http://bugs.php.net/?id=21425&edit=1
#21425 [Fbk->Csd]: rename() - interesting behaviour
ID: 21425 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Filesystem function related Operating System: Debian GNU/Linux PHP Version: 4.3.0 New Comment: solved the problem... there were really no problems, just didn't realize a bug in my script ;( sorry for the inconvenience... Previous Comments: [2003-01-05 07:38:27] [EMAIL PROTECTED] Assuming that you run this script with the Command Line version (not through your webserver), can you run: strace php yourscript.php and put this output somewhere online? We should be able to figure out what fails in the script. Derick [2003-01-05 07:34:55] [EMAIL PROTECTED] perms of the file: -rw-r--r--1 phanatic phanatic 99 Jan 5 10:36 users perms of the dir: drwxr-xr-x5 phanatic phanatic 4096 Jan 5 12:06 temp but in my opinion, if this happens because of the permissions, then why does the second script work? thanx in advance... [2003-01-05 07:24:20] [EMAIL PROTECTED] Can you please show us the permission of the directory and of the files please? It looks I really CAN NOT reproduce it there... Thank you. [2003-01-05 07:21:23] [EMAIL PROTECTED] the file is there, i'm sure about it... and the script itself is in '/home/phanatic/temp', too!!! so it's not a bogus in my opinion... just test it yourself. [2003-01-05 07:13:40] [EMAIL PROTECTED] The error is clear it can't find /home/phanatic/temp/users, probably because of permissions or probably because it's NOT the good directory. Are you sure ./ is /home/phanatic/temp/? Anyway this is bogus, if you need any help please take a look at http://www.php.net/support.php . Thank you for your report. 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/21425 -- Edit this bug report at http://bugs.php.net/?id=21425&edit=1
#6678 [Com]: Different behaviour of arithmetic operations on Linux PHP and Windows PHP
ID: 6678 Comment by: linux at hotmail dot com Reported By: info at emre dot de Status: Closed Bug Type: Unknown/Other Function Operating System: Windows 2000 & SuSE Linux PHP Version: 4.0.2 New Comment: http://www.cafepress.com/fearpenguin http://www.cafepress.com/tux_vs_msn http://www.cafepress.com/chixdiglinux http://www.cafepress.com/design4living Previous Comments: [2000-10-15 11:25:46] [EMAIL PROTECTED] Your problem is probably due to the size of the numeric datatype (which is system dependant). The number that you're passing is actually too big (ie: over 2 billion). See http://www.php.net/manual/language.types.php [2000-09-12 05:41:28] info at emre dot de > 8; } // The array containing the bits is joined to a string, the bytes separated by a dot $ip = "$bytes[3].$bytes[2].$bytes[1].$bytes[0]"; return ($ip); } print int2ip(3232235648); /* Result should be 192.168.0.128. On WAMP it works fine, on LAMP it doesn´t. Maybe this one´s not bug but I´m too dump - still this "wrong" behaviour has been verfied on several Linux systems running Apache and PHP. The correct one has been verified on three Windows systems running Apache and PHP (latest) */ ?> -- Edit this bug report at http://bugs.php.net/?id=6678&edit=1
#4754 [Com]: Linux-OracleDB -> defunc ->--enable-sigchild ->problems with persistent conect.
ID: 4754 Comment by: linux at hotmail dot com Reported By: jl_villar at hotmail dot com Status: Closed Bug Type: Oracle related Operating System: Linux RedHat 6.1 PHP Version: 4.0.0 Release New Comment: http://www.cafepress.com/fearpenguin http://www.cafepress.com/tux_vs_msn http://www.cafepress.com/chixdiglinux http://www.cafepress.com/design4living Previous Comments: [2000-08-08 22:33:27] [EMAIL PROTECTED] closed due to missing feedback [2000-06-02 11:31:18] thies at cvs dot php dot net please try to reproduce the behaviour *without* using oracle-connections. just try to see if there's a difference in apache's behaviour when u use --enable-sigchild opposed not using it! [2000-06-01 13:10:08] jl_villar at hotmail dot com In Spanish: -- En Linux,con Oracle 8.1.6, PHP4.0.0 y Apache 1.3.12 para evitar procesos , recompile PHP con --enable-sigchild Se solucionaron los procesos pero aparecen problemas con las conexiones persistentes de apache. Algunas veces, no cierra el socket cuando deja de recibir información por un tiempo especificado en el httpd.conf KeepAliveTimeout(normalmente 15 segundos). No cierra el socket transcurrido este tiempo pero tampoco lo atiende, lo que da lugar que algunos navegadores se muestren bloqueados en la posición de "read" del socket. Como no este socket no esta cerrado se mantien esperando de manera indefinida. Gracias JL -- Edit this bug report at http://bugs.php.net/?id=4754&edit=1
Bug #52818 [Com]: PCRE segfault
Edit report at https://bugs.php.net/bug.php?id=52818&edit=1 ID: 52818 Comment by: eugenia at linux dot com Reported by:svimik at mail dot ru Summary:PCRE segfault Status: Not a bug Type: Bug Package:Reproducible crash Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: change the pcre.recursion_limit directive prevents a stack overflow but not correct the problem with preg_match. After the change, the preg_match function not find a coincidence in the same context (maybe because it stops the recursion) but finds a coincidence in a reduced context. So, why do you think is not a bug? Give me an exact explanation, tell me how I can solving this problem and I will tell you that it's not a bug. But now, is a bug. Previous Comments: [2010-09-14 17:45:55] paj...@php.net It does not matter if you use apache or not, same cause, same solution. I mentioned apache as an example. [2010-09-14 17:32:26] svimik at mail dot ru >Because it depends on your apache builds As I said, I'm NOT using Apache, I run this script directly in console, by "php -f file.php" command. >In any case, that's not something we can fix. Why is not possible to catch this error? [2010-09-14 17:06:21] paj...@php.net Because it depends on your apache builds and configurations. You can increase both using php.ini and with some tools on unix (don't remember which, but there is other reports about how to do it here). In any case, that's not something we can fix. [2010-09-14 16:27:11] svimik at mail dot ru Why stack overflow is not a bug? [2010-09-14 13:09:14] ahar...@php.net I can replicate this on a stock trunk build, and it is (as usual) a simple stack overflow. Closing. 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 https://bugs.php.net/bug.php?id=52818 -- Edit this bug report at https://bugs.php.net/bug.php?id=52818&edit=1
Bug #54716 [Com]: Internal Server Error when php compiled with oci driver
Edit report at https://bugs.php.net/bug.php?id=54716&edit=1
ID: 54716
Comment by: debian at linux dot org
Reported by:dominik dot szybowski at bzwbk dot pl
Summary:Internal Server Error when php compiled with oci
driver
Status: Feedback
Type: Bug
Package:OCI8 related
Operating System: AIX
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
My Configuration :
- Debian GNU/Linux 6 64-bit
- Oracle Instantclient 11.2
- PHP 5.3.14
- mod_auth_kerb 5.4
- Apache 2.2.16
- Kerberos Heimdal
This can be reproduced using Apache graceful command.
Just after the mod_auth_kerb will fail to read the kerberos conf
gss_import_name() failed: Miscellaneous failure (, Can't open/find Kerberos
configuration file. it will use the same default kerberos configuration as
Oracle Database !!!
You can force the path using sqlnet.ora but it will fail after when using gss
acquire credential (unknown error 2 or 21).
We did not find a fix.
Previous Comments:
[2012-01-09 14:01:56] rattlebrain at gmx dot net
I have a similar problem.
mod_auth_kerb works fine as long as I don't use the PHP OCI8 extension. As soon
as I load the OCI8 extension, mod_auth_kerb starts to behave weird. After an
Apache (re)start everything is fine, but when I reload Apache I'm getting in a
browser "Internal Server Error" and in the error log (just like the topic
starter):
[Mon Jan 09 14:33:00 2012] [error] [client 10.206.33.199] gss_import_name()
failed: Miscellaneous failure (, Can't open/find Kerberos configuration file)
After stracing the Apache processes it appeared that /krb5/krb.conf is trying
to be opened, but obviously fails on a Linux system. I could prove that Oracle
OCI is doing this by setting the SQLNET.KERBEROS5_CONF parameter to a different
value in sqlnet.ora.
So in some way OCI mixes up the Kerberos stuff that mod_auth_kerb is using, but
only when Apache is reloaded. Without everything works perfect, including the
PHP OCI8 stuff.
I'm using:
- Debian GNU/Linux 6 64-bit
- Oracle Instantclient Basic 11.2.0.2.0
- PHP 5.3.3 (Debian package rebuild to include OCI8)
- mod_auth_kerb 5.4
- Apache 2.2.16
To create the OCI8 stuff I added the following parameters to the standard
Debian PHP build parameters:
--with-oci8=shared,/usr
--with-pdo-oci=shared,/usr
This is the complete configure command:
CFLAGS="-g -O2 -O2 -Wall -fsigned-char -fno-strict-aliasing -gstabs"
PROG_SENDMAIL="/usr/sbin/sendmail" ../configure \
--prefix=/usr --with-apxs2=/usr/bin/apxs2 \
--with-config-file-path=/etc/php5/apache2 \
--with-config-file-scan-dir=/etc/php5/apache2/conf.d \
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --disable-debug
--with-regex=php --disable-rp
ath --disable-static --with-pic --with-layout=GNU --with-pear=/usr/share/php
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-sysvmsg
--enable-bcmath --with-bz2
--enable-ctype --with-db4 --with-qdbm=/usr --without-gdbm --with-iconv
--enable-exif --enable-ftp --with-gettext --enable-mbstring --with-onig=/usr
--with-pcre-regex=/usr --
enable-shmop --enable-sockets --enable-wddx --with-libxml-dir=/usr --with-zlib
--with-kerberos=/usr --with-openssl=/usr --enable-soap --enable-zip
--with-mhash=yes --with-ex
ec-dir=/usr/lib/php5/libexec --with-system-tzdata \
--without-mm \
--with-curl=shared,/usr \
--with-enchant=shared,/usr \
--with-zlib-dir=/usr \
--with-gd=shared,/usr --enable-gd-native-ttf \
--with-gmp=shared,/usr \
--with-jpeg-dir=shared,/usr \
--with-xpm-dir=shared,/usr/X11R6 \
--with-png-dir=shared,/usr \
--with-freetype-dir=shared,/usr \
--with-imap=shared,/usr \
--with-imap-ssl \
--with-interbase=shared,/usr --with-pdo-firebird=shared,/usr \
--enable-intl=shared \
--with-ttf=shared,/usr \
--with-t1lib=shared,/usr \
--with-ldap=shared,/usr \
--with-ldap-sasl=/usr \
--with-mcrypt=shared,/usr \
--with-mysql=shared,/usr \
--with-mysqli=shared,/usr/bin/mysql_config \
--with-pspell=shared,/usr \
--with-unixODBC=shared,/usr \
--with-recode=shared,/usr \
--with-xsl=shared,/usr \
--with-snmp=shared,/usr \
--with-sqlite=shared,/usr \
--with-sqlite3=shared,/usr \
--with-mssql=shared,/usr \
#48603 [Com]: Installing PHP with PEAR support causes installation error
ID: 48603 Comment by: linux at acoustype dot com Reported By: manuel dot schmitt at manitu dot de Status: Open Bug Type: PHAR related Operating System: Linux 2.4 PHP Version: 5.2.10 New Comment: The same error is given to me. make OK make install NG same error can't install but --without-pear make install OK CentOS 5.3 32bit Previous Comments: [2009-06-19 11:08:16] manuel dot schmitt at manitu dot de Description: Installing PHP 5.2.10 with PEAR enabled causes the following error: Fatal error: Error: cannot open phar "/home/redhat/BUILD/php-5.2.10/pear/install-pear-nozlib.phar" in /home/redhat/BUILD/php-5.2.10/pear/install-pear-nozlib.phar on line 795 Reproduce code: --- Configure PHP 5.2.10 with PEAR, build and install it. Our configure options are: ./configure \ --prefix=/usr/local/php5 \ --with-config-file-path=/usr/local/php5/etc \ --with-apxs=/usr/sbin/apxs \ --disable-debug \ --enable-bcmath \ --enable-calendar \ --enable-ctype \ --enable-dbase \ --enable-exif \ --enable-ftp \ --enable-force-cgi-redirect \ --enable-mbstring \ --enable-pdo \ --enable-session \ --enable-soap \ --enable-sockets \ --enable-sqlite-utf8 \ --enable-track-vars \ --enable-wddx \ --enable-zip \ --with-bz2 \ --with-curl \ --with-curlwrappers \ --with-dom \ --with-dom-xslt \ --with-freetype-dir \ --with-gd \ --with-gettext=/usr \ --with-imagemagick \ --with-jpeg-dir \ --with-ldap \ --with-mysql \ --with-openssl \ --with-pcre-regex \ --with-pear \ --with-pdo-mysql \ --with-pdo-sqlite \ --with-pdo-sqlite2 \ --with-png-dir \ --with-ttf \ --with-xslt \ --with-xsl \ --with-zlib Expected result: PEAR should be installed correctly. Actual result: -- The error described above -- Edit this bug report at http://bugs.php.net/?id=48603&edit=1
#38815 [NEW]: kadm5_create_principal() warning
From: klem at linux dot ee Operating system: Linux PHP version: 4.4.4 PHP Bug Type: Unknown/Other Function Bug description: kadm5_create_principal() warning Description: Example from manual gives warning: "No policy specified for [EMAIL PROTECTED]; assigning "default" in .. on line .." Reproduce code: --- $attributes = KRB5_KDB_REQUIRES_PRE_AUTH | KRB5_KDB_DISALLOW_PROXIABLE; $options = array(KADM5_PRINC_EXPIRE_TIME => 0, KADM5_POLICY => "default", KADM5_ATTRIBUTES => $attributes); kadm5_create_principal($handle, "[EMAIL PROTECTED]","password", $options); Expected result: no warning Actual result: -- warning, that no policy was specified and a default policy was assigned -- Edit bug report at http://bugs.php.net/?id=38815&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38815&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38815&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38815&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38815&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38815&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38815&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38815&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38815&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38815&r=support Expected behavior:http://bugs.php.net/fix.php?id=38815&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38815&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38815&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38815&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38815&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38815&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38815&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38815&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38815&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38815&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38815&r=mysqlcfg
#22427 [Com]: Missing Form Post Data
ID: 22427 Comment by: linux at mccoull dot net Reported By: jroland at uow dot edu dot au Status: No Feedback Bug Type: *General Issues Operating System: Windows XP / 2000 PHP Version: 4.2.3 New Comment: I have been having similar problems, i.e. a form which submits happily in Firefox, but not in IE 7. I have found this (very old!) forum entry - http://www.thescripts.com/forum/thread4451.html - which covers my issue, and I have implemented the solution by checking for (isset($_POST['submit']) || isset($_POST['submit_x'])) to check whether my submit button has been clicked. Note that is an underscore, not a '.'. The solution works for GET method as well, if you are using that. If you submit a form with a 'submit' image button using GET, the browser URL shows submit.x=aa&submit.y=bb where aa and bb are the coordinates within the button image of where you clicked, but you should still check for $_GET['submit_x'] NOT $_GET['submit.x']. As discussed in the above referred forum log this is an issue affecting Internet Explorer, Netscape and Opera, and maybe other browsers, and seems to be a simple failure to conform to the HTML standard for handling forms. Hope this helps someone. Andy Previous Comments: [2007-03-12 19:53:16] jpsoren at gmail dot com I experience this problem as well. * Happens both with and without enctype set for form * Happens in IE6 and IE7, NOT in Firefox 1.5/2 * Changing form to GET works flawlessly * Input can range from a few text fields (1-6) or a mix of text fields and file fields, or just file fields (enctype set when file fields exist) and POST data will come up empty * Often times hitting reload and selecting to resubmit the form data will have the POST data show up * NO POST data will show up - I don't just lose some early fields PHP 5.2.x (module), Apache 2.2.x, Windows XP SP2 This is a serious issue. Doesn't seem like anyone in this thread has found any sort of solution. Please post (or GET, ha) if you have any insight. [2007-02-22 15:25:15] elio at tondo dot it I am experiencing the same problem reported on 29 Aug 2006 by "egil at egil dot net". I can add some more details: - I confirm that it happens only with IE; - it is triggered when a character between 0x80 and 0x9f is used in a form field (e.g. the "Word" quotation marks, but also the Euro symbol) -- please note that these are the transposition in the "high half" part of extended ASCII of the 32 "control characters" of ASCII (0x00 - 0x1f); - it has some relationship with character encoding; - I can reproduce it on Linux with Apache 2 on Fedora 4 - 6 if I don't force "AddDefaultCharset UTF-8" in httpd.conf (the default in Fedora); with this directive the problem dies not happen, but the "strange" characters are interpreted incorrectly (because the file is not UTF8); - I cannot reproduce it on Linux Mandrake 10 / Apache 2; - I cannot reproduce it on Windows XP / XAMPP (Apache 2). A further interesting detail: it happens only if the file containing the form has the .php extension; if it has the .htm extension it does not happen! (please note that I am using plain HTML for the form and some PHP to show the results). >From all of the above, it looks like it is not a PHP bug, but instead a IE6 bug that is triggered by some combination of MIME types and character encodings. I am going to prepare a simpler test case (I am currently using a rather complicated page with a multi part form that I extracted from an application that was working on Mandrake and ceased to work on Fedora, and worked again by adding a dummy hidden field as the first one in the form...). When it will be ready I will post it here. In the meantime, does anyone know if a similar problem has been reported elsewhere? [2007-02-19 15:27:27] arek_felinczak at o2 dot pl I had the same problem with empty $_POST table. In my case solution was to remove post_max_size line from php.ini. In php.ini i had post_max_size = 16000 instead of default post_max_size = 8M [2006-12-07 22:30:59] celtic at sairyx dot org I'm experiencing the same problem. Server's running Apache 2 on a Windows Server 2003 machine. IE 6.0, Windows XP SP 2, and about 90% of the time, POST data never reaches my PHP script. Firefox 1.5 in the same conditions, and it runs perfectly. It does seem suspiciously like an IE bug, but this seems too big to be a coincidence that IE never sends POST data to only these PHP applications. -
#36183 [NEW]: urlencode wrongly decodes %00-chars
From: karel at linux dot be
Operating system: Linux
PHP version: 4.4.2
PHP Bug Type: URL related
Bug description: urlencode wrongly decodes %00-chars
Description:
PHP-version: 4.3.11 (linux), and 4.4.0 (windows)
I don't know if this bug is reproducible on any higher version of PHP as I
don't have them to work on.
If you submit a POST/GET/parse_str() to a webpage, where a variable has an
URLencoded string in it, which contains %00. It will end up being mangled
totally.
Just check the reproduce-code, it'll be more clear then my explanation
here.
Reproduce code:
---
$comp_me = gzcompress('Compress me', 9);
parse_str( 'var='. urlencode( $comp_me ) );
var_dump( urlencode($var) );
var_dump( urlencode( $comp_me ) );
Expected result:
I would expect to see 2 urlencoded strings, EXACTLY the same.
Actual result:
--
string(42) "x%DAs%CE%CF-%28J-.V%C8M%05%5C0%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
---^^^
--
Edit bug report at http://bugs.php.net/?id=36183&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36183&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36183&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36183&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36183&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36183&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36183&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36183&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36183&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36183&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36183&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36183&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36183&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36183&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36183&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36183&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36183&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36183&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36183&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36183&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36183&r=mysqlcfg
[PHP-BUG] Bug #54015 [NEW]: PHP processes remaining active while they should not
From: Operating system: CentOS 5.5 PHP version: 5.3.5 Package: FPM related Bug Type: Bug Bug description:PHP processes remaining active while they should not Description: PHP processes are still active even though they are freed up. As soon as a php-fpm reload is performed, the number of php processes drops. So seems that php is not updating the status of the processes. extract of the conf file: pm = dynamic pm.max_children = 120 pm.start_servers = 20 pm.min_spare_servers = 10 pm.max_spare_servers = 20 pm.max_requests = 1000 -- Edit bug report at http://bugs.php.net/bug.php?id=54015&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54015&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54015&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54015&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54015&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54015&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54015&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54015&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54015&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54015&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54015&r=support Expected behavior: http://bugs.php.net/fix.php?id=54015&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54015&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54015&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54015&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54015&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54015&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54015&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54015&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54015&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54015&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54015&r=mysqlcfg
Bug #54716 [Com]: Internal Server Error when php compiled with oci driver
Edit report at https://bugs.php.net/bug.php?id=54716&edit=1 ID: 54716 Comment by: debian at linux dot org Reported by:dominik dot szybowski at bzwbk dot pl Summary:Internal Server Error when php compiled with oci driver Status: Feedback Type: Bug Package:OCI8 related Operating System: AIX PHP Version:5.2.17 Block user comment: N Private report: N New Comment: In our case the PDO Oracle driver break kerberos config. No need to use it, the bug appears when reloading Apache if the PDO Oracle driver is "ON". Just disabled it. Previous Comments: [2012-08-24 06:44:48] debian at linux dot org My Configuration : - Debian GNU/Linux 6 64-bit - Oracle Instantclient 11.2 - PHP 5.3.14 - mod_auth_kerb 5.4 - Apache 2.2.16 - Kerberos Heimdal This can be reproduced using Apache graceful command. Just after the mod_auth_kerb will fail to read the kerberos conf gss_import_name() failed: Miscellaneous failure (, Can't open/find Kerberos configuration file. it will use the same default kerberos configuration as Oracle Database !!! You can force the path using sqlnet.ora but it will fail after when using gss acquire credential (unknown error 2 or 21). We did not find a fix. [2012-01-09 14:01:56] rattlebrain at gmx dot net I have a similar problem. mod_auth_kerb works fine as long as I don't use the PHP OCI8 extension. As soon as I load the OCI8 extension, mod_auth_kerb starts to behave weird. After an Apache (re)start everything is fine, but when I reload Apache I'm getting in a browser "Internal Server Error" and in the error log (just like the topic starter): [Mon Jan 09 14:33:00 2012] [error] [client 10.206.33.199] gss_import_name() failed: Miscellaneous failure (, Can't open/find Kerberos configuration file) After stracing the Apache processes it appeared that /krb5/krb.conf is trying to be opened, but obviously fails on a Linux system. I could prove that Oracle OCI is doing this by setting the SQLNET.KERBEROS5_CONF parameter to a different value in sqlnet.ora. So in some way OCI mixes up the Kerberos stuff that mod_auth_kerb is using, but only when Apache is reloaded. Without everything works perfect, including the PHP OCI8 stuff. I'm using: - Debian GNU/Linux 6 64-bit - Oracle Instantclient Basic 11.2.0.2.0 - PHP 5.3.3 (Debian package rebuild to include OCI8) - mod_auth_kerb 5.4 - Apache 2.2.16 To create the OCI8 stuff I added the following parameters to the standard Debian PHP build parameters: --with-oci8=shared,/usr --with-pdo-oci=shared,/usr This is the complete configure command: CFLAGS="-g -O2 -O2 -Wall -fsigned-char -fno-strict-aliasing -gstabs" PROG_SENDMAIL="/usr/sbin/sendmail" ../configure \ --prefix=/usr --with-apxs2=/usr/bin/apxs2 \ --with-config-file-path=/etc/php5/apache2 \ --with-config-file-scan-dir=/etc/php5/apache2/conf.d \ --build=x86_64-linux-gnu --host=x86_64-linux-gnu --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --disable-debug --with-regex=php --disable-rp ath --disable-static --with-pic --with-layout=GNU --with-pear=/usr/share/php --enable-calendar --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-bcmath --with-bz2 --enable-ctype --with-db4 --with-qdbm=/usr --without-gdbm --with-iconv --enable-exif --enable-ftp --with-gettext --enable-mbstring --with-onig=/usr --with-pcre-regex=/usr -- enable-shmop --enable-sockets --enable-wddx --with-libxml-dir=/usr --with-zlib --with-kerberos=/usr --with-openssl=/usr --enable-soap --enable-zip --with-mhash=yes --with-ex ec-dir=/usr/lib/php5/libexec --with-system-tzdata \ --without-mm \ --with-curl=shared,/usr \ --with-enchant=shared,/usr \ --with-zlib-dir=/usr \ --with-gd=shared,/usr --enable-gd-native-ttf \ --with-gmp=shared,/usr \ --with-jpeg-dir=shared,/usr \ --with-xpm-dir=shared,/usr/X11R6 \ --with-png-dir=shared,/usr \ --with-freetype-dir=shared,/usr \ --with-imap=shared,/usr \ --with-imap-ssl \ --with-interbase=shared,/usr --with-pdo-firebird=shared,/usr \ --enable-intl=shared \ --with-ttf=shared,/usr \ --with-t1lib=shared,/usr \ --with-ldap=shared,/usr \ --with-ldap-sasl=/usr \ --with-mcrypt=shared,/usr \ --with-mysql=shared,/usr \ --with-mysqli=shared,/usr/bin/mysql_config \ --with-pspell=shared,/usr \ --
#32751 [NEW]: Segfault after code execution (destructor calls)
From: prism at pld-linux dot org Operating system: PLD Linux Distribution PHP version: 5.0.4 PHP Bug Type: Zend Engine 2 problem Bug description: Segfault after code execution (destructor calls) Description: Zend engine or all modules which use persistent_list. persistent_list is destroyed after modules are unloaded. But some modules register own destructors for elements put on persistent_list. When Zend destroys such entry from persistent_list, it tries to call destructor from unloaded module and segfaults. Reproduce code: --- Look here: http://comments.gmane.org/gmane.linux.pld.devel.english/785 and start reading from post written at 16 Apr 17:33 by Michal Lukaszek, and below from that. Expected result: No segfault. Actual result: -- > (gdb) bt > #0 0xb78a6978 in ?? () > #1 0xb7f557da in plist_entry_destructor (ptr=0x81e11b8) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204 > #2 0xb7f5385f in zend_hash_apply_deleter (ht=0x8052c50, p=0x81ec1a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:574 > #3 0xb7f53ab0 in zend_hash_graceful_reverse_destroy (ht=0x8052c50) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:640 > #4 0xb7f558f6 in zend_destroy_rsrc_list (ht=0x8052c50, tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:234 > #5 0xb7f49c20 in zend_shutdown (tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend.c:714 > #6 0xb7ef42d5 in php_module_shutdown (tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/main/main.c:1518 > #7 0x0804be1e in main (argc=2, argv=0xb174) > at /home/comp/rpm/BUILD/php-5.0.4/sapi/cli/php_cli.c:1055 > (gdb) f 1 > #1 0xb7f557da in plist_entry_destructor (ptr=0x81e11b8) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204 > 204 ld->plist_dtor_ex(le TSRMLS_CC); > (gdb) p ld->plist_dtor_ex > $1 = 0xb78a6978 > (gdb) x ld->plist_dtor_ex > 0xb78a6978: Cannot access memory at address 0xb78a6978 it's in (unloaded) php-mysql module > The list here is "persistent_list", which is used by php-mysql for > persistent connection - so it's probably bug in php-mysql module or php > engine itself. -- Edit bug report at http://bugs.php.net/?id=32751&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32751&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32751&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32751&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32751&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32751&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32751&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32751&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32751&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32751&r=support Expected behavior: http://bugs.php.net/fix.php?id=32751&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32751&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32751&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32751&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32751&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32751&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32751&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32751&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32751&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32751&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32751&r=mysqlcfg
#32751 [Fbk->Opn]: Segfault after code execution (destructor calls)
ID: 32751 User updated by: prism at pld-linux dot org Reported By: prism at pld-linux dot org -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: PLD Linux Distribution PHP Version: 5.0.4 New Comment: What else do you need? You have been given exact cause and explanation what to fix. Let me know if we can still give you some more information. Previous Comments: [2005-04-19 08:51:00] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-04-18 21:49:05] prism at pld-linux dot org Description: Zend engine or all modules which use persistent_list. persistent_list is destroyed after modules are unloaded. But some modules register own destructors for elements put on persistent_list. When Zend destroys such entry from persistent_list, it tries to call destructor from unloaded module and segfaults. Reproduce code: --- Look here: http://comments.gmane.org/gmane.linux.pld.devel.english/785 and start reading from post written at 16 Apr 17:33 by Michal Lukaszek, and below from that. Expected result: No segfault. Actual result: -- > (gdb) bt > #0 0xb78a6978 in ?? () > #1 0xb7f557da in plist_entry_destructor (ptr=0x81e11b8) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204 > #2 0xb7f5385f in zend_hash_apply_deleter (ht=0x8052c50, p=0x81ec1a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:574 > #3 0xb7f53ab0 in zend_hash_graceful_reverse_destroy (ht=0x8052c50) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:640 > #4 0xb7f558f6 in zend_destroy_rsrc_list (ht=0x8052c50, tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:234 > #5 0xb7f49c20 in zend_shutdown (tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend.c:714 > #6 0xb7ef42d5 in php_module_shutdown (tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/main/main.c:1518 > #7 0x0804be1e in main (argc=2, argv=0xb174) > at /home/comp/rpm/BUILD/php-5.0.4/sapi/cli/php_cli.c:1055 > (gdb) f 1 > #1 0xb7f557da in plist_entry_destructor (ptr=0x81e11b8) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204 > 204 ld->plist_dtor_ex(le TSRMLS_CC); > (gdb) p ld->plist_dtor_ex > $1 = 0xb78a6978 > (gdb) x ld->plist_dtor_ex > 0xb78a6978: Cannot access memory at address 0xb78a6978 it's in (unloaded) php-mysql module > The list here is "persistent_list", which is used by php-mysql for > persistent connection - so it's probably bug in php-mysql module or php > engine itself. -- Edit this bug report at http://bugs.php.net/?id=32751&edit=1
#32751 [Fbk->Opn]: Segfault after code execution (destructor calls)
ID: 32751 User updated by: prism at pld-linux dot org Reported By: prism at pld-linux dot org -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: PLD Linux Distribution PHP Version: 5.0.4 New Comment: I did't try in other OS. Later, I'll see in Windows - but I have to set up the environment first. Yes. I used glibc 2.3.4 before, and switched to 2.3.5 to see if it helps. It also happened earlier, when I had some older glibc, but I ignored it. The code also fails in CLI. Actually, we test it in CLI because Apache doesn't get any output from PHP module since it dies - proxy says that zero-sized reply comes. And finally: Yes, we build as much we can as modules to package it into separate packages. Previous Comments: [2005-04-19 22:23:38] [EMAIL PROTECTED] Are you able to reproduce it under a different OS? Or at least with different glibc? Is it reproducible only with Apache2 or with CLI too? As far as I can see, mysql is built as shared module or am I wrong? [2005-04-19 21:20:11] prism at pld-linux dot org What else do you need? You have been given exact cause and explanation what to fix. Let me know if we can still give you some more information. [2005-04-19 08:51:00] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-04-18 21:49:05] prism at pld-linux dot org Description: Zend engine or all modules which use persistent_list. persistent_list is destroyed after modules are unloaded. But some modules register own destructors for elements put on persistent_list. When Zend destroys such entry from persistent_list, it tries to call destructor from unloaded module and segfaults. Reproduce code: --- Look here: http://comments.gmane.org/gmane.linux.pld.devel.english/785 and start reading from post written at 16 Apr 17:33 by Michal Lukaszek, and below from that. Expected result: No segfault. Actual result: -- > (gdb) bt > #0 0xb78a6978 in ?? () > #1 0xb7f557da in plist_entry_destructor (ptr=0x81e11b8) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204 > #2 0xb7f5385f in zend_hash_apply_deleter (ht=0x8052c50, p=0x81ec1a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:574 > #3 0xb7f53ab0 in zend_hash_graceful_reverse_destroy (ht=0x8052c50) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_hash.c:640 > #4 0xb7f558f6 in zend_destroy_rsrc_list (ht=0x8052c50, tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:234 > #5 0xb7f49c20 in zend_shutdown (tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend.c:714 > #6 0xb7ef42d5 in php_module_shutdown (tsrm_ls=0x804f0a0) > at /home/comp/rpm/BUILD/php-5.0.4/main/main.c:1518 > #7 0x0804be1e in main (argc=2, argv=0xb174) > at /home/comp/rpm/BUILD/php-5.0.4/sapi/cli/php_cli.c:1055 > (gdb) f 1 > #1 0xb7f557da in plist_entry_destructor (ptr=0x81e11b8) > at /home/comp/rpm/BUILD/php-5.0.4/Zend/zend_list.c:204 > 204 ld->plist_dtor_ex(le TSRMLS_CC); > (gdb) p ld->plist_dtor_ex > $1 = 0xb78a6978 > (gdb) x ld->plist_dtor_ex > 0xb78a6978: Cannot access memory at address 0xb78a6978 it's in (unloaded) php-mysql module > The list here is "persistent_list", which is used by php-mysql for > persistent connection - so it's probably bug in php-mysql module or php > engine itself. -- Edit this bug report at http://bugs.php.net/?id=32751&edit=1
#32751 [Fbk->Opn]: Segfault after code execution (destructor calls)
ID: 32751 User updated by: prism at pld-linux dot org Reported By: prism at pld-linux dot org -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: PLD Linux Distribution PHP Version: 5.0.4 New Comment: I can't really test it at the moment. My colleague also encountered the same problem after upgrade to glibc 2.3.5 and PHP 5.0.4 - when he downgraded to PHP 5.0.3 everything was working fine. I searched the php bugs database for "plist_entry_destructor" and I found that one user had similar problem in PHP 4.3.x some time ago, and it makes me think that this is not only mysql-module related. I suggest you to try the new glibc and see if PHP works without any problems. If there is anything else I can do, just ask. Tomorrow, we will be trying to find the bug in the PHP code, so I might have some more information in a day or two. Previous Comments: [2005-04-23 19:17:25] [EMAIL PROTECTED] If you load only and ONLY the mysql extension in your php.ini, can you reproduce this? [2005-04-23 01:00:49] prism at pld-linux dot org Our Configure Command: './configure' 'LDFLAGS=' 'CFLAGS=-O2 -march=i686 -DEAPI=1 -I/usr/X11R6/include -I/usr/include/apr -I/usr/include/apr-util -I/usr/include' 'CXXFLAGS=-O2 -march=i686' 'FFLAGS=-O2 -march=i686' 'CPPFLAGS=' 'CC=i686-pld-linux-gcc' 'CXX=i686-pld-linux-g++' '--build=i686-pld-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc/php' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--x-libraries=/usr/X11R6/lib' '--with-apxs2=/usr/sbin/apxs' '--enable-maintainer-zts' '--with-config-file-path=/etc/php' '--with-exec-dir=/usr/bin' '--disable-debug' '--enable-memory-limit' '--enable-bcmath=shared' '--enable-calendar=shared' '--enable-ctype=shared' '--enable-dba=shared' '--enable-dbx=shared' '--enable-dio=shared' '--enable-dom=shared' '--enable-exif=shared' '--enable-filepro=shared' '--enable-ftp=shared' '--enable-gd-native-ttf' '--enable-gd-jus-conf' '--enable-magic-quotes' '--enable-mbstring=shared,all' '--enable-mbregex' '--enable-pcntl=shared' '--enable-posix=shared' '--enable-session' '--enable-shared' '--enable-shmop=shared' '--enable-sysvmsg=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-track-vars' '--enable-trans-sid' '--enable-safe-mode' '--enable-sockets=shared' '--enable-ucd-snmp-hack' '--enable-wddx=shared' '--enable-xml=shared' '--enable-yp=shared' '--enable-soap=shared' '--with-bz2=shared' '--with-cpdflib=shared' '--with-curl=shared' '--with-db4' '--with-dbase=shared' '--with-expat-dir=shared,/usr' '--with-iconv=shared' '--with-fam=shared' '--with-filepro=shared' '--with-freetype-dir=shared' '--with-gettext=shared' '--with-gd=shared,/usr' '--with-gdbm' '--with-gmp=shared' '--with-imap=shared' '--with-imap-ssl' '--with-interbase=shared,/usr' '--with-jpeg-dir=/usr' '--with-ldap=shared' '--with-mcrypt=shared' '--with-mhash=shared' '--with-mime-magic=shared,/usr/share/file/magic.mime' '--with-ming=shared' '--with-mnogosearch=shared,/usr' '--with-msession=shared' '--with-mssql=shared' '--with-mysql=shared,/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mysqli=shared' '--with-ncurses=shared' '--with-openssl=shared' '--with-pcre-regex=shared' '--with-pear=/usr/share/pear' '--with-pgsql=shared,/usr' '--with-png-dir=/usr' '--with-pspell=shared' '--with-readline=shared' '--with-recode=shared' '--with-regex=php' '--without-sablot-js' '--with-snmp=shared' '--with-sybase=shared,/usr' '--with-sybase-ct=shared,/usr&#x
#31019 [NEW]: Logic error in ext/mssql/config.m4
From: adamg at pld-linux dot org Operating system: Irrelevant PHP version: 4.3.10RC1 PHP Bug Type: Compile Failure Bug description: Logic error in ext/mssql/config.m4 Description: As of 4.3.10RC1 following line was introduced in ext/mssql/config.m4 if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" || test ! -r "$F REETDS_INSTALLATION_DIR/lib/libtds.so"; then Which, translated into human, means: "IF either libtds.a OR libtds.so is not readable by, fail" Which is a nonsense, since it requires presence of both of the files - otherwise configure script will refuse to compile. Obviously the || should be changed to &&. -- Edit bug report at http://bugs.php.net/?id=31019&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31019&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31019&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31019&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31019&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31019&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31019&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31019&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31019&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31019&r=support Expected behavior: http://bugs.php.net/fix.php?id=31019&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31019&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31019&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31019&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31019&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31019&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31019&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31019&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31019&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=31019&r=mysqlcfg
#31019 [Opn]: Logic error in ext/mssql/config.m4
ID: 31019 User updated by: adamg at pld-linux dot org Reported By: adamg at pld-linux dot org Status: Open Bug Type: Compile Failure Operating System: Irrelevant PHP Version: 4.3.10RC1 New Comment: As of 4.3.10RC1 following line was introduced in ext/mssql/config.m4 if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" || test ! -r "$F REETDS_INSTALLATION_DIR/lib/libtds.so"; then Which, translated into human, means: "IF either libtds.a OR libtds.so is not readable by, fail" Which is a nonsense, since it requires presence of both of the files - otherwise configure script will refuse to compile. Obviously the || should be changed to &&. Following trivial patchfixes that issue. --- php-4.3.10RC1/ext/mssql/config.m4~ 2004-12-08 11:52:30.205750088 +0100 +++ php-4.3.10RC1/ext/mssql/config.m4 2004-12-08 11:52:51.807466128 +0100 @@ -32,7 +32,7 @@ fi fi - if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" || test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.so"; then + if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" && test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.so"; then AC_MSG_ERROR(Could not find $FREETDS_INSTALLATION_DIR/lib/libtds.[a|so]) fi Previous Comments: ---- [2004-12-08 12:35:58] adamg at pld-linux dot org Description: As of 4.3.10RC1 following line was introduced in ext/mssql/config.m4 if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" || test ! -r "$F REETDS_INSTALLATION_DIR/lib/libtds.so"; then Which, translated into human, means: "IF either libtds.a OR libtds.so is not readable by, fail" Which is a nonsense, since it requires presence of both of the files - otherwise configure script will refuse to compile. Obviously the || should be changed to &&. -- Edit this bug report at http://bugs.php.net/?id=31019&edit=1
#31020 [NEW]: Logic error in ext/mssql/config.m4
From: adamg at pld-linux dot org Operating system: Irrelevant PHP version: 5CVS-2004-12-08 (dev) PHP Bug Type: Compile Failure Bug description: Logic error in ext/mssql/config.m4 Description: As of 5.0.3RC1 following line was introduced in ext/mssql/config.m4 if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" || test ! -r "$F REETDS_INSTALLATION_DIR/lib/libtds.so"; then Which, translated into human, means: "IF either libtds.a OR libtds.so is not readable by, fail" Which is a nonsense, since it requires presence of both of the files - otherwise configure script will refuse to compile. Obviously the || should be changed to &&. --- php-5.0.3RC1/ext/mssql/config.m4~ 2004-11-22 20:45:17.0 +0100 +++ php-5.0.3RC1/ext/mssql/config.m42004-12-08 11:53:48.786803952 +0100 @@ -32,7 +32,7 @@ fi fi - if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" || test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.so"; then + if test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.a" && test ! -r "$FREETDS_INSTALLATION_DIR/lib/libtds.so"; then AC_MSG_ERROR(Could not find $FREETDS_INSTALLATION_DIR/lib/libtds.[a|so]) fi -- Edit bug report at http://bugs.php.net/?id=31020&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31020&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31020&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31020&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31020&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31020&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31020&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31020&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31020&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31020&r=support Expected behavior: http://bugs.php.net/fix.php?id=31020&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31020&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31020&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31020&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31020&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31020&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31020&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31020&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31020&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=31020&r=mysqlcfg
#31358 [NEW]: Compile time error, incompatible types in assignment
From: hawk at pld-linux dot org Operating system: PLD Linux running on PowerPC PHP version: 4.3.10 PHP Bug Type: Compile Failure Bug description: Compile time error, incompatible types in assignment Description: The compilation of PHP 4.3.10 fails on Linux running on PowerPC with following error: /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c -o Zend/zend.lo /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c: In function `zend_error': /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c:776: incompatible types in assignment make: *** [Zend/zend.lo] Error 1 Following code change is reponsible for this bug: cvs diff -u -r 1.162.2.21 -r 1.162.2.22 Zend/zend.c Line 776 is: usr_copy = args; where both usr_copy and args are of type va_list. Such code will not compile on Linux on PowerPC (and probably on some other architectures too) because va_list is struct here. I know only two ways for fixing it. One is to use va_copy, but I'm not sure if its safe to change following portion of code: #if defined(va_copy) va_copy(usr_copy, args); #else usr_copy = args; #endif just into: va_copy(usr_copy, args); Probably its not safe. The second way is to use usr_copy[0] = args[0]; for the affected architectures, but its not safe either AFAIR. I also suppose that php 5.0.3 is affected too, because it contains same code -- Edit bug report at http://bugs.php.net/?id=31358&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31358&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31358&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31358&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31358&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31358&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31358&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31358&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31358&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31358&r=support Expected behavior: http://bugs.php.net/fix.php?id=31358&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31358&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31358&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31358&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31358&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31358&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31358&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31358&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31358&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31358&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31358&r=mysqlcfg
#31358 [Opn]: Compile time error, incompatible types in assignment in zend.c on PPC
ID: 31358 User updated by: hawk at pld-linux dot org -Summary: Compile time error, incompatible types in assignment Reported By: hawk at pld-linux dot org Status: Open Bug Type: Compile Failure -Operating System: PLD Linux running on PowerPC +Operating System: PLD Linux 1.0 running on PowerPC PHP Version: 4.3.10 New Comment: The bug affects only PPC systems with older GCC which don't support va_copy (sorry, didn't noticed this earlier), the workaround is to change line 776 of zend.c: usr_copy = args; into memcpy(usr_copy, args, sizeof(va_list)); for these architectures. It seems to work perfectly Previous Comments: [2004-12-30 22:03:06] hawk at pld-linux dot org Description: The compilation of PHP 4.3.10 fails on Linux running on PowerPC with following error: /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c -o Zend/zend.lo /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c: In function `zend_error': /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c:776: incompatible types in assignment make: *** [Zend/zend.lo] Error 1 Following code change is reponsible for this bug: cvs diff -u -r 1.162.2.21 -r 1.162.2.22 Zend/zend.c Line 776 is: usr_copy = args; where both usr_copy and args are of type va_list. Such code will not compile on Linux on PowerPC (and probably on some other architectures too) because va_list is struct here. I know only two ways for fixing it. One is to use va_copy, but I'm not sure if its safe to change following portion of code: #if defined(va_copy) va_copy(usr_copy, args); #else usr_copy = args; #endif just into: va_copy(usr_copy, args); Probably its not safe. The second way is to use usr_copy[0] = args[0]; for the affected architectures, but its not safe either AFAIR. I also suppose that php 5.0.3 is affected too, because it contains same code -- Edit this bug report at http://bugs.php.net/?id=31358&edit=1
#31358 [Fbk->Opn]: Compile time error, incompatible types in assignment in zend.c on PPC
ID: 31358 User updated by: hawk at pld-linux dot org Reported By: hawk at pld-linux dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: PLD Linux 1.0 running on PowerPC PHP Version: 4.3.10 Assigned To: stas New Comment: According to 'gcc -v': Reading specs from /usr/lib/gcc-lib/ppc-pld-linux/2.95.4/specs gcc version 2.95.4 20010319 (prerelease) And yes, there is stdarg.h in /usr/lib/gcc-lib/ppc-pld-linux/2.95.4/include/stdarg.h Previous Comments: [2005-01-02 08:58:47] [EMAIL PROTECTED] Which GCC do you have? It is rather strange va_copy is not defined on Linux. Do you have stdarg.h anywhere? [2004-12-31 19:46:59] hawk at pld-linux dot org The bug affects only PPC systems with older GCC which don't support va_copy (sorry, didn't noticed this earlier), the workaround is to change line 776 of zend.c: usr_copy = args; into memcpy(usr_copy, args, sizeof(va_list)); for these architectures. It seems to work perfectly [2004-12-30 22:03:06] hawk at pld-linux dot org Description: The compilation of PHP 4.3.10 fails on Linux running on PowerPC with following error: /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c -o Zend/zend.lo /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c: In function `zend_error': /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c:776: incompatible types in assignment make: *** [Zend/zend.lo] Error 1 Following code change is reponsible for this bug: cvs diff -u -r 1.162.2.21 -r 1.162.2.22 Zend/zend.c Line 776 is: usr_copy = args; where both usr_copy and args are of type va_list. Such code will not compile on Linux on PowerPC (and probably on some other architectures too) because va_list is struct here. I know only two ways for fixing it. One is to use va_copy, but I'm not sure if its safe to change following portion of code: #if defined(va_copy) va_copy(usr_copy, args); #else usr_copy = args; #endif just into: va_copy(usr_copy, args); Probably its not safe. The second way is to use usr_copy[0] = args[0]; for the affected architectures, but its not safe either AFAIR. I also suppose that php 5.0.3 is affected too, because it contains same code -- Edit this bug report at http://bugs.php.net/?id=31358&edit=1
#27530 [NEW]: safe_mode breaks authorization via header() in 4.3.5RC2, too
From: arekm at pld-linux dot org Operating system: Linux 2.4/2.6 + glibc 2.3.2 PHP version: 4.3.4 PHP Bug Type: Output Control Bug description: safe_mode breaks authorization via header() in 4.3.5RC2, too Description: The problem is that when safe_mode = On and we have simple script: and I get 3 Server: Apache/2.0.48 (Unix) mod_fastcgi/2.4.2 mod_ssl/2.0.48 OpenSSL/0.9.7c DAV/2 4 X-Powered-By: PHP/4.3.5RC2 5 WWW-Authenticate: 1000 which is unknown authentication method for any browser. According to documentation (http://pl2.php.net/manual/en/features.safe-mode.functions.php) UID should be appended to user specified string. Tested in on different setups like apache 1.3.29+php 4.3.3, php 4.3.4, apache 2.0.48+php 4.3.5RC2 in fastcgi mode, without fastcgi mode. Always reproducible. Turning safe_mode = Off fixes problem of course. Reproduce code: --- See description. Expected result: 3 Server: Apache/2.0.48 (Unix) mod_fastcgi/2.4.2 mod_ssl/2.0.48 OpenSSL/0.9.7c DAV/2 4 X-Powered-By: PHP/4.3.5RC2 5 WWW-Authenticate: Basic realm=\"log in\" + somehwere UID since that's safe mode. Actual result: -- 3 Server: Apache/2.0.48 (Unix) mod_fastcgi/2.4.2 mod_ssl/2.0.48 OpenSSL/0.9.7c DAV/2 4 X-Powered-By: PHP/4.3.5RC2 5 WWW-Authenticate: 1000 -- Edit bug report at http://bugs.php.net/?id=27530&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27530&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27530&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27530&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27530&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27530&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27530&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27530&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27530&r=support Expected behavior: http://bugs.php.net/fix.php?id=27530&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27530&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27530&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27530&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27530&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27530&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27530&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27530&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27530&r=float
#27543 [NEW]: php as cgi with extenstion=overload.so in php.ini crashes
From: arekm at pld-linux dot org Operating system: Linux 2.4/2.6 glibc 2.3.3 PHP version: 4.3.5RC3 PHP Bug Type: Reproducible crash Bug description: php as cgi with extenstion=overload.so in php.ini crashes Description: [EMAIL PROTECTED] ~]$ php Content-type: text/html X-Powered-By: PHP/4.3.5RC3 (press ctrl+d) zsh: segmentation fault php php in cgi mode segfaults when extension=overload.so in php.ini. removing this extensions causes that segfault no longer happens. Almost every of my extensions is as loadable module but at this time I'm loading overload.so only. Content-type: text/html X-Powered-By: PHP/4.3.5RC3 [1]PHP Logo PHP Version 4.3.5RC3 System Linux arm.t19.ds.pwr.wroc.pl 2.6.4 #1 Fri Mar 5 16:14:32 CET 2004 i686 Build Date Mar 9 2004 01:39:56 Configure Command './configure' 'LDFLAGS=-s' 'CFLAGS=-O2 -march=athlon -DEAPI=1 -I/usr/X11R6/include' 'CXXFLAGS=-O2-march=athlon' 'FFLAGS=-O2 -march=athlon' 'CPPFLAGS=' 'CC=athlon-pld-linux-gcc' 'CXX=athlon-pld-linux-g++' '--build=athlon-pld-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc/php' '--datadir=/usr/share' '--includedir=/usr/include''--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--x-libraries=/usr/X11R6/lib' '--with-apxs2=/usr/sbin/apxs' '--with-config-file-path=/etc/php' '--with-exec-dir=/usr/bin' '--disable-debug' '--enable-memory-limit' '--enable-bcmath=shared''--enable-calendar=shared' '--enable-ctype=shared' '--enable-dba=shared' '--enable-dbx=shared' '--enable-dio=shared' '--enable-exif=shared' '--enable-ftp=shared' '--enable-filepro=shared' '--enable-gd-native-ttf' '--enable-magic-quotes' '--enable-mbstring=shared,all' '--enable-mbregex' '--enable-overload=shared' '--enable-pcntl=shared' '--enable-posix=shared' '--enable-session' '--enable-shared' '--enable-shmop=shared' '--enable-sysvmsg=shared' '--enable-sysvsem=shared''--enable-sysvshm=shared' '--enable-track-vars' '--enable-trans-sid''--enable-safe-mode' '--enable-sockets=shared' '--enable-ucd-snmp-hack' '--enable-wddx=shared' '--enable-xml=shared' '--enable-xslt=shared' '--enable-yp=shared''--with-bz2=shared''--with-cpdflib=shared' '--with-crack=shared' '--with-curl=shared' '--with-db=shared' '--with-db4' '--with-dbase=shared' '--with-dom=shared' '--with-dom-xslt=shared' '--with-dom-exslt=shared' '--with-expat-dir=shared,/usr' '--with-fribidi=shared' '--with-iconv=shared' '--with-filepro=shared' '--with-freetype-dir=shared' '--with-gettext=shared' '--with-gd=shared,/usr''--with-gdbm' '--with-gmp=shared' '--with-hyperwave=shared''--with-imap=shared''--with-imap-ssl' '--with-interbase=shared,/usr' '--with-jpeg-dir=shared,/usr' '--with-ldap=shared' '--with-mcal=shared,/usr' '--with-mcrypt=shared' '--with-mhash=shared' '--with-mime-magic=shared,/usr/share/file/magic.mime' '--with-ming=shared' '--with-mnogosearch=shared,/usr' '--with-msession=shared' '--with-mssql=shared' '--with-mysql=shared,/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-ncurses=shared' '--with-openssl' '--with-pcre-regex=shared' '--with-pdflib=shared' '--with-pear=/usr/share/pear' '--with-pgsql=shared,/usr' '--with-png-dir=shared,/u
#27543 [Bgs]: php as cgi with extenstion=overload.so in php.ini crashes
ID: 27543 User updated by: arekm at pld-linux dot org Reported By: arekm at pld-linux dot org Status: Bogus Bug Type: Reproducible crash Operating System: Linux 2.4/2.6 glibc 2.3.3 PHP Version: 4.3.5RC3 New Comment: Sorry for too much data. Unfortunately I wasn't able to reproduce this with simple compilation of vanilla php. Yes, the sources have few patches (mailny am/ac things like enabling build of some modules as shared ones). The problem is probably related to fact that we have different php binaries/modules like cgi, fastcgi, cli, apache2 sapi module using exactly the same ext modules (built as .so objects) to avoid having too many duplicates. Setting CFLAGS, LDFLAGS isn't any outsmarting configure. configure itself can't find out what compiler optimizations I want. That's why CFLAGS/LDFLAGS exists. Also using not existing options to configure doesn't make any difference. They are ignored after all. What's wrong with shared PCRE? Previous Comments: [2004-03-09 18:56:26] [EMAIL PROTECTED] Thank you for all the irrelevant information..(you obviously ignored the instructions about how to report) Necessary information would only have been: 1. your configure line 2. gdb backtrace 3. Steps how to reproduce Furthermore: Your configure line seems a bit weird since you certainly CAN NOT get a CGI binary with it. You didn't use clean sources when you configured the binary. Get the latest stable snapshot and drop ALL those LDFLAGS / CFLAGS etc., don't try outsmarting the configure.. Also, you should look into the './configure --help' output sometime, some of those options you used don't even exist. And making PCRE extension shared is not very good idea either.. Bogus. (open a better report with the above mentioned information if you still can reproduce the crash with clean sources from latest STABLE snapshot using proper configure line..) ---- [2004-03-09 18:35:47] arekm at pld-linux dot org Description: [EMAIL PROTECTED] ~]$ php Content-type: text/html X-Powered-By: PHP/4.3.5RC3 (press ctrl+d) zsh: segmentation fault php php in cgi mode segfaults when extension=overload.so in php.ini. removing this extensions causes that segfault no longer happens. Almost every of my extensions is as loadable module but at this time I'm loading overload.so only. Content-type: text/html X-Powered-By: PHP/4.3.5RC3 [1]PHP Logo PHP Version 4.3.5RC3 System Linux arm.t19.ds.pwr.wroc.pl 2.6.4 #1 Fri Mar 5 16:14:32 CET 2004 i686 Build Date Mar 9 2004 01:39:56 Configure Command './configure' 'LDFLAGS=-s' 'CFLAGS=-O2 -march=athlon -DEAPI=1 -I/usr/X11R6/include' 'CXXFLAGS=-O2 -march=athlon' 'FFLAGS=-O2 -march=athlon' 'CPPFLAGS=' 'CC=athlon-pld-linux-gcc' 'CXX=athlon-pld-linux-g++' '--build=athlon-pld-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc/php' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--x-libraries=/usr/X11R6/lib' '--with-apxs2=/usr/sbin/apxs' '--with-config-file-path=/etc/php' '--with-exec-dir=/usr/bin' '--disable-debug' '--enable-memory-limit' '--enable-bcmath=shared' '--enable-calendar=shared' '--enable-ctype=shared' '--enable-dba=shared' '--enable-dbx=shared' '--enable-dio=shared' '--enable-exif=shared' '--enable-ftp=shared' '--enable-filepro=shared' '--enable-gd-native-ttf' '--enable-magic-quotes' '--enable-mbstring=shared,all' '--enable-mbregex' '--enable-overload=shared' '--enable-pcntl=shared' '--enable-posix=shared' '--enable-session' '--enable-shared' '--enable-shmop=shared' '--enable-sysvmsg=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-track-vars' '--enable-trans-sid
#27899 [Com]: Apache got segfault after received SIGHUP
ID: 27899 Comment by: remco at linux-adept dot nl Reported By: charvel at bluemission dot com Status: No Feedback Bug Type: Apache2 related Operating System: Linux 2.4.25 PHP Version: 4.3.6RC2 New Comment: 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. Previous Comments: [2004-04-16 08:49:45] afraser at w3internet dot com Thought I would check the previous version of Apache, since I only got this problem after upgrading Apache (2.0.48 to 2.0.49) and PHP (4.3.3 to 4.3.5) [EMAIL PROTECTED] home] www/bin/httpd -v Server version: Apache/2.0.48 Server built: Dec 14 2003 15:23:08 [EMAIL PROTECTED] home]# www/bin/apachectl configtest [Fri Apr 16 09:46:54 2004] [crit] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP. Pre-configuration failed Probably this is not a bug... but if this makes sense to one of you gurus could you explain to us what we did wrong? [2004-04-13 12:44:17] [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. [2004-04-09 11:13:18] [EMAIL PROTECTED] 1. As you're using a threaded webserver and asking for trouble this bug is pretty much bogus. (the crash happens elsewhere than in PHP itself..where is the GDB backtrace?) 2. Try adding your original configure options (those ones excluded which I told you NOT to use) one by one and see which one causes the crash, like this: # rm -f config.cache # ./configure --disable-all --with-apxs2 --with-zlib # make clean && make (try them all _separately_ first!) [2004-04-09 05:24:09] charvel at bluemission dot com 1. worker 2. In this case work fine. [2004-04-08 19:01:21] [EMAIL PROTECTED] 1. What MPM is Apache2 using? 2. Get fresh sources, and use this configure line: # ./configure --disable-all --with-apxs2 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/27899 -- Edit this bug report at http://bugs.php.net/?id=27899&edit=1
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810
Comment by: remco at linux-adept dot nl
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:
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.
Previous Comments:
[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
[2004-04-16 03:35:45] towerofpower at operamail dot com
You might want to take a look at...
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20462
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17055
This seems very similar.
Apache 2.0.49, mod_ssl (OpenSSL 0.9.7d), PHP 4.3.6, mod_perl 1.99_13,
mod_delfate (zlib 1.1.4), perl 5.8.3
Built with VS.NET 2002 under Win2k, SP4 (except PHP 4.3.6 -- official
binary)
After 'net stop Apache2'...
Apache.exe - Application Error
The instruction at "0x77f92373" referenced memory at "0x0010". The
memory could not be "written".
We do have a workaround for this problem:
set "LogLevel" under httpd.conf from "warn" to "error"
(this only works for a select set of versions of Apache and PHP)
If Apache2 is not started with "-D SSL" and PHP 4.3.6 is used (over
4.3.5), the app error does not happen.
[2004-04-15 17:45:01] danu at drydog dot com
Here's the diffs between the old (working) version of PCRE and the new
(broken) version of PCRE. Note changes in memory allocation code, which
I believe is causing the problem:
Note: 4.3.4 works (1.29.2.3, 1.132.2.10)
Note: 4.3.5 is broken (1.29.2.5, 1.132.2.16)
diff pcre.4.3.4/config.m4 pcre.4.3.5/config.m4
2c2
< dnl $Id: config.m4,v 1.29.2.3 2003/06/29 00:08:29 andrei Exp $
---
> dnl $Id: config.m4,v 1.29.2.5 2003/12/16 22:14:55 andrei Exp $
Only in pcre.4.3.4: pcrelib
diff pcre.4.3.4/php_pcre.c pcre.4.3.5/php_pcre.c
19c19
< /* $Id: php_pcre.c,v 1.132.2.10 2003/09/12 01:32:38 sniper Exp $ */
---
> /* $Id: php_pcre.c,v 1.132.2.16 2004/02/01 19:56:16 moriyoshi Exp $
*/
108a109,117
>
> 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
>
124,133d132
< /* {{{ PHP_RINIT_FUNCTION(pcre) */
< static PHP_RINIT_FUNCTION(pcre)
< {
< pcre_malloc = php_pcre_malloc;
< pcre_free = php_pcre_free;
<
< return SUCCESS;
< }
< /* }}} */
<
177c176
< while (isspace((int)*p)) p++;
---
> while (isspace((int)*(unsigned char *)p)) p++;
186c185
< if (isalnum((int)delimiter) || delimiter == '\\') {
---
> if (isalnum((int)*(unsigned char *)&delimiter) || delimiter == '\\')
{
351c350
< int flags; /* Match
control flags */
---
> long flags; /* Match
> control flags */
365c364
< int start_offset = 0; /* Where the new
search starts */
---
> long start_offset = 0; /* Where the new
> search starts */
432c431
< int name_cnt, name_size, ni = 0;
---
> int name_cnt = 0, name_size, ni = 0;
1394a1394,1398
> case '\0':
> *q++ = '\\';
> *q++ = '0';
> break;
>
1526c1530
< PHP_RINIT(pcre),
---
> NULL
[2004-04-15 16:10:22] danu at drydog dot com
NOT fixed with php-4.3.6
I just tried this and it isn't
#27735 [Com]: restart of apache2 via kill -1 or apachectl causes crash
ID: 27735 Comment by: remco at linux-adept dot nl Reported By: as at netoholic dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.5 / 4.3.6 New Comment: 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. Previous Comments: [2004-04-16 08:32:27] [EMAIL PROTECTED] One of those bugs is good enough. Leave this one BOGUS. [2004-04-16 05:58:07] as at netoholic dot de Still present in 4.3.6... Hello Devs, anybody there ??? Read also http://bugs.php.net/bug.php?id=27810 [2004-03-31 15:30:49] noackjr at alumni dot rice dot edu This wasn't "Bogus", as expected. It's fixed in CVS according to Bug 27810: http://bugs.php.net/bug.php?id=27810 [2004-03-31 05:53:04] js at iksz dot hu Nor FreeBSD, nor Linux libc checks whether regfree() got a null pointer. These bugs should be filtered in libc level. [2004-03-31 00:00:21] josestefan at hotmail dot com sorry, my report is wrong. I forgot that the error occurs after the first php request, when I did my testing. 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/27735 -- Edit this bug report at http://bugs.php.net/?id=27735&edit=1
[PHP-BUG] Bug #60659 [NEW]: FPM does not clear auth_user on request accept
From: Operating system: Linux PHP version: 5.3.8 Package: FPM related Bug Type: Bug Bug description:FPM does not clear auth_user on request accept Description: Multiple requests hitting the same FPM worker process will get logged (by php-fpm) with the last authenticated user seen instead of empty when there is no authenticated user for the current request. Attached patch clears auth_user field (and also clears query_string), those two being the only char arrays not seeing initialization in fpm_request_accepting(). Test script: --- # configure php-fpm to use only one worker and log access restart php-fpm curl -u user $php_fpm_page_via_nginx curl $php_fpm_page_via_nginx curl $php_fpm_page_via_nginx # All logged access lines will show remote user to be "user" -- Edit bug report at https://bugs.php.net/bug.php?id=60659&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60659&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60659&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60659&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60659&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60659&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60659&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60659&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60659&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60659&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60659&r=support Expected behavior: https://bugs.php.net/fix.php?id=60659&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60659&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60659&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60659&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60659&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60659&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60659&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60659&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60659&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60659&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60659&r=mysqlcfg
#39702 [NEW]: php crashes in the allocator
From: zippel at linux-m68k dot org Operating system: linux-m68k PHP version: 5.2.0 PHP Bug Type: Reproducible crash Bug description: php crashes in the allocator Description: Hi, php currently crashes everytime it does something nontrivial. I debugged the problem a bit and the problem is in the Zend allocator. The configure script produces a ZEND_MM_ALIGNMENT value of 2, but this is not enough for the allocator as it needs two bits for type information. Increasing the alignment fixes the problem. I reported this problem also in the Debian BTS, where I also included a possible patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401129 -- Edit bug report at http://bugs.php.net/?id=39702&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39702&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39702&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39702&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39702&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39702&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39702&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39702&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39702&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39702&r=support Expected behavior:http://bugs.php.net/fix.php?id=39702&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39702&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39702&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39702&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39702&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39702&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39702&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39702&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39702&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39702&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39702&r=mysqlcfg
#37499 [NEW]: CLI segmentation faults during cleanup (only with sybase-ct extension enabled)
From: hawk at pld-linux dot org Operating system: PLD Linux 2.0 PHP version: 5.1.4 PHP Bug Type: Reproducible crash Bug description: CLI segmentation faults during cleanup (only with sybase-ct extension enabled) Description: CLI segfaults exactly the same way as was described in bug #34725 but only when sybase-ct extension is enabled. PLD Linux 2.0, php 5.1.4, default PLD packages, sybase-ct is compiled as shared. Reproduce code: --- /usr/bin/php -r '"Hello world";' Expected result: Displays "Hello World" as it should but also reports segmentation fault. Actual result: -- (gdb) run Starting program: /usr/bin/php -r 'print "Hello World";' Hello World Program received signal SIGSEGV, Segmentation fault. 0x4fccba80 in ?? () (gdb) bt #0 0x4fccba80 in ?? () #1 0x4fb920d1 in tsrm_shutdown () at /home/users/hawk/rpm/BUILD/php-5.1.4/TSRM/TSRM.c:180 #2 0x0804ad94 in main (argc=3, argv=0xb004) at /home/users/hawk/rpm/BUILD/php-5.1.4/sapi/cli/php_cli.c:1255 -- Edit bug report at http://bugs.php.net/?id=37499&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37499&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37499&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37499&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37499&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37499&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37499&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37499&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37499&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37499&r=support Expected behavior:http://bugs.php.net/fix.php?id=37499&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37499&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37499&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37499&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37499&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37499&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37499&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37499&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37499&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37499&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37499&r=mysqlcfg
#37499 [Opn]: CLI segmentation faults during cleanup (only with sybase-ct extension enabled)
ID: 37499 User updated by: hawk at pld-linux dot org Reported By: hawk at pld-linux dot org Status: Open Bug Type: Reproducible crash Operating System: PLD Linux 2.0 PHP Version: 5.1.4 New Comment: Reproduce code of course was /usr/bin/php -r 'print "Hello world";' Previous Comments: [2006-05-18 14:13:02] hawk at pld-linux dot org Description: CLI segfaults exactly the same way as was described in bug #34725 but only when sybase-ct extension is enabled. PLD Linux 2.0, php 5.1.4, default PLD packages, sybase-ct is compiled as shared. Reproduce code: --- /usr/bin/php -r '"Hello world";' Expected result: Displays "Hello World" as it should but also reports segmentation fault. Actual result: -- (gdb) run Starting program: /usr/bin/php -r 'print "Hello World";' Hello World Program received signal SIGSEGV, Segmentation fault. 0x4fccba80 in ?? () (gdb) bt #0 0x4fccba80 in ?? () #1 0x4fb920d1 in tsrm_shutdown () at /home/users/hawk/rpm/BUILD/php-5.1.4/TSRM/TSRM.c:180 #2 0x0804ad94 in main (argc=3, argv=0xb004) at /home/users/hawk/rpm/BUILD/php-5.1.4/sapi/cli/php_cli.c:1255 -- Edit this bug report at http://bugs.php.net/?id=37499&edit=1
#36142 [NEW]: SOAP usage halts session
From: arekm at pld-linux dot org
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: Session related
Bug description: SOAP usage halts session
Description:
Very long running SOAP query in one tab in web browser halts the same
session on the server so nothing can be done in the same app (using the
same session) in second tab of the browser.
Reproduce code:
---
"http://www.nask.pl:1000"; /* unreachable host */,
'uri' => "blah",
'encoding'=>'ISO-8859-2',
'trace' => true,
'exceptions' => false));
$response = $client->__soapCall("blah", array());
if (is_soap_fault($response))
echo "SOAP fault";
break;
case "disp":
echo "DISPLAY ME " . $_SESSION["cnt"] . "";
break;
}
?>
soap
disp
Expected result:
DISPLAY ME X where X increases without waiting for SOAP query to finish.
Actual result:
--
Browser waits for server reply and gets it only after soap query
finishes.
How to reproduce?
1) open http://somwhere/a.php?cmd=disp in two tabs of the same browser (so
php session will be shared)
... where a.php is php script above
2) click disp several times, counter should increase
3) in second tab try click on soap (which will issue soap query to
unreachable server/port so it will take long time)
4) back in first tab try to click on disp
now at 4) browser will wait for server to reply until soap query finishes
--
Edit bug report at http://bugs.php.net/?id=36142&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36142&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36142&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36142&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36142&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36142&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36142&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36142&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36142&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36142&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36142&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36142&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36142&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36142&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36142&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36142&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36142&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36142&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36142&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36142&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36142&r=mysqlcfg
#36142 [Opn->Csd]: SOAP usage halts session
ID: 36142
User updated by: arekm at pld-linux dot org
Reported By: arekm at pld-linux dot org
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Found the solution:
session_write_close();
$response = $client->__soapCall("blah", array());
session_start();
Previous Comments:
[2006-01-24 13:13:36] arekm at pld-linux dot org
Description:
Very long running SOAP query in one tab in web browser halts the same
session on the server so nothing can be done in the same app (using the
same session) in second tab of the browser.
Reproduce code:
---
"http://www.nask.pl:1000"; /* unreachable host */,
'uri' => "blah",
'encoding'=>'ISO-8859-2',
'trace' => true,
'exceptions' => false));
$response = $client->__soapCall("blah", array());
if (is_soap_fault($response))
echo "SOAP fault";
break;
case "disp":
echo "DISPLAY ME " . $_SESSION["cnt"] . "";
break;
}
?>
soap
disp
Expected result:
DISPLAY ME X where X increases without waiting for SOAP query to
finish.
Actual result:
--
Browser waits for server reply and gets it only after soap query
finishes.
How to reproduce?
1) open http://somwhere/a.php?cmd=disp in two tabs of the same browser
(so php session will be shared)
... where a.php is php script above
2) click disp several times, counter should increase
3) in second tab try click on soap (which will issue soap query to
unreachable server/port so it will take long time)
4) back in first tab try to click on disp
now at 4) browser will wait for server to reply until soap query
finishes
--
Edit this bug report at http://bugs.php.net/?id=36142&edit=1
#34257 [NEW]: lib64 not handled correctly in ming extension
From: arekm at pld-linux dot org Operating system: Linux PHP version: 5.1.0RC1 PHP Bug Type: Compile Failure Bug description: lib64 not handled correctly in ming extension Description: When building ming extension configure script checks only /usr/lib (where lib is hardcoded) so no support for ie. amd64 platform when lib64 is used. -- Edit bug report at http://bugs.php.net/?id=34257&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34257&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34257&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34257&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34257&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34257&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34257&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34257&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34257&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34257&r=support Expected behavior: http://bugs.php.net/fix.php?id=34257&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34257&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34257&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34257&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34257&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34257&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34257&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34257&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34257&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34257&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34257&r=mysqlcfg
#34257 [Opn]: lib64 not handled correctly in ming extension
ID: 34257 User updated by: arekm at pld-linux dot org Reported By: arekm at pld-linux dot org Status: Open Bug Type: Compile Failure Operating System: Linux PHP Version: 5.1.0RC1 New Comment: diff -urN php-5.1.0RC1.org/ext/ming/config.m4 php-5.1.0RC1/ext/ming/config.m4 --- php-5.1.0RC1.org/ext/ming/config.m4 2005-07-18 01:58:39.0 +0200 +++ php-5.1.0RC1/ext/ming/config.m4 2005-08-25 19:23:28.356268128 +0200 @@ -9,7 +9,7 @@ AC_CHECK_LIB(m, sin) for i in $PHP_MING /usr/local /usr; do -if test -f $i/lib/libming.$SHLIB_SUFFIX_NAME -o -f $i/lib/libming.a; then +if test -f $i/$PHP_LIBDIR/libming.$SHLIB_SUFFIX_NAME -o -f $i/$PHP_LIBDIR/libming.a; then MING_DIR=$i break fi Previous Comments: [2005-08-25 19:31:58] arekm at pld-linux dot org Description: When building ming extension configure script checks only /usr/lib (where lib is hardcoded) so no support for ie. amd64 platform when lib64 is used. -- Edit this bug report at http://bugs.php.net/?id=34257&edit=1
[PHP-BUG] Bug #60100 [NEW]: segmentation fault at Zip::extractto()
From:
Operating system: PLD/Linux
PHP version: 5.3.8
Package: Reproducible crash
Bug Type: Bug
Bug description:segmentation fault at Zip::extractto()
Description:
(gdb) bt
#0 0x767a1e34 in free () from /lib64/libc.so.6
#1 0x711439ef in php_zip_extract_file (za=0xb01d40, dest=0xaddc28
"test", file=0xb019b0 "admin/", file_len=)
at /usr/src/debug/php-5.3.8/ext/zip/php_zip.c:226
#2 0x71143d62 in c_ziparchive_extractTo (ht=,
return_value=0xadc7f8, return_value_ptr=,
this_ptr=,
return_value_used=) at
/usr/src/debug/php-5.3.8/ext/zip/php_zip.c:2487
#3 0x71a648b4 in ?? () from /usr/lib64/php/suhosin.so
#4 0x77d18b34 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3140) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:322
#5 0x77cb8fcb in execute (op_array=0xb01c50) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#6 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#7 0x77d1881c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3068) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:344
#8 0x77cb8fcb in execute (op_array=0xad9878) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#9 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#10 0x77c94a80 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.8/Zend/zend.c:1308
#11 0x77c40ff0 in php_execute_script (primary_file=0x7fffe440)
at /usr/src/debug/php-5.3.8/main/main.c:2299
#12 0x00404969 in main (argc=2, argv=0x7fffe5f8) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1188
Test script:
---
open($file);
if ($res === TRUE) {
$zip->extractTo($extractPath);
$zip->close();
return TRUE;
} else {
return FALSE;
}
}
zip_extract('file11.zip','test');
--
Edit bug report at https://bugs.php.net/bug.php?id=60100&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60100&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60100&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60100&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60100&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60100&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60100&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60100&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60100&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60100&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60100&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60100&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60100&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60100&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60100&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60100&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60100&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60100&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60100&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60100&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60100&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60100&r=mysqlcfg
Bug #60100 [Com]: segmentation fault at Zip::extractto()
Edit report at https://bugs.php.net/bug.php?id=60100&edit=1
ID: 60100
Comment by: adamg at pld-linux dot org
Reported by:adamg at pld-linux dot org
Summary:segmentation fault at Zip::extractto()
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: PLD/Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
http://adamg.eu/~adamg/zip/
But it seems it was a distro problem caused by a recently applied patch, but I
am puting the zip files for reference anyway.
Previous Comments:
[2011-10-19 21:03:59] paj...@php.net
Please provide the zip file you use to test.
[2011-10-19 20:59:47] adamg at pld-linux dot org
Description:
(gdb) bt
#0 0x767a1e34 in free () from /lib64/libc.so.6
#1 0x711439ef in php_zip_extract_file (za=0xb01d40, dest=0xaddc28
"test", file=0xb019b0 "admin/", file_len=)
at /usr/src/debug/php-5.3.8/ext/zip/php_zip.c:226
#2 0x71143d62 in c_ziparchive_extractTo (ht=,
return_value=0xadc7f8, return_value_ptr=, this_ptr=,
return_value_used=) at
/usr/src/debug/php-5.3.8/ext/zip/php_zip.c:2487
#3 0x71a648b4 in ?? () from /usr/lib64/php/suhosin.so
#4 0x77d18b34 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3140) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:322
#5 0x77cb8fcb in execute (op_array=0xb01c50) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#6 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#7 0x77d1881c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3068) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:344
#8 0x77cb8fcb in execute (op_array=0xad9878) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#9 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#10 0x77c94a80 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.8/Zend/zend.c:1308
#11 0x77c40ff0 in php_execute_script (primary_file=0x7fffe440) at
/usr/src/debug/php-5.3.8/main/main.c:2299
#12 0x00404969 in main (argc=2, argv=0x7fffe5f8) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1188
Test script:
---
open($file);
if ($res === TRUE) {
$zip->extractTo($extractPath);
$zip->close();
return TRUE;
} else {
return FALSE;
}
}
zip_extract('file11.zip','test');
--
Edit this bug report at https://bugs.php.net/bug.php?id=60100&edit=1
Bug #60100 [Fbk->Csd]: segmentation fault at Zip::extractto()
Edit report at https://bugs.php.net/bug.php?id=60100&edit=1
ID: 60100
User updated by:adamg at pld-linux dot org
Reported by:adamg at pld-linux dot org
Summary:segmentation fault at Zip::extractto()
-Status: Feedback
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: PLD/Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Yes, just checked, does not happen with unpatched php.
Closing a bug report, sorry about the noise.
Previous Comments:
[2011-10-29 21:19:34] paj...@php.net
a distro problem? Were you not using the PHP src?
[2011-10-29 20:30:21] adamg at pld-linux dot org
http://adamg.eu/~adamg/zip/
But it seems it was a distro problem caused by a recently applied patch, but I
am puting the zip files for reference anyway.
[2011-10-19 21:03:59] paj...@php.net
Please provide the zip file you use to test.
[2011-10-19 20:59:47] adamg at pld-linux dot org
Description:
(gdb) bt
#0 0x767a1e34 in free () from /lib64/libc.so.6
#1 0x711439ef in php_zip_extract_file (za=0xb01d40, dest=0xaddc28
"test", file=0xb019b0 "admin/", file_len=)
at /usr/src/debug/php-5.3.8/ext/zip/php_zip.c:226
#2 0x71143d62 in c_ziparchive_extractTo (ht=,
return_value=0xadc7f8, return_value_ptr=, this_ptr=,
return_value_used=) at
/usr/src/debug/php-5.3.8/ext/zip/php_zip.c:2487
#3 0x71a648b4 in ?? () from /usr/lib64/php/suhosin.so
#4 0x77d18b34 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3140) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:322
#5 0x77cb8fcb in execute (op_array=0xb01c50) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#6 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#7 0x77d1881c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3068) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:344
#8 0x77cb8fcb in execute (op_array=0xad9878) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#9 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#10 0x77c94a80 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.8/Zend/zend.c:1308
#11 0x77c40ff0 in php_execute_script (primary_file=0x7fffe440) at
/usr/src/debug/php-5.3.8/main/main.c:2299
#12 0x00404969 in main (argc=2, argv=0x7fffe5f8) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1188
Test script:
---
open($file);
if ($res === TRUE) {
$zip->extractTo($extractPath);
$zip->close();
return TRUE;
} else {
return FALSE;
}
}
zip_extract('file11.zip','test');
--
Edit this bug report at https://bugs.php.net/bug.php?id=60100&edit=1
#37793 [Com]: child pid xxx exit signal Segmentation fault (11)
ID: 37793 Comment by: jeffs dot linux at gmail dot com Reported By: niklas dot meyerson at natverkstan dot net Status: No Feedback Bug Type: Apache2 related Operating System: Debian 2.6 PHP Version: 5.1.4 New Comment: I am having this same error, my error code is as follows: [Wed Oct 29 16:29:36 2008] [notice] child pid 18880 exit signal Segmentation fault (11) I traced it back to a preg_match function that opens up a file around 3.2KB and matches comment tags (its an html file). I am certain that it has something to do with it because a die() function before it registers but after it gives me a white errorless screen. I dont know if the preg_match is the same issue, but it is certainly my issue! The thing is I dont know how to get around this on... I might need to change my approch. Previous Comments: [2006-06-21 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-06-13 17:18:52] [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 for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-06-13 10:45:58] niklas dot meyerson at natverkstan dot net Description: A couple of weeks ago I installed apache2 and php5.1.4 on our server. Every night since apache has crashed. In the errorlog for apache I see a couple of notices like this one: child pid 25354 exit signal Segmentation fault (11) And when I restarts apache the errorlog sais gives me lots of warnings: [warn] child process 4246 still did not exit, sending a SIGTERM And then errors: [error] child process 4246 still did not exit, sending a SIGKILL Reproduce code: --- I don't know what's causing it. Expected result: No crash. Actual result: -- Error log: [Mon Jun 12 19:14:31 2006] [notice] child pid 5264 exit signal Segmentation fault (11) [Mon Jun 12 19:25:51 2006] [notice] child pid 5569 exit signal Segmentation fault (11) [Mon Jun 12 22:20:34 2006] [notice] child pid 6161 exit signal Segmentation fault (11) [Mon Jun 12 22:36:26 2006] [error] server reached MaxClients setting, consider raising the MaxClients setting [Tue Jun 13 02:07:36 2006] [notice] child pid 4845 exit signal Segmentation fault (11) [Tue Jun 13 02:50:37 2006] [notice] child pid 6989 exit signal Segmentation fault (11) [Tue Jun 13 03:03:58 2006] [notice] child pid 7067 exit signal Segmentation fault (11) [Tue Jun 13 03:09:16 2006] [notice] child pid 6451 exit signal Segmentation fault (11) At apache restart: [Tue Jun 13 11:05:25 2006] [warn] child process 4246 still did not exit, sending a SIGTERM [Tue Jun 13 11:05:25 2006] [warn] child process 7104 still did not exit, sending a SIGTERM [Tue Jun 13 11:05:25 2006] [warn] child process 7044 still did not exit, sending a SIGTERM [Tue Jun 13 11:05:25 2006] [warn] child process 5450 still did not exit, sending a SIGTERM [Tue Jun 13 11:05:25 2006] [warn] child process 4250 still did not exit, sending a SIGTERM [Tue Jun 13 11:05:25 2006] [warn] child process 7058 still did not exit, sending a SIGTERM [Tue Jun
[PHP-BUG] Bug #61390 [NEW]: Segfault occurs in simple flatfile test
From: Operating system: Linux PHP version: 5.4.0 Package: DBM/DBA related Bug Type: Bug Bug description:Segfault occurs in simple flatfile test Description: I have a simple test case that dba_opens a flatfile once which returns a resource descriptor, inserts a key and value into that flatfile, opens the same flatfile again returning a second resource, closes the second resource, and again reads the a key from the first descriptor. This causes a seg fault. Test script: --- Note, this test case requires the dba extension to be installed. Expected result: I expect that instead of seg faulting on the final line, that it would instead print: This is a test insert 1 Actual result: -- (gdb) bt #0 flatfile_findkey (dba=0x0, key_datum=...) at /home/corey/php-5.4.0/ext/dba/libflatfile/flatfile.c:172 #1 0x004f05dd in flatfile_fetch (dba=0x0, key_datum=...) at /home/corey/php-5.4.0/ext/dba/libflatfile/flatfile.c:90 #2 0x004ef0fe in dba_fetch_flatfile (info=, key=0x7fcd5cb42a10 "key1", keylen=4, skip=, newlen=0x7fff6396689c) at /home/corey/php-5.4.0/ext/dba/dba_flatfile.c:70 #3 0x004ed1fb in zif_dba_fetch (ht=2, return_value=0x7fcd5cc57cb0, return_value_ptr=, this_ptr=, return_value_used=) at /home/corey/php-5.4.0/ext/dba/dba.c:1020 #4 0x00722b83 in zend_do_fcall_common_helper_SPEC (execute_data=) at /home/corey/php-5.4.0/Zend/zend_vm_execute.h:642 #5 0x006dd2c5 in execute (op_array=0x7fcd5cc560a8) at /home/corey/php-5.4.0/Zend/zend_vm_execute.h:410 #6 0x0067f585 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/corey/php-5.4.0/Zend/zend.c:1272 #7 0x00622109 in php_execute_script (primary_file=0x7fff63968f70) at /home/corey/php-5.4.0/main/main.c:2473 #8 0x007253ee in do_cli (argc=2, argv=0x7fff63969368) at /home/corey/php-5.4.0/sapi/cli/php_cli.c:983 #9 0x00725c9f in main (argc=2, argv=0x7fff63969368) at /home/corey/php-5.4.0/sapi/cli/php_cli.c:1356 Here's the valgrind memcheck log: ==18497== Memcheck, a memory error detector ==18497== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18497== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18497== Command: /usr/bin/php new.php ==18497== Parent PID: 17376 ==18497== ==18497== Invalid read of size 8 ==18497==at 0xB2E009B: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x5603F2: php_execute_script (in /usr/bin/php) ==18497==by 0x64688C: ??? (in /usr/bin/php) ==18497==by 0x3C0D41EE5C: (below main) (in /lib64/libc-2.13.so) ==18497== Address 0x5216d88 is 56 bytes inside a block of size 88 free'd ==18497==at 0x4A05187: free (vg_replace_malloc.c:325) ==18497==by 0x5C16CD: ??? (in /usr/bin/php) ==18497==by 0x5BE0D4: ??? (in /usr/bin/php) ==18497==by 0x5BF93B: zend_hash_apply_with_argument (in /usr/bin/php) ==18497==by 0x5C175D: ??? (in /usr/bin/php) ==18497==by 0x5BF5AB: zend_hash_del_key_or_index (in /usr/bin/php) ==18497==by 0x5C1888: _zend_list_delete (in /usr/bin/php) ==18497==by 0xB2DF3D3: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x5603F2: php_execute_script (in /usr/bin/php) ==18497==by 0x64688C: ??? (in /usr/bin/php) ==18497==by 0x3C0D41EE5C: (below main) (in /lib64/libc-2.13.so) ==18497== ==18497== Invalid read of size 8 ==18497==at 0xB2E2376: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0xB2E00BF: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x5603F2: php_execute_script (in /usr/bin/php) ==18497==by 0x64688C: ??? (in /usr/bin/php) ==18497==by 0x3C0D41EE5C: (below main) (in /lib64/libc-2.13.so) ==18497== Address 0x5216d50 is 0 bytes inside a block of size 88 free'd ==18497==at 0x4A05187: free (vg_replace_malloc.c:325) ==18497==by 0x5C16CD: ??? (in /usr/bin/php) ==18497==by 0x5BE0D4: ??? (in /usr/bin/php) ==18497==by 0x5BF93B: zend_hash_apply_with_argument (in /usr/bin/php) ==18497==by 0x5C175D: ??? (in /usr/bin/php) ==18497==by 0x5BF5AB: zend_hash_del_key_or_index (in /usr/bin/php) ==18497==by 0x5C1888: _zend_list_delete (in /usr/bin/php) ==18497==by 0xB2DF3D3: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x
Bug #61390 [Opn]: Segfault occurs in simple flatfile test
Edit report at https://bugs.php.net/bug.php?id=61390&edit=1 ID: 61390 User updated by:cjashfor at linux dot vnet dot ibm dot com Reported by:cjashfor at linux dot vnet dot ibm dot com Summary:Segfault occurs in simple flatfile test Status: Open Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The first echo in the test case is incorrect. It should read: echo "open ./test0.dbm as a flatfile db, and insert a key\n" Previous Comments: [2012-03-14 19:08:02] cjashfor at linux dot vnet dot ibm dot com Description: I have a simple test case that dba_opens a flatfile once which returns a resource descriptor, inserts a key and value into that flatfile, opens the same flatfile again returning a second resource, closes the second resource, and again reads the a key from the first descriptor. This causes a seg fault. Test script: --- Note, this test case requires the dba extension to be installed. Expected result: I expect that instead of seg faulting on the final line, that it would instead print: This is a test insert 1 Actual result: -- (gdb) bt #0 flatfile_findkey (dba=0x0, key_datum=...) at /home/corey/php-5.4.0/ext/dba/libflatfile/flatfile.c:172 #1 0x004f05dd in flatfile_fetch (dba=0x0, key_datum=...) at /home/corey/php-5.4.0/ext/dba/libflatfile/flatfile.c:90 #2 0x004ef0fe in dba_fetch_flatfile (info=, key=0x7fcd5cb42a10 "key1", keylen=4, skip=, newlen=0x7fff6396689c) at /home/corey/php-5.4.0/ext/dba/dba_flatfile.c:70 #3 0x004ed1fb in zif_dba_fetch (ht=2, return_value=0x7fcd5cc57cb0, return_value_ptr=, this_ptr=, return_value_used=) at /home/corey/php-5.4.0/ext/dba/dba.c:1020 #4 0x00722b83 in zend_do_fcall_common_helper_SPEC (execute_data=) at /home/corey/php-5.4.0/Zend/zend_vm_execute.h:642 #5 0x006dd2c5 in execute (op_array=0x7fcd5cc560a8) at /home/corey/php-5.4.0/Zend/zend_vm_execute.h:410 #6 0x0067f585 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/corey/php-5.4.0/Zend/zend.c:1272 #7 0x00622109 in php_execute_script (primary_file=0x7fff63968f70) at /home/corey/php-5.4.0/main/main.c:2473 #8 0x007253ee in do_cli (argc=2, argv=0x7fff63969368) at /home/corey/php-5.4.0/sapi/cli/php_cli.c:983 #9 0x00725c9f in main (argc=2, argv=0x7fff63969368) at /home/corey/php-5.4.0/sapi/cli/php_cli.c:1356 Here's the valgrind memcheck log: ==18497== Memcheck, a memory error detector ==18497== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18497== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18497== Command: /usr/bin/php new.php ==18497== Parent PID: 17376 ==18497== ==18497== Invalid read of size 8 ==18497==at 0xB2E009B: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x5603F2: php_execute_script (in /usr/bin/php) ==18497==by 0x64688C: ??? (in /usr/bin/php) ==18497==by 0x3C0D41EE5C: (below main) (in /lib64/libc-2.13.so) ==18497== Address 0x5216d88 is 56 bytes inside a block of size 88 free'd ==18497==at 0x4A05187: free (vg_replace_malloc.c:325) ==18497==by 0x5C16CD: ??? (in /usr/bin/php) ==18497==by 0x5BE0D4: ??? (in /usr/bin/php) ==18497==by 0x5BF93B: zend_hash_apply_with_argument (in /usr/bin/php) ==18497==by 0x5C175D: ??? (in /usr/bin/php) ==18497==by 0x5BF5AB: zend_hash_del_key_or_index (in /usr/bin/php) ==18497==by 0x5C1888: _zend_list_delete (in /usr/bin/php) ==18497==by 0xB2DF3D3: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x5603F2: php_execute_script (in /usr/bin/php) ==18497==by 0x64688C: ??? (in /usr/bin/php) ==18497==by 0x3C0D41EE5C: (below main) (in /lib64/libc-2.13.so) ==18497== ==18497== Invalid read of size 8 ==18497==at 0xB2E2376: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0xB2E00BF: ??? (in /usr/lib64/php/modules/dba.so) ==18497==by 0x5FDE3C: ??? (in /usr/bin/php) ==18497==by 0x5D6793: execute (in /usr/bin/php) ==18497==by 0x5B3965: zend_execute_scripts (in /usr/bin/php) ==18497==by 0x5603F2: php_execute_script (in /usr/bin/php) ==18497==by 0x64688C: ??? (in /usr/bin/php) ==18497==by 0x3C0D41EE5C: (below main) (in /lib64/libc-2.13.so) ==18497== Address 0x5216d50 is 0 bytes inside a block of size 88 free'd ==18497==at 0x4A05187: free (vg_re
Bug #61390 [Com]: Segfault occurs in simple flatfile test
Edit report at https://bugs.php.net/bug.php?id=61390&edit=1 ID: 61390 Comment by: cjashfor at linux dot vnet dot ibm dot com Reported by:cjashfor at linux dot vnet dot ibm dot com Summary:Segfault occurs in simple flatfile test Status: Open Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The first valgrind memcheck I ran was on the installed php, and so it's missing some file/line# information. Here's one where I ran it on the php where I built it; it contains complete file/line# info: ==18593== Memcheck, a memory error detector ==18593== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18593== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18593== Command: /home/corey/php-5.4.0/sapi/cli/php new.php ==18593== Parent PID: 17376 ==18593== ==18593== Invalid read of size 8 ==18593==at 0x4ED1D9: zif_dba_fetch (dba.c:1018) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== Address 0x51e48e8 is 56 bytes inside a block of size 88 free'd ==18593==at 0x4A05187: free (vg_replace_malloc.c:325) ==18593==by 0x68D55D: plist_entry_destructor (zend_list.c:209) ==18593==by 0x689D0E: zend_hash_apply_deleter (zend_hash.c:650) ==18593==by 0x68B7CB: zend_hash_apply_with_argument (zend_hash.c:743) ==18593==by 0x68D5ED: list_entry_destructor (zend_list.c:183) ==18593==by 0x68B3F0: zend_hash_del_key_or_index (zend_hash.c:531) ==18593==by 0x68D6D6: _zend_list_delete (zend_list.c:57) ==18593==by 0x4ED35F: zif_dba_close (dba.c:969) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== ==18593== Invalid read of size 8 ==18593==at 0x4EF0E6: dba_fetch_flatfile (dba_flatfile.c:67) ==18593==by 0x4ED1FA: zif_dba_fetch (dba.c:1020) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== Address 0x51e48b0 is 0 bytes inside a block of size 88 free'd ==18593==at 0x4A05187: free (vg_replace_malloc.c:325) ==18593==by 0x68D55D: plist_entry_destructor (zend_list.c:209) ==18593==by 0x689D0E: zend_hash_apply_deleter (zend_hash.c:650) ==18593==by 0x68B7CB: zend_hash_apply_with_argument (zend_hash.c:743) ==18593==by 0x68D5ED: list_entry_destructor (zend_list.c:183) ==18593==by 0x68B3F0: zend_hash_del_key_or_index (zend_hash.c:531) ==18593==by 0x68D6D6: _zend_list_delete (zend_list.c:57) ==18593==by 0x4ED35F: zif_dba_close (dba.c:969) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== ==18593== Invalid read of size 8 ==18593==at 0x4F047A: flatfile_findkey (flatfile.c:172) ==18593==by 0x4F05DC: flatfile_fetch (flatfile.c:90) ==18593==by 0x4EF0FD: dba_fetch_flatfile (dba_flatfile.c:70) ==18593==by 0x4ED1FA: zif_dba_fetch (dba.c:1020) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== Address 0x51e5050 is 16 bytes inside a block of size 48 free'd ==18593==at 0x4A05187: free (vg_replace_malloc.c:325) ==18593==by 0x4ED39F: dba_close (dba.c:401) ==18593==by 0x68D55D: plist_entry_destructor (zend_list.c:209) ==18593==by 0x689D0E: zend_hash_apply_deleter (zend_hash.c:650) ==18593==by 0x68B7CB: zend_hash_apply_with_argument (zend_hash.c:743) ==18593==by 0x68D5ED: list_entry_destructor (zend_list.c:183) ==18593==by 0x
Bug #61390 [Com]: Segfault occurs in simple flatfile test
Edit report at https://bugs.php.net/bug.php?id=61390&edit=1 ID: 61390 Comment by: cjashfor at linux dot vnet dot ibm dot com Reported by:cjashfor at linux dot vnet dot ibm dot com Summary:Segfault occurs in simple flatfile test Status: Open Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.4.0 Block user comment: N Private report: N New Comment: >From what I can tell from debugging, what's happening is that on the first >dba_popen, a dba_info structure is allocated for the first resource. On the second dba_popen, since it's the same file, the dba_info from the first resource is reused. I don't know if this alone is a legitimate thing to do, because now two resources are sharing the same dba_info. At the very least, I would think that some sort of reference counter is need in dba_info to track how many resources are linked to it. When the first resource is closed, the dba_info structure is free'd at dba.c:dba_close():423. Consequently, when the second resource is referenced, it's using an already-free'd dba_info structure, and this causes a seg fault. If it's truly OK to have to resources reference the same dba_info structure, one solution might be to add a reference counter to dba_info, and to set it to 1 on the initial allocation, and increment it when linking to it on subsequent dba_popens. When closing resources, the reference counter is decremented, and the structure is released only when the count reaches zero. Any thoughts? Previous Comments: ---- [2012-03-14 19:28:48] cjashfor at linux dot vnet dot ibm dot com The first valgrind memcheck I ran was on the installed php, and so it's missing some file/line# information. Here's one where I ran it on the php where I built it; it contains complete file/line# info: ==18593== Memcheck, a memory error detector ==18593== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18593== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18593== Command: /home/corey/php-5.4.0/sapi/cli/php new.php ==18593== Parent PID: 17376 ==18593== ==18593== Invalid read of size 8 ==18593==at 0x4ED1D9: zif_dba_fetch (dba.c:1018) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== Address 0x51e48e8 is 56 bytes inside a block of size 88 free'd ==18593==at 0x4A05187: free (vg_replace_malloc.c:325) ==18593==by 0x68D55D: plist_entry_destructor (zend_list.c:209) ==18593==by 0x689D0E: zend_hash_apply_deleter (zend_hash.c:650) ==18593==by 0x68B7CB: zend_hash_apply_with_argument (zend_hash.c:743) ==18593==by 0x68D5ED: list_entry_destructor (zend_list.c:183) ==18593==by 0x68B3F0: zend_hash_del_key_or_index (zend_hash.c:531) ==18593==by 0x68D6D6: _zend_list_delete (zend_list.c:57) ==18593==by 0x4ED35F: zif_dba_close (dba.c:969) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== ==18593== Invalid read of size 8 ==18593==at 0x4EF0E6: dba_fetch_flatfile (dba_flatfile.c:67) ==18593==by 0x4ED1FA: zif_dba_fetch (dba.c:1020) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== Address 0x51e48b0 is 0 bytes inside a block of size 88 free'd ==18593==at 0x4A05187: free (vg_replace_malloc.c:325) ==18593==by 0x68D55D: plist_entry_destructor (zend_list.c:209) ==18593==by 0x689D0E: zend_hash_apply_deleter (zend_hash.c:650) ==18593==by 0x68B7CB: zend_hash_apply_with_argument (zend_hash.c:743) ==18593==by 0x68D5ED: list_entry_destructor (zend_list.c:183) ==18593==by 0x68B3F0: zend_hash_del_key_or_index (zend_hash.c:531) ==18593==by 0x68D6D6: _zend_list_delete (zend_list.c:57) ==18593==by 0x4ED35F: zif_dba_close (dba.c:969) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==1859
Bug #51278 [Com]: Crash when using reopened persistent connection after one resource closed
Edit report at https://bugs.php.net/bug.php?id=51278&edit=1 ID: 51278 Comment by: cjashfor at linux dot vnet dot ibm dot com Reported by:christopher dot jones at oraclel dot com Summary:Crash when using reopened persistent connection after one resource closed Status: Open Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.3SVN-2010-03-12 (SVN) Block user comment: N Private report: N New Comment: Shouldn't someone at least be assigned to fix this bug? I reported what appears to be an identical bug - 61390 - and it was closed after just a small amount of discussion from the developers, followed by inactivity. Previous Comments: [2010-03-12 01:17:26] christopher dot jones at oraclel dot com Description: Do two dba_popen() calls using the same file. Close one resource with dba_close(). Then do a dba_fetch on the still open resource. This results in a crash in flatfile_findkey() with a NULL dba pointer. Program received signal SIGSEGV, Segmentation fault. 0x0817c3b4 in flatfile_findkey (dba=0x0, key_datum=...) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:173 (gdb) bt #0 0x0817c3b4 in flatfile_findkey (dba=0x0, key_datum=...) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:173 #1 0x0817bfaa in flatfile_fetch (dba=0x0, key_datum=...) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:91 #2 0x0817a671 in dba_fetch_flatfile (info=0x89abb20, key=0x897b2bc "key1", keylen=4, skip=0, newlen=0xbfffd348) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/dba_flatfile.c:70 #3 0x0817871b in zif_dba_fetch (ht=2, return_value=0x897a638, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/ext/dba/dba.c:1025 #4 0x0844ccf0 in zend_do_fcall_common_helper_SPEC (execute_data=0x89abcc8) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:313 #5 0x084507ae in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x89abcc8) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:1603 #6 0x0844c38d in execute (op_array=0x897ac98) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/Zend/zend_vm_execute.h:104 #7 0x0841ff12 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend.c:1194 #8 0x083b6c16 in php_execute_script (primary_file=0xb7c4) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/main/main.c:2260 #9 0x084dd733 in main (argc=2, argv=0xb954) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/sapi/cli/php_cli.c:1192 Test script: --- See ext/dba/tests/dba015.phpt -- Edit this bug report at https://bugs.php.net/bug.php?id=51278&edit=1
#49392 [NEW]: Many PHP tests try to verify float to integer overflow result
From: cndougla at linux dot vnet dot ibm dot com Operating system: Any PHP version: 6SVN-2009-08-27 (SVN) PHP Bug Type: Unknown/Other Function Bug description: Many PHP tests try to verify float to integer overflow result Description: Many tests have input values like 10.5e10 that must be converted to integer values. On 32-bit systems, the conversion overflows. According to the PHP manual: --- If the float is beyond the boundaries of integer (usually +/- 2.15e+9 = 2^31), the result is undefined, since the float doesn't have enough precision to give an exact integer result. No warning, not even a notice will be issued when this happens! --- Therefore, the tests are attempting to verify undefined values. Reproduce code: --- We found a bunch of testcases with this issue by running in a ppc64 kernel / ppc32 userspace: ext/standard/tests/array/array_fill_variation1.phpt ext/standard/tests/array/array_keys_variation_002.phpt ext/standard/tests/general_functions/gettype_settype_variation2.phpt ext/standard/tests/strings/htmlspecialchars_decode_variation2.phpt ext/standard/tests/strings/pack.phpt ext/standard/tests/strings/sprintf_variation35.phpt ext/standard/tests/strings/sprintf_variation4.phpt ext/standard/tests/strings/sprintf_variation41.phpt ext/standard/tests/strings/strncasecmp_variation5.phpt ext/standard/tests/strings/strncmp_variation5.phpt ext/standard/tests/strings/strrpos_variation14.phpt ext/standard/tests/strings/strrpos_variation15.phpt ext/standard/tests/strings/vsprintf_variation15.phpt ext/standard/tests/strings/vsprintf_variation16.phpt ext/standard/tests/strings/vsprintf_variation4.phpt We also found the following test had issues on ppc64/ppc64: ext/standard/tests/strings/vsprintf_variation15_64bit.phpt Expected result: These tests should not be checking for the value of the direct or indirect overflow of a float to integer conversion. The tests should have the one or two subtests that do this removed. Actual result: -- The tests fail on some platforms, especially split 64/32-bit installations. -- Edit bug report at http://bugs.php.net/?id=49392&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49392&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49392&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49392&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49392&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49392&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49392&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49392&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49392&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49392&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49392&r=support Expected behavior: http://bugs.php.net/fix.php?id=49392&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49392&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49392&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49392&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49392&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49392&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49392&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49392&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49392&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49392&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49392&r=mysqlcfg
#46318 [NEW]: gdImageFill invalid stack overflow comparison
From: cndougla at linux dot vnet dot ibm dot com Operating system: PHP version: 5.2.6 PHP Bug Type: GD related Bug description: gdImageFill invalid stack overflow comparison Description: In gdImageFill, a stack is created for the flood fill algorithm. Originally it seems the stack was created with space for 1,200,000 structures, but that has since been commented out and the stack is now created dynamically with the depth determined by the size of the image. The macro used to push structures onto the stack was checking for overflow based on checking the current stack pointer. Instead of comparing the stack pointer to the real size of the stack, the stack pointer was compared against the size of the structure (16 bytes) * 1,200,000 * 10. I have no idea why the factor of 10 was there. This large value wraps 32-bit arithmetic all the way around such that the comparison was no longer valid, and it always seemed the stack had overflowed even before anything was pushed onto it. Reproduce code: --- Expected result: 1 Actual result: -- 0 when the bug shows up. I found it to fail on ppc64 when it was built as a ppc32 userspace library, while on a ppc32 or x86 or x86_64 system it passed just fine. -- Edit bug report at http://bugs.php.net/?id=46318&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46318&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46318&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46318&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46318&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46318&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46318&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46318&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46318&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46318&r=support Expected behavior:http://bugs.php.net/fix.php?id=46318&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46318&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46318&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46318&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46318&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46318&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46318&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46318&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46318&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46318&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46318&r=mysqlcfg
#46318 [Com]: gdImageFill invalid stack overflow comparison
ID: 46318
Comment by: cndougla at linux dot vnet dot ibm dot com
Reported By: cndougla at linux dot vnet dot ibm dot com
Status: Open
Bug Type:GD related
PHP Version: 5.2.6
New Comment:
A patch to fix the issue:
diff -uNr -ur php-5.2.6.orig/ext/gd/libgd/gd.c
php-5.2.6/ext/gd/libgd/gd.c
--- php-5.2.6.orig/ext/gd/libgd/gd.c2007-11-04 17:56:00.0
-0600
+++ php-5.2.6/ext/gd/libgd/gd.c 2008-10-16 13:03:41.0 -0500
@@ -1938,9 +1938,9 @@
struct seg {int y, xl, xr, dy;};
/* max depth of stack */
-#define FILL_MAX 120
+#define FILL_MAX ((int)(im->sy*im->sx)/4)
#define FILL_PUSH(Y, XL, XR, DY) \
-if (sp=0 && Y+(DY)=0 && Y+(DY)y = Y; sp->xl = XL; sp->xr = XR; sp->dy = DY; sp++;}
#define FILL_POP(Y, XL, XR, DY) \
Previous Comments:
[2008-10-16 19:30:38] cndougla at linux dot vnet dot ibm dot com
Description:
In gdImageFill, a stack is created for the flood fill algorithm.
Originally it seems the stack was created with space for 1,200,000
structures, but that has since been commented out and the stack is now
created dynamically with the depth determined by the size of the image.
The macro used to push structures onto the stack was checking for
overflow based on checking the current stack pointer. Instead of
comparing the stack pointer to the real size of the stack, the stack
pointer was compared against the size of the structure (16 bytes) *
1,200,000 * 10. I have no idea why the factor of 10 was there. This
large value wraps 32-bit arithmetic all the way around such that the
comparison was no longer valid, and it always seemed the stack had
overflowed even before anything was pushed onto it.
Reproduce code:
---
Expected result:
1
Actual result:
--
0 when the bug shows up. I found it to fail on ppc64 when it was built
as a ppc32 userspace library, while on a ppc32 or x86 or x86_64 system
it passed just fine.
--
Edit this bug report at http://bugs.php.net/?id=46318&edit=1
#38053 [NEW]: PHP not work with apache 2.2.2
From: onur dot yerlikaya at linux dot org dot tr Operating system: Windows XP PHP version: 5.1.4 PHP Bug Type: Apache2 related Bug description: PHP not work with apache 2.2.2 Description: PHP not work with apache 2.2.2 Expected result: When i install Apache 2.2.2 with PHP like a module. it did not work. -- Edit bug report at http://bugs.php.net/?id=38053&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38053&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38053&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38053&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38053&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38053&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38053&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38053&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38053&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38053&r=support Expected behavior:http://bugs.php.net/fix.php?id=38053&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38053&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38053&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38053&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38053&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38053&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38053&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38053&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38053&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38053&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38053&r=mysqlcfg
#38053 [Opn]: PHP not work with apache 2.2.2
ID: 38053 User updated by: onur dot yerlikaya at linux dot org dot tr Reported By: onur dot yerlikaya at linux dot org dot tr Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.1.4 New Comment: sorry it does NOT work. Previous Comments: [2006-07-10 06:17:20] onur dot yerlikaya at linux dot org dot tr Description: PHP not work with apache 2.2.2 Expected result: When i install Apache 2.2.2 with PHP like a module. it did not work. -- Edit this bug report at http://bugs.php.net/?id=38053&edit=1
#38053 [Com]: PHP not work with apache 2.2.2
ID: 38053 Comment by: unur dot yerlikaya at linux dot org dot tr Reported By: onur dot yerlikaya at linux dot org dot tr Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.1.4 New Comment: yea, just an update - it still does NOT work. Previous Comments: [2006-07-10 06:28:51] onur dot yerlikaya at linux dot org dot tr sorry it does NOT work. [2006-07-10 06:17:20] onur dot yerlikaya at linux dot org dot tr Description: PHP not work with apache 2.2.2 Expected result: When i install Apache 2.2.2 with PHP like a module. it did not work. -- Edit this bug report at http://bugs.php.net/?id=38053&edit=1
[PHP-BUG] Bug #54578 [NEW]: bitwiseNot_basiclong_64bit test fails on ppc64
From: Operating system: Linux PHP version: 5.3.6 Package: *Math Functions Bug Type: Bug Bug description:bitwiseNot_basiclong_64bit test fails on ppc64 Description: When running the bitwiseNot_basiclong_64bit.phpt test on ppc64, the output differs in one place from the expected results. This seems to be a result of MAX_64Bit + 1 being internally interpreted as a float and some kind of rounding error, however I'm not certain that is the case. The failing test is the third from the bottom in the output. I originally found this in 5.3.2 on RHEL 6, but I built a local 5.3.6 and it happens there still as well. bash-4.1# php --version PHP 5.3.6 (cli) (built: Apr 20 2011 09:26:51) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies bash-4.1# Expected result: --EXPECT-- --- testing: 9223372036854775807 --- int(-9223372036854775808) --- testing: -9223372036854775808 --- int(9223372036854775807) --- testing: 2147483647 --- int(-2147483648) --- testing: -2147483648 --- int(2147483647) --- testing: 9223372034707292160 --- int(-9223372034707292161) --- testing: -9223372034707292160 --- int(9223372034707292159) --- testing: 2147483648 --- int(-2147483649) --- testing: -2147483649 --- int(2147483648) --- testing: 4294967294 --- int(-4294967295) --- testing: 4294967295 --- int(-4294967296) --- testing: 4294967293 --- int(-4294967294) --- testing: 9223372036854775806 --- int(-9223372036854775807) --- testing: 9.2233720368548E+18 --- int(9223372036854775807) --- testing: -9223372036854775807 --- int(9223372036854775806) --- testing: -9.2233720368548E+18 --- int(9223372036854775807) ===DONE=== Actual result: -- --- testing: 9223372036854775807 --- int(-9223372036854775808) --- testing: -9223372036854775808 --- int(9223372036854775807) --- testing: 2147483647 --- int(-2147483648) --- testing: -2147483648 --- int(2147483647) --- testing: 9223372034707292160 --- int(-9223372034707292161) --- testing: -9223372034707292160 --- int(9223372034707292159) --- testing: 2147483648 --- int(-2147483649) --- testing: -2147483649 --- int(2147483648) --- testing: 4294967294 --- int(-4294967295) --- testing: 4294967295 --- int(-4294967296) --- testing: 4294967293 --- int(-4294967294) --- testing: 9223372036854775806 --- int(-9223372036854775807) --- testing: 9.2233720368548E+18 --- int(-9223372036854775808) --- testing: -9223372036854775807 --- int(9223372036854775806) --- testing: -9.2233720368548E+18 --- int(9223372036854775807) ===DONE=== -- Edit bug report at http://bugs.php.net/bug.php?id=54578&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54578&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54578&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54578&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54578&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54578&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54578&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54578&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54578&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54578&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54578&r=support Expected behavior: http://bugs.php.net/fix.php?id=54578&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54578&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54578&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54578&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54578&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54578&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54578&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54578&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54578&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54578&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54578&r=mysqlcfg
Bug #61390 [Com]: Segfault occurs in simple flatfile test
Edit report at https://bugs.php.net/bug.php?id=61390&edit=1 ID: 61390 Comment by: cjashfor at linux dot vnet dot ibm dot com Reported by:cjashfor at linux dot vnet dot ibm dot com Summary:Segfault occurs in simple flatfile test Status: No Feedback Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.4.0 Assigned To:dmitry Block user comment: N Private report: N New Comment: This bug should be re-opened because it hasn't been fixed. I don't know what the correct solution is in the implementation, but the bug shouldn't be closed till it's resolved. Previous Comments: [2013-02-18 00:35:45] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2012-05-21 13:54:41] dmi...@php.net why dba_close() closes a persistent resource? In comparison mysql_close() doesn't close connection opened using mysql_pconnect() and as result ext/mysql doesn't make this problem. BTW: ZE resources have refcount, but unfortunately it couldn't help in this case. [2012-03-31 01:37:19] yohg...@php.net The needs of resource reference counter is pointed out by Stefan Esser many years ago. I'm not sure who is the right person, but I'll assign this to Dmitry for now so that someone could take care of this. ---- [2012-03-16 19:33:42] cjashfor at linux dot vnet dot ibm dot com >From what I can tell from debugging, what's happening is that on the first >dba_popen, a dba_info structure is allocated for the first resource. On the second dba_popen, since it's the same file, the dba_info from the first resource is reused. I don't know if this alone is a legitimate thing to do, because now two resources are sharing the same dba_info. At the very least, I would think that some sort of reference counter is need in dba_info to track how many resources are linked to it. When the first resource is closed, the dba_info structure is free'd at dba.c:dba_close():423. Consequently, when the second resource is referenced, it's using an already-free'd dba_info structure, and this causes a seg fault. If it's truly OK to have to resources reference the same dba_info structure, one solution might be to add a reference counter to dba_info, and to set it to 1 on the initial allocation, and increment it when linking to it on subsequent dba_popens. When closing resources, the reference counter is decremented, and the structure is released only when the count reaches zero. Any thoughts? ---- [2012-03-14 19:28:48] cjashfor at linux dot vnet dot ibm dot com The first valgrind memcheck I ran was on the installed php, and so it's missing some file/line# information. Here's one where I ran it on the php where I built it; it contains complete file/line# info: ==18593== Memcheck, a memory error detector ==18593== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18593== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18593== Command: /home/corey/php-5.4.0/sapi/cli/php new.php ==18593== Parent PID: 17376 ==18593== ==18593== Invalid read of size 8 ==18593==at 0x4ED1D9: zif_dba_fetch (dba.c:1018) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==by 0x6DD2C4: execute (zend_vm_execute.h:410) ==18593==by 0x67F584: zend_execute_scripts (zend.c:1272) ==18593==by 0x622108: php_execute_script (main.c:2473) ==18593==by 0x7253ED: do_cli (php_cli.c:983) ==18593==by 0x725C9E: main (php_cli.c:1356) ==18593== Address 0x51e48e8 is 56 bytes inside a block of size 88 free'd ==18593==at 0x4A05187: free (vg_replace_malloc.c:325) ==18593==by 0x68D55D: plist_entry_destructor (zend_list.c:209) ==18593==by 0x689D0E: zend_hash_apply_deleter (zend_hash.c:650) ==18593==by 0x68B7CB: zend_hash_apply_with_argument (zend_hash.c:743) ==18593==by 0x68D5ED: list_entry_destructor (zend_list.c:183) ==18593==by 0x68B3F0: zend_hash_del_key_or_index (zend_hash.c:531) ==18593==by 0x68D6D6: _zend_list_delete (zend_list.c:57) ==18593==by 0x4ED35F: zif_dba_close (dba.c:969) ==18593==by 0x722B82: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==18593==b
