#38238 [Com]: PHP with PEAR running on IIS
ID: 38238 Comment by: webmaster at impactbs dot com Reported By: rmarescu at gmail dot com Status: No Feedback Bug Type: IIS related Operating System: MS Windows Server 2003 PHP Version: 5.1.4 New Comment: IIS 6 Win2003 SP1 standard PHP 5.1.6 ISAPI The site is running Invision Power Board 2.7 in it's own application pool using the MSSQL driver. I'm getting the same error: PHP has encountered an Access Violation at 7C8224B2 Intermittently on a forum that's actively serving 30-80 at a given time but this error also happened before the DNS was even pointed to the site (basically it started just after I installed PHP 5 on the server that didn't have PHP on it before the site was hosted on it). I think you're already aware of the problem but if I can provide anymore information let me know. I'm going to move to the CGI version which apparently is more stable under IIS. Previous Comments: [2006-08-05 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-07-28 08:15:36] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2006-07-28 07:16:53] rmarescu at gmail dot com This is another error that I'm receiving from time to time: PHP has encountered an Access Violation at 02DB3C09 After a page refresh, the error dissapear. [2006-07-27 18:18:25] rmarescu at gmail dot com Description: After installing the PHP version 5.1.4, running for several hours, I'm getting this error: PHP has encountered an Access Violation at 7C8224B2 The error occurs when I'm using require() function. After removing require() function, 1-2 times the script works, but after that I received the same error with another address. -- Edit this bug report at http://bugs.php.net/?id=38238edit=1
#38933 [NEW]: dirname not support binary file path
From: foxgoblin at gmail dot com Operating system: Windows XP PHP version: 5.1.6 PHP Bug Type: Directory function related Bug description: dirname not support binary file path Description: function dirname not support binary file path Reproduce code: --- ? echo dirname(c:\\window\\\xd7\xc0\\test); ? Expected result: c:\window\×À Actual result: -- c:\window -- Edit bug report at http://bugs.php.net/?id=38933edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38933r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38933r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38933r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38933r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38933r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38933r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38933r=needscript Try newer version:http://bugs.php.net/fix.php?id=38933r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38933r=support Expected behavior:http://bugs.php.net/fix.php?id=38933r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38933r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38933r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38933r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38933r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38933r=dst IIS Stability:http://bugs.php.net/fix.php?id=38933r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38933r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38933r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38933r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38933r=mysqlcfg
#38232 [Opn-Bgs]: Relative Path Includes Broken
ID: 38232 Updated by: [EMAIL PROTECTED] Reported By: serverprivacy at gmail dot com -Status: Open +Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: Windows XP Pro SP2 PHP Version: 5.2.0RC2-dev New Comment: Dupe of bug#38904 (marking this as bogus as the other is already assigned) Previous Comments: [2006-09-22 23:54:12] serverprivacy at gmail dot com I don't really know what that is, but according to my phpinfo(), yes I am using it. Server API Apache 2.0 Filter [2006-09-22 08:29:28] [EMAIL PROTECTED] You aren't running the apache2filter SAPI by any chance? [2006-07-27 09:39:11] serverprivacy at gmail dot com Updated version, drop down box didn't have it listed. [2006-07-27 09:31:38] serverprivacy at gmail dot com Description: Including a file using a relative path with a . or ./ fails, giving a No such file or directory error. OS: Windows XP Pro SP2 PHP: 5.2.0RC2-dev Web: Apache 2.2.2 Reproduce code: --- All files are in the same directory. test1.php ?php include(message.php); ? test2.php ?php include(./message.php); ? message.php ?php echo Success; ? Expected result: test1 and test2 should both produce Success. Actual result: -- test1 is fine. test2 gives the following error message: Warning: include(./message.php) [function.include]: failed to open stream: No such file or directory in C:\Apache\htdocs\test2.php on line 2 Warning: include() [function.include]: Failed opening './message.php' for inclusion (include_path='.;C:\Apache\PHP;C:\Apache\PHP\PEAR;C:\Apache\htdocs') in C:\Apache\htdocs\test2.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=38232edit=1
#38874 [Opn-Asn]: Will not load extension
ID: 38874 Updated by: [EMAIL PROTECTED] Reported By: dabbaking at gmail dot com -Status: Open +Status: Assigned Bug Type: MySQLi related Operating System: Win32 PHP Version: 5.2.0RC5 Assigned To: georg Previous Comments: [2006-09-22 21:45:08] dabbaking at gmail dot com I have RC5-dev running. Still a problem. [2006-09-19 19:58:41] dabbaking at gmail dot com I'm not getting any errors. The normal mysql extension loads. I have libmysql.dll in my path before mysql. [2006-09-19 15:02:52] [EMAIL PROTECTED] Do you get any error messages? Does mysql extension load? Do you have libmysql.dll from the php distribution in your PATH *before* mysql database directory. [2006-09-18 21:54:04] dabbaking at gmail dot com I just want to note that the other extensions on the list loaded fine. Including the normal mysql extension. I have MySQL 5.0 running. [2006-09-18 21:51:37] dabbaking at gmail dot com Description: The mysqli extension won't load. Reproduce code: --- extension=php_mysqli.dll Expected result: Suppose to load the extension Actual result: -- The extension did not load. -- Edit this bug report at http://bugs.php.net/?id=38874edit=1
#38861 [Opn-Asn]: PDO retrive no mysql-results when using the same variable
ID: 38861
Updated by: [EMAIL PROTECTED]
Reported By: Drezil at web dot de
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Debian/Sarge
PHP Version: 5.1.6
Assigned To: wez
Previous Comments:
[2006-09-19 18:49:19] Drezil at web dot de
This is definitely a bug in PDO. I tried unset($qry);, a $qry = null;
and so on and so forth.
the exact same code actually works in my other enviroment (WinXP, IIS5,
PHP 5.0.7, Mysql 4.1.15). I also un-/reinstall php on the debian
system.
To get it even more confusing i got such constructs in other scripts,
which work as the should.
as shown in the mysql-log the prepare and the execute is omitted
correctly. even $qry-rowCount(); echos '1'.. but still $qry-fetch()
returns false.
by the way: a buffered-query problem in not solved by just renaming the
var's (because if an unbuffered qry is sent, it must be closed
explicitly before reusing the same connection. this does't depend on
the var-name in php). This would just raise an error during script
execution (which is printed to me due to an error-level of E_ALL |
E_STRICT).
my script is quite complex, so i reduced the example to the minimum. A
more detailed view on the source-code can be fond at:
http://vserver.mission-unknown.de/stuff/code.phps
if this is no bug, WHY does the EXACT SAME script behave completely
different on both systems? The differences in the php.ini are only
system-specific due to win/unix reasons so there is no
misconfigured-excuse.
Sorry to cause you so much trouble.. ;)
[2006-09-19 16:49:49] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You either need to enable buffered queries or disabled native
prepare for this to work. Or replace closeCursor() with unset
($qry).
The issue is actually a MySQL limitation with buffered
queries.
[2006-09-17 17:11:54] Drezil at web dot de
Description:
with update to php 5.1.6 i ran into problems with the pdo-mysql module
(loaded as dyn. extension in the php.ini).
If i reuse a variable after retrieving a mysql-result any following
result is empty although the query (as shown in the mysql-log) is
ommited correctly and has valid results.
switching mysql 4.1.15 to mysql 5.0.x or the oter way round doesn't fix
anything.
Reproduce code:
---
?php
$user = 'xxx';
$pass = 'xxx';
try {
$dbh = new PDO('mysql:host=localhost;dbname=xxx', $user, $pass);
$qry = $dbh-query('SELECT 1+1')
echo '\''.print($qry-fetch(PDO::FETCH_NUM),true).'\'br /';
$qry-closeCursor();
$qry = $dbh-query('SELECT 1+1')
echo '\''.print($qry-fetch(PDO::FETCH_NUM),true).'\'br /';
$qry-closeCursor();
$qry = $dbh-query('SELECT 1+1')
echo '\''.print($qry-fetch(PDO::FETCH_NUM),true).'\'br /';
$qry-closeCursor();
} catch (PDOException $e) {
print Error!: . $e-getMessage() . br/;
die();
}
?
Expected result:
'2'br /
'2'br /
'2'br /
Actual result:
--
'2'br /
''br /
''br /
if i just rename the objects to $qry1, $qry2, $qry3 everything works
fine and as expected.
looks like closeCursor() deosn't work right or the objects are not
overwritten correctly.
--
Edit this bug report at http://bugs.php.net/?id=38861edit=1
#37919 [Opn-Fbk]: PHP doesn't read the configurations propertly
ID: 37919 Updated by: [EMAIL PROTECTED] Reported By: rafael dot amador at gmail dot com -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Windows XP Pro SP2 PHP Version: 5.1.4 or above New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-07-27 17:21:12] rafael dot amador at gmail dot com the bug is present in 5.1.5. Nobody will fix this anoying bug? [2006-06-27 02:16:12] rafael dot amador at gmail dot com i configured the php file with the registry entry pointing to it and didn't work but if i comment the doc_root option in php.ini all works WELL. a couple of questions come to me now: why the windows PATH method doesn't works? why the registry method works only with doc_root disabled? i saw a lot of bugs that have similar behavior. check this beacuse if isn't a bug then isn't documentated. [2006-06-26 21:09:11] rafael dot amador at gmail dot com i rebooted my server and again i've the same result [2006-06-26 19:58:59] rafael dot amador at gmail dot com and the same result in the lastest snapshot [2006-06-26 19:58:00] rafael dot amador at gmail dot com i've installed the version using the same php.ini and overwritting all fuiles in php directory , later i stoped the iisadmin/w3svc service and later started again 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/37919 -- Edit this bug report at http://bugs.php.net/?id=37919edit=1
#38757 [Opn-Asn]: MultiPart Form Uploads fail with FastCGI
ID: 38757 Updated by: [EMAIL PROTECTED] Reported By: davidb at pins dot net -Status: Open +Status: Assigned Bug Type: Apache related Operating System: Solaris 8 PHP Version: 5.1.6 Assigned To: dmitry Previous Comments: [2006-09-20 14:50:28] davidb at pins dot net I just downloaded the latest snap php5.2-200609200230, but the poll() still shows the same thing: poll(0xFFBEDB18, 1, 1000) = 1 can you please tell me where to get the right stuff to test? Thanks. [2006-09-19 20:52:55] davidb at pins dot net Ummm...well, here's what I installed: php5.2-200609141630 Does this have what I need? If not, can you tell me what URL to go look for? I went to the snaps.php.net page for this. [2006-09-19 20:43:12] [EMAIL PROTECTED] You have tested the old version, pool(..., 1000) means 1 second timeout. In new version you should have 5 seconds. [2006-09-18 21:29:16] davidb at pins dot net One other thing which we noticed - if we take our sample (which breaks) and change the multipart-form to a regular form, the problem does not occur. This is weird, and I have no idea how it may bear into the problem. It may be a red herring of some sort. Any ideas on the next step in debugging? [2006-09-15 03:51:35] davidb at pins dot net Greetings. I tried with the latest 5.2 (downloaded today). It doesn't seem to make a difference. The poll() still exits with 0, then proceeds to read everything in anyway. Heres the truss, with timestamps this time: 94.3878 accept(0, 0xFFBEDC78, 0xFFBEDBC4, 1)= 4 AF_UNIX name = 94.3880 fcntl(0, F_SETLK, 0xFFBEDC50) = 0 typ=F_UNLCK whence=SEEK_SET start=0 len=0 sys=4290697848 pid=2086536 95.3952 poll(0xFFBEDB18, 1, 1000) = 0 fd=4 ev=POLLRDNORM rev=0 95.3959 shutdown(4, 1, 1) = 0 recv(4, 0xFFBEDC50, 8, 0) (sleeping...) signotifywait() (sleeping...) lwp_sema_wait(0xFD70DE60) (sleeping...) sema type: USYNC_THREAD count = 0 103.4047recv(4, 0101\001\0\b\0\0, 8, 0) = 8 103.4050recv(4, \001\0\0\0\0\0\0, 8, 0) = 8 103.4051recv(4, 0104\001\016\0\0, 8, 0) = 8 103.4051recv(4, 0E06 C O N T E N, 8, 0) = 8 103.4052recv(4, T _ L E N G T H, 8, 0) = 8 103.4053recv(4, 1 2 8 9 9 00104, 8, 0) = 8 103.4054recv(4, \001\0 E\0\0\f 7, 8, 0) = 8 103.4055recv(4, C O N T E N T _, 8, 0) = 8 103.4055recv(4, T Y P E m u l t, 8, 0) = 8 I guess the big question is why is poll exiting with 0 when there's a pile of valid data? David. 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/38757 -- Edit this bug report at http://bugs.php.net/?id=38757edit=1
#38698 [Opn-Asn]: for some keys cdbmake creates corrupted db and cdb can't read valid db.
ID: 38698
Updated by: [EMAIL PROTECTED]
Reported By: oleg1917 at mail dot ru
-Status: Open
+Status: Assigned
Bug Type: DBM/DBA related
Operating System: centos 4.3
PHP Version: 5.1.6
Assigned To: helly
Previous Comments:
[2006-09-12 16:40:40] oleg1917 at mail dot ru
this one http://kudiz.com/129test.cdb
is created by Bernstein's cdbmake utility.
[2006-09-12 15:25:31] [EMAIL PROTECTED]
That's the PHP generated db, do you have the one made outside
of PHP?
[2006-09-05 15:07:04] oleg1917 at mail dot ru
here is it http://kudiz.com/129php.cdb
i've got the same result on several boxes with centos 4.x, trustix 2.x
distros and php 5.1.x
[2006-09-05 14:38:35] [EMAIL PROTECTED]
Can you please provide a copy of the 129php.cdb file.
[2006-09-03 13:16:08] oleg1917 at mail dot ru
Description:
i used integer numbers packed into binary strings as keys.
for some numbers dba's cdbmake handler produces files that can't be
read by Bernshtein's tools like cdbtest and CPAN's perl module
CDB_File. And vice versa files produced by Bernshtein's cdbmake and
CPAN's perl module CDB_File can't be read by dba's cdb handler.
Reproduce code:
---
?php
$handler = 'cdb_make';
$db_file = '129php.cdb';
echo database handler: $handler\n;
// print md5 checksum of 129test.cdb which is generated by
cdb_make program
var_dump(md5_file(dirname(__FILE__).'/129test.cdb'));
if (($db_make=dba_open($db_file, n, $handler))!==FALSE) {
dba_insert(pack('i',129), Booo!, $db_make);
dba_close($db_make);
// write md5 checksum of generated database file
var_dump(md5_file($db_file));
} else {
echo Error creating database\n;
}
?
Expected result:
database handler: cdb_make
string(32) 1f34b74bde3744265acfc21e0f30af95
string(32) 1f34b74bde3744265acfc21e0f30af95
Actual result:
--
database handler: cdb_make
string(32) 1f34b74bde3744265acfc21e0f30af95
string(32) b9ee8bfe966a01e287f8aa45b3fcc958
--
Edit this bug report at http://bugs.php.net/?id=38698edit=1
#38819 [Opn-Fbk]: segfault in ldap_get_entries()
ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: What was your configure line and did you enable any of mysql related extensions? If yes, then what is the version of MySQL? Previous Comments: [2006-09-19 19:54:19] madcoder at gmail dot com Apparently it looks like pastebin is having problems... I've copied the same output here, for redundancy: http://www.framewerk.org/~madcoder/vgrind.log [2006-09-19 19:49:48] madcoder at gmail dot com I ran it through valgrind with --leak-check=full -v --show-reachable=yes, and copied the output here: http://pastebin.com/790150 [2006-09-19 19:39:47] madcoder at gmail dot com Now that's interesting... It runs fine with valgrind. Here are the ERROR SUMMARY and LEAK SUMMARY sections: ==7964== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 93 from 1) ==7964== malloc/free: in use at exit: 71,780 bytes in 1,268 blocks. ==7964== malloc/free: 38,082 allocs, 36,814 frees, 3,611,397 bytes allocated. ==7964== For counts of detected errors, rerun with: -v ==7964== searching for pointers to 1,268 not-freed blocks. ==7964== checked 2,962,048 bytes. ==7964== LEAK SUMMARY: ==7964==definitely lost: 32,841 bytes in 4 blocks. ==7964== possibly lost: 0 bytes in 0 blocks. ==7964==still reachable: 38,939 bytes in 1,264 blocks. ==7964== suppressed: 0 bytes in 0 blocks. ==7964== Use --leak-check=full to see details of leaked memory. Running with --leak-check=full, I get the following: ==7968== 73 (32 direct, 41 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 8 ==7968==at 0x4A1AB8E: malloc (vg_replace_malloc.c:149) ==7968==by 0x64825AB: tds_alloc_context (in /usr/lib64/libsybdb.so.4.0) ==7968==by 0x6472C3F: dbinit (in /usr/lib64/libsybdb.so.4.0) ==7968==by 0x1595DC: zm_startup_mssql (php_mssql.c:301) ==7968==by 0x31B325: zend_startup_module_ex (zend_API.c:1397) ==7968==by 0x3224A3: zend_hash_apply (zend_hash.c:666) ==7968==by 0x31B4EE: zend_startup_modules (zend_API.c:1444) ==7968==by 0x2BB230: php_module_startup (main.c:1557) ==7968==by 0x3E460A: main (php_cli.c:681) ==7968== ==7968== 32,768 bytes in 1 blocks are definitely lost in loss record 8 of 8 ==7968==at 0x4A1C10D: calloc (vg_replace_malloc.c:279) ==7968==by 0x6472C16: dbinit (in /usr/lib64/libsybdb.so.4.0) ==7968==by 0x1595DC: zm_startup_mssql (php_mssql.c:301) ==7968==by 0x31B325: zend_startup_module_ex (zend_API.c:1397) ==7968==by 0x3224A3: zend_hash_apply (zend_hash.c:666) ==7968==by 0x31B4EE: zend_startup_modules (zend_API.c:1444) ==7968==by 0x2BB230: php_module_startup (main.c:1557) ==7968==by 0x3E460A: main (php_cli.c:681) [2006-09-19 06:24:54] [EMAIL PROTECTED] Doesn't look like PHP problem to me. Could you plz also see if `valgrind /usr/bin/php test.php` show you something interesting? Please put valgrind's log somewhere and paste the URL here. [2006-09-18 23:38:16] madcoder at gmail dot com Sorry for the delay (I had to fix an error with gdb not generating backtraces on AMD64...) Here's the backtrace: - (gdb) run Starting program: /usr/bin/php -e test.php [Thread debugging using libthread_db enabled] [New Thread 47773184727840 (LWP 28424)] done searching Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47773184727840 (LWP 28424)] 0x2b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 153 getvalues.c: No such file or directory. in getvalues.c - (gdb) bt #0 0x2b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153 #1 0x556a25c0 in zif_ldap_get_entries (ht=1441370656, return_value=0x55e987a8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1438266616, tsrm_ls=0x55e9cc60) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068 #2 0x55890d35 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9f13efb0, tsrm_ls=0x55ba4450) at zend_vm_execute.h:200 #3 0x55899c6a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff9f13efb0, tsrm_ls=0x55ba4450) at zend_vm_execute.h:1640 #4 0x5589039b in execute (op_array=0x55e96ad8, tsrm_ls=0x55ba4450) at zend_vm_execute.h:92 #5 0x55868a42 in zend_execute_scripts (type=8, tsrm_ls=0x55ba4450, retval=0x0, file_count=3) at
#38849 [Opn-Bgs]: ntwdblib.dll that comes with PHP5 does not work
ID: 38849 Updated by: [EMAIL PROTECTED] Reported By: dan dot mashal at gmail dot com -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: Windows PHP Version: 5.1.6 New Comment: Please complain to Microsoft and ask them why it's impossible to install the required libraries @ win2003. Not PHP problem. Previous Comments: [2006-09-20 13:47:56] dan dot mashal at gmail dot com So let me make sure I have this correct. According to edink if I am running W2k3 web edition, install PHP5 and then MSSQL connectivity does not work due to a broken file shipped with PHP it's not a bug and I'm supposed to just sit here twiddling my thumbs? Please give a solution instead of saying it's not a bug. [2006-09-20 09:18:23] [EMAIL PROTECTED] That is in no way a PHP bug. [2006-09-19 22:28:37] dan dot mashal at gmail dot com Like I said you cannot install client tools on Windows Server 2003 web edition. [2006-09-19 15:06:08] [EMAIL PROTECTED] Installing Client Tools will solve the problem, not a bug in PHP itself. [2006-09-18 22:24:41] dan dot mashal at gmail dot com http://64.78.33.121/weberror.jpg 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/38849 -- Edit this bug report at http://bugs.php.net/?id=38849edit=1
#38886 [Opn-Fbk]: PDO fails for no apparent reason, pages that works randomly breaks
ID: 38886 Updated by: [EMAIL PROTECTED] Reported By: tg at idiom dot dk -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux 2.6.12.5 PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-19 20:54:49] tg at idiom dot dk Description: I run an Apache (2.0.58) server, PDO (1.0RC2) and APC (3.0.11). My PDO randomly gives me this error (Fatal error: Call to a member function execute() on a non-object in /var/www/*/htdocs/classes/pdoMysql.class.php on line 33 ), without any errors in the log. The error occurs more frequently when the server is loading, but it also happens with no particular load, and some seconds after it works flawless again. I've tried the latest CVS snapshop for PHP 5, but it didn't fix the problem. PHP configure flags: './configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--without-bz2' '--disable-calendar' '--disable-ctype' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--without-hwapi' '--without-iconv' '--without-informix' '--disable-ipv6' '--without-kerberos' '--disable-mbstring' '--with-mcrypt' '--disable-memory-limit' '--without-mhash' '--without-ming' '--without-msql' '--without-mssql' '--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--without-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' '--disable-sockets' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--without-db4' '--without-flatfile' '--with-gdbm' '--without-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-ldap' '--with-ldap-sasl' '--with-mysql=/usr/lib/mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--without-pdo-dblib' '--with-pdo-mysql=/usr' '--without-pdo-odbc' '--without-pdo-pgsql' '--without-pdo-sqlite' '--with-readline' '--without-libedit' '--without-mm' '--without-sqlite' Reproduce code: --- #Snip: $this-cfg = array( 'db' = 'mysql', 'db_user' = '*', 'db_pwd' = '*', 'db_host' = 'localhost', 'db_db' = '*', 'db_opts' = array( PDO::ERRMODE_SILENT = true, PDO::ATTR_PERSISTENT = true, PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true ) ); $this-pdo = new PDO($this-cfg['db'].':host='.$this-cfg['db_host'].';dbname='.$this-cfg['db_db'],$this-cfg['db_user'],$this-cfg['db_pwd'],$this-cfg['db_opts']); $stmt = $this-pdo-prepare(SELECT * FROM users); $stmt-execute(); Expected result: An array of info Actual result: -- Fatal error: Call to a member function execute() on a non-object in /var/www/*/htdocs/classes/pdoMysql.class.php on line 33 -- Edit this bug report at http://bugs.php.net/?id=38886edit=1
#38901 [Opn-Fbk]: wddx mangles utf8 characters in serialized strings (broken more than in 4.4)
ID: 38901
Updated by: [EMAIL PROTECTED]
Reported By: grzegorz dot nosek at netart dot pl
-Status: Open
+Status: Feedback
Bug Type: WDDX related
Operating System: Linux
PHP Version: 5.1.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-09-20 13:46:02] grzegorz dot nosek at netart dot pl
Description:
wddx gets confused if you try to serialize a string with utf8
characters (like the one below, it contains 'z with dot above', 'o
acute', 'l stroke' and 'w' - in case it gets messed up somehow).
serialized string will contain char code='C5'/char code='BC'/ ...
etc, which will get fed into xml_utf8_decode byte by byte (after
decoding the hex value), totally wrecking the output.
Up to this point, it's a duplicate of #38900.
However, PHP5 has another bug with variable names (e.g. hash keys)
containing UTF8 characters. It seems that the var name is converted
down from UTF8 to ISO-8859-1, yielding question marks instead of
characters outside latin1.
Another hackish patch (whitespace-mutilated):
--- a/ext/wddx/wddx.c
+++ b/ext/wddx/wddx.c
@@ -814,10 +814,7 @@ static void php_wddx_push_element(void *
if (atts) for (i = 0; atts[i]; i++) {
if (!strcmp(atts[i], EL_NAME) atts[++i] atts[i][0]) {
- char *decoded;
- int decoded_len;
- decoded = xml_utf8_decode(atts[i], strlen(atts[i]), decoded_len,
ISO-8859-1);
- stack-varname = decoded;
+ stack-varname = estrndup(atts[i], strlen(atts[i]));
break;
}
}
@@ -1057,7 +1054,12 @@ static void php_wddx_process_data(void *
wddx_stack_top(stack, (void**)ent);
switch (Z_TYPE_P(ent)) {
case ST_STRING:
- decoded = xml_utf8_decode(s, len, decoded_len, ISO-8859-1);
+ if (len 1) {
+ decoded = xml_utf8_decode(s, len, decoded_len, ISO-8859-1);
+ } else {
+ decoded = estrndup(s, len);
+ decoded_len = len;
+ }
Reproduce code:
---
See http://bugs.php.net/bug.php?id=38900
--
Edit this bug report at http://bugs.php.net/?id=38901edit=1
#38934 [NEW]: move_uploaded_file() cannot read uploaded file outside of open_basedir
From: phpbugs at thequod dot de
Operating system: Ubuntu Linux
PHP version: 5.1.6
PHP Bug Type: Safe Mode/open_basedir
Bug description: move_uploaded_file() cannot read uploaded file outside of
open_basedir
Description:
According to the documentation PHP should be able to read
the uploaded file, although it's outside the open_basedir
directories:
Note: move_uploaded_file() is both safe mode and
open_basedir aware. However, restrictions are placed only
on the destination path as to allow the moving of uploaded
files in which filename may conflict with such
restrictions. move_uploaded_file() ensures the safety of
this operation by allowing only those files uploaded
through PHP to be moved.
However, I have to add /tmp to open_basedir - which is bad
in terms of users would be allowed to access the files
there!
I've not explicitely set the upload_tmp_dir directive, so
the default /tmp gets used.
See also these old bugs, where it seems to have been
fixed, but now is broken again:
http://bugs.php.net/bug.php?id=21885
http://bugs.php.net/bug.php?id=27559
Reproduce code:
---
upload.php file:
?php
error_reporting(E_ALL);
ini_set('display_errors', 'on');
if( empty($_FILES) )
{
?
!-- The data encoding type, enctype, MUST be specified as below --
form enctype=multipart/form-data action=upload.php method=POST
!-- MAX_FILE_SIZE must precede the file input field --
input type=hidden name=MAX_FILE_SIZE value=3 /
!-- Name of input element determines name in $_FILES array --
Send this file: input name=userfile type=file /
input type=submit value=Send File /
/form
?php
}
else
{
$uploadfile = dirname(__FILE__).'/upload_file.test';
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
$uploadfile)) {
echo File is valid, and was successfully uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
}
?
Expected result:
File upload.
Actual result:
--
Warning: move_uploaded_file()
[function.move-uploaded-file]: open_basedir restriction in
effect. File(/tmp/phpoNSKDN) is not within the allowed
path(s): (/XXX) in ...
--
Edit bug report at http://bugs.php.net/?id=38934edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38934r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38934r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38934r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38934r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38934r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38934r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38934r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38934r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38934r=support
Expected behavior:http://bugs.php.net/fix.php?id=38934r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38934r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38934r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38934r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38934r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38934r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38934r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38934r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38934r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38934r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38934r=mysqlcfg
#38898 [Opn-Fbk]: #38431 once again (xmlrpc segfault)
ID: 38898 Updated by: [EMAIL PROTECTED] Reported By: grzegorz dot nosek at netart dot pl -Status: Open +Status: Feedback Bug Type: XMLRPC-EPI related Operating System: Linux PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-20 13:12:56] grzegorz dot nosek at netart dot pl Description: Guys, you broke it again in 5.1.5 (5.1.6 is still broken, btw.) This patch seems to fix it. Why was it reverted? http://cvs.php.net/viewvc.cgi/php-src/ext/xmlrpc/xmlrpc-epi-php.c?r1=1.39.2.5r2=1.39.2.6 Is there any reason for the commit linked below? http://cvs.php.net/viewvc.cgi/php-src/ext/xmlrpc/xmlrpc-epi-php.c?view=log#rev1.39.2.7 Test case below, taken from 5.1.6 distribution (ext/xmlrpc/tests/bug38431.phpt), fails with a segfault. Reproduce code: --- --TEST-- Bug #38431 (xmlrpc_get_type() crashes PHP on objects) --SKIPIF-- ?php if (!extension_loaded(xmlrpc)) print skip; ? --FILE-- ?php var_dump(xmlrpc_get_type(new stdclass)); var_dump(xmlrpc_get_type(array())); $var = array(1,2,3); var_dump(xmlrpc_get_type($var)); $var = array(test=1,2,3); var_dump(xmlrpc_get_type($var)); $var = array(test=1,test2=2); var_dump(xmlrpc_get_type($var)); echo Done\n; ? --EXPECTF-- string(5) array string(5) array string(5) array string(5) mixed string(6) struct Done -- Edit this bug report at http://bugs.php.net/?id=38898edit=1
#38893 [Opn-Bgs]: Apache says aborted when libphp4.so is loaded
ID: 38893 Updated by: [EMAIL PROTECTED] Reported By: msingh at nexthop dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Redhat Linux 2.6 PHP Version: 4.4.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-09-20 07:37:05] msingh at nexthop dot com Description: When I add LoadModule libphp4.so in httpd.conf and try to start apache it fails to start and displays Abort httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Aborted The backtrace for same is as follows: (gdb) bt bt #0 0x0f9620a8 in kill () from /lib/libc.so.6 #1 0x0faaec70 in pthread_kill () from /lib/libpthread.so.0 #2 0x0faaf03c in raise () from /lib/libpthread.so.0 #3 0x0f961ea4 in raise () from /lib/libc.so.6 #4 0x0f963414 in abort () from /lib/libc.so.6 #5 0x0fa32828 in __deregister_frame_info_bases () from /lib/libc.so.6 #6 0x0fa328a8 in __deregister_frame_info () from /lib/libc.so.6 #7 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #8 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #9 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #10 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #11 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #12 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #13 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #14 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so ---Type return to continue, or q return to quit--- #15 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #16 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #17 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #18 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #19 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so #20 0x0f5e5a38 in __do_global_dtors_aux () from /usr/local/apache2/modules/libphp4.so LDD output for httpd and libphp4.so: bash-3.00# ldd bin/httpd ldd bin/httpd libssl.so.5 = /lib/libssl.so.5 (0x0ffa8000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x0fe6d000) libaprutil-0.so.0 = /usr/local/apache2/lib/libaprutil-0.so.0 (0x0fe35000) libdb-4.3.so = /lib/libdb-4.3.so (0x0fd26000) libexpat.so.0 = /usr/lib/libexpat.so.0 (0x0fce) libapr-0.so.0 = /usr/local/apache2/lib/libapr-0.so.0 (0x0fc99000) librt.so.1 = /lib/librt.so.1 (0x0fc65000) libm.so.6 = /lib/libm.so.6 (0x0fb9a000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x0fb4d000) libnsl.so.1 = /lib/libnsl.so.1 (0x0fb17000) libpthread.so.0 = /lib/libpthread.so.0 (0x0faa6000) libdl.so.2 = /lib/libdl.so.2 (0x0fa83000) libc.so.6 = /lib/libc.so.6 (0x0f92f000) libgssapi_krb5.so.2 = /usr/lib/libgssapi_krb5.so.2 (0x0f8f9000) libkrb5.so.3 = /usr/lib/libkrb5.so.3 (0x0f86a000) libcom_err.so.2 = /lib/libcom_err.so.2 (0x0f847000) libk5crypto.so.3 = /usr/lib/libk5crypto.so.3 (0x0f803000) libresolv.so.2 = /lib/libresolv.so.2 (0x0f7d) libz.so.1 = /usr/lib/libz.so.1 (0x0f79d000) /lib/ld.so.1 (0x3000) libkrb5support.so.0 = /usr/lib/libkrb5support.so.0 (0x0f77a000) bash-3.00# bash-3.00# ldd modules/libphp4.so ldd modules/libphp4.so libcrypt.so.1 = /lib/libcrypt.so.1 (0x6fde9000) libresolv.so.2 = /lib/libresolv.so.2 (0x6fdb6000) libm.so.6 = /lib/libm.so.6 (0x6fceb000) libdl.so.2 = /lib/libdl.so.2 (0x6fcc8000) libnsl.so.1 = /lib/libnsl.so.1 (0x6fc92000) libc.so.6 = /lib/libc.so.6 (0x6fb3e000) /lib/ld.so.1 (0x0800) bash-3.00# bash-3.00# Please suggest on what can be done? Thanks in Advance. -- Edit this bug report at http://bugs.php.net/?id=38893edit=1
#38908 [Opn-Fbk]: big NEGATIVE integers won't overflow on Linux
ID: 38908 Updated by: [EMAIL PROTECTED] Reported By: golikov at hotmail dot com -Status: Open +Status: Feedback Bug Type: Variables related Operating System: Linux (2.6.9-34.0.2.ELsmp) PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Not reproducible. Previous Comments: [2006-09-21 04:14:46] golikov at hotmail dot com Description: If big negative number (-3032250090012579) is converted to integer, php 5.1.6 does not overflow on LINUX and uses max negative integer value (-2147483648) instead. Though on Windows it works as ok. Related bug #30315. Reproduce code: --- $a2 = 2224955379988029; echo $a2 = (int) . (int)$a2 . \n; $a3 = -2224955379988029; echo $a3 = (int) . (int)$a3 . \n; Expected result: 2.224955379988E+015 = (int)-888097219 -2.224955379988E+015 = (int)888097219 Actual result: -- 2.22495537999E+15 = (int)-888097219 -2.22495537999E+15 = (int)-2147483648 -- Edit this bug report at http://bugs.php.net/?id=38908edit=1
#38913 [Opn-Fbk]: dba_open crash for db4
ID: 38913
Updated by: [EMAIL PROTECTED]
Reported By: nemesis at home dot ro
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux kernel 2.6.16
PHP Version: 5.1.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-09-21 15:32:09] nemesis at home dot ro
Description:
Upgrade from php 5.1.2 to 5.1.6 and then dba_open doesn't work anymore
with db4
Reproduce code:
---
?php
var_dump(dba_open('xxx.db', 'c', 'db4'));
?
Expected result:
To print a resouce identifier like
resource(4) of type (dba)
Actual result:
--
Warning: dba_open(xxx.db,r): Driver initialization failed for handler:
db4: Unknown error 140682440 in test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=38913edit=1
#38914 [Opn-Bgs]: mb_htmlentites should be
ID: 38914 Updated by: [EMAIL PROTECTED] Reported By: selecter at gmail dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Gentoo Linux x86_64 PHP Version: 5.1.6 New Comment: PHP6 will have a decent Unicode support. Previous Comments: [2006-09-21 19:08:38] selecter at gmail dot com changed wrong summary once again... [2006-09-21 19:07:34] selecter at gmail dot com Description: htmlentites in unaware of multi-byte strings and I have to assign a desired encoding every time I use this function. I like to use mb_internal_encoding in once place to specify encoding :-) -- Edit this bug report at http://bugs.php.net/?id=38914edit=1
#38916 [Opn-Bgs]: oci iinstant client 10.2.0.2, configure says: libraries not found
ID: 38916 Updated by: [EMAIL PROTECTED] Reported By: schulze-horst at gmx dot net -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: Linux FC4 PHP Version: 5.1.6 New Comment: Which means you don't have either libnzz10.so or libclntsh.so. Both libraries are required. Previous Comments: [2006-09-21 20:43:40] schulze-horst at gmx dot net Description: When trying to build php-5.1.6 (or php-5.0.5) with oci8 instantclient support, configure fails claiming it cannot find the libraries. php-4.4.4 builds fine on the same mashine. BTW this seems to be an old issue occuring again and again with growing Oracle version numbers (cf. e.g. Bug #35471, #30744). Trying pecl extension with ./cvsclean ./buildconf --force does not solve the problem. libtool 1.5.16 autoconf (GNU Autoconf) 2.59 GNU Make 3.80 gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) instantclient-basiclite-linux32-10.2.0.2-20060331 instantclient-sdk-linux32-10.2.0.2-20060331 Reproduce code: --- php-5.1.6 ./configure --enable-memory-limit --with-oci8=instantclient,/usr/lib/oracle/10.2.0.2/client/lib php-5.0.5 ./configure --enable-memory-limit --with-oci8-instant-client=/usr/lib/oracle/10.2.0.2/client/lib Expected result: Expecting ./configure to setup the build environment. Actual result: -- checking for Oracle (OCI8) support... yes checking Oracle Instant Client directory... /usr/lib/oracle/10.2.0.2/client/lib checking Oracle Instant Client SDK header directory... /usr/lib/oracle/10.2.0.2/client/lib/sdk/include checking Oracle Instant Client version... configure: error: Oracle Instant Client libraries not found -- Edit this bug report at http://bugs.php.net/?id=38916edit=1
#38891 [Ver-Opn]: curlwrappers fail
ID: 38891 Updated by: [EMAIL PROTECTED] Reported By: hannes dot magnusson at gmail dot com -Status: Verified +Status: Open Bug Type: cURL related Operating System: FreeBSD PHP Version: 5CVS-2006-09-20 (CVS) New Comment: The segfault is fixed for now, but the driver returns wrong data, so get_headers() still doesn't work with curlwrappers. Previous Comments: [2006-09-20 07:05:02] hannes dot magnusson at gmail dot com Description: The following script fails --with-curlwrappers, works fine without them. Reproduce code: --- php -r 'get_headers(http://example.com;); get_headers(http://example.com;);' Actual result: -- 5.1-cvs: FATAL: emalloc(): Unable to allocate 1515870811 bytes Segmentation fault: 11 (core dumped) #0 0x28c42a17 in kill () from /lib/libc.so.6 #1 0x08257fd9 in _emalloc (size=1515870811, __zend_filename=0x8356700 /usr/src/php/5.1/Zend/zend_API.c, __zend_lineno=1149, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/5.1/Zend/zend_alloc.c:206 #2 0x082583ed in _estrndup (s=0x853d824 \b, length=1515870810, __zend_filename=0x8356700 /usr/src/php/5.1/Zend/zend_API.c, __zend_lineno=1149, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/5.1/Zend/zend_alloc.c:440 #3 0x082712c8 in add_next_index_stringl (arg=0x0, str=0x853d824 \b, length=1515870810, duplicate=1) at /usr/src/php/5.1/Zend/zend_API.c:1149 #4 0x082018de in zif_get_headers (ht=1, return_value=0x853c7a4, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/php/5.1/ext/standard/url.c:683 #5 0x08288b7d in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfe610) at zend_vm_execute.h:200 #6 0x082884e9 in execute (op_array=0x853f524) at zend_vm_execute.h:92 #7 0x082636b3 in zend_eval_string (str=0x853f524 \004, retval_ptr=0x0, string_name=0x835f273 Command line code) at /usr/src/php/5.1/Zend/zend_execute_API.c:1116 #8 0x0826384c in zend_eval_string_ex (str=0xbfbfea80 get_headers(\http://example.com\;); get_headers(\http://example.com\;);, retval_ptr=0x0, string_name=0x835f273 Command line code, handle_exceptions=1) at /usr/src/php/5.1/Zend/zend_execute_API.c:1150 #9 0x082f49b4 in main (argc=3, argv=0xbfbfe958) at /usr/src/php/5.1/sapi/cli/php_cli.c:1182 5.2-cvs: PHP Fatal error: Out of memory (allocated 262144) at /usr/src/php/5.2/Zend/zend_API.c:1205 (tried to allocate 1515870811 bytes) in Command line code on line 1 /usr/src/php/5.2/main/streams/streams.c(386) : Stream of type 'MEMORY' 0x84f0aa4 (path:(null)) was not closed /usr/src/php/5.2/main/streams/streams.c(386) : Stream of type 'cURL' 0x84f07e4 (path:http://example.com) was not closed -- Edit this bug report at http://bugs.php.net/?id=38891edit=1
#38920 [Opn-Bgs]: preg_replace allows backreferences from a replacement string
ID: 38920
Updated by: [EMAIL PROTECTED]
Reported By: jason at vancetech dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: FreeBSD 6.1
PHP Version: 4.4.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2006-09-22 08:13:34] jason at vancetech dot com
Description:
preg_replace allows backreferences from the replacement string which
seems insecure. Parsing every replacement string is necessary when
data comes from a tainted source.
Perl handles this nicely by only allowing backreference's that are used
directly in the replacement text and not contained in a {tainted}
string.
Reproduce code:
---
$text = 'This item costs $0.99';
$html = 'b%COST%No items%COST%/b';
print preg_replace('/%COST%.*?%COST%/i', $text, $html);
Expected result:
bThis item costs $0.99/b
Actual result:
--
This item costs %COST%No items%COST%.99
--
Edit this bug report at http://bugs.php.net/?id=38920edit=1
#37438 [Ana-Fbk]: PDO_MySQL segfaults Apache child
ID: 37438 Updated by: [EMAIL PROTECTED] Reported By: indeyets at gmail dot com -Status: Analyzed +Status: Feedback Bug Type: PDO related Operating System: FreeBSD PHP Version: 5.1.4 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-22 15:49:34] [EMAIL PROTECTED] Bug still exists in 5.1.6 [2006-09-22 15:48:47] [EMAIL PROTECTED] This appears to be a bug related to the Primary Key. I experienced the issue with a table that had an integer primary key (non auto inc) and PHP would segfault if the table had a row who's PK == 0. Deleting the row solved the problem [2006-05-15 10:04:52] [EMAIL PROTECTED] See #37445 for more info. [2006-05-14 16:22:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-05-14 16:15:40] indeyets at gmail dot com Description: After upgrading from 5.1.2 to 5.1.4 apache childs began to segfault at some requests. Backtrace showed, that the problem lies inside of PDO_MySQL. The issue was originally mentioned here: http://pecl.php.net/bugs/bug.php?id=7433 reverting this patch solves the issue: http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12r2=1.48.2.13 Actual result: -- #0 0x2908180a in mysql_more_results () from /usr/local/lib/mysql/libmysqlclient.so.15 #1 0x29064c4c in pdo_mysql_stmt_dtor (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo_mysql/mysql_statement.c:79 #2 0x29022bee in free_statement (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2200 #3 0x29022c63 in pdo_dbstmt_free_storage (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2245 #4 0x28740a46 in ?? () from /usr/local/libexec/apache22/libphp5.so -- Edit this bug report at http://bugs.php.net/?id=37438edit=1
#38919 [Opn-Bgs]: php_mysql.dll unresolved import function _zval_copy_ctor_func
ID: 38919 Updated by: [EMAIL PROTECTED] Reported By: boardman_malibu at yahoo dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: win98se PHP Version: 5.1.6 New Comment: Please make sure you've removed all php4ts.dll and other dlls from PHP4 and then reinstall PHP5. Not PHP problem. Previous Comments: [2006-09-22 20:33:08] boardman_malibu at yahoo dot com edink's highly technical reply would mean that php5ts.dll at some version renamed '_zval_copy_ctor' to '_zval_copy_ctor_func', which would require all php_modules to be recompiled with the new name, sorry not buying it. [2006-09-22 20:16:28] boardman_malibu at yahoo dot com I have never been able to launch php_mysql.dll or php_mysqli.dll. The windows GUI reports that certain unnamed libraries were missing. The dependency walker that comes with visual studio 6 indicates that php_mysql.dll is trying to import the function '_zval_copy_ctor_func' from PHP5ts.dll, which is not there. There is a function called '_zval_copy_ctor' in php5ts.dll. This problem is present in all versions of php_mysql.dll I have tried, including the lastest from mysql.org AND php.net I am currently able to access Mysql 5 with php 4.4.4 with the compiled in client. follow up: There is no function '_zval_copy_ctor_func' in PHP4ts.dll either, which indicates the problem is the php_mysql.dll source. The '_func' at the end is unsual, all the imports are functions, after all. Anybody not running Win98se, don't bother to reply since dll linking by the OS has changed with newer versions. [2006-09-22 14:02:03] [EMAIL PROTECTED] You are most likely mixing dlls from different PHP versions, php_mysql.dll works fine. [2006-09-22 02:50:15] boardman_malibu at yahoo dot com Description: I have never been able to launch php_mysql.dll or php_mysqli.dll. The windows GUI reports that certain unnamed libraries were missing. The dependency walker that comes with visual studio 6 indicates that php_mysql.dll is trying to import the function '_zval_copy_ctor_func' from PHP5ts.dll, which is not there. There is a function called '_zval_copy_ctor' in php5ts.dll. This problem is present in all versions of php_mysql.dll I have tried, including the lastest from mysql.org AND php.net I am currently able to access Mysql 5 with php 4.4.4 with the compiled in client. -- Edit this bug report at http://bugs.php.net/?id=38919edit=1
#38933 [Opn-Bgs]: dirname not support binary file path
ID: 38933 Updated by: [EMAIL PROTECTED] Reported By: foxgoblin at gmail dot com -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: Windows XP PHP Version: 5.1.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-09-23 07:28:38] foxgoblin at gmail dot com Description: function dirname not support binary file path Reproduce code: --- ? echo dirname(c:\\window\\\xd7\xc0\\test); ? Expected result: c:\window\×À Actual result: -- c:\window -- Edit this bug report at http://bugs.php.net/?id=38933edit=1
#38935 [NEW]: Strange results or object to array cast
From: marcus at synchromedia dot co dot uk
Operating system: All
PHP version: 5.1.6
PHP Bug Type: Class/Object related
Bug description: Strange results or object to array cast
Description:
When you cast an object to an array, and the object contains
private or protected members, the resulting array keys are
effectively corrupted.
Private members get the object class prepended to their
name. Protected members get a '*' prepended to their name.
The docs say:
If you convert an object to an array, you get the
properties (member variables) of that object as the array's
elements. The keys are the member variable names.
In reality, this is not true.
I don't see any real value in preserving access levels -
arrays are not objects and they should not try to behave as
them. You can find out the access level via introspection if
you really need it, and by definition you have an instance
handy to look at.
If it's intentional, it's not very helpful. As there's no
separator between class name and variable name it's
impossible to separate it correctly - if I had a property
called 'Myclassfield1' in a Myclass instance, I would not be
able to tell if it was a public property called
'Myclassfield1' or a private property called 'field1'.
As this is deviating from documented behaviour and it's also
fairly useless as it stands, I don't see any reason for
keeping it like this.
Reproduce code:
---
?php
class Myclass {
public $field1 = '';
private $field2 = '';
protected $field3 = '';
}
$myclass = new Myclass;
var_dump($myclass);
var_dump((array)$myclass);
?
Expected result:
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[field2]=
string(0)
[field3]=
string(0)
}
Actual result:
--
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[Myclassfield2]=
string(0)
[*field3]=
string(0)
}
--
Edit bug report at http://bugs.php.net/?id=38935edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38935r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38935r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38935r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38935r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38935r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38935r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38935r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38935r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38935r=support
Expected behavior:http://bugs.php.net/fix.php?id=38935r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38935r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38935r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38935r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38935r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38935r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38935r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38935r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38935r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38935r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38935r=mysqlcfg
#38935 [Opn-Bgs]: Strange results or object to array cast
ID: 38935
Updated by: [EMAIL PROTECTED]
Reported By: marcus at synchromedia dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: All
PHP Version: 5.1.6
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
The class information is needed, see for example
class A {
private $p;
}
class B extends A {
private $p;
}
var_dump((array)new B());
Previous Comments:
[2006-09-23 15:31:13] marcus at synchromedia dot co dot uk
Description:
When you cast an object to an array, and the object contains
private or protected members, the resulting array keys are
effectively corrupted.
Private members get the object class prepended to their
name. Protected members get a '*' prepended to their name.
The docs say:
If you convert an object to an array, you get the
properties (member variables) of that object as the array's
elements. The keys are the member variable names.
In reality, this is not true.
I don't see any real value in preserving access levels -
arrays are not objects and they should not try to behave as
them. You can find out the access level via introspection if
you really need it, and by definition you have an instance
handy to look at.
If it's intentional, it's not very helpful. As there's no
separator between class name and variable name it's
impossible to separate it correctly - if I had a property
called 'Myclassfield1' in a Myclass instance, I would not be
able to tell if it was a public property called
'Myclassfield1' or a private property called 'field1'.
As this is deviating from documented behaviour and it's also
fairly useless as it stands, I don't see any reason for
keeping it like this.
Reproduce code:
---
?php
class Myclass {
public $field1 = '';
private $field2 = '';
protected $field3 = '';
}
$myclass = new Myclass;
var_dump($myclass);
var_dump((array)$myclass);
?
Expected result:
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[field2]=
string(0)
[field3]=
string(0)
}
Actual result:
--
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[Myclassfield2]=
string(0)
[*field3]=
string(0)
}
--
Edit this bug report at http://bugs.php.net/?id=38935edit=1
#38935 [Bgs]: Strange results for object to array cast
ID: 38935
User updated by: marcus at synchromedia dot co dot uk
-Summary: Strange results or object to array cast
Reported By: marcus at synchromedia dot co dot uk
Status: Bogus
Bug Type: Class/Object related
Operating System: All
PHP Version: 5.1.6
New Comment:
I'm sorry but that's a bogus explanation. Please double-
check the documentation? What you describe is contrary to
the documentation.
The reasoning you express also fails completely on my point
about there being no separator between class name and
property name. How can you consider this to be reasonable
behaviour?:
class A {
private $A;
}
class B extends A {
private $A;
public $AA;
}
var_dump((array)new B());
array(3) {
[BA]=
NULL
[AA]=
NULL
[AA]=
NULL
}
Given that this undocumented behaviour is thus proven
ambiguous, unreliable and contrary to existing docs, how can
you say that it's 'needed'? Are you saying that there's
widespread code that depends on this weirdness, when 99% of
use cases will not expect it?
At the very least this is a valid documentation bug.
Previous Comments:
[2006-09-23 16:09:53] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The class information is needed, see for example
class A {
private $p;
}
class B extends A {
private $p;
}
var_dump((array)new B());
[2006-09-23 15:31:13] marcus at synchromedia dot co dot uk
Description:
When you cast an object to an array, and the object contains
private or protected members, the resulting array keys are
effectively corrupted.
Private members get the object class prepended to their
name. Protected members get a '*' prepended to their name.
The docs say:
If you convert an object to an array, you get the
properties (member variables) of that object as the array's
elements. The keys are the member variable names.
In reality, this is not true.
I don't see any real value in preserving access levels -
arrays are not objects and they should not try to behave as
them. You can find out the access level via introspection if
you really need it, and by definition you have an instance
handy to look at.
If it's intentional, it's not very helpful. As there's no
separator between class name and variable name it's
impossible to separate it correctly - if I had a property
called 'Myclassfield1' in a Myclass instance, I would not be
able to tell if it was a public property called
'Myclassfield1' or a private property called 'field1'.
As this is deviating from documented behaviour and it's also
fairly useless as it stands, I don't see any reason for
keeping it like this.
Reproduce code:
---
?php
class Myclass {
public $field1 = '';
private $field2 = '';
protected $field3 = '';
}
$myclass = new Myclass;
var_dump($myclass);
var_dump((array)$myclass);
?
Expected result:
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[field2]=
string(0)
[field3]=
string(0)
}
Actual result:
--
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[Myclassfield2]=
string(0)
[*field3]=
string(0)
}
--
Edit this bug report at http://bugs.php.net/?id=38935edit=1
#38913 [Fbk-Opn]: dba_open crash for db4
ID: 38913
User updated by: nemesis at home dot ro
Reported By: nemesis at home dot ro
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux kernel 2.6.16
PHP Version: 5.1.6
New Comment:
Yes, it works (the linux version, the windows version does not have db4
built in (only db3))
Is there any time table for backporting this fix to the 5.1 series ?
Previous Comments:
[2006-09-23 11:54:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-09-21 15:32:09] nemesis at home dot ro
Description:
Upgrade from php 5.1.2 to 5.1.6 and then dba_open doesn't work anymore
with db4
Reproduce code:
---
?php
var_dump(dba_open('xxx.db', 'c', 'db4'));
?
Expected result:
To print a resouce identifier like
resource(4) of type (dba)
Actual result:
--
Warning: dba_open(xxx.db,r): Driver initialization failed for handler:
db4: Unknown error 140682440 in test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=38913edit=1
#38935 [Bgs]: Strange results for object to array cast
ID: 38935
Updated by: [EMAIL PROTECTED]
Reported By: marcus at synchromedia dot co dot uk
Status: Bogus
Bug Type: Class/Object related
Operating System: All
PHP Version: 5.1.6
New Comment:
There are separators, null bytes.
Previous Comments:
[2006-09-23 16:39:22] marcus at synchromedia dot co dot uk
I'm sorry but that's a bogus explanation. Please double-
check the documentation? What you describe is contrary to
the documentation.
The reasoning you express also fails completely on my point
about there being no separator between class name and
property name. How can you consider this to be reasonable
behaviour?:
class A {
private $A;
}
class B extends A {
private $A;
public $AA;
}
var_dump((array)new B());
array(3) {
[BA]=
NULL
[AA]=
NULL
[AA]=
NULL
}
Given that this undocumented behaviour is thus proven
ambiguous, unreliable and contrary to existing docs, how can
you say that it's 'needed'? Are you saying that there's
widespread code that depends on this weirdness, when 99% of
use cases will not expect it?
At the very least this is a valid documentation bug.
[2006-09-23 16:09:53] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The class information is needed, see for example
class A {
private $p;
}
class B extends A {
private $p;
}
var_dump((array)new B());
[2006-09-23 15:31:13] marcus at synchromedia dot co dot uk
Description:
When you cast an object to an array, and the object contains
private or protected members, the resulting array keys are
effectively corrupted.
Private members get the object class prepended to their
name. Protected members get a '*' prepended to their name.
The docs say:
If you convert an object to an array, you get the
properties (member variables) of that object as the array's
elements. The keys are the member variable names.
In reality, this is not true.
I don't see any real value in preserving access levels -
arrays are not objects and they should not try to behave as
them. You can find out the access level via introspection if
you really need it, and by definition you have an instance
handy to look at.
If it's intentional, it's not very helpful. As there's no
separator between class name and variable name it's
impossible to separate it correctly - if I had a property
called 'Myclassfield1' in a Myclass instance, I would not be
able to tell if it was a public property called
'Myclassfield1' or a private property called 'field1'.
As this is deviating from documented behaviour and it's also
fairly useless as it stands, I don't see any reason for
keeping it like this.
Reproduce code:
---
?php
class Myclass {
public $field1 = '';
private $field2 = '';
protected $field3 = '';
}
$myclass = new Myclass;
var_dump($myclass);
var_dump((array)$myclass);
?
Expected result:
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[field2]=
string(0)
[field3]=
string(0)
}
Actual result:
--
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
array(3) {
[field1]=
string(0)
[Myclassfield2]=
string(0)
[*field3]=
string(0)
}
--
Edit this bug report at http://bugs.php.net/?id=38935edit=1
#38935 [Bgs]: Strange results for object to array cast
ID: 38935
User updated by: marcus at synchromedia dot co dot uk
Reported By: marcus at synchromedia dot co dot uk
Status: Bogus
Bug Type: Class/Object related
Operating System: All
PHP Version: 5.1.6
New Comment:
Well, that's good to know, but it does mean that you're
justifying undocumented behaviour with yet more undocumented
behaviour.
I see that these null bytes are there, but they're not
separators; they're prefixes to both class and property
name, that is, the resulting array keys are of the form:
NULLclassnameNULLpropertyname
I still fail to see how this is bogus when it's so wildly
different to what's documented, and is implemented in such a
way as to be useful in only the most obtuse of situations,
to the detriment of all other occasions. One change that
would make all this much more palatable while preserving the
additional information AND conforming closer to the docs:
only provide extended class information for properties that
are NOT in the current class. For example:
?php
class A {
private $A;
}
class B extends A {
private $A;
public $B;
}
$a = (array)new B;
foreach($a as $k = $v) {
echo bin2hex($k).\n;
}
?
At present this produces:
00420041
00410041
My suggestion is to change that to:
00420041
41
That way we will be in the situation that all unambiguous
properties in the current class are available using their
unmodified names, just like the docs say. The only remaining
issue is with protected values - I don't know that
preserving that status is of much value anyway - it's not as
if you can cast back from an array to an object anyway.
Previous Comments:
[2006-09-23 17:34:44] [EMAIL PROTECTED]
There are separators, null bytes.
[2006-09-23 16:39:22] marcus at synchromedia dot co dot uk
I'm sorry but that's a bogus explanation. Please double-
check the documentation? What you describe is contrary to
the documentation.
The reasoning you express also fails completely on my point
about there being no separator between class name and
property name. How can you consider this to be reasonable
behaviour?:
class A {
private $A;
}
class B extends A {
private $A;
public $AA;
}
var_dump((array)new B());
array(3) {
[BA]=
NULL
[AA]=
NULL
[AA]=
NULL
}
Given that this undocumented behaviour is thus proven
ambiguous, unreliable and contrary to existing docs, how can
you say that it's 'needed'? Are you saying that there's
widespread code that depends on this weirdness, when 99% of
use cases will not expect it?
At the very least this is a valid documentation bug.
[2006-09-23 16:09:53] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The class information is needed, see for example
class A {
private $p;
}
class B extends A {
private $p;
}
var_dump((array)new B());
[2006-09-23 15:31:13] marcus at synchromedia dot co dot uk
Description:
When you cast an object to an array, and the object contains
private or protected members, the resulting array keys are
effectively corrupted.
Private members get the object class prepended to their
name. Protected members get a '*' prepended to their name.
The docs say:
If you convert an object to an array, you get the
properties (member variables) of that object as the array's
elements. The keys are the member variable names.
In reality, this is not true.
I don't see any real value in preserving access levels -
arrays are not objects and they should not try to behave as
them. You can find out the access level via introspection if
you really need it, and by definition you have an instance
handy to look at.
If it's intentional, it's not very helpful. As there's no
separator between class name and variable name it's
impossible to separate it correctly - if I had a property
called 'Myclassfield1' in a Myclass instance, I would not be
able to tell if it was a public property called
'Myclassfield1' or a private property called 'field1'.
As this is deviating from documented behaviour and it's also
fairly useless as it stands, I don't see any reason for
keeping it like this.
Reproduce code:
---
?php
class Myclass {
public $field1 = '';
private $field2 = '';
protected $field3 = '';
}
$myclass = new Myclass;
var_dump($myclass);
var_dump((array)$myclass);
?
Expected result:
object(Myclass)#1 (3) {
[field1]=
string(0)
[field2:private]=
string(0)
[field3:protected]=
string(0)
}
#38919 [Bgs-Opn]: php_mysql.dll unresolved import function _zval_copy_ctor_func
ID: 38919 User updated by: boardman_malibu at yahoo dot com Reported By: boardman_malibu at yahoo dot com -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: win98se PHP Version: 5.1.6 New Comment: tony2001 also fails to address the issue. Please read again that visual studio dependency walker identified the bad import call. it had no problem identifing which dll was which. I would like to know how the php_mysql.dll binary from php.net was compiled without a warning of this problem. I also need to repeat that there is no function '_zval_copy_ctor_func' in either php4ts.dll or php5ts.dll, so dll versions have nothing to do with this. I hope the next comment will be from someone familiar with the source code. Previous Comments: [2006-09-23 12:08:40] [EMAIL PROTECTED] Please make sure you've removed all php4ts.dll and other dlls from PHP4 and then reinstall PHP5. Not PHP problem. [2006-09-22 20:33:08] boardman_malibu at yahoo dot com edink's highly technical reply would mean that php5ts.dll at some version renamed '_zval_copy_ctor' to '_zval_copy_ctor_func', which would require all php_modules to be recompiled with the new name, sorry not buying it. [2006-09-22 20:16:28] boardman_malibu at yahoo dot com I have never been able to launch php_mysql.dll or php_mysqli.dll. The windows GUI reports that certain unnamed libraries were missing. The dependency walker that comes with visual studio 6 indicates that php_mysql.dll is trying to import the function '_zval_copy_ctor_func' from PHP5ts.dll, which is not there. There is a function called '_zval_copy_ctor' in php5ts.dll. This problem is present in all versions of php_mysql.dll I have tried, including the lastest from mysql.org AND php.net I am currently able to access Mysql 5 with php 4.4.4 with the compiled in client. follow up: There is no function '_zval_copy_ctor_func' in PHP4ts.dll either, which indicates the problem is the php_mysql.dll source. The '_func' at the end is unsual, all the imports are functions, after all. Anybody not running Win98se, don't bother to reply since dll linking by the OS has changed with newer versions. [2006-09-22 14:02:03] [EMAIL PROTECTED] You are most likely mixing dlls from different PHP versions, php_mysql.dll works fine. [2006-09-22 02:50:15] boardman_malibu at yahoo dot com Description: I have never been able to launch php_mysql.dll or php_mysqli.dll. The windows GUI reports that certain unnamed libraries were missing. The dependency walker that comes with visual studio 6 indicates that php_mysql.dll is trying to import the function '_zval_copy_ctor_func' from PHP5ts.dll, which is not there. There is a function called '_zval_copy_ctor' in php5ts.dll. This problem is present in all versions of php_mysql.dll I have tried, including the lastest from mysql.org AND php.net I am currently able to access Mysql 5 with php 4.4.4 with the compiled in client. -- Edit this bug report at http://bugs.php.net/?id=38919edit=1
#38937 [NEW]: openssl_csr_parse()
From: bassijunior at yahoo dot com dot br Operating system: Windows XP PHP version: 5.1.6 PHP Bug Type: Feature/Change Request Bug description: openssl_csr_parse() Description: I need to open a certificate request like one array, like I did with the X.509 certificate. To verify a X.509 certificate I use openssl_x509_parse( mixed x509cert [, bool shortnames]). And about the certificate request? I want to do the same that i did with certificate.How Can read it? Is there any function to do that? -- Edit bug report at http://bugs.php.net/?id=38937edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38937r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38937r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38937r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38937r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38937r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38937r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38937r=needscript Try newer version:http://bugs.php.net/fix.php?id=38937r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38937r=support Expected behavior:http://bugs.php.net/fix.php?id=38937r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38937r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38937r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38937r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38937r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38937r=dst IIS Stability:http://bugs.php.net/fix.php?id=38937r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38937r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38937r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38937r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38937r=mysqlcfg
#38938 [NEW]: more useful initialization for strptime
From: soletan at toxa dot de
Operating system: Linux
PHP version: 5CVS-2006-09-23 (snap)
PHP Bug Type: Date/time related
Bug description: more useful initialization for strptime
Description:
Hi,
in addition to bug #38524 I'd prefer initializing call to strptime in a
more useful way. While it is easiest way to memset all with 0's, some
fields like tm_mon can't be interpreted properly.
My proposal uses 0xFF for initialization to get all values set -1.
Then in addition, I add array element value NULL on every field that
wasn't touched by strptime. I consider this to be quite common behaviour
in PHP ...
Below is my proposal for a patch on latest CVS snapshot.
Best Regards,
Thomas Urban
*** datetime.c.orig 2006-08-24 14:30:57.0 +0200
--- datetime.c 2006-09-24 02:16:09.0 +0200
***
*** 101,107
return;
}
! memset(parsed_time, 0, sizeof(parsed_time));
unparsed_part = strptime(ts, format, parsed_time);
if (unparsed_part == NULL) {
--- 101,107
return;
}
! memset(parsed_time, 0xFF, sizeof(parsed_time));
unparsed_part = strptime(ts, format, parsed_time);
if (unparsed_part == NULL) {
***
*** 109,122
}
array_init(return_value);
! add_assoc_long(return_value, tm_sec, parsed_time.tm_sec);
! add_assoc_long(return_value, tm_min, parsed_time.tm_min);
! add_assoc_long(return_value, tm_hour, parsed_time.tm_hour);
! add_assoc_long(return_value, tm_mday, parsed_time.tm_mday);
! add_assoc_long(return_value, tm_mon, parsed_time.tm_mon);
! add_assoc_long(return_value, tm_year, parsed_time.tm_year);
! add_assoc_long(return_value, tm_wday, parsed_time.tm_wday);
! add_assoc_long(return_value, tm_yday, parsed_time.tm_yday);
add_assoc_string(return_value, unparsed, unparsed_part, 1);
}
/* }}} */
--- 109,146
}
array_init(return_value);
! if ( parsed_time.tm_sec 0 )
! add_assoc_null(return_value, tm_sec);
! else
! add_assoc_long(return_value, tm_sec, parsed_time.tm_sec);
! if ( parsed_time.tm_min 0 )
! add_assoc_null(return_value, tm_min);
! else
! add_assoc_long(return_value, tm_min, parsed_time.tm_min);
! if ( parsed_time.tm_hour 0 )
! add_assoc_null(return_value, tm_hour);
! else
! add_assoc_long(return_value, tm_hour, parsed_time.tm_hour);
! if ( parsed_time.tm_mday 0 )
! add_assoc_null(return_value, tm_mday);
! else
! add_assoc_long(return_value, tm_mday, parsed_time.tm_mday);
! if ( parsed_time.tm_mon 0 )
! add_assoc_null(return_value, tm_mon);
! else
! add_assoc_long(return_value, tm_mon, parsed_time.tm_mon);
! if ( parsed_time.tm_year 0 )
! add_assoc_null(return_value, tm_year);
! else
! add_assoc_long(return_value, tm_year, parsed_time.tm_year);
! if ( parsed_time.tm_wday 0 )
! add_assoc_null(return_value, tm_wday);
! else
! add_assoc_long(return_value, tm_wday, parsed_time.tm_wday);
! if ( parsed_time.tm_yday 0 )
! add_assoc_null(return_value, tm_yday);
! else
! add_assoc_long(return_value, tm_yday, parsed_time.tm_yday);
add_assoc_string(return_value, unparsed, unparsed_part, 1);
}
/* }}} */
--
Edit bug report at http://bugs.php.net/?id=38938edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38938r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38938r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38938r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38938r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38938r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38938r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38938r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38938r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38938r=support
Expected behavior:http://bugs.php.net/fix.php?id=38938r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38938r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38938r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38938r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38938r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38938r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38938r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38938r=gnused
#38819 [Fbk-Opn]: segfault in ldap_get_entries()
ID: 38819 User updated by: madcoder at gmail dot com Reported By: madcoder at gmail dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: My configure line (generated by gentoo's portage): - './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2' '--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5' '--with-config-file-scan-dir=/etc/php/-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--disable-ctype' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--without-hwapi' '--without-iconv' '--without-informix' '--disable-ipv6' '--without-kerberos' '--disable-mbstring' '--with-mcrypt' '--enable-memory-limit' '--without-mhash' '--without-ming' '--without-msql' '--with-mssql' '--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp' '--enable-soap' '--enable-sockets' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm' '--without-inifile' '--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap' '--without-ldap-sasl' '--with-mysql=/usr/lib/mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--disable-sqlite-utf8' - The version of MySQL is: Client API version 4.1.21 My Gentoo portage USE flags for dev-lang/php: [ebuild R ] dev-lang/php-5.1.6-r4 USE=apache2 berkdb bzip2 cli crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls pcre pdo-external postgres readline reflection session simplexml snmp soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile -force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos -libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic -posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc -truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc -xmlwriter -yaz -zip I have also compiled with pdo-external, including dblib, mysql, pgsql, and sqlite support. The pdo-mysql version is the same library (4.1.21). I can recompile without mysql support to see if that might be part of it? Or PDO? Previous Comments: [2006-09-23 11:32:03] [EMAIL PROTECTED] What was your configure line and did you enable any of mysql related extensions? If yes, then what is the version of MySQL? [2006-09-19 19:54:19] madcoder at gmail dot com Apparently it looks like pastebin is having problems... I've copied the same output here, for redundancy: http://www.framewerk.org/~madcoder/vgrind.log [2006-09-19 19:49:48] madcoder at gmail dot com I ran it through valgrind with --leak-check=full -v --show-reachable=yes, and copied the output here: http://pastebin.com/790150 [2006-09-19 19:39:47] madcoder at gmail dot com Now that's interesting... It runs fine with valgrind. Here are the ERROR SUMMARY and LEAK SUMMARY sections: ==7964== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 93 from 1) ==7964== malloc/free: in use at exit: 71,780 bytes in 1,268 blocks. ==7964== malloc/free: 38,082 allocs, 36,814 frees, 3,611,397 bytes allocated. ==7964== For counts of detected errors, rerun with: -v ==7964== searching for pointers to 1,268 not-freed blocks. ==7964== checked 2,962,048 bytes. ==7964== LEAK SUMMARY: ==7964==definitely lost: 32,841 bytes in 4 blocks. ==7964== possibly lost: 0 bytes in 0 blocks. ==7964==still reachable: 38,939 bytes in 1,264 blocks. ==7964== suppressed: 0 bytes in 0 blocks. ==7964== Use
