#33281 [Opn]: Possible deadlock in PHP-cleanup under heavy load
ID: 33281 User updated by: jimmy dot makela at loopia dot se Reported By: jimmy dot makela at loopia dot se Status: Open Bug Type: Apache related Operating System: FreeBSD 4.9-RELEASE-p10 PHP Version: 4.3.11 New Comment: When it happened again yesterday the last request before the problem occured (and the process started looping) was a script using GD-functions for creating thumbnails, so GD is the prime suspect. The version of the GD-port installed is gd-2.0.33_1,1 The GD-library is not stripped either, and it is compiled with standard options. We have verified that the dynamic symbols look ok, I'm guessing that it is GDB which is confused by the dlopen'ed library? I'll try to create a small script for reproducing the problem and stress-testing that script. Previous Comments: [2005-06-09 22:17:42] jimmy dot makela at loopia dot se Regarding your questions: 1. I don't know, I was hoping for a suggestion to that part. The library have not been stripped manually, and doesn't seem to be stripped. A recompile could be done if that would help, just specify what to change. # file /usr/local/libexec/apache/libphp4.so /usr/local/libexec/apache/libphp4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped objdump -T does show symbols, but I have no idea of what object.11 maps to. I can provide a complete list of the dynamic symbol table if that helps. 2. A list of the loaded extensions follows: php4-bcmath-4.3.11_1 php4-calendar-4.3.11_1 php4-ctype-4.3.11_1 php4-curl-4.3.11_1 php4-domxml-4.3.11_1 php4-exif-4.3.11_1 php4-extensions-1.0 php4-ftp-4.3.11_1 php4-gd-4.3.11_1 php4-gettext-4.3.11_1 php4-iconv-4.3.11_1 php4-imap-4.3.11_1 php4-mcrypt-4.3.11_1 php4-mysql-4.3.11_1 php4-overload-4.3.11_1 php4-pcre-4.3.11_1 php4-posix-4.3.11_1 php4-session-4.3.11_1 php4-tokenizer-4.3.11_1 php4-xml-4.3.11_1 php4-zlib-4.3.11_1 Let me know if you need additional information. [2005-06-09 16:45:55] [EMAIL PROTECTED] A couple of questions. 1. Why is gdb just reporting object.11 instead of a real symbol? Have the symbols been stripped from your libphp4.so? Could you recompile and put them back to get a better backtrace? 2. Do you have any custom extensions loaded? And if you do, are they in C++? The FreeBSD4 rtld has notoriously bad support for C++ shared libraries. [2005-06-09 09:49:42] jimmy dot makela at loopia dot se Description: Periodically on one of our webservers one apache-process starts using up all CPU until it is killed. A ktrace of the process gives the output: 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 ad infinitum. When attaching to the process with GDB and doing a backtrace, we get the following update: #0 0x28092648 in symlook_obj () from /usr/libexec/ld-elf.so.1 #1 0x28091032 in dlclose () from /usr/libexec/ld-elf.so.1 #2 0x283b3251 in object.11 () from /usr/local/libexec/apache/libphp4.so #3 0x283b4bfc in object.11 () from /usr/local/libexec/apache/libphp4.so #4 0x283b4d3a in object.11 () from /usr/local/libexec/apache/libphp4.so #5 0x283b0a00 in object.11 () from /usr/local/libexec/apache/libphp4.so #6 0x2838cb7a in object.11 () from /usr/local/libexec/apache/libphp4.so #7 0x2838cb57 in object.11 () from /usr/local/libexec/apache/libphp4.so #8 0x283c911d in object.11 () from /usr/local/libexec/apache/libphp4.so #9 0x80557e8 in ap_child_exit_modules () #10 0x805a7b1 in clean_child_exit () #11 0x805bba2 in just_die () #12 0xbfbfffac in ?? () #13 0x28091f83 in r_debug_state () from /usr/libexec/ld-elf.so.1 #14 0x28091e1e in r_debug_state () from /usr/libexec/ld-elf.so.1 #15 0x2809021b in find_symdef () from /usr/libexec/ld-elf.so.1 #16 0x2808fa78 in _rtld_bind () from /usr/libexec/ld-elf.so.1 #17 0x2808f461 in _rtld_bind_start () from /usr/libexec/ld-elf.so.1 #18 0x805d3dd in make_child () #19 0x805d64c in perform_idle_server_maintenance () #20 0x805db5d in standalone_main () #21 0x805e0a7 in main () #22 0x804fd0e in _start () which to me suggest that something in the PHP cleanup code is deadlocking. Any help in getting to the bottom of this would be greatly appreciated. If you need any additional information, we will provide it. -- Edit this bug report at http://bugs.php.net/?id=33281&edit=1
#33292 [NEW]: apache_get_modules crashes
From: doug_craig at charter dot net Operating system: Win 2000 5.00.2195 sp4 PHP version: 5CVS-2005-06-10 (dev) PHP Bug Type: Reproducible crash Bug description: apache_get_modules crashes Description: Only modification from php.ini-recommended is to enable MySQL (and changes made by PHP 5.0.4 Installer). PHP installed as an Apache module. Apache/1.3.33 (Win32) Reproduce code: --- Expected result: Array ( [0] => core [1] => http_core [2] => mod_so [3] => sapi_apache2 [4] => mod_mime [5] => mod_rewrite ) Actual result: -- No error report to Apache error.log Windows error: Apache.exe - Application Error for a memory reference that could not be read. -- Edit bug report at http://bugs.php.net/?id=33292&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33292&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33292&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33292&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33292&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33292&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33292&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33292&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33292&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33292&r=support Expected behavior: http://bugs.php.net/fix.php?id=33292&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33292&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33292&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33292&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33292&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33292&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33292&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33292&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33292&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33292&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33292&r=mysqlcfg
#33291 [Opn->WFx]: An addition of consistent function name aliases
ID: 33291 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com -Status: Open +Status: Wont fix Bug Type:Feature/Change Request PHP Version: 5CVS-2005-06-10 (dev) New Comment: As I have said many times, the day strlen() becomes str_len() is the day the lunatics have taken over the asylum. Previous Comments: [2005-06-10 00:05:39] philip at cornado dot com Description: Request: For PHP to add a ton of function aliases that make the naming schemes consistent. Some examples: is_set(), str_pos(), array_key()... -- Edit this bug report at http://bugs.php.net/?id=33291&edit=1
#33291 [NEW]: An addition of consistent function name aliases
From: philip at cornado dot com Operating system: PHP version: 5CVS-2005-06-10 (dev) PHP Bug Type: Feature/Change Request Bug description: An addition of consistent function name aliases Description: Request: For PHP to add a ton of function aliases that make the naming schemes consistent. Some examples: is_set(), str_pos(), array_key()... -- Edit bug report at http://bugs.php.net/?id=33291&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33291&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33291&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33291&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33291&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33291&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33291&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33291&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33291&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33291&r=support Expected behavior: http://bugs.php.net/fix.php?id=33291&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33291&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33291&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33291&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33291&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33291&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33291&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33291&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33291&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33291&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33291&r=mysqlcfg
#33283 [Opn->Fbk]: Apache GPF's when attempting to use PDO
ID: 33283
Updated by: [EMAIL PROTECTED]
Reported By: david dot prusak at copart dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.0.4
New Comment:
If you add:
$stmt = null;
$dbh = null;
to the end of your script, does the segfault go away?
Previous Comments:
[2005-06-09 21:26:39] david dot prusak at copart dot com
Oops sorry about that.
This fails with a gpf:
prepare("SELECT * FROM TABLE");
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
?>
While this works just fine and prints "Connected",
getMessage();
}
?>
When I use exec, I don't get the GPF, but I'm also not getting the
correct results. When trying to query a fake table, I don't get an
error. When I query the correct table, I don't get a count.
When I put in an incorrect database, user or password, I do get the
correct error. So that tells me that I can connect to the database.
";
$count = $dbh->exec("SELECT * FROM FAKETABLE");
print "Count: $count";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
?>
I did verify the php.ini is correct. I put in a typo in the ini file
to see if Apache will err on start up and it did. (brute force method
:) )
Hope that's not too much information.
--David
[2005-06-09 19:39:53] [EMAIL PROTECTED]
Sounds like two different issues, neither of which is PDO specific ;-)
Check that you were modifying the right php.ini file, and that you
restarted apache after changing it. (phpinfo() will help you to figure
that out).
Your script is broken, btw. You catch the exception, effectively
ignoring the error, and then continue to use the $dbh even though you
"know" it isn't there. You should move that code inside the try {}
block, just after you echo "Connected";
The GPF concerns me, but I suspect it will go away once you load PDO
correctly. If you're feeling motivated, can you try pruning down your
script to the smallest possible test case that reproduces the GPF? I'm
hoping you can cut it down to something like this:
getMessage();
}
$foo->bar();
?>
[2005-06-09 19:10:13] david dot prusak at copart dot com
Might want to ingore the gdb information I provided. It's not correct
on the windows system. I more than happy to help debug. Just let me
know what you need and how I can get it to you.
Thanks,
--David
[2005-06-09 17:56:53] david dot prusak at copart dot com
Description:
When attempting to use the PDO class, Apache GPF's.
My PHP.ini reads as follows:
extension_dir = "C:\php\ext"
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Apache/PHP doesn't alert me that the libraries couldn't be loaded.
The code provided is 100% reproducable on my system.
Removing all the code except the database connection doesn't crash.
The code does say that the connection was established.
I'm not 100% sure if it's php or my php.ini file. The backtrace tells
me that the class doesn't exist. That leaves me with a suspicion that
it could be config related.
Reproduce code:
---
true));
echo "Connected\n";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
$email = "[EMAIL PROTECTED]";
$stmt = $dbh->prepare("CALL SPROC(?, ?)");
$stmt->bindParam(1, $email);
$stmt->bindParam(2, $return_value, PDO_PARAM_STR, 80);
$stmt->execute();
print "procedure returned $return_value\n";
?>
Expected result:
Results from the database without error
Actual result:
--
(gdb) target exec C:\php\php.exe
(gdb) run test.php
Starting program: /cygdrive/c/php/php.exe test.php
PHP Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException ()
from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
--
Edit this bug report at http://bugs.php.net/?id=33283&edit=1
#33290 [Opn->Bgs]: __destruct and shutdown functions are not called
ID: 33290
Updated by: [EMAIL PROTECTED]
Reported By: gasper dot kozak at tobonet dot com
-Status: Open
+Status: Bogus
Bug Type: Zend Engine 2 problem
-Operating System: Linux 2.6.10-gentoo-r2+Apache2
+Operating System: *
-PHP Version: 5.0.4
+PHP Version: 5.*
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
It is being called, RTFM.
Previous Comments:
[2005-06-09 23:36:02] gasper dot kozak at tobonet dot com
Description:
The __destruct method of a simple class (not inherited) is not called,
same goes for shutdown function.
URL of the problem: http://www.kje.si/iass/lib/App/test_destruct.php
Works with PHP 5.0.3 + Apache2, running on 2.6.11-gentoo, which is my
other server.
URL of the working script:
http://dev.tobonet.com/kje.si/lib/App/test_destruct.php
The code below is the stored into a file, nothing else is there, no
other files included, nothing.
The configure command is copied from phpinfo:
'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5' '--without-pear'
'--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-cpdflib'
'--disable-ctype' '--with-curl' '--with-curlwrappers' '--disable-dbase'
'--enable-dio' '--disable-exif' '--without-fam' '--without-fbsql'
'--without-fdftk' '--disable-filepro' '--enable-ftp' '--with-gettext'
'--without-gmp' '--without-hwapi' '--without-iconv'
'--without-informix' '--without-ingres' '--without-interbase'
'--without-kerberos' '--enable-mbstring' '--with-mcrypt'
'--without-mcve' '--disable-memory-limit' '--without-mhash'
'--without-mime-magic' '--without-ming' '--without-mnogosearch'
'--without-msql' '--without-mssql' '--with-ncurses' '--without-oci8'
'--without-oracle' '--with-openssl' '--with-openssl-dir=/usr'
'--without-ovrimos' '--disable-pcntl' '--without-pcre-regx'
'--without-pfpro' '--with-pgsql' '--with-pspell' '--without-recode'
'--enable-shmop' '--without-snmp' '--enable-soap' '--enable-sockets'
'--without-sybase' '--without-sybase-ct' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--disable-wddx'
'--without-xsl' '--without-xmlrpc' '--disable-yp' '--with-zlib'
'--disable-debug' '--without-cdb' '--with-db4' '--without-dbm'
'--with-flatfile' '--with-gdbm' '--with-inifile' '--without-qdbm'
'--with-jpeg-dir=/usr' '--with-freetype-dir=/usr' '--with-t1lib=/usr'
'--with-ttf=/usr' '--enable-gd-jis-conf' '--enable-gd-native-ttf'
'--with-png-dir=/usr' '--with-tiff-dir=/usr' '--without-xpm-dir'
'--with-gd' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--without-ldap-sasl' '--with-unixODBC' '--without-adabas'
'--without-birdstep' '--without-dbmaker' '--without-empress'
'--without-esoob' '--without-ibm-db2' '--without-iodbc'
'--without-sapdb' '--without-solid' '--with-mysqli' '--with-mm'
'--without-msession' '--without-sqlite' '--enable-dba'
'--with-readline' '--without-libedit' '--enable-versioning'
Reproduce code:
---
name = "MyDestructableClass";
}
function __destruct()
{
print "Destroying " . $this->name . "\n";
}
}
// create a class
$obj = new MyDestructableClass();
?>
Expected result:
Text output:
In constructor
OnShutdown function called.
Destroying MyDestructableClass
Actual result:
--
Text output:
In constructor
--
Edit this bug report at http://bugs.php.net/?id=33290&edit=1
#33290 [NEW]: __destruct and shutdown functions are not called
From: gasper dot kozak at tobonet dot com
Operating system: Linux 2.6.10-gentoo-r2+Apache2
PHP version: 5.0.4
PHP Bug Type: Zend Engine 2 problem
Bug description: __destruct and shutdown functions are not called
Description:
The __destruct method of a simple class (not inherited) is not called,
same goes for shutdown function.
URL of the problem: http://www.kje.si/iass/lib/App/test_destruct.php
Works with PHP 5.0.3 + Apache2, running on 2.6.11-gentoo, which is my
other server.
URL of the working script:
http://dev.tobonet.com/kje.si/lib/App/test_destruct.php
The code below is the stored into a file, nothing else is there, no other
files included, nothing.
The configure command is copied from phpinfo:
'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5' '--without-pear'
'--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-cpdflib'
'--disable-ctype' '--with-curl' '--with-curlwrappers' '--disable-dbase'
'--enable-dio' '--disable-exif' '--without-fam' '--without-fbsql'
'--without-fdftk' '--disable-filepro' '--enable-ftp' '--with-gettext'
'--without-gmp' '--without-hwapi' '--without-iconv' '--without-informix'
'--without-ingres' '--without-interbase' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mcve'
'--disable-memory-limit' '--without-mhash' '--without-mime-magic'
'--without-ming' '--without-mnogosearch' '--without-msql'
'--without-mssql' '--with-ncurses' '--without-oci8' '--without-oracle'
'--with-openssl' '--with-openssl-dir=/usr' '--without-ovrimos'
'--disable-pcntl' '--without-pcre-regx' '--without-pfpro' '--with-pgsql'
'--with-pspell' '--without-recode' '--enable-shmop' '--without-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--enable-sysvmsg' '--enable-sysvsem'
'--enable-sysvshm' '--with-tidy' '--disable-wddx' '--without-xsl'
'--without-xmlrpc' '--disable-yp' '--with-zlib' '--disable-debug'
'--without-cdb' '--with-db4' '--without-dbm' '--with-flatfile'
'--with-gdbm' '--with-inifile' '--without-qdbm' '--with-jpeg-dir=/usr'
'--with-freetype-dir=/usr' '--with-t1lib=/usr' '--with-ttf=/usr'
'--enable-gd-jis-conf' '--enable-gd-native-ttf' '--with-png-dir=/usr'
'--with-tiff-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-imap'
'--with-imap-ssl' '--with-ldap' '--without-ldap-sasl' '--with-unixODBC'
'--without-adabas' '--without-birdstep' '--without-dbmaker'
'--without-empress' '--without-esoob' '--without-ibm-db2'
'--without-iodbc' '--without-sapdb' '--without-solid' '--with-mysqli'
'--with-mm' '--without-msession' '--without-sqlite' '--enable-dba'
'--with-readline' '--without-libedit' '--enable-versioning'
Reproduce code:
---
name = "MyDestructableClass";
}
function __destruct()
{
print "Destroying " . $this->name . "\n";
}
}
// create a class
$obj = new MyDestructableClass();
?>
Expected result:
Text output:
In constructor
OnShutdown function called.
Destroying MyDestructableClass
Actual result:
--
Text output:
In constructor
--
Edit bug report at http://bugs.php.net/?id=33290&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33290&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33290&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33290&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33290&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33290&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33290&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33290&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33290&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33290&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33290&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33290&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33290&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33290&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33290&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33290&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33290&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33290&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33290&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33290&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33290&r=mysqlcfg
#33289 [NEW]: short_open_tag behaviour suggestion
From: shurikk at mail dot ru
Operating system: any
PHP version: 4.3.11
PHP Bug Type: Feature/Change Request
Bug description: short_open_tag behaviour suggestion
Description:
just a suggestion for short_open_tag
When it's ON, can parser ignore everything that is not "
file data.php
$value = 5;
include('data.xml'); // error
Expected result:
xml output with xml header
Actual result:
--
parser error
--
Edit bug report at http://bugs.php.net/?id=33289&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33289&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33289&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33289&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33289&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33289&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33289&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33289&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33289&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33289&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33289&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33289&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33289&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33289&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33289&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33289&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33289&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33289&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33289&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33289&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33289&r=mysqlcfg
#33288 [Bgs]: strtotime() error on dates ranging from 2006-05-01 to 2006-05-31 with Swedish.
ID: 33288
User updated by: henke at mac dot se
Reported By: henke at mac dot se
Status: Bogus
Bug Type: Date/time related
Operating System: Win 2003 Server
PHP Version: 5.0.4
New Comment:
Yepp I realized that. The darn dates are outputted from MSSQL
DB and it work when using PHP 4.3 but when they upgraded to
Win 2003 and PHP 5.04 I guess the ouput changed from 24 May to
24 Maj when retrieving from db.
I'm going to bark up another tree now!
Previous Comments:
[2005-06-09 23:09:01] [EMAIL PROTECTED]
strtotime doesn't care about locales, and it won't work. Using the
english name works fine here:
1148421600
[2005-06-09 22:55:17] henke at mac dot se
Only effects Swedish dates. i.e. '24 Maj 2006'
[2005-06-09 22:45:07] henke at mac dot se
Description:
Using strtotime() funktion on dates between 2006-05-01 to
2006-05-30 always returns -1.
This issue only affects May dates in 2006 which is weird.
Reproduce code:
---
strtotime('24 May 2006 0:00');
Tested only with swedish localisation so you could try
setlocale(LC_TIME,'swedish');
strtotime('24 Maj 2006 0:00');
Expected result:
A unix timestamp
Actual result:
--
-1
--
Edit this bug report at http://bugs.php.net/?id=33288&edit=1
#33288 [Opn->Bgs]: strtotime() error on dates ranging from 2006-05-01 to 2006-05-31 with Swedish.
ID: 33288
Updated by: [EMAIL PROTECTED]
Reported By: henke at mac dot se
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Win 2003 Server
PHP Version: 5.0.4
New Comment:
strtotime doesn't care about locales, and it won't work. Using the
english name works fine here:
1148421600
Previous Comments:
[2005-06-09 22:55:17] henke at mac dot se
Only effects Swedish dates. i.e. '24 Maj 2006'
[2005-06-09 22:45:07] henke at mac dot se
Description:
Using strtotime() funktion on dates between 2006-05-01 to
2006-05-30 always returns -1.
This issue only affects May dates in 2006 which is weird.
Reproduce code:
---
strtotime('24 May 2006 0:00');
Tested only with swedish localisation so you could try
setlocale(LC_TIME,'swedish');
strtotime('24 Maj 2006 0:00');
Expected result:
A unix timestamp
Actual result:
--
-1
--
Edit this bug report at http://bugs.php.net/?id=33288&edit=1
#33288 [Opn]: strtotime() error on dates ranging from 2006-05-01 to 2006-05-31 with Swedish.
ID: 33288
User updated by: henke at mac dot se
-Summary: strtotime() error on dates ranging from 2006-05-01 to
2006-05-31
Reported By: henke at mac dot se
Status: Open
Bug Type: Date/time related
Operating System: Win 2003 Server
PHP Version: 5.0.4
New Comment:
Only effects Swedish dates. i.e. '24 Maj 2006'
Previous Comments:
[2005-06-09 22:45:07] henke at mac dot se
Description:
Using strtotime() funktion on dates between 2006-05-01 to
2006-05-30 always returns -1.
This issue only affects May dates in 2006 which is weird.
Reproduce code:
---
strtotime('24 May 2006 0:00');
Tested only with swedish localisation so you could try
setlocale(LC_TIME,'swedish');
strtotime('24 Maj 2006 0:00');
Expected result:
A unix timestamp
Actual result:
--
-1
--
Edit this bug report at http://bugs.php.net/?id=33288&edit=1
#33288 [NEW]: strtotime() error on dates ranging from 2006-05-01 to 2006-05-31
From: henke at mac dot se
Operating system: Win 2003 Server
PHP version: 5.0.4
PHP Bug Type: Date/time related
Bug description: strtotime() error on dates ranging from 2006-05-01 to
2006-05-31
Description:
Using strtotime() funktion on dates between 2006-05-01 to
2006-05-30 always returns -1.
This issue only affects May dates in 2006 which is weird.
Reproduce code:
---
strtotime('24 May 2006 0:00');
Tested only with swedish localisation so you could try
setlocale(LC_TIME,'swedish');
strtotime('24 Maj 2006 0:00');
Expected result:
A unix timestamp
Actual result:
--
-1
--
Edit bug report at http://bugs.php.net/?id=33288&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33288&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33288&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33288&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33288&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33288&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33288&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33288&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33288&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33288&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33288&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33288&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33288&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33288&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33288&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33288&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33288&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33288&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33288&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33288&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33288&r=mysqlcfg
#33281 [Opn]: Possible deadlock in PHP-cleanup under heavy load
ID: 33281 User updated by: jimmy dot makela at loopia dot se Reported By: jimmy dot makela at loopia dot se Status: Open Bug Type: Apache related Operating System: FreeBSD 4.9-RELEASE-p10 PHP Version: 4.3.11 New Comment: Regarding your questions: 1. I don't know, I was hoping for a suggestion to that part. The library have not been stripped manually, and doesn't seem to be stripped. A recompile could be done if that would help, just specify what to change. # file /usr/local/libexec/apache/libphp4.so /usr/local/libexec/apache/libphp4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped objdump -T does show symbols, but I have no idea of what object.11 maps to. I can provide a complete list of the dynamic symbol table if that helps. 2. A list of the loaded extensions follows: php4-bcmath-4.3.11_1 php4-calendar-4.3.11_1 php4-ctype-4.3.11_1 php4-curl-4.3.11_1 php4-domxml-4.3.11_1 php4-exif-4.3.11_1 php4-extensions-1.0 php4-ftp-4.3.11_1 php4-gd-4.3.11_1 php4-gettext-4.3.11_1 php4-iconv-4.3.11_1 php4-imap-4.3.11_1 php4-mcrypt-4.3.11_1 php4-mysql-4.3.11_1 php4-overload-4.3.11_1 php4-pcre-4.3.11_1 php4-posix-4.3.11_1 php4-session-4.3.11_1 php4-tokenizer-4.3.11_1 php4-xml-4.3.11_1 php4-zlib-4.3.11_1 Let me know if you need additional information. Previous Comments: [2005-06-09 16:45:55] [EMAIL PROTECTED] A couple of questions. 1. Why is gdb just reporting object.11 instead of a real symbol? Have the symbols been stripped from your libphp4.so? Could you recompile and put them back to get a better backtrace? 2. Do you have any custom extensions loaded? And if you do, are they in C++? The FreeBSD4 rtld has notoriously bad support for C++ shared libraries. [2005-06-09 09:49:42] jimmy dot makela at loopia dot se Description: Periodically on one of our webservers one apache-process starts using up all CPU until it is killed. A ktrace of the process gives the output: 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 ad infinitum. When attaching to the process with GDB and doing a backtrace, we get the following update: #0 0x28092648 in symlook_obj () from /usr/libexec/ld-elf.so.1 #1 0x28091032 in dlclose () from /usr/libexec/ld-elf.so.1 #2 0x283b3251 in object.11 () from /usr/local/libexec/apache/libphp4.so #3 0x283b4bfc in object.11 () from /usr/local/libexec/apache/libphp4.so #4 0x283b4d3a in object.11 () from /usr/local/libexec/apache/libphp4.so #5 0x283b0a00 in object.11 () from /usr/local/libexec/apache/libphp4.so #6 0x2838cb7a in object.11 () from /usr/local/libexec/apache/libphp4.so #7 0x2838cb57 in object.11 () from /usr/local/libexec/apache/libphp4.so #8 0x283c911d in object.11 () from /usr/local/libexec/apache/libphp4.so #9 0x80557e8 in ap_child_exit_modules () #10 0x805a7b1 in clean_child_exit () #11 0x805bba2 in just_die () #12 0xbfbfffac in ?? () #13 0x28091f83 in r_debug_state () from /usr/libexec/ld-elf.so.1 #14 0x28091e1e in r_debug_state () from /usr/libexec/ld-elf.so.1 #15 0x2809021b in find_symdef () from /usr/libexec/ld-elf.so.1 #16 0x2808fa78 in _rtld_bind () from /usr/libexec/ld-elf.so.1 #17 0x2808f461 in _rtld_bind_start () from /usr/libexec/ld-elf.so.1 #18 0x805d3dd in make_child () #19 0x805d64c in perform_idle_server_maintenance () #20 0x805db5d in standalone_main () #21 0x805e0a7 in main () #22 0x804fd0e in _start () which to me suggest that something in the PHP cleanup code is deadlocking. Any help in getting to the bottom of this would be greatly appreciated. If you need any additional information, we will provide it. -- Edit this bug report at http://bugs.php.net/?id=33281&edit=1
#33287 [NEW]: foreach does not give errors
From: chris at deskpro dot com
Operating system: Win/MacOS linux untested
PHP version: 4.3.11
PHP Bug Type: Arrays related
Bug description: foreach does not give errors
Description:
This is a repost of 33264
33264 was closed because it was said the bug is the same
as 31114. They are however completly different.
31114 is about foreach where the $key and $value are the
same:
foreach ($array AS $key => $key)
which should, perhaps issue a warning.
However, 33264 is about foreach not issuing an error
when you try and loop on an unset variable or a string
e.g.:
$array = '';
foreach ($array AS $value) {
this should, and used to issue an error (I think it was
fatal). It not longer does.
The manual even suggests this error is not preventable
with a @, but not it dosen't appear at all.
So this is both a real bug and important.
Reproduce code:
---
Expected result:
Error about $a not being an array.
Actual result:
--
No error.
--
Edit bug report at http://bugs.php.net/?id=33287&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33287&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33287&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33287&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33287&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33287&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33287&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33287&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33287&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33287&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33287&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33287&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33287&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33287&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33287&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33287&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33287&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33287&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33287&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33287&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33287&r=mysqlcfg
#33283 [Fbk->Opn]: Apache GPF's when attempting to use PDO
ID: 33283
User updated by: david dot prusak at copart dot com
Reported By: david dot prusak at copart dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.0.4
New Comment:
Oops sorry about that.
This fails with a gpf:
prepare("SELECT * FROM TABLE");
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
?>
While this works just fine and prints "Connected",
getMessage();
}
?>
When I use exec, I don't get the GPF, but I'm also not getting the
correct results. When trying to query a fake table, I don't get an
error. When I query the correct table, I don't get a count.
When I put in an incorrect database, user or password, I do get the
correct error. So that tells me that I can connect to the database.
";
$count = $dbh->exec("SELECT * FROM FAKETABLE");
print "Count: $count";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
?>
I did verify the php.ini is correct. I put in a typo in the ini file
to see if Apache will err on start up and it did. (brute force method
:) )
Hope that's not too much information.
--David
Previous Comments:
[2005-06-09 19:39:53] [EMAIL PROTECTED]
Sounds like two different issues, neither of which is PDO specific ;-)
Check that you were modifying the right php.ini file, and that you
restarted apache after changing it. (phpinfo() will help you to figure
that out).
Your script is broken, btw. You catch the exception, effectively
ignoring the error, and then continue to use the $dbh even though you
"know" it isn't there. You should move that code inside the try {}
block, just after you echo "Connected";
The GPF concerns me, but I suspect it will go away once you load PDO
correctly. If you're feeling motivated, can you try pruning down your
script to the smallest possible test case that reproduces the GPF? I'm
hoping you can cut it down to something like this:
getMessage();
}
$foo->bar();
?>
[2005-06-09 19:10:13] david dot prusak at copart dot com
Might want to ingore the gdb information I provided. It's not correct
on the windows system. I more than happy to help debug. Just let me
know what you need and how I can get it to you.
Thanks,
--David
[2005-06-09 17:56:53] david dot prusak at copart dot com
Description:
When attempting to use the PDO class, Apache GPF's.
My PHP.ini reads as follows:
extension_dir = "C:\php\ext"
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Apache/PHP doesn't alert me that the libraries couldn't be loaded.
The code provided is 100% reproducable on my system.
Removing all the code except the database connection doesn't crash.
The code does say that the connection was established.
I'm not 100% sure if it's php or my php.ini file. The backtrace tells
me that the class doesn't exist. That leaves me with a suspicion that
it could be config related.
Reproduce code:
---
true));
echo "Connected\n";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
$email = "[EMAIL PROTECTED]";
$stmt = $dbh->prepare("CALL SPROC(?, ?)");
$stmt->bindParam(1, $email);
$stmt->bindParam(2, $return_value, PDO_PARAM_STR, 80);
$stmt->execute();
print "procedure returned $return_value\n";
?>
Expected result:
Results from the database without error
Actual result:
--
(gdb) target exec C:\php\php.exe
(gdb) run test.php
Starting program: /cygdrive/c/php/php.exe test.php
PHP Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException ()
from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
--
Edit this bug report at http://bugs.php.net/?id=33283&edit=1
#31725 [Fbk->Csd]: sqlite/zend engine 2 weird problems
ID: 31725 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-21 Assigned To: wez New Comment: I've tried the scripts pasted above and a couple of combinations and all the problems seem to be fixed. Now I'm getting a mem leak in the sqlite lib itself. Thanks, Nuno Previous Comments: [2005-06-07 18:12:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-06-07 17:42:48] [EMAIL PROTECTED] Probably this bug should be fixed in CVS HEAD and PHP_5_0 with the following patch: http://cvs.php.net/diff.php/php-src/ext/sqlite/sqlite.c?r1=1.146.2.6&r2=1.146.2.7&ty=u [2005-04-26 23:12:09] [EMAIL PROTECTED] Sorry, valgrind took a while to finish. The output: http://mega.ist.utl.pt/~ncpl/valgrind-php.txt [2005-04-26 20:26:06] [EMAIL PROTECTED] valgrind... [2005-04-26 20:02:44] [EMAIL PROTECTED] Well, I've already posted 2 examples with backtraces above. I've run the ini-update.php script (available in the above URL) and I got this: #0 0x4046dd67 in mallopt () from /lib/libc.so.6 #1 0x4046db5e in mallopt () from /lib/libc.so.6 #2 0x4046c908 in free () from /lib/libc.so.6 #3 0x081ea0e7 in shutdown_memory_manager (silent=0, full_shutdown=0) at /cvs/php-src/Zend/zend_alloc.c:511 #4 0x081c9821 in php_request_shutdown (dummy=0x0) at /cvs/php-src/main/main.c:1228 #5 0x082633df in main (argc=2, argv=0xb944) at /cvs/php-src/sapi/cli/php_cli.c:1057 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/31725 -- Edit this bug report at http://bugs.php.net/?id=31725&edit=1
#33286 [NEW]: nested array_walk function broken
From: pumuckel at metropolis dot de
Operating system: Linux
PHP version: 5.0.4
PHP Bug Type: Arrays related
Bug description: nested array_walk function broken
Description:
Nested array_walk calls don't work.
Reason: BG(array_walk_fci_cache) will not get re-initialized after inner
array_walk call.
Following patch will help - better solution would be a local
array_walk_fci_cache var inside the php_walk_array function:
diff -u php-5.0.4/ext/standard/array.c
php-5.0.4.patched/ext/standard/array.c
--- php-5.0.4/ext/standard/array.c 2005-03-12 11:12:49.0
+0100
+++ php-5.0.4.patched/ext/standard/array.c 2005-06-09
19:31:43.0 +0200
@@ -1079,6 +1079,8 @@
}
zend_hash_move_forward_ex(target_hash, &pos);
}
+
+BG(array_walk_fci_cache) = empty_fcall_info_cache;
return 0;
}
Reproduce code:
---
";
}
function test_func($item2, $key)
{
echo "test_func";
$arr = array(1, 2, 3, 4);
array_walk($arr, 'test_subfunc', 'extra_arg');
}
$x = array(5,6,7);
array_walk($x, 'test_func');
?>
Expected result:
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
Actual result:
--
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
Warning: Missing argument 3 for test_subfunc() in foo.php on line 3
test_subfunc
test_subfunc
--
Edit bug report at http://bugs.php.net/?id=33286&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33286&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33286&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33286&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33286&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33286&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33286&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33286&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33286&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33286&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33286&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33286&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33286&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33286&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33286&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33286&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33286&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33286&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33286&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33286&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33286&r=mysqlcfg
#33283 [Opn->Fbk]: Apache GPF's when attempting to use PDO
ID: 33283
Updated by: [EMAIL PROTECTED]
Reported By: david dot prusak at copart dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.0.4
New Comment:
Sounds like two different issues, neither of which is PDO specific ;-)
Check that you were modifying the right php.ini file, and that you
restarted apache after changing it. (phpinfo() will help you to figure
that out).
Your script is broken, btw. You catch the exception, effectively
ignoring the error, and then continue to use the $dbh even though you
"know" it isn't there. You should move that code inside the try {}
block, just after you echo "Connected";
The GPF concerns me, but I suspect it will go away once you load PDO
correctly. If you're feeling motivated, can you try pruning down your
script to the smallest possible test case that reproduces the GPF? I'm
hoping you can cut it down to something like this:
getMessage();
}
$foo->bar();
?>
Previous Comments:
[2005-06-09 19:10:13] david dot prusak at copart dot com
Might want to ingore the gdb information I provided. It's not correct
on the windows system. I more than happy to help debug. Just let me
know what you need and how I can get it to you.
Thanks,
--David
[2005-06-09 17:56:53] david dot prusak at copart dot com
Description:
When attempting to use the PDO class, Apache GPF's.
My PHP.ini reads as follows:
extension_dir = "C:\php\ext"
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Apache/PHP doesn't alert me that the libraries couldn't be loaded.
The code provided is 100% reproducable on my system.
Removing all the code except the database connection doesn't crash.
The code does say that the connection was established.
I'm not 100% sure if it's php or my php.ini file. The backtrace tells
me that the class doesn't exist. That leaves me with a suspicion that
it could be config related.
Reproduce code:
---
true));
echo "Connected\n";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
$email = "[EMAIL PROTECTED]";
$stmt = $dbh->prepare("CALL SPROC(?, ?)");
$stmt->bindParam(1, $email);
$stmt->bindParam(2, $return_value, PDO_PARAM_STR, 80);
$stmt->execute();
print "procedure returned $return_value\n";
?>
Expected result:
Results from the database without error
Actual result:
--
(gdb) target exec C:\php\php.exe
(gdb) run test.php
Starting program: /cygdrive/c/php/php.exe test.php
PHP Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException ()
from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
--
Edit this bug report at http://bugs.php.net/?id=33283&edit=1
#29689 [Asn->Csd]: default value of protected member overrides default value of private
ID: 29689
Updated by: [EMAIL PROTECTED]
Reported By: php dot net at benjamin dot schulz dot name
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-19
Assigned To: andi
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
fixed it
Previous Comments:
[2005-05-17 16:10:19] [EMAIL PROTECTED]
No, I think it should output foo, baz, baz. Private property is to
behave for external functions as if it did not exist at all. However,
protected property is shared by the whole inheritance chain, so
redefining it means redefining it everywhere.
[2005-04-19 16:19:11] [EMAIL PROTECTED]
foo, "\n";
}
}
class bar extends foo {
protected $foo = 'bar';
function printFoo2()
{
echo __CLASS__, ': ', $this->foo, "\n";
}
}
class baz extends bar {
protected $foo = 'baz';
function printFoo3()
{
echo __CLASS__, ': ', $this->foo, "\n";
}
}
$bar = new baz;
$bar->printFoo1();
$bar->printFoo2();
$bar->printFoo3();
?>
Outputs:
foo: baz
bar: baz
baz: baz
When it should output:
foo: foo
bar: bar
baz: baz
Right?
[2004-08-31 19:00:41] php dot net at benjamin dot schulz dot name
you don't get the point, the problem is that baz's protected $foo
overrides foo's private $foo, that should not happen
using parent::foo() is a common technique, and there is a $this because
it get's the context of the calling point
[2004-08-31 18:32:35] [EMAIL PROTECTED]
Please, be more verbose next time if you want to get any help. Your
conciseness doesn't help very much.
The problem is that you're trying to access class members through $this
variable using static methods. As you can understand in this case there
is no $this and behavior seems to be undefined (shouldn't there be an
error, btw?).
[2004-08-31 17:48:56] php dot net at benjamin dot schulz dot name
yep tony, you're right, and now read the bug 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/29689
--
Edit this bug report at http://bugs.php.net/?id=29689&edit=1
#29860 [Com]: Cannot compile with mysql and mysqli extensions
ID: 29860 Comment by: michael at mompopmedia dot com Reported By: rjanson at msn dot com Status: No Feedback Bug Type: Compile Failure Operating System: Redhat 9 PHP Version: 5.0.1 New Comment: For what it is worth, I can confirm the same issue building php5.0.4 on RHE 3. MySQL packages as follows: MySQL-client-4.1.11-0 MySQL-shared-compat-4.1.11-0 MySQL-embedded-4.1.11-0 MySQL-bench-4.1.11-0 MySQL-shared-4.1.11-0 perl-DBD-MySQL-2.1021-3 MySQL-devel-4.1.11-0 MySQL-server-4.1.11-0 I'm also running Apache/1.3.33 chris at leftbrained dot org suggestion did the trick. Previous Comments: [2005-05-09 18:48:49] jorge dot tiao dot pereira at gmail dot com so do i. i don´t connect mysql database to the pega in php. how do it? [2005-02-19 19:32:23] chris at leftbrained dot org I know this hasn't been looked at in some time, but I've spent that last few days working out this exact problem. Apache 2.0.53 - Built by me into /usr/local/apache MySQL 4.1.9 - Used the RPM download of of mysql.com >MySQL-client-4.1.9-0 >MySQL-shared-compat-4.1.9-0 >MySQL-server-4.1.9-0 >MySQL-bench-4.1.9-0 >MySQL-devel-4.1.9-0 PHP 5.0.3 - ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config I'm on some form of RedHat Enterprise, I'm not quite sure how I would check which one. I was coming up witht he same exact errors, and the *only* way I was able to make it work was this: cd /usr/lib/mysql rename .a .a_old *.a rename .la .la_old *.la Then run configure/make/make install Then rename these files back. cd /usr/lib/mysql rename .a_old .a *.a_old rename .la_old .la *.la_old I'm not sure what precisely these files are, and this was a last resort attempt for me, but it worked. Chris [2004-10-28 21:49:01] kpederson at mail dot ewu dot edu I can confirm a few things. I have both the static and the shared libraries installed as they both come in the standard mysql-devel rpm: /usr/lib/libmysqlclient.so /usr/lib/libmysqlclient.so.14 /usr/lib/mysql /usr/lib/mysql/libmysqlclient.a /usr/lib/mysql/libmysqlclient_r.la /usr/lib/mysql/libmysqld.a /usr/lib/mysql/libmysqlclient_r.a /usr/lib/mysql/mysqld.sym /usr/lib/mysql/libmysqlclient.la /usr/lib/libmysqlclient.so.14.0.0 /usr/lib/libmysqlclient_r.so /usr/lib/libmysqlclient_r.so.14 /usr/lib/libmysqlclient_r.so.14.0.0 If the static libraries are found, then the make dies with linking problems. I temporarily did a 'rename .a .a_old *.a' and 'rename .la .la_old *.la' in my /usr/lib/mysql directory, and then was able to make everything successfully. The output of ./configure ... | grep -i mysql gives: checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... /var/run/mysql/mysql.sock checking for MySQL UNIX socket location... /var/run/mysql/mysql.sock checking for mysql_close in -lmysqlclient... (cached) yes checking for MySQLi support... yes checking whether to enable embedded MySQLi support... no checking for mysql_set_server_option in -lmysqlclient... (cached) yes checking for mysql_stmt_field_count in -lmysqlclient... (cached) yes BTW, I'm running Redhat Enterprise AS using PHP-5.0.2 and MySQL-4.1.7 (stable). [2004-10-14 01:00:05] 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". [2004-10-07 12:52:08] stormchaser1 at gmail dot com forgot to mention it's the MySQL 5.0.1-alpha installed from rpms from mysql.com 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/29860 -- Edit this bug report at http://bugs.php.net/?id=29860&edit=1
#33283 [Opn]: Apache GPF's when attempting to use PDO
ID: 33283
User updated by: david dot prusak at copart dot com
Reported By: david dot prusak at copart dot com
Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.0.4
New Comment:
Might want to ingore the gdb information I provided. It's not correct
on the windows system. I more than happy to help debug. Just let me
know what you need and how I can get it to you.
Thanks,
--David
Previous Comments:
[2005-06-09 17:56:53] david dot prusak at copart dot com
Description:
When attempting to use the PDO class, Apache GPF's.
My PHP.ini reads as follows:
extension_dir = "C:\php\ext"
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Apache/PHP doesn't alert me that the libraries couldn't be loaded.
The code provided is 100% reproducable on my system.
Removing all the code except the database connection doesn't crash.
The code does say that the connection was established.
I'm not 100% sure if it's php or my php.ini file. The backtrace tells
me that the class doesn't exist. That leaves me with a suspicion that
it could be config related.
Reproduce code:
---
true));
echo "Connected\n";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
$email = "[EMAIL PROTECTED]";
$stmt = $dbh->prepare("CALL SPROC(?, ?)");
$stmt->bindParam(1, $email);
$stmt->bindParam(2, $return_value, PDO_PARAM_STR, 80);
$stmt->execute();
print "procedure returned $return_value\n";
?>
Expected result:
Results from the database without error
Actual result:
--
(gdb) target exec C:\php\php.exe
(gdb) run test.php
Starting program: /cygdrive/c/php/php.exe test.php
PHP Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My
Documents\htdocs_80\pages\project_manager\test.php on line 17
Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException ()
from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
--
Edit this bug report at http://bugs.php.net/?id=33283&edit=1
#33285 [NEW]: dbase functions return garabe on certain file
From: andrewz at springsrescuemission dot org
Operating system: Linux 2.4.30 (Trustix 2.2)
PHP version: 5.0.4
PHP Bug Type: dBase related
Bug description: dbase functions return garabe on certain file
Description:
Using PHP's dbase system cannot understand some columns and yields garbage
on a certain .dbf file (http://65.108.181.103/zip.dbf).
The .dbf was tested successfully with several other programs
(OpenOffice.org 1.1.4 and Shapefile Library C).
According to file, .dbf is dbase 3 format:
$ file zip.dbf
zip.dbf: DBase 3 data file (586 records)
To enable dbase support, I used the standard Trustix 2.2 source RPM and
included "--enable-dbase".
On a different system with PHP 4.3.10 and Linux 2.4.27 (Redhat 7.3), I
verified the problem with dbase_get_record_with_names(). (The function
dbase_get_header_info() was not available on this platform.)
Reproduce code:
---
$db = dbase_open("zip.dbf",0);
print_r(dbase_get_header_info($db));
if ($db) {
$record_numbers = dbase_numrecords($db);
for ($i = 1; $i <= $record_numbers; $i++) {
$row = dbase_get_record_with_names($db, $i);
print_r($row);
}
}
Expected result:
The dbase_header_info() does not understand some columns and includes
garbage (e.g. length field). Then the dbase_get_record_with_names() has
incorrect data.
Here is output of Shapefile Library C's dbfdump -h on the same zip.dbf.
This output is good.
Field 0: Type=Double, Title=`AREA', Width=20, Decimals=5
Field 1: Type=Double, Title=`PERIMETER', Width=20, Decimals=5
Field 2: Type=Integer, Title=`ZT08_D00_', Width=11, Decimals=0
Field 3: Type=Integer, Title=`ZT08_D00_I', Width=11, Decimals=0
Field 4: Type=String, Title=`ZCTA', Width=5, Decimals=0
Field 5: Type=String, Title=`NAME', Width=90, Decimals=0
Field 6: Type=String, Title=`LSAD', Width=2, Decimals=0
Field 7: Type=String, Title=`LSAD_TRANS', Width=50, Decimals=0
AREAPERIMETER ZT08_D00_ ZT08_D00_I ZCTA
NAME
LSAD LSAD_TRANS
0.05115 1.30727 2 1 80428
80428
Z5 5-Digit ZCTA
Actual result:
--
SCRIPT OUTPUT
Array
(
[0] => Array
(
[name] => AREA
[type] => unknown
[length] => 1300
[precision] => 0
[format] => ´ "@
[offset] => 1
)
[1] => Array
(
[name] => PERIMETER
[type] => unknown
[length] => 1300
[precision] => 0
[format] => ´ "@
[offset] => 1301
)
[truncated]
--
Edit bug report at http://bugs.php.net/?id=33285&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33285&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33285&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33285&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33285&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33285&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33285&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33285&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33285&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33285&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33285&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33285&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33285&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33285&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33285&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33285&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33285&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33285&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33285&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33285&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33285&r=mysqlcfg
#33284 [NEW]: CGI Error with mssqlselect
From: peter dot bernholt at hec dot de
Operating system: Windows XP
PHP version: 4.3.11
PHP Bug Type: CGI related
Bug description: CGI Error with mssqlselect
Description:
Hi all,
I am using PHP with IIS ,Windows XP and SQL Server 2000. The Function
mssql_query causes an error, when there is an result of an
Select-Statement (not true or false). Update, insert and delete works
fine. A select with an empty table is ok, true ("true").
I am not using the "header"-function!
Regards, Peter
Reproduce code:
---
$connection=mssql_connect($server,$username,$password);
@mssql_select_db($database,$connection) or die( "Unable to select
database");
$sqlquery="Select * FROM Tablename";
$result= mssql_query($sqlquery);
Expected result:
The Table contains one row, i would expect to get the result in $result.
Actual result:
--
The specified CGI application misbehaved by not returning a complete set
of HTTP headers. The headers it did return are:
--
Edit bug report at http://bugs.php.net/?id=33284&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33284&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33284&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33284&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33284&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33284&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33284&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33284&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33284&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33284&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33284&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33284&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33284&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33284&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33284&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33284&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33284&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33284&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33284&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33284&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33284&r=mysqlcfg
#33283 [NEW]: Apache GPF's when attempting to use PDO
From: david dot prusak at copart dot com
Operating system: Windows XP
PHP version: 5.0.4
PHP Bug Type: PDO related
Bug description: Apache GPF's when attempting to use PDO
Description:
When attempting to use the PDO class, Apache GPF's.
My PHP.ini reads as follows:
extension_dir = "C:\php\ext"
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Apache/PHP doesn't alert me that the libraries couldn't be loaded.
The code provided is 100% reproducable on my system.
Removing all the code except the database connection doesn't crash. The
code does say that the connection was established.
I'm not 100% sure if it's php or my php.ini file. The backtrace tells me
that the class doesn't exist. That leaves me with a suspicion that it
could be config related.
Reproduce code:
---
true));
echo "Connected\n";
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
$email = "[EMAIL PROTECTED]";
$stmt = $dbh->prepare("CALL SPROC(?, ?)");
$stmt->bindParam(1, $email);
$stmt->bindParam(2, $return_value, PDO_PARAM_STR, 80);
$stmt->execute();
print "procedure returned $return_value\n";
?>
Expected result:
Results from the database without error
Actual result:
--
(gdb) target exec C:\php\php.exe
(gdb) run test.php
Starting program: /cygdrive/c/php/php.exe test.php
PHP Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My Documents\htdocs_80\pages\project_manager\test.php
on line 17
Fatal error: Class 'PDO' not found in c:\Documents and
Settings\dmprusak1\My Documents\htdocs_80\pages\project_manager\test.php
on line 17
Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException ()
from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
--
Edit bug report at http://bugs.php.net/?id=33283&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33283&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33283&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33283&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33283&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33283&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33283&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33283&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33283&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33283&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33283&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33283&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33283&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33283&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33283&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33283&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33283&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33283&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33283&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33283&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33283&r=mysqlcfg
#31326 [Com]: Object Destruction Order
ID: 31326
Comment by: ebenblues at yahoo dot com
Reported By: sir dot gallahad at gmail dot com
Status: No Feedback
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5.0.2
New Comment:
I believe this is a bug in PHP's garbage collection. The ordering in
which __destruct methods are called can be very important when objects
contain instances of other objects as class variables. I have run into
problems because of the simple order that PHP uses to call __destruct
methods.
The order in which objects are destroyed should be determined by the
number of references left which point to the object (I believe Java
does something like this). In general, the Zend engine should use
something like the following algorithm for garbage collection:
foreach (object left to destroy) {
if(no references point at this object) {
call object's __destruct method
destroy object
}
}
The only hole in this algorithm is that an object that contains a
reference to itself will never be destroyed and cause an endless loop
in the algorithm above. These types of objects should be destroyed
last. The above algorithm can be easily modified to achieve this.
Please address this issue with PHP garbage collection. Thanks!
Previous Comments:
[2005-03-20 18:05:49] [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.
[2005-02-28 21:05:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-12-28 20:27:18] sir dot gallahad at gmail dot com
Description:
First of all. It's not a bug. It's a sugestion to give more stability
to the engine.
When the Zend Engine reaches the end of a script page it cleans up the
classes that have been created.
Nowadays it cleans up in the order the classes have been created.
I suggest that it would be a safer routine to destroy a class following
a heap of objects (first in last out).
It would help some nesting routines, not mentioning the memory
allocation.
Reproduce code:
---
aVar = $pMe;
echo
str_repeat("",$ident)."[".$this->aVar."]";
$ident++;
}
function __destruct() {
global $ident;
$ident--;
echo
str_repeat("",$ident)."[/".$this->aVar."]";
}
}
$v1 = new Tag("tag1");
$v2 = new Tag("tag2");
$v3 = new Tag("tag3");
echo '';
?>
Expected result:
[tag1]
[tag2]
[tag3]
[/tag3]
[/tag2]
[/tag1]
Actual result:
--
[tag1]
[tag2]
[tag3]
[/tag1]
[/tag2]
[/tag3]
--
Edit this bug report at http://bugs.php.net/?id=31326&edit=1
#33281 [Opn]: Possible deadlock in PHP-cleanup under heavy load
ID: 33281 Updated by: [EMAIL PROTECTED] Reported By: jimmy dot makela at loopia dot se Status: Open Bug Type: Apache related Operating System: FreeBSD 4.9-RELEASE-p10 PHP Version: 4.3.11 New Comment: A couple of questions. 1. Why is gdb just reporting object.11 instead of a real symbol? Have the symbols been stripped from your libphp4.so? Could you recompile and put them back to get a better backtrace? 2. Do you have any custom extensions loaded? And if you do, are they in C++? The FreeBSD4 rtld has notoriously bad support for C++ shared libraries. Previous Comments: [2005-06-09 09:49:42] jimmy dot makela at loopia dot se Description: Periodically on one of our webservers one apache-process starts using up all CPU until it is killed. A ktrace of the process gives the output: 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 ad infinitum. When attaching to the process with GDB and doing a backtrace, we get the following update: #0 0x28092648 in symlook_obj () from /usr/libexec/ld-elf.so.1 #1 0x28091032 in dlclose () from /usr/libexec/ld-elf.so.1 #2 0x283b3251 in object.11 () from /usr/local/libexec/apache/libphp4.so #3 0x283b4bfc in object.11 () from /usr/local/libexec/apache/libphp4.so #4 0x283b4d3a in object.11 () from /usr/local/libexec/apache/libphp4.so #5 0x283b0a00 in object.11 () from /usr/local/libexec/apache/libphp4.so #6 0x2838cb7a in object.11 () from /usr/local/libexec/apache/libphp4.so #7 0x2838cb57 in object.11 () from /usr/local/libexec/apache/libphp4.so #8 0x283c911d in object.11 () from /usr/local/libexec/apache/libphp4.so #9 0x80557e8 in ap_child_exit_modules () #10 0x805a7b1 in clean_child_exit () #11 0x805bba2 in just_die () #12 0xbfbfffac in ?? () #13 0x28091f83 in r_debug_state () from /usr/libexec/ld-elf.so.1 #14 0x28091e1e in r_debug_state () from /usr/libexec/ld-elf.so.1 #15 0x2809021b in find_symdef () from /usr/libexec/ld-elf.so.1 #16 0x2808fa78 in _rtld_bind () from /usr/libexec/ld-elf.so.1 #17 0x2808f461 in _rtld_bind_start () from /usr/libexec/ld-elf.so.1 #18 0x805d3dd in make_child () #19 0x805d64c in perform_idle_server_maintenance () #20 0x805db5d in standalone_main () #21 0x805e0a7 in main () #22 0x804fd0e in _start () which to me suggest that something in the PHP cleanup code is deadlocking. Any help in getting to the bottom of this would be greatly appreciated. If you need any additional information, we will provide it. -- Edit this bug report at http://bugs.php.net/?id=33281&edit=1
#33215 [Opn]: open_basedir leaks between vhosts
ID: 33215 User updated by: soenke at city-map dot de Reported By: soenke at city-map dot de Status: Open Bug Type: Safe Mode/open_basedir Operating System: FC2/3 PHP Version: 4CVS-2005-06-01 (stable) New Comment: Got it: It's somehow related to safe_mode. I hat the safe_mode directives in an Apache directive: php_admin_flag safe_mode_gid On php_admin_flag safe_mode On That does _NOT_ work. After commenting out the the like this: # php_admin_flag safe_mode_gid On php_admin_flag safe_mode On # it works. Now the PHP flags are in the global Apache config. But that's a strange behaviour, too, isn't it? Previous Comments: [2005-06-09 14:22:54] soenke at city-map dot de Bug reopened. This issue remains with new ECC RAM. [2005-06-06 13:15:32] soenke at city-map dot de Thx for your attention. Yes, I tried the Apache/PHP binaries from Fedora, too. Exactly the same issue. I'm getting the suspicion that it's a memory fault. I'll report the result here and reopen the bug if the bug remains with new RAM. [2005-06-04 01:06:48] [EMAIL PROTECTED] Have you tried by using the Fedora provided Apache2 (the binary rpm)?? As I can NOT reproduce this with it. [2005-06-01 23:01:20] soenke at city-map dot de Description: I discovered the strange behaviour of PHP4 that the open_basedir settings of several vhosts are leaking between each other. PHP configure line: './configure' \ '--with-apxs2=/usr/sbin/apxs' \ '--prefix=/usr' \ '--with-mysql=/usr' \ '--enable-safe-mode' \ '--enable-trans-sid' \ '--with-jpeg-dir=/usr' \ '--with-gd' \ '--with-zlib-dir=/usr' \ '--with-freetype-dir=/usr' \ Apache line: "./configure" \ "--enable-layout=RedHat" \ "--enable-mods-shared=most" \ "--enable-module=ssl" \ "--enable-ssl" \ "--with-ssl=/usr" \ "--enable-so" \ It's a mass-hosting Apache 2.0.54 server with many vhosts running the confixx tool. Here an example of 2 vhosts (generated by confixx): ServerName xxx.de ServerAlias DocumentRoot /usr/local/httpd/htdocs/web405/html SuexecUserGroup web405 web405 php_admin_value open_basedir /usr/local/httpd/htdocs/web405/html/:/usr/local/httpd/htdocs/web405/phptmp/:/usr/local/httpd/htdocs/web405/files/:/usr/local/httpd/htdocs/web405/atd/ php_admin_value file_uploads 1 php_admin_value upload_tmp_dir /usr/local/httpd/htdocs/web405/phptmp/ ServerName xxx ServerAlias xxx DocumentRoot /usr/local/httpd/htdocs/web309/html SuexecUserGroup web309 web309 php_admin_value open_basedir /usr/local/httpd/htdocs/web309/html/:/usr/local/httpd/htdocs/web309/phptmp/:/usr/local/httpd/htdocs/web309/files/:/usr/local/httpd/htdocs/web309/atd/ php_admin_value file_uploads 1 php_admin_value upload_tmp_dir /usr/local/httpd/htdocs/web309/phptmp/ Options FollowSymLinks SymLinksIfOwnerMatch The /usr/local/httpd/htdocs path is a real directory, no symlinks. Now I open one of these virtual hosts via web-browser. That works. But if I try to open the second vhost: Warning: Unknown(): open_basedir restriction in effect. File(/usr/local/httpd/htdocs/web405/html/index.php) is not within the allowed path(s): (/usr/local/httpd/htdocs/web309/html/:/usr/local/httpd/htdocs/web309/phptmp/:/usr/local/httpd/htdocs/web309/files/:/usr/local/httpd/htdocs/web309/atd/) in Unknown on line 0 Warning: Unknown(/usr/local/httpd/htdocs/web405/html/index.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/usr/local/httpd/htdocs/web405/html/index.php' for inclusion (include_path='.') in Unknown on line 0 The second vhost uses the open_basedir settings from the first one. That's really strange. I tested this with PHP4.3.10/11 and the latest CVS snapshot. I upgraded the Fedora distribution and recompiled Apache+PHP. No success. Now I really didn't know what to do any more and so opened this bug report. If you need more information or debugging it's no problem since it's no production system yet. -- Edit this bug report at http://bugs.php.net/?id=33215&edit=1
#33274 [Opn->Csd]: Class extended from MySQLi mangles members on calling parent method
ID: 33274
User updated by: flying dot mushroom at gmail dot com
Reported By: flying dot mushroom at gmail dot com
-Status: Open
+Status: Closed
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5.0.3
New Comment:
Fixed in CVS
Previous Comments:
[2005-06-09 12:51:50] flying dot mushroom at gmail dot com
Yep; the CVS version (200506090830) fixes it, producing the expected
result.
[2005-06-08 18:02:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-08 12:27:00] flying dot mushroom at gmail dot com
Description:
A class that extends mysqli, if passing its own members directly to the
parent constructor, will have those members mangled after the call.
Assigning member values to local variables and then passing those to
the parent solves the problem on for the user, but the above behaviour
shouldn't happen...?
(Replacing the line "parent::__construct($this->p_host, $this->p_uname,
$this->p_password);" with "parent::__construct($host, $username,
$password);" produces the expected result.)
This same problem is reported on the comment by hans at lintoo dot dk
on http://www.php.net/manual/en/ref.mysqli.php
Reproduce code:
---
p_host = $host;
$this->p_uname= $username;
$this->p_password = $password;
parent::__construct($this->p_host, $this->p_uname,
$this->p_password);
}
}
var_dump(new db_mysql('localhost', 'username', 'password'));
?>
Expected result:
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
string(8) "password"
}
Actual result:
--
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=33274&edit=1
php-bugs@lists.php.net
From: devik at cdi dot cz Operating system: Linux PHP version: 5.0.4 PHP Bug Type: Scripting Engine problem Bug description: Reference is killed by unset but not by other =& Description: This is variation on #15025. But I accept the bug is feature and I show other bug it triggers. Basic problem is that when you take ref of array item then the item will turn into reference (which will survive even array copy). I don't see it as too big problem as long as I can get rid of the reference. "unset" does the trick as expected: $r =& $A[0]; unset($r); - $A[0] is not reference any more But something like: $r =& $othervar; doesn't kill reference - you see zval with is_ref=1 and refcount=1. It prevents you from writing handy code: $c = &$c[$i] when traversing complex structures. Reproduce code: --- Expected result: I expect $a without references. Actual result: -- $a[0] is reference with refcount(1). -- Edit bug report at http://bugs.php.net/?id=33282&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33282&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33282&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33282&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33282&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33282&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33282&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33282&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33282&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33282&r=support Expected behavior: http://bugs.php.net/fix.php?id=33282&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33282&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33282&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33282&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33282&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33282&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33282&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33282&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33282&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33282&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33282&r=mysqlcfg
#33215 [Csd->Opn]: open_basedir leaks between vhosts
ID: 33215 User updated by: soenke at city-map dot de Reported By: soenke at city-map dot de -Status: Closed +Status: Open Bug Type: Safe Mode/open_basedir Operating System: FC2/3 PHP Version: 4CVS-2005-06-01 (stable) New Comment: Bug reopened. This issue remains with new ECC RAM. Previous Comments: [2005-06-06 13:15:32] soenke at city-map dot de Thx for your attention. Yes, I tried the Apache/PHP binaries from Fedora, too. Exactly the same issue. I'm getting the suspicion that it's a memory fault. I'll report the result here and reopen the bug if the bug remains with new RAM. [2005-06-04 01:06:48] [EMAIL PROTECTED] Have you tried by using the Fedora provided Apache2 (the binary rpm)?? As I can NOT reproduce this with it. [2005-06-01 23:01:20] soenke at city-map dot de Description: I discovered the strange behaviour of PHP4 that the open_basedir settings of several vhosts are leaking between each other. PHP configure line: './configure' \ '--with-apxs2=/usr/sbin/apxs' \ '--prefix=/usr' \ '--with-mysql=/usr' \ '--enable-safe-mode' \ '--enable-trans-sid' \ '--with-jpeg-dir=/usr' \ '--with-gd' \ '--with-zlib-dir=/usr' \ '--with-freetype-dir=/usr' \ Apache line: "./configure" \ "--enable-layout=RedHat" \ "--enable-mods-shared=most" \ "--enable-module=ssl" \ "--enable-ssl" \ "--with-ssl=/usr" \ "--enable-so" \ It's a mass-hosting Apache 2.0.54 server with many vhosts running the confixx tool. Here an example of 2 vhosts (generated by confixx): ServerName xxx.de ServerAlias DocumentRoot /usr/local/httpd/htdocs/web405/html SuexecUserGroup web405 web405 php_admin_value open_basedir /usr/local/httpd/htdocs/web405/html/:/usr/local/httpd/htdocs/web405/phptmp/:/usr/local/httpd/htdocs/web405/files/:/usr/local/httpd/htdocs/web405/atd/ php_admin_value file_uploads 1 php_admin_value upload_tmp_dir /usr/local/httpd/htdocs/web405/phptmp/ ServerName xxx ServerAlias xxx DocumentRoot /usr/local/httpd/htdocs/web309/html SuexecUserGroup web309 web309 php_admin_value open_basedir /usr/local/httpd/htdocs/web309/html/:/usr/local/httpd/htdocs/web309/phptmp/:/usr/local/httpd/htdocs/web309/files/:/usr/local/httpd/htdocs/web309/atd/ php_admin_value file_uploads 1 php_admin_value upload_tmp_dir /usr/local/httpd/htdocs/web309/phptmp/ Options FollowSymLinks SymLinksIfOwnerMatch The /usr/local/httpd/htdocs path is a real directory, no symlinks. Now I open one of these virtual hosts via web-browser. That works. But if I try to open the second vhost: Warning: Unknown(): open_basedir restriction in effect. File(/usr/local/httpd/htdocs/web405/html/index.php) is not within the allowed path(s): (/usr/local/httpd/htdocs/web309/html/:/usr/local/httpd/htdocs/web309/phptmp/:/usr/local/httpd/htdocs/web309/files/:/usr/local/httpd/htdocs/web309/atd/) in Unknown on line 0 Warning: Unknown(/usr/local/httpd/htdocs/web405/html/index.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/usr/local/httpd/htdocs/web405/html/index.php' for inclusion (include_path='.') in Unknown on line 0 The second vhost uses the open_basedir settings from the first one. That's really strange. I tested this with PHP4.3.10/11 and the latest CVS snapshot. I upgraded the Fedora distribution and recompiled Apache+PHP. No success. Now I really didn't know what to do any more and so opened this bug report. If you need more information or debugging it's no problem since it's no production system yet. -- Edit this bug report at http://bugs.php.net/?id=33215&edit=1
#25922 [Asn->Csd]: In error handler, modifying 5th arg (errcontext) may result in seg fault
ID: 25922
Updated by: [EMAIL PROTECTED]
Reported By: jeroen at derks dot it
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.20 Debian 3.0
PHP Version: 4-STABLE-CVS-20031021
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD, PHP_5_0 and PHP_4_4.
Previous Comments:
[2005-06-08 16:13:42] [EMAIL PROTECTED]
The bug is still reprodusabe in PHP_4_4 and HEAD.
[2003-10-22 19:49:40] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-10-21 06:16:08] [EMAIL PROTECTED]
With PHP 4.3.4RC3-dev:
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(152) : Block 0x08508470 status:
Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x08509568 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x085095A0 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x085095D0, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(165) : Block 0x085095D8 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509608, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x08509610 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509640, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(165) : Block 0x08509648 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509678, expected=0x7312F8DC)
End: Unknown
...and so on. GDB backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14715)]
0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00
"zend_opcode.c",
__zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:259
259 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00
"zend_opcode.c",
__zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:259
#1 0x08265895 in destroy_op_array (op_array=0x8508af8) at
zend_opcode.c:169
#2 0x0826566b in destroy_zend_function (function=0x8508af8) at
zend_opcode.c:100
#3 0x08272fa7 in zend_hash_destroy (ht=0x8415848) at zend_hash.c:553
#4 0x0826cb30 in zend_shutdown () at zend.c:559
#5 0x082358bf in php_module_shutdown () at main.c:1284
#6 0x08290fb0 in main (argc=2, argv=0xbc84) at php_cli.c:876
Note: Works fine with PHP 5.
[2003-10-20 14:11:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2003-10-20 07:54:21] jeroen at derks dot it
Description:
Modifying 5th parameter of error handler will make PHP crash when
leaving the error handler.
NB: This seems to happen only when the error was generated in a
function (possibly also in a member function). Please see the code.
NB2: When changing function test()'s parameter name into $args, PHP
exitted normally.
Reproduce code:
---
function my_error_handler( $error, $errmsg = '', $errfile = '',
$errline = 0, $errcontext = '' )
{
$errcontext = '';
}
#33256 [Fbk->Opn]: treatment of initial vectors invalidates algorithm
ID: 33256
User updated by: bwise837 at users dot sourceforge dot net
Reported By: bwise837 at users dot sourceforge dot net
-Status: Feedback
+Status: Open
Bug Type: mcrypt related
Operating System: *
PHP Version: 5.0.4
New Comment:
An example script with thorough comments is here:
http://www.oceanofstones.net/mcrypt-problem.php
Previous Comments:
[2005-06-06 18:34:58] [EMAIL PROTECTED]
Could you please put the script you've mentioned as a text file some
website so that it can be downloaded?
[2005-06-06 14:34:50] bwise837 at users dot sourceforge dot net
Description:
The initial vectors are treated in MCRYPT in a way
that invalidates the algorithms. This appears to apply
to all PHP version, all algorithms, all modes.
Diligent searching of the bug database does not reveal
any similar bug reports. This is a fundamental design
error, not a minor problem like '\0' line terminators
getting trimmed when decrypting binary data.
The example on page
http://us4.php.net/manual/en/function.mcrypt-module-open.php
clearly shows that decryption does not merely require the N bits of the
"secret key" to decrypt, but also the M bits of
the "initial vector" to decrypt. This is NOT the way initial
vectors are used in standard cryptography, as documented
by Schneier, Koblitz, Rivest, et al. You have wrapped the
encryption algorithm (all algorithms, all modes) in another,
creating a new encryption algorithm that requires an N+M
bit secret key to decrypt. This is a VERY SERIOUS error.
Schneier's writings are full of examples of how such simple
changes, that naivley look like improvements, can sometimes
break the security of the algorithm. Maybe it did here, maybe not: a
fully cryptanalysis is required to determine
if the new N+M-bit-key algorithm is as good as the
N-bit-key algorithm on which it was based. Until then, it
can't be trusted.
I'm sorry to say such strong things, but I happen to have
a mathematical background in cryptography, and I'm shocked
to find such an elementary and gross error.
There is a simple work around, and I'd be happy to send
a php script I've made which demos it. The essence is to
always use a public, constant string for the MCRYPT-style
IV, while using a secret, random string for the standard-
style IV. This adds one extra block to the cipher text length, but that
is a small price to pay for undoing a
terribly wrong design decision.
(The script is more than 20 lines, and I don't have
my own website up yet. But it's a simple fix.)
Reproduce code:
---
from http://us4.php.net/manual/en/function.mcrypt-module-open.php
Expected result:
I would expect, as per textbook cryptography, to be
able to decrypt the string using ONLY the secret key:
In cryptography, the reverse of security by obscurity is Kerckhoffs'
principle from the late 1880s, which states that system designers
should assume that the entire design of a security system is known to
all attackers, with the exception of the cryptographic key: "the
security of a cypher resides entirely in the key".
from
http://www.answers.com/topic/security-through-obscurity
Actual result:
--
Both the IV and 'secret key' are needed to decrypt,
in violation of Kerckhoff's laws.
Outside MCRYPT, for every single algorithm and mode, only
the secret key is required to decrypt. This alone mathematically proves
that MCRYPT is implementing different
algorithms with different true keys ('true key' = what is
required to decrypt = 'secret key' + MCRYPT-style 'IV') than
the algorithms which it claims to implement.
--
Edit this bug report at http://bugs.php.net/?id=33256&edit=1
#33274 [Fbk->Opn]: Class extended from MySQLi mangles members on calling parent method
ID: 33274
User updated by: flying dot mushroom at gmail dot com
Reported By: flying dot mushroom at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5.0.3
New Comment:
Yep; the CVS version (200506090830) fixes it, producing the expected
result.
Previous Comments:
[2005-06-08 18:02:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-08 12:27:00] flying dot mushroom at gmail dot com
Description:
A class that extends mysqli, if passing its own members directly to the
parent constructor, will have those members mangled after the call.
Assigning member values to local variables and then passing those to
the parent solves the problem on for the user, but the above behaviour
shouldn't happen...?
(Replacing the line "parent::__construct($this->p_host, $this->p_uname,
$this->p_password);" with "parent::__construct($host, $username,
$password);" produces the expected result.)
This same problem is reported on the comment by hans at lintoo dot dk
on http://www.php.net/manual/en/ref.mysqli.php
Reproduce code:
---
p_host = $host;
$this->p_uname= $username;
$this->p_password = $password;
parent::__construct($this->p_host, $this->p_uname,
$this->p_password);
}
}
var_dump(new db_mysql('localhost', 'username', 'password'));
?>
Expected result:
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
string(8) "password"
}
Actual result:
--
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=33274&edit=1
#33281 [NEW]: Possible deadlock in PHP-cleanup under heavy load
From: jimmy dot makela at loopia dot se Operating system: FreeBSD 4.9-RELEASE-p10 PHP version: 4.3.11 PHP Bug Type: Apache related Bug description: Possible deadlock in PHP-cleanup under heavy load Description: Periodically on one of our webservers one apache-process starts using up all CPU until it is killed. A ktrace of the process gives the output: 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x1,0x280a1060,0xbfbff540) 63458 httpdRET sigprocmask 0 63458 httpdCALL sigprocmask(0x3,0xbfbff540,0) 63458 httpdRET sigprocmask 0 ad infinitum. When attaching to the process with GDB and doing a backtrace, we get the following update: #0 0x28092648 in symlook_obj () from /usr/libexec/ld-elf.so.1 #1 0x28091032 in dlclose () from /usr/libexec/ld-elf.so.1 #2 0x283b3251 in object.11 () from /usr/local/libexec/apache/libphp4.so #3 0x283b4bfc in object.11 () from /usr/local/libexec/apache/libphp4.so #4 0x283b4d3a in object.11 () from /usr/local/libexec/apache/libphp4.so #5 0x283b0a00 in object.11 () from /usr/local/libexec/apache/libphp4.so #6 0x2838cb7a in object.11 () from /usr/local/libexec/apache/libphp4.so #7 0x2838cb57 in object.11 () from /usr/local/libexec/apache/libphp4.so #8 0x283c911d in object.11 () from /usr/local/libexec/apache/libphp4.so #9 0x80557e8 in ap_child_exit_modules () #10 0x805a7b1 in clean_child_exit () #11 0x805bba2 in just_die () #12 0xbfbfffac in ?? () #13 0x28091f83 in r_debug_state () from /usr/libexec/ld-elf.so.1 #14 0x28091e1e in r_debug_state () from /usr/libexec/ld-elf.so.1 #15 0x2809021b in find_symdef () from /usr/libexec/ld-elf.so.1 #16 0x2808fa78 in _rtld_bind () from /usr/libexec/ld-elf.so.1 #17 0x2808f461 in _rtld_bind_start () from /usr/libexec/ld-elf.so.1 #18 0x805d3dd in make_child () #19 0x805d64c in perform_idle_server_maintenance () #20 0x805db5d in standalone_main () #21 0x805e0a7 in main () #22 0x804fd0e in _start () which to me suggest that something in the PHP cleanup code is deadlocking. Any help in getting to the bottom of this would be greatly appreciated. If you need any additional information, we will provide it. -- Edit bug report at http://bugs.php.net/?id=33281&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33281&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33281&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33281&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33281&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33281&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33281&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33281&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33281&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33281&r=support Expected behavior: http://bugs.php.net/fix.php?id=33281&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33281&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33281&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33281&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33281&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33281&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33281&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33281&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33281&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33281&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33281&r=mysqlcfg
