Bug #63558 [Fbk-NoF]: Random crash in php-fpm
Edit report at https://bugs.php.net/bug.php?id=63558edit=1 ID: 63558 Updated by: php-bugs@lists.php.net Reported by: goelvivek2011 at gmail dot com Summary: Random crash in php-fpm -Status: Feedback +Status: No Feedback Type: Bug Package: SQLite related Operating System: amazon-linux PHP Version: 5.3.18 Private report: N New Comment: 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 Re-Opened. Thank you. Previous Comments: [2013-10-24 06:52:38] yohg...@php.net By the way, we don't fix 5.3 bug anymore. Try it with 5.4. [2013-10-24 06:51:41] yohg...@php.net I guess amazon-linux also has debuginfo packages. To identify which packages you need, use gdb and read start up message. (i.e. execute 'gdb php-cgi') Then you can get better backtrace. [2012-11-20 06:14:39] goelvivek2011 at gmail dot com @laruence How to identify the cause? What all can go wrong in this flow? [2012-11-20 02:55:41] larue...@php.net according to your description, I think maybe not a fpm issue, but sqlite3 [2012-11-19 07:30:29] goelvivek2011 at gmail dot com Description: Description: php-fpm is randomly crashing with error message: WARNING: [pool www] child 20063 exited on signal 11 (SIGSEGV - core dumped) after 187826.894044 seconds from start PHP package details: PHP 5.3.18 (cli) (built: Nov 5 2012 19:35:04) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies Configuration command: Configure Command = './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-amazon-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable- ftp' '--enable-magic-quotes' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--without-sqlite' '--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--with-mhash' '--enable-force-cgi-redirect' '--libdir=/usr/lib64/php' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbregex' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--enable-mysqlnd=shared' '--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--enable-dom=shared' '--with-pgsql=shared' '--enable-wddx=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--with-curl=shared,/usr' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-pgsql=shared,/usr' '--with-pdo- sqlite=shared,/usr' '--with-pdo-dblib=shared,/usr' '--with-sqlite3=shared,/usr' '--enable-json=shared' '--enable-zip=shared,/usr' '--without-readline' '--with-libedit' '--with-pspell=shared' '--enable-phar=shared' '--with-mcrypt=shared,/usr' '--with-tidy=shared,/usr' '--with-mssql=shared,/usr' '--enable-sysvmsg=shared' '--enable-sysvshm=shared' '--enable-sysvsem=shared' '--enable-posix=shared' '--with-unixODBC=shared,/usr' '--enable-fileinfo=shared' '--enable-intl=shared' '--with-icu-dir=/usr' '--with-enchant=no' '--with-recode=shared,/usr' Any other information unique or specific to your setup: We are custom compiling sqlite3 extension. For compilation we followed following steps: 1. Download php source code. 2. Download latest sqlite3 source code. 3. Copy latest sqlite files to ext/sqlite3/libsqlite/ folder. 4
Bug #63355 [Fbk-NoF]: PHP 5.3.x failes with core dump
Edit report at https://bugs.php.net/bug.php?id=63355edit=1 ID: 63355 Updated by: php-bugs@lists.php.net Reported by: rainer dot herbst at uni-potsdam dot de Summary: PHP 5.3.x failes with core dump -Status: Feedback +Status: No Feedback Type: Bug Package: Reproducible crash Operating System: Solaris 10 SPARC PHP Version: 5.3.18 Private report: N New Comment: 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 Re-Opened. Thank you. Previous Comments: [2013-10-24 07:33:20] yohg...@php.net Since we don't fix bugs in 5.3, could you try to see if 5.4 or later segfaults. [2012-11-12 14:25:39] rainer dot herbst at uni-potsdam dot de The core dumps with the zend_hash_find problem occure when APC is disabled. With APC enabled, we find zend_vm_stack_alloc in the core dumps. [2012-11-12 13:36:02] johan...@php.net Does this also happen without APC? Any chance to get som ereproduce code? hard to identify otherwise. [2012-11-12 09:46:05] rainer dot herbst at uni-potsdam dot de Disabling APC does not solve the Problem. In both php 5.3. and 5.4 we still receive core dumps like this: core '/var/cores/n-moodle2-6.1352712335.24296.httpd' of 24296: /opt/zeik/apache24/sbin/httpd -k start -f /opt/site/etc/httpd/httpd.co fe09de40 zend_hash_find (fe646b24, 21b888, 25, ffbff180, ff, 6f646c65) + 50 fe018e10 zend_set_compiled_filename (21b888, 2252, ffbff1f8, 21ba68, 24, 0) + 48 fdfdbabc open_file_for_scanning (ffbff4c8, 1, ffc0, 21b888, 0, 0) + 304 fdfdbbec compile_file (ffbff4c8, 2, 0, 0, 21b7c8, 21b7c8) + 94 fd9a20f0 phar_compile_file (ffbff4c8, 2, ffc0, 80, 540ba4, 48) + 3b8 fe07e7e8 zend_execute_scripts (2, 0, 1, ffbff4c8, 70687000, 7068702d) + 140 fe19e6dc php_handler (53ee28, e1, 0, 1231d8, 127920, 0) + 74c 0005c534 ap_run_handler (53ee28, 53f9f0, 0, 1413b8, , 1) + 8c 0005d1c4 ap_invoke_handler (53ee28, 0, 53ede8, 0, 0, 0) + 154 0007da90 ap_process_async_request (53ee28, 0, 4, 4b0870, 0, 4) + 488 0007dba4 ap_process_request (53ee28, 4, 53ee28, 53fa50, 0, 4b0870) + 24 00078edc ap_process_http_sync_connection (4b0870, 4b0b20, 0, 4b05d8, 53ee28, 4b0b08) + 7c 0007903c ap_process_http_connection (4b0870, 4b05d8, 4b05d8, 4b0b20, 0, 0) + 64 0006c1f4 ap_run_process_connection (4b0870, 4b05d8, 4b05d8, 1416f0, , 0) + 8c 0006c8c8 ap_process_connection (4b0870, 4b05d8, 4b05d8, 14, 4ae638, 4b45a8) + 60 0008746c child_main (14, 86398, 0, da6d8, 4b0870, 0) + 93c 0008775c make_child (dfd18, 14, 0, 0, 1cf4, fefb6100) + 1f4 00087820 startup_children (20, 2, 97fe4, 1415f8, 14, 1) + 90 00087f7c prefork_run (ba940, 11a108, dfd18, 0, 0, b4928) + 254 000379bc ap_run_mpm (ba940, 11a108, dfd18, f2050, , 0) + 9c 0002e01c main (5, ffbffd4c, ffbffd64, ac800, ff0e0100, 0) + 12ec 0002ba38 _start (0, 0, 0, 0, 0, 0) + d8 zend_hash_find is quite a short function, so it should not be so difficult to find the reason for this annoying instability... [2012-10-30 12:01:18] rainer dot herbst at uni-potsdam dot de Compiled the latest APC version (3.1.13), but same behaviour: - core dumps with fe256d98 zend_vm_stack_alloc (1040, ffbff478, fe222de8, 0, 0, 0) + 110 - Service brought to maintenance modus every now and than. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63355 -- Edit this bug report at https://bugs.php.net/bug.php?id=63355edit=1
Bug #51271 [Fbk-NoF]: CLI script + Sockets + Windows causes hang/pause at end of script execution
Edit report at https://bugs.php.net/bug.php?id=51271edit=1 ID: 51271 Updated by: php-bugs@lists.php.net Reported by: funnymonkeybanana at gmail dot com Summary: CLI script + Sockets + Windows causes hang/pause at end of script execution -Status: Feedback +Status: No Feedback Type: Bug Package: CGI/CLI related Operating System: win32 only PHP Version: 5.2.13 Private report: N New Comment: 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 Re-Opened. Thank you. Previous Comments: [2013-10-24 08:11:33] yohg...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-11 02:45:51] funnymonkeybanana at gmail dot com Description: I've experienced this problem for years but have never bothered to report it until now. I write a lot of command-line PHP scripts and I've found that scripts that do not attempt to open a socket connection terminate immediately at the end of the program. However, scripts that contact remote (or even 'localhost') servers (i.e. open a socket during script execution) hang for about 5 seconds before returning control to the command prompt. I only experience this issue on Windows machines. Linux and OSX boxes seem unaffected. Test script: --- ?php file_get_contents(http://www.google.com/;); echo Hi!\n; ? Expected result: Return to the command prompt as soon as the Hi! is output. Actual result: -- Reaches the end of the script (after displaying Hi!) and simply hangs for 5 seconds or so. -- Edit this bug report at https://bugs.php.net/bug.php?id=51271edit=1
Bug #64057 [Fbk-NoF]: substr_replace failed charset utf-8
Edit report at https://bugs.php.net/bug.php?id=64057edit=1 ID: 64057 Updated by: php-bugs@lists.php.net Reported by: ltsujiguchi at gmail dot com Summary: substr_replace failed charset utf-8 -Status: Feedback +Status: No Feedback Type: Bug Package: Strings related Operating System: Ubuntu 12.10 PHP Version: 5.4.11 Private report: N New Comment: 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 Re-Opened. Thank you. Previous Comments: [2013-10-24 06:32:39] yohg...@php.net Taking look at the source code, I don't see the cause of this report. I also get http://3v4l.org/FMSW9 Try to ask Ubuntu developers. [2013-10-10 07:36:31] datib...@php.net Couldn't reproduce this on quite a few versions; see also: http://3v4l.org/FMSW9 [2013-01-26 13:54:01] ltsujiguchi at gmail dot com Using echo bin2hex($cond); Return: 6e6f74696369612e6e6f74696369615f746974756c6f204c494b452025c3a925204f52206e6f74696 369615f6e6f74696369615f636f6e746575646f204c494b4525c3a9253f [2013-01-26 13:50:36] ltsujiguchi at gmail dot com Update comment above: [2013-01-26 13:37 UTC] ltsujiguchi at gmail dot com Using source in gedit new file Manually ?php $replacement = '%éééééááááá%'; $cond = 'noticia.noticia_titulo LIKE ? OR noticia.noticia_conteudo LIKE ?'; $posItem = stripos($cond, '?'); $cond = substr_replace($cond, $replacement, $posItem, 1); $posItem = stripos($cond, '?'); $cond = substr_replace($cond, $replacement, $posItem, 1); echo $cond; ? Result: noticia.noticia_titulo LIKE %éééééááááá% OR noticia.noticia_cont%éééééááááá%udo LIKE ? [2013-01-26 13:42:04] ltsujiguchi at gmail dot com Concatenating solved using substr. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64057 -- Edit this bug report at https://bugs.php.net/bug.php?id=64057edit=1
Bug #65796 [Com]: mkdir creates folders with wrong permissions
Edit report at https://bugs.php.net/bug.php?id=65796edit=1
ID: 65796
Comment by: leight+bugs dot php at gmail dot com
Reported by:cmfcmf dot flach at gmail dot com
Summary:mkdir creates folders with wrong permissions
Status: Not a bug
Type: Bug
Package:Directory function related
Operating System: Linux/Ubuntu 13.4
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I suspect your umask is 022. The manual states that the mode is modified by
your current umask. Try a umask(0) and see if it is still an issue.
Previous Comments:
[2013-10-01 09:53:40] m...@php.net
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
Check your umask.
[2013-10-01 09:48:19] d...@php.net
I get the same on PHP 5.5.3. chmod('test', 0777) then transforms the directory
to
the right chmod.
[2013-10-01 09:44:10] cmfcmf dot flach at gmail dot com
Description:
Creating a directory using mkdir() does not respect the permissions given.
Test script:
---
?php
// Create a folder with 0777 permissions.
mkdir('test', 0777);
// Should be 0777, but is 0755.
echo substr(sprintf('%o', fileperms('test')), -4);
Expected result:
I expect the folder to be created with 0777 permission.
Actual result:
--
The folder is created with 0755 permission.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65796edit=1
Bug #65647 [Com]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1
ID: 65647
Comment by: leight+bugs dot php at gmail dot com
Reported by:piotr dot m at shwrm dot com
Summary:@list call behaves incorrectly and may cause
Segmentation fault (11)
Status: Open
Type: Bug
Package:*General Issues
Operating System: Linux / Ubuntu 13.04
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Unable to reproduce with 5.5.3 or 5.6.0-dev on Debian 7 or OSX using PHP CLI
(unable to test with Apache at present).
Piotr do you get the same results using the CLI? What other modules do you have
loaded?
A backtrace of the coredump might also be useful.
Previous Comments:
[2013-09-10 09:21:08] piotr dot m at shwrm dot com
Description:
Call to @list on an array returned by function_get_args() will incorrectly fill
variables (only last one is filled) 80% of the time and will cause a
Segmentation fault (11) on the other 20%.
PHP 5.5.3 run on Apache 2.2.22
Test script:
---
function a() {
$opts = func_get_args();
@list($a, $b, $c) = $opts;
var_dump($a, $b, $c);
}
a('1','22', '333');
Expected result:
string '1' (length=1)
string '22' (length=2)
string '333' (length=3)
Actual result:
--
null
null
string '333' (length=3)
Or segfault:
[Tue Sep 10 10:57:46 2013] [notice] child pid 32315 exit signal Segmentation
fault (11), possible coredump in /etc/apache2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65647edit=1
[PHP-BUG] Bug #65387 [NEW]: Memleak:Circular references on callbacks can't be resolved by Garbage Collector
From: bugs dot php dot net at ss dot chernousov dot net Operating system: Any PHP version: 5.5.1 Package: Scripting Engine problem Bug Type: Bug Bug description:Memleak:Circular references on callbacks can't be resolved by Garbage Collector Description: GC fails to resolve the circular reference if object A retains a reference to a callback in object B and object B retains a reference to object A. Both objects leak. Native PHP stuff like SPL iterators with callbacks and Stream callbacks are also vulnerable to this problem. This does not apply to userland PHP objects (i.e. objects of classes that were defined in PHP scripts by a user). I provided a test script with a number of tests, including SPL iterators with callbacks, Stream callbacks, as well as 3rd-party extensions like pecl-event, pecl-ev, pecl-libevent, pecl-eio. Test script: --- https://gist.github.com/5lava/53aa2e53c7f8c658f045 Expected result: NULL GC Obj::__destruct THE END or NULL Obj::__destruct GC THE END Actual result: -- NULL GC THE END Obj::__destruct -- Edit bug report at https://bugs.php.net/bug.php?id=65387edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65387r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65387r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65387r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65387r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65387r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65387r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65387r=needscript Try newer version: https://bugs.php.net/fix.php?id=65387r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65387r=support Expected behavior: https://bugs.php.net/fix.php?id=65387r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65387r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65387r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65387r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65387r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65387r=dst IIS Stability: https://bugs.php.net/fix.php?id=65387r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65387r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65387r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65387r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65387r=mysqlcfg
Req #65285 [Wfx]: socket_sendmsg() - accept numeric file descriptors
Edit report at https://bugs.php.net/bug.php?id=65285edit=1
ID: 65285
User updated by:bugs dot php dot net at ss dot chernousov dot net
Reported by:bugs dot php dot net at ss dot chernousov dot net
Summary:socket_sendmsg() - accept numeric file descriptors
Status: Wont fix
Type: Feature/Change Request
Package:Sockets related
PHP Version:5.5Git-2013-07-18 (Git)
Block user comment: N
Private report: N
New Comment:
Well, when you're dealing a lot with libevent, libev, libeio and other
low-level
stuff, there's no point to convert $fd from integer to zval using
fopen('php://fd/...') and then back within socket_sendmsg() each time, it's
just
useless waste of time. For example, when a script accepts new connections with
pecl_event, it gets $fd as an integer in callback, and then it has to forward
those $fd's to other processes using sendmsg.
So in general it's a matter of performance and optimization, especially in
pretty
loaded environments.
The suggested patch is extremely simple, the only thing it lacks is limiting to
cli sapi only.
Previous Comments:
[2013-07-20 17:55:00] cataphr...@php.net
I don't see much point in it. In cli you can just open the file descriptor with
php://fd and then pass it to socket_sendmsg().
[2013-07-18 23:01:09] bugs dot php dot net at ss dot chernousov dot net
I see your point, quite reasonable.
But isn't it possible to limit it to cli sapi only, like php://fd?
[2013-07-18 22:39:00] cataphr...@php.net
Unfortunately, this kind of functionality has been strictly limited in the past
(php://fd has been limited to the cli sapi) under the rationale that it would
allow PHP to manipulate Apache's file descriptors (when running as module) or
whatever other file descriptors such as logs' or the the client connection
socket's.
I find the argument that this is a vulnerability unpersuasive, but that's the
conclusion that prevailed.
Won't fix.
[2013-07-18 08:21:08] bugs dot php dot net at ss dot chernousov dot net
Description:
It would be pretty useful if socket_sendmsg() could work not only with sockets,
but also with numeric file descriptors.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65285edit=1
[PHP-BUG] Req #65285 [NEW]: socket_sendmsg() - accept numeric file descriptors
From: bugs dot php dot net at ss dot chernousov dot net Operating system: PHP version: 5.5Git-2013-07-18 (Git) Package: Sockets related Bug Type: Feature/Change Request Bug description:socket_sendmsg() - accept numeric file descriptors Description: It would be pretty useful if socket_sendmsg() could work not only with sockets, but also with numeric file descriptors. -- Edit bug report at https://bugs.php.net/bug.php?id=65285edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65285r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65285r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65285r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65285r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65285r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65285r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65285r=needscript Try newer version: https://bugs.php.net/fix.php?id=65285r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65285r=support Expected behavior: https://bugs.php.net/fix.php?id=65285r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65285r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65285r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65285r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65285r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65285r=dst IIS Stability: https://bugs.php.net/fix.php?id=65285r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65285r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65285r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65285r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65285r=mysqlcfg
Req #65285 [Wfx]: socket_sendmsg() - accept numeric file descriptors
Edit report at https://bugs.php.net/bug.php?id=65285edit=1 ID: 65285 User updated by:bugs dot php dot net at ss dot chernousov dot net Reported by:bugs dot php dot net at ss dot chernousov dot net Summary:socket_sendmsg() - accept numeric file descriptors Status: Wont fix Type: Feature/Change Request Package:Sockets related PHP Version:5.5Git-2013-07-18 (Git) Block user comment: N Private report: N New Comment: I see your point, quite reasonable. But isn't it possible to limit it to cli sapi only, like php://fd? Previous Comments: [2013-07-18 22:39:00] cataphr...@php.net Unfortunately, this kind of functionality has been strictly limited in the past (php://fd has been limited to the cli sapi) under the rationale that it would allow PHP to manipulate Apache's file descriptors (when running as module) or whatever other file descriptors such as logs' or the the client connection socket's. I find the argument that this is a vulnerability unpersuasive, but that's the conclusion that prevailed. Won't fix. [2013-07-18 08:21:08] bugs dot php dot net at ss dot chernousov dot net Description: It would be pretty useful if socket_sendmsg() could work not only with sockets, but also with numeric file descriptors. -- Edit this bug report at https://bugs.php.net/bug.php?id=65285edit=1
[PHP-BUG] Bug #65260 [NEW]: socket_sendmsg/socket_recvmsg wrong number of file descriptors
From: bugs dot php dot net at ss dot chernousov dot net Operating system: Gentoo Linux PHP version: 5.5.0 Package: Sockets related Bug Type: Bug Bug description:socket_sendmsg/socket_recvmsg wrong number of file descriptors Description: Regardless of how many file descriptors were sent with socket_sendmsg(), socket_recvmsg() always receives fd/0 as the very first descriptor (even if it wasn't sent at all) and then maximum two descriptors that were really sent. Test script sends one descriptor $fd, but receives two, as described above. If we add more descriptors to send (let's say 5, and change third argument of socket_cmsg_space() to 5), only first two will be actually received, and extra fd/0 will precede them. I know these functions are still experimental, but they are like a manna from heaven many backend php-developers were seeking. Test script: --- https://gist.github.com/5lava/5993637 Similar PHP test https://github.com/cataphract/php-src/blob/sendrecvmsg/ext/sockets/tests/socket_cmsg_rights.phpt taken from here: https://wiki.php.net/rfc/sendrecvmsg Expected result: One new file descriptors should be added after socket_recvmsg() call. Actual result: -- Two new file descriptors added. First is always referencing fd/0, and 2nd is the one which was actually sent. File descriptors before socket_recvmsg() call: 0 - /etc/passwd --- reopened fd/0 1 - /dev/pts/3 --- stdout 2 - /dev/pts/3 --- stderr 3 - socket:[5819664] --- $send_s 4 - socket:[5819665] --- $recv_s 5 - /etc/group --- $fd - the one we want to send 6 - pipe:[5819666] --- passthru() pipe File descriptors after socket_recvmsg() call: 0 - /etc/passwd --- reopened fd/0 1 - /dev/pts/3 --- stdout 2 - /dev/pts/3 --- stderr 3 - socket:[5819664] --- $send_s 4 - socket:[5819665] --- $recv_s 5 - /etc/group --- $fd - the one we sent 6 - /etc/passwd --- always the same as fd/0 - shouldn't be here at all 7 - /etc/group --- that's the only one we expected to receive 6 - pipe:[5819666] --- passthru() pipe $data contains two Resources: Array ( ... [control] = [0] = [data] = Array ( [0] = Resource id #10 [1] = Resource id #11 ) ... ) -- Edit bug report at https://bugs.php.net/bug.php?id=65260edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65260r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65260r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65260r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65260r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65260r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65260r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65260r=needscript Try newer version: https://bugs.php.net/fix.php?id=65260r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65260r=support Expected behavior: https://bugs.php.net/fix.php?id=65260r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65260r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65260r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65260r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65260r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65260r=dst IIS Stability: https://bugs.php.net/fix.php?id=65260r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65260r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65260r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65260r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65260r=mysqlcfg
Bug #65260 [Com]: socket_sendmsg/socket_recvmsg wrong number of file descriptors
Edit report at https://bugs.php.net/bug.php?id=65260edit=1 ID: 65260 Comment by: bugs dot php dot net at ss dot chernousov dot net Reported by:bugs dot php dot net at ss dot chernousov dot net Summary:socket_sendmsg/socket_recvmsg wrong number of file descriptors Status: Feedback Type: Bug Package:Sockets related Operating System: Gentoo Linux PHP Version:5.5.0 Assigned To:cataphract Block user comment: N Private report: N New Comment: Works like a charm to me. Thank you so much. Previous Comments: [2013-07-14 23:54:43] cataphr...@php.net Can you test this branch: https://github.com/cataphract/php-src/tree/bug65260 ? Thanks [2013-07-14 09:10:18] bugs dot php dot net at ss dot chernousov dot net Description: Regardless of how many file descriptors were sent with socket_sendmsg(), socket_recvmsg() always receives fd/0 as the very first descriptor (even if it wasn't sent at all) and then maximum two descriptors that were really sent. Test script sends one descriptor $fd, but receives two, as described above. If we add more descriptors to send (let's say 5, and change third argument of socket_cmsg_space() to 5), only first two will be actually received, and extra fd/0 will precede them. I know these functions are still experimental, but they are like a manna from heaven many backend php-developers were seeking. Test script: --- https://gist.github.com/5lava/5993637 Similar PHP test https://github.com/cataphract/php-src/blob/sendrecvmsg/ext/sockets/tests/socket_cmsg_rights.phpt taken from here: https://wiki.php.net/rfc/sendrecvmsg Expected result: One new file descriptors should be added after socket_recvmsg() call. Actual result: -- Two new file descriptors added. First is always referencing fd/0, and 2nd is the one which was actually sent. File descriptors before socket_recvmsg() call: 0 - /etc/passwd --- reopened fd/0 1 - /dev/pts/3 --- stdout 2 - /dev/pts/3 --- stderr 3 - socket:[5819664] --- $send_s 4 - socket:[5819665] --- $recv_s 5 - /etc/group --- $fd - the one we want to send 6 - pipe:[5819666] --- passthru() pipe File descriptors after socket_recvmsg() call: 0 - /etc/passwd --- reopened fd/0 1 - /dev/pts/3 --- stdout 2 - /dev/pts/3 --- stderr 3 - socket:[5819664] --- $send_s 4 - socket:[5819665] --- $recv_s 5 - /etc/group --- $fd - the one we sent 6 - /etc/passwd --- always the same as fd/0 - shouldn't be here at all 7 - /etc/group --- that's the only one we expected to receive 6 - pipe:[5819666] --- passthru() pipe $data contains two Resources: Array ( ... [control] = [0] = [data] = Array ( [0] = Resource id #10 [1] = Resource id #11 ) ... ) -- Edit this bug report at https://bugs.php.net/bug.php?id=65260edit=1
Req #60524 [Com]: specify temp dir by php.ini
Edit report at https://bugs.php.net/bug.php?id=60524edit=1 ID: 60524 Comment by: mail+bugs dot php dot net at kazik dot de Reported by:mail+bugs dot php dot net at kazik dot de Summary:specify temp dir by php.ini Status: Closed Type: Feature/Change Request Package:Filesystem function related Operating System: * PHP Version:* Assigned To:stas Block user comment: N Private report: N New Comment: The 5.5's pull request is here: https://github.com/php/php-src/pull/262 It should be easy to patch 5.4 and 5.3 with that or a slightly modified version (there a older patches for 5.3 and 5.4 available). Whether this should be backported or not is not for me to decide. So, feel free to port. Previous Comments: [2013-07-09 12:07:46] mail at tomsommer dot dk Any chance of getting this backported to 5.3 and 5.4? [2013-01-29 06:58:31] s...@php.net The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. merged into 5.5 as 475a644bd84c071da04b4272b829a187a2c6d282 [2012-05-10 15:27:56] mail+bugs dot php dot net at kazik dot de Added patch for 5.3.4, of course (and not 4.3.4) [2012-05-10 15:25:59] mail+bugs dot php dot net at kazik dot de Added patch for 4.3.4 [2011-12-14 14:33:53] mail+bugs dot php dot net at kazik dot de Description: This patch (against 5.3.8) adds a new php.ini directive to specify the path for the temporary files. Why: If, for security reasons, every user is only allowed to use their own home directories, it's not possible to specify their own tmp dir (e.g. /home/user/tmp). The directory for uploading and session can already be specified. Since all users may use the same php.ini (different [HOST=domain] entries, [1]) it's not possible to set the environment TMPDIR variable, because it would affect all users. [1] http://php.net/manual/en/ini.sections.php Test script: --- ini: system_tmp_dir = /home/user/tmp php: var_export(sys_get_temp_dir()); Expected result: '/home/user/tmp' Actual result: -- '/tmp' (depends on system configuration) -- Edit this bug report at https://bugs.php.net/bug.php?id=60524edit=1
[PHP-BUG] Bug #65120 [NEW]: fpm build fails on ppc: #error Unsupported processor
From: php-bugs-2013 at ryandesign dot com Operating system: Mac OS X 10.5.8 PHP version: 5.5.0 Package: Compile Failure Bug Type: Bug Bug description:fpm build fails on ppc: #error Unsupported processor Description: Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling with Apple's gcc 4.0.1 which comes with Xcode, with the following error: :info:build /bin/sh /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps -- mode=compile /usr/bin/gcc-4.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/main - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/date/lib - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex - I/Volumes/Data/macports/leopard/include/libxml2 - I/Volumes/Data/macports/leopard/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/TSRM - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/Zend - I/Volumes/Data/macports/leopard/include -no-cpp-precomp -pipe -O2 -arch ppc - fvisibility=hidden -c /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo :info:build In file included from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15, :info:build from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21: :info:build /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). Previous bug reports about fpm sapi build failure on PowerPC or POWER processors include #51214 (closed as not a bug because fpm wasn't part of php at that time); #51772 (closed as no feedback; there was a patch attached but someone said it was unstable); #54273 (closed as won't fix because the person handling the bug had no access to PowerPC equipment). -- Edit bug report at https://bugs.php.net/bug.php?id=65120edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65120r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65120r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65120r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65120r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65120r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65120r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65120r=needscript Try newer version: https://bugs.php.net/fix.php?id=65120r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65120r=support Expected behavior: https://bugs.php.net/fix.php?id=65120r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65120r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65120r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65120r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65120r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65120r=dst IIS Stability: https://bugs.php.net/fix.php?id=65120r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65120r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65120r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65120r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65120r=mysqlcfg
Bug #65120 [Fbk-Opn]: fpm build fails on ppc: #error Unsupported processor
Edit report at https://bugs.php.net/bug.php?id=65120edit=1 ID: 65120 User updated by:php-bugs-2013 at ryandesign dot com Reported by:php-bugs-2013 at ryandesign dot com Summary:fpm build fails on ppc: #error Unsupported processor -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: Mac OS X 10.5.8 PHP Version:5.5.0 Block user comment: N Private report: N New Comment: I am not a C programmer and I'm not familiar with your code, so I'm probably not the best candidate to fix this. Previous Comments: [2013-06-25 15:56:54] fel...@php.net Can you provide a patch that works on such architecture? [2013-06-25 08:55:27] php-bugs-2013 at ryandesign dot com Description: Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling with Apple's gcc 4.0.1 which comes with Xcode, with the following error: :info:build /bin/sh /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps -- mode=compile /usr/bin/gcc-4.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/main - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/date/lib - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex - I/Volumes/Data/macports/leopard/include/libxml2 - I/Volumes/Data/macports/leopard/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/TSRM - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/Zend - I/Volumes/Data/macports/leopard/include -no-cpp-precomp -pipe -O2 -arch ppc - fvisibility=hidden -c /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo :info:build In file included from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15, :info:build from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21: :info:build /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). Previous bug reports about fpm sapi build failure on PowerPC or POWER processors include #51214 (closed as not a bug because fpm wasn't part of php at that time); #51772 (closed as no feedback; there was a patch attached but someone said it was unstable); #54273 (closed as won't fix because the person handling the bug had no access to PowerPC equipment). -- Edit this bug report at https://bugs.php.net/bug.php?id=65120edit=1
[PHP-BUG] Req #64865 [NEW]: Search for .user.ini files from script dir up to CONTEXT_DOCUMENT_ROOT
From: php-bugs at sievers dot dialup dot fu-berlin dot de Operating system: PHP version: 5.5Git-2013-05-17 (Git) Package: CGI/CLI related Bug Type: Feature/Change Request Bug description:Search for .user.ini files from script dir up to CONTEXT_DOCUMENT_ROOT Description: Currently PHP-CGI searches for .user.ini files in the script directory and all parent directories up to DOCUMENT_ROOT. See: http://php.net/manual/en/configuration.file.per-user.php If Apache web servers use the UserDir module the php scripts lie out of the DOCUMENT_ROOT, which causes PHP-CGI to search only in the script directory for .user.ini files. This is inconvenient for users, who have to copy their .user.ini files to all sub-directories in order to apply their settings. Since Apache 2.3.13 there is an additional CONTEXT_DOCUMENT_ROOT variable, which is set by mod_userdir and probably mod_alias accordingly. See http://stackoverflow.com/questions/12129433/what-is-servercontext-prefix/12129649#12129649 PHP-CGI could use this variable (if set) to search for .user.ini files. It could search from the script directory up to CONTEXT_DOCUMENT_ROOT. If the variable is not set, PHP-CGI should use DOCUMENT_ROOT as it has before. Even other web servers (e.g. Apache 2.2) can profit from this change, since it's easy to set CONTEXT_DOCUMENT_ROOT variable via a RewriteRule directive. Apache http's suexec support the CONTEXT_DOCUMENT_ROOT variable too: *) suexec: Add environment variables CONTEXT_DOCUMENT_ROOT, CONTEXT_PREFIX, REDIRECT_ERROR_NOTES, REDIRECT_SCRIPT_FILENAME, REQUEST_SCHEME to the whitelist in suexec. PR 51499. [Graham Laverty graham reg ca, Stefan Fritsch] (http://mirror.serversupportforum.de/apache//httpd/CHANGES_2.4) Jan Sievers -- Edit bug report at https://bugs.php.net/bug.php?id=64865edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64865r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64865r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64865r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64865r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64865r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64865r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64865r=needscript Try newer version: https://bugs.php.net/fix.php?id=64865r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64865r=support Expected behavior: https://bugs.php.net/fix.php?id=64865r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64865r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64865r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64865r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64865r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64865r=dst IIS Stability: https://bugs.php.net/fix.php?id=64865r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64865r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64865r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64865r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64865r=mysqlcfg
[PHP-BUG] Bug #64811 [NEW]: SplTempFileObject doesn't provide valid return values for SplFileInfo / filenam
From: bugs+php at childno dot de
Operating system: Any
PHP version: 5.4.15
Package: SPL related
Bug Type: Bug
Bug description:SplTempFileObject doesn't provide valid return values for
SplFileInfo / filenam
Description:
the SplTempFileObject is intended to use the php://temp in-memory storage.
This has disadvantages if it is used for creating files on the fly that
needed to be processed afterwards. Typically you want to provide
SplFileInfo to certain interfaces that might handle and read the content
again.
e.g. see
http://stackoverflow.com/questions/12555139
Test script:
---
$file = new \SplTempFileObject();
if ($file-fwrite(foo) !== null)
print('wrote `' . $file-ftell() . '` byte(s) to `' .
$file-getRealPath() . '`');
// wrote `3` byte(s) to ``
// ^^ thats ok for 2MB while it is expected to be in-memory
$file = new \SplTempFileObject(0);
if ($file-fwrite(foo) !== null)
print('wrote `' . $file-ftell() . '` byte(s) to `' .
$file-getRealPath() . '`');
// wrote `3` byte(s) to ``
// NOT OK Because we set the limit to 0 to force writing stuff to the
filesystem
$file = new \SplFileObject(tempnam(sys_get_temp_dir(), rand()), 'w+');
if ($file-fwrite(bar) !== null)
print('wrote `' . $file-ftell() . '` byte(s) to `' .
$file-getRealPath() . '`');
// wrote `3` byte(s) to `/tmp/2123740490ZwI6Qd`
// ^^ that's what I expect even for \SplTempFileObject(0)
Expected result:
\SplTempFileObject-getFileName() should return s.th. like
`2123740490ZwI6Qd` \SplTempFileObject-getFileInfo() should return a valid
SplFileInfo Object pointing to /tmp/2123740490ZwI6Qd
\SplTempFileObject-getRealPath() should return s.th. like
/tmp/2123740490ZwI6Qd
Actual result:
--
\SplTempFileObject-getFileName() will return php://temp
\SplTempFileObject-getFileInfo() will return an empty object / file
pointer \SplTempFileObject-getRealPath() will always return an empty
string!
--
Edit bug report at https://bugs.php.net/bug.php?id=64811edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64811r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64811r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64811r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64811r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64811r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64811r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64811r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64811r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64811r=support
Expected behavior: https://bugs.php.net/fix.php?id=64811r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64811r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64811r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64811r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64811r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64811r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64811r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64811r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64811r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64811r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64811r=mysqlcfg
Bug #64724 [Com]: Objects stored in Sessions sometimes get lost.
Edit report at https://bugs.php.net/bug.php?id=64724edit=1
ID: 64724
Comment by: php dot bugs at lippe-net dot de
Reported by:php dot bugs at lippe-net dot de
Summary:Objects stored in Sessions sometimes get lost.
Status: Feedback
Type: Bug
Package:*General Issues
Operating System: Debian Wheezy
PHP Version:5.4.14
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
The debian libapache2-mod-php5 (5.4.4-14) is certainly not thread-safe.
Previous Comments:
[2013-05-07 09:46:46] m...@php.net
It seems, or it does?
Is this a ZTS build?
Thanks.
[2013-05-06 16:20:44] php dot bugs at lippe-net dot de
The only thing is a DBG v4.6.4 installation, but it seems to make no difference
if it is activated or not.
[2013-04-29 14:15:19] m...@php.net
Can't reproduce.
Do you have any special extensions loaded? If so, see if that also happens
without them loaded.
[2013-04-27 15:45:48] larue...@php.net
maybe due to the serialize
[2013-04-26 15:04:24] php dot bugs at lippe-net dot de
Description:
The transactions array of the $_SESSION variable is initialized only once.
If you repeat the invocation of the script. After a while the array contains
some
elements that are no more Objects of class S but references (for example
r:5607;).
Test script:
---
?php
class S implements \Serializable {
protected $data = [];
public function __construct() {
for ( $i = 0; $i = mt_rand(4, 7); $i++ ) {
$this-data[] = mt_rand(0, 50);
}
}
public function serialize() {
return serialize($this-data);
}
public function unserialize($data) {
$this-data = unserialize($data);
}
}
session_name(testS);
session_start();
if ( empty($_SESSION[transactions]) ) {
$_SESSION[transactions] = [ new S(), new S(), new S(), new S() ];
}
echo serialize($_SESSION);
?
Expected result:
Example (first call):
transactions|a:4:{i:0;C:1:S:76:{a:8:
{i:0;i:9;i:1;i:24;i:2;i:23;i:3;i:46;i:4;i:29;i:5;i:4;i:6;i:44;i:7;i:14;}}i:1;C:1:
S:51:{a:5:{i:0;i:11;i:1;i:45;i:2;i:12;i:3;i:10;i:4;i:21;}}i:2;C:1:S:59:{a:6:
{i:0;i:47;i:1;i:5;i:2;i:40;i:3;i:35;i:4;i:29;i:5;i:14;}}i:3;C:1:S:58:{a:6:
{i:0;i:20;i:1;i:20;i:2;i:7;i:3;i:44;i:4;i:7;i:5;i:27;}}}
Actual result:
--
Example (after some roundabout 50 calls):
transactions|a:4:{i:0;r:5607;i:1;r:5617;i:2;r:5624;i:3;r:5632;}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64724edit=1
Bug #64724 [Com]: Objects stored in Sessions sometimes get lost.
Edit report at https://bugs.php.net/bug.php?id=64724edit=1
ID: 64724
Comment by: php dot bugs at lippe-net dot de
Reported by:php dot bugs at lippe-net dot de
Summary:Objects stored in Sessions sometimes get lost.
Status: Feedback
Type: Bug
Package:*General Issues
Operating System: Debian Wheezy
PHP Version:5.4.14
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
The only thing is a DBG v4.6.4 installation, but it seems to make no difference
if it is activated or not.
Previous Comments:
[2013-04-29 14:15:19] m...@php.net
Can't reproduce.
Do you have any special extensions loaded? If so, see if that also happens
without them loaded.
[2013-04-27 15:45:48] larue...@php.net
maybe due to the serialize
[2013-04-26 15:04:24] php dot bugs at lippe-net dot de
Description:
The transactions array of the $_SESSION variable is initialized only once.
If you repeat the invocation of the script. After a while the array contains
some
elements that are no more Objects of class S but references (for example
r:5607;).
Test script:
---
?php
class S implements \Serializable {
protected $data = [];
public function __construct() {
for ( $i = 0; $i = mt_rand(4, 7); $i++ ) {
$this-data[] = mt_rand(0, 50);
}
}
public function serialize() {
return serialize($this-data);
}
public function unserialize($data) {
$this-data = unserialize($data);
}
}
session_name(testS);
session_start();
if ( empty($_SESSION[transactions]) ) {
$_SESSION[transactions] = [ new S(), new S(), new S(), new S() ];
}
echo serialize($_SESSION);
?
Expected result:
Example (first call):
transactions|a:4:{i:0;C:1:S:76:{a:8:
{i:0;i:9;i:1;i:24;i:2;i:23;i:3;i:46;i:4;i:29;i:5;i:4;i:6;i:44;i:7;i:14;}}i:1;C:1:
S:51:{a:5:{i:0;i:11;i:1;i:45;i:2;i:12;i:3;i:10;i:4;i:21;}}i:2;C:1:S:59:{a:6:
{i:0;i:47;i:1;i:5;i:2;i:40;i:3;i:35;i:4;i:29;i:5;i:14;}}i:3;C:1:S:58:{a:6:
{i:0;i:20;i:1;i:20;i:2;i:7;i:3;i:44;i:4;i:7;i:5;i:27;}}}
Actual result:
--
Example (after some roundabout 50 calls):
transactions|a:4:{i:0;r:5607;i:1;r:5617;i:2;r:5624;i:3;r:5632;}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64724edit=1
Bug #64741 [Nab]: Various ways to reassign this
Edit report at https://bugs.php.net/bug.php?id=64741edit=1
ID: 64741
User updated by:php dot bugs at daverandom dot com
Reported by:php dot bugs at daverandom dot com
Summary:Various ways to reassign this
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I accept that the bulk of the examples below are difficult/impossible to
prevent
with the static analysis that happens at compile time, given the range of
dynamic ways to do this that makes PHP a great language. I too would not like
to
see PEBKAC prevention affecting performance.
However, I think there is one example above that warrants further inspection:
unset($this) actually causes a segfault (this can be seen here:
http://codepad.viper-7.com/NX7v1q) and should be detectable at compile time
fairly easily/inexpensively I would have thought, although I'm no expert on the
PHP src.
Previous Comments:
[2013-04-30 11:52:38] johan...@php.net
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
we prevent from mistakes, we don't prevent people from shooting in their feed,
especially as such checks would slow down *all* variable access.
[2013-04-30 11:42:15] php dot bugs at daverandom dot com
Description:
The engine prevents userland code from directly reassigning $this with a
compile
time error, but it does not prevent a number of other mechanisms. The following
are all possible:
unset($this);
// ...
public function test()
{
${'th'.'is'} = 'foo';
}
// ...
public function test()
{
$foo = 'this';
$$foo = 'foo';
}
// ...
function ref($arg)
{
$arg = 'foo';
}
public function test()
{
ref($this);
}
Test script:
---
?php
function ref($arg)
{
$arg = 'foo';
}
class ThisReassignments
{
public function test1() { var_dump($this); ${'th'.'is'} = 'foo';
var_dump($this); }
public function test2() { var_dump($this); $foo = 'this'; $$foo =
'foo';; var_dump($this); }
public function test3() { var_dump($this); ref($this); var_dump($this);
}
}
(new ThisReassignments)-test1();
(new ThisReassignments)-test2();
(new ThisReassignments)-test3();
// NB: unset() causes a segmentation fault and doesn't *really* work, but
it should emit a meaningful error
Expected result:
Fatal error with a meaningful error message in all cases
Actual result:
--
object(ThisReassignments)#1 (0) {
}
string(3) foo
object(ThisReassignments)#1 (0) {
}
string(3) foo
object(ThisReassignments)#1 (0) {
}
string(3) foo
--
Edit this bug report at https://bugs.php.net/bug.php?id=64741edit=1
[PHP-BUG] Bug #64741 [NEW]: Various ways to reassign this
From: php dot bugs at daverandom dot com
Operating system: Any
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Various ways to reassign this
Description:
The engine prevents userland code from directly reassigning $this with a
compile
time error, but it does not prevent a number of other mechanisms. The
following
are all possible:
unset($this);
// ...
public function test()
{
${'th'.'is'} = 'foo';
}
// ...
public function test()
{
$foo = 'this';
$$foo = 'foo';
}
// ...
function ref($arg)
{
$arg = 'foo';
}
public function test()
{
ref($this);
}
Test script:
---
?php
function ref($arg)
{
$arg = 'foo';
}
class ThisReassignments
{
public function test1() { var_dump($this); ${'th'.'is'} = 'foo';
var_dump($this); }
public function test2() { var_dump($this); $foo = 'this'; $$foo =
'foo';; var_dump($this); }
public function test3() { var_dump($this); ref($this);
var_dump($this); }
}
(new ThisReassignments)-test1();
(new ThisReassignments)-test2();
(new ThisReassignments)-test3();
// NB: unset() causes a segmentation fault and doesn't *really* work,
but it should emit a meaningful error
Expected result:
Fatal error with a meaningful error message in all cases
Actual result:
--
object(ThisReassignments)#1 (0) {
}
string(3) foo
object(ThisReassignments)#1 (0) {
}
string(3) foo
object(ThisReassignments)#1 (0) {
}
string(3) foo
--
Edit bug report at https://bugs.php.net/bug.php?id=64741edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64741r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64741r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64741r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64741r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64741r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64741r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64741r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64741r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64741r=support
Expected behavior: https://bugs.php.net/fix.php?id=64741r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64741r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64741r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64741r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64741r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64741r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64741r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64741r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64741r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64741r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64741r=mysqlcfg
[PHP-BUG] Bug #64724 [NEW]: Objects stored in Sessions sometimes get lost.
From: php dot bugs at lippe-net dot de
Operating system: Debian Wheezy
PHP version: 5.4.14
Package: Session related
Bug Type: Bug
Bug description:Objects stored in Sessions sometimes get lost.
Description:
The transactions array of the $_SESSION variable is initialized only
once.
If you repeat the invocation of the script. After a while the array
contains some
elements that are no more Objects of class S but references (for example
r:5607;).
Test script:
---
?php
class S implements \Serializable {
protected $data = [];
public function __construct() {
for ( $i = 0; $i = mt_rand(4, 7); $i++ ) {
$this-data[] = mt_rand(0, 50);
}
}
public function serialize() {
return serialize($this-data);
}
public function unserialize($data) {
$this-data = unserialize($data);
}
}
session_name(testS);
session_start();
if ( empty($_SESSION[transactions]) ) {
$_SESSION[transactions] = [ new S(), new S(), new S(), new S() ];
}
echo serialize($_SESSION);
?
Expected result:
Example (first call):
transactions|a:4:{i:0;C:1:S:76:{a:8:
{i:0;i:9;i:1;i:24;i:2;i:23;i:3;i:46;i:4;i:29;i:5;i:4;i:6;i:44;i:7;i:14;}}i:1;C:1:
S:51:{a:5:{i:0;i:11;i:1;i:45;i:2;i:12;i:3;i:10;i:4;i:21;}}i:2;C:1:S:59:{a:6:
{i:0;i:47;i:1;i:5;i:2;i:40;i:3;i:35;i:4;i:29;i:5;i:14;}}i:3;C:1:S:58:{a:6:
{i:0;i:20;i:1;i:20;i:2;i:7;i:3;i:44;i:4;i:7;i:5;i:27;}}}
Actual result:
--
Example (after some roundabout 50 calls):
transactions|a:4:{i:0;r:5607;i:1;r:5617;i:2;r:5624;i:3;r:5632;}
--
Edit bug report at https://bugs.php.net/bug.php?id=64724edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64724r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64724r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64724r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64724r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64724r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64724r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64724r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64724r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64724r=support
Expected behavior: https://bugs.php.net/fix.php?id=64724r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64724r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64724r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64724r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64724r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64724r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64724r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64724r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64724r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64724r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64724r=mysqlcfg
Bug #49348 [Com]: Uninitialized ++$foo-bar; does not cause a notice (but ++$bar; does!)
Edit report at https://bugs.php.net/bug.php?id=49348edit=1 ID: 49348 Comment by: bugs dot php dot net at majkl578 dot cz Reported by:BelStudent at yandex dot ru Summary:Uninitialized ++$foo-bar; does not cause a notice (but ++$bar; does!) Status: Closed Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: The message is not consistent with the other one triggered in similar case. Consider the following code: $x = new stdClass(); echo $x-foo++; echo $x-bar; It triggers two notices: Notice: Undefined property: foo Notice: Undefined property: stdClass::$bar The first one was added by fix for this bug and is wrong. It should be same as the other one (should contain classname and dollar). Previous Comments: [2013-02-21 08:58:40] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c6d903ce7615a7197cb997d67d98058c3ec5d6a Log: fix bug #49348 - issue notice on get_property_ptr_ptr when used for read [2013-02-20 08:35:21] dmi...@php.net I think the fix is fine, but it may go only into 5.5 and above. [2013-02-19 09:18:04] s...@php.net Potential fix in this pull: https://github.com/php/php-src/pull/281 [2013-02-19 04:59:16] s...@php.net The problem here is that get_property_ptr_ptr does not produce notices. It doesn't because it does not know the fetch type - in some cases it's BP_VAR_W, then it shouldn't produce notice, in some it's BP_VAR_RW and then it should. However get_property_ptr_ptr doesn't have a parameter to pass this info. Looks like such parameter needs to be added... [2009-09-01 08:41:52] sjo...@php.net I was talking about this: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362view=markup#l251 With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With ++$this-foo, it is BP_VAR_W. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49348 -- Edit this bug report at https://bugs.php.net/bug.php?id=49348edit=1
[PHP-BUG] Bug #64513 [NEW]: DateTimeImmutable is incompatible with DateTime and leads to BC breaks
From: bugs dot php dot net at majkl578 dot cz
Operating system: -
PHP version: 5.5.0beta1
Package: Date/time related
Bug Type: Bug
Bug description:DateTimeImmutable is incompatible with DateTime and leads to BC
breaks
Description:
PHP 5.5 adds DateTimeImmutable, which extends DateTime.
As Benjamin Eberlei already pointed out in internals list [1], the behavior
is not compatible with each other and therefore the inheritance seems to be
wrong.
This bad implementation is not backward compatible and may lead to serious
problems with existing code.
Here are some examples which would get broken (bad behavior or even
infinite loop!) by passing DateTimeImmutable instead of DateTime.
function testOne(DateTime $dt)
{
for ($i = 1; $i = 2; $i++, $dt-modify('first day of next month')) {
echo $dt-format('Y/m/d'), PHP_EOL;
}
}
testOne(new DateTime());
// 2013/03/25
// 2013/04/01
testOne(new DateTimeImmutable());
// 2013/03/25
// 2013/03/25
---
function testTwo(DateTime $from, DateTime $to)
{
for ($current = clone $from; $current = $to; $current-modify('+ 1
day'))
{
echo $current-format('Y/m/d'), PHP_EOL;
}
}
testTwo(new DateTime(), new DateTime('+ 1 day'));
// 2013/03/25
// 2013/03/26
testTwo(new DateTimeImmutable(), new DateTimeImmutable('+ 1 day'));
// 2013/03/25
// 2013/03/25
// 2013/03/25
// infinite loop occurs!
This clearly shows what side-effects might this feature have.
Please, do not add another badly designed feature and revert it before 5.5
gets released.
[1] http://marc.info/?l=php-internalsm=136135370215794w=2
--
Edit bug report at https://bugs.php.net/bug.php?id=64513edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64513r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64513r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64513r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64513r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64513r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64513r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64513r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64513r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64513r=support
Expected behavior: https://bugs.php.net/fix.php?id=64513r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64513r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64513r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64513r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64513r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64513r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64513r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64513r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64513r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64513r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64513r=mysqlcfg
Bug #54710 [Com]: sys_get_temp_dir() does not respect upload_tmp_dir
Edit report at https://bugs.php.net/bug.php?id=54710edit=1 ID: 54710 Comment by: mail+bugs dot php dot net at kazik dot de Reported by:royanee at yahoo dot com Summary:sys_get_temp_dir() does not respect upload_tmp_dir Status: Not a bug Type: Bug Package:PHP options/info functions PHP Version:5.3.6 Block user comment: N Private report: N New Comment: This issue is handled in: https://bugs.php.net/bug.php?id=60524 And it's available in php 5.5.0 Alpha 5 and up. Previous Comments: [2011-06-04 00:15:35] royanee at yahoo dot com @iliaa: Please tell me how to set the location of the temporary directory using php_admin_value or php_value, as I do not see a way of setting the temporary directory at the vhost level in the documentation. If that is not currently possible, please reclassify this as a valid feature request. Thank you for your time. [2011-05-30 18:00:05] il...@php.net 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 function is designed to return the location of the temporary directory, not the file upload directory. [2011-05-11 15:47:13] royanee at yahoo dot com Additionally, enabling open_basedir results in FALSE and triggers the following warning: PHP Warning: tempnam(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/www/myvhost/) [2011-05-11 15:45:07] royanee at yahoo dot com Description: The only configuration option for setting the temporary directory for normal operations is the upload_tmp_dir option. As such, functions that rely on the temporary directory should respect the upload_tmp_dir option to ensure that true separation of concerns between virtual hosts can be achieved. This is particularly important when also using open_basedir. Note that the following line is correctly located in the vhost config: php_admin_value upload_tmp_dir /www/myvhost/tmp Test script: --- ?php // Create a temporary file in the temporary // files directory using sys_get_temp_dir() $temp_file = tempnam(sys_get_temp_dir(), 'Tux'); echo $temp_file; ? Expected result: /www/myvhost/tmp/TuxDRhRIg Actual result: -- /tmp/TuxDRhRIg -- Edit this bug report at https://bugs.php.net/bug.php?id=54710edit=1
[PHP-BUG] Bug #64285 [NEW]: Build failure: unknown type name 'php_socket'
From: php-bugs-2013 at ryandesign dot com Operating system: OS X 10.8.2 PHP version: 5.5.0alpha5 Package: Sockets related Bug Type: Bug Bug description:Build failure: unknown type name 'php_socket' Description: I'm the maintainer of PHP in MacPorts, trying to update our php55 packages. In 5.5.0alpha4 everything built fine but with 5.5.0alpha5 the sockets extension does not build. The first error is: /bin/sh /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/libtool --mode=compile /usr/bin/clang -I. - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets -DPHP_ATOM_INC - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/include - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/main - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets -I/opt/local/include/php55/php - I/opt/local/include/php55/php/main -I/opt/local/include/php55/php/TSRM - I/opt/local/include/php55/php/Zend -I/opt/local/include/php55/php/ext - I/opt/local/include/php55/php/ext/date/lib -I/opt/local/include - I/opt/local/include -DHAVE_CONFIG_H -pipe -O2 -arch x86_64 -c /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/conversions.c -o conversions.lo /usr/bin/clang -I. - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets -DPHP_ATOM_INC - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/include - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/main - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets -I/opt/local/include/php55/php - I/opt/local/include/php55/php/main -I/opt/local/include/php55/php/TSRM - I/opt/local/include/php55/php/Zend -I/opt/local/include/php55/php/ext - I/opt/local/include/php55/php/ext/date/lib -I/opt/local/include - I/opt/local/include -DHAVE_CONFIG_H -pipe -O2 -arch x86_64 -c /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/conversions.c -fno-common -DPIC -o .libs/conversions.o In file included from /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- sockets/work/php-5.5.0alpha5/ext/sockets/conversions.c:1: ./sockaddr_conv.h:19:65: error: unknown type name 'php_socket'; did you mean 'php_socket_t'? int php_set_inet6_addr(struct sockaddr_in6 *sin6, char *string, php_socket *php_sock TSRMLS_DC); ^~ php_socket_t /opt/local/include/php55/php/main/php_network.h:95:13: note: 'php_socket_t' declared here typedef int php_socket_t; ^ The sockets extension appears to have undergone extensive changes between 5.5.0alpha4 and 5.5.0alpha5 and I don't know how to fix this problem. -- Edit bug report at https://bugs.php.net/bug.php?id=64285edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64285r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64285r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64285r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64285r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64285r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64285r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64285r=needscript Try newer version: https://bugs.php.net/fix.php?id=64285r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64285r=support Expected behavior: https://bugs.php.net/fix.php?id=64285r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64285r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64285r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64285r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64285r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64285r=dst IIS Stability: https://bugs.php.net/fix.php?id=64285r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64285r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64285r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64285r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php
Bug #64284 [Fbk-Opn]: Build failure: 'ext/intl/intl_error.h' file not found
Edit report at https://bugs.php.net/bug.php?id=64284edit=1 ID: 64284 User updated by:php-bugs-2013 at ryandesign dot com Reported by:php-bugs-2013 at ryandesign dot com Summary:Build failure: 'ext/intl/intl_error.h' file not found -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: OS X 10.8.2 PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: I doubt the problem is OS X-specific. Yes, we are using phpize to build the bundled extensions, just as we do to build third-party extensions. We've been using phpize ever since we started offering separately-installable PHP modules in 2009. This has worked fine until now. I was not aware using phpize was not supported. What should we be using instead? I am reluctant to change something that has been working for three years. Yes, I'm aware you have #includes for ext/date and ext/standard elsewhere in the code. This is not a problem because the ext/date and ext/standard files get installed by the main php55 port. There are 22 occurrences in ext/intl of '#include intl_error.h' and 4 of '#include ../intl_error.h' and only this one occurrence of '#include ext/intl/intl_error.h' which is why I suggested this change. Previous Comments: [2013-02-23 13:03:27] cataphr...@php.net We have this kind of includes all over the place: http://lxr.php.net/search?q=%22include+ext%22defs=refs=path=hist=project=PHP_TRUNK specifically for intl: http://lxr.php.net/search?q=%22include+ext%22defs=refs=path=ext%2Fintlhist=project=PHP_TRUNK Your compile command line is very strange. It's looking for headers in a central location (/opt/local/include/php55), as if you're compiling ext/intl with phpize (which is not supported), and it also has includes for ...ext/intl/main, ...ext/intl/Zend ...ext/intl/ext. All these directories main, Zend, ext are under the root of the PHP source tree, not ext/intl. Maybe you could provide steps to reproduce this from a fresh tarball, though my ability to diagnose the problem will be limited as I don't use or have access to Mac OS X. [2013-02-23 10:52:46] php-bugs-2013 at ryandesign dot com I may have selected the wrong package for this bug report. I'm talking about the intl extension bundled with PHP, not the intl extension on PECL. [2013-02-23 10:39:40] php-bugs-2013 at ryandesign dot com Description: I'm the maintainer of PHP in MacPorts, trying to update our php55 packages. In 5.5.0alpha4 everything built fine but with 5.5.0alpha5 the intl extension does not build: /bin/sh /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl/libtool --mode=compile /usr/bin/clang - I/opt/local/include -Wno-write-strings -I. - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl - DPHP_ATOM_INC - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl/include - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl/main - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl -I/opt/local/include/php55/php - I/opt/local/include/php55/php/main -I/opt/local/include/php55/php/TSRM - I/opt/local/include/php55/php/Zend -I/opt/local/include/php55/php/ext - I/opt/local/include/php55/php/ext/date/lib -I/opt/local/include - I/opt/local/include -I/opt/local/include -DHAVE_CONFIG_H -pipe -O2 -arch x86_64 -c /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl/converter/converter.c -o converter/converter.lo mkdir converter/.libs /usr/bin/clang -I/opt/local/include -Wno-write-strings -I. - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php- 5.5.0alpha5/ext/intl -DPHP_ATOM_INC - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl/include - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl/main - I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_php/php55- intl/work/php-5.5.0alpha5/ext/intl -I/opt/local/include/php55/php - I/opt/local/include/php55/php/main -I/opt/local/include/php55/php/TSRM - I/opt/local/include/php55/php/Zend -I/opt/local/include/php55/php/ext - I/opt/local/include/php55/php/ext/date/lib -I/opt/local/include - I/opt/local/include -I/opt/local/include -DHAVE_CONFIG_H -pipe -O2
Bug #62366 [Fbk-NoF]: Reflection problem
Edit report at https://bugs.php.net/bug.php?id=62366edit=1
ID: 62366
Updated by: php-bugs@lists.php.net
Reported by: alejosimon at gmail dot com
Summary: Reflection problem
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Reflection related
Operating System: Win7 x64
PHP Version: 5.4.4
New Comment:
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.
Previous Comments:
[2012-06-20 17:02:00] alejosimon at gmail dot com
Yes!! I'm sorry, this bug is from the APC extension. Without APC everything
works
perfect.
I´m use APC 3.1.9 and .10
Thanks for your time.
[2012-06-20 00:09:13] fel...@php.net
I can't reproduce it. Are you using any external extension?
[2012-06-19 22:29:39] alejosimon at gmail dot com
Description:
The some methods of reflection class don´t return the correctly values.
Test script:
---
?php
$object = new \stdClass ;
$ref = new \ReflectionClass( $object ) ;
var_dump( $ref-getName() ) ;
var_dump( $ref-name ) ;
print_r( $ref ) ;
var_dump( $ref ) ;
?
Expected result:
string(8) stdClass
string(8) stdClass
ReflectionClass Object
(
[name ] = stdClass
)
object(ReflectionClass)#37 (1) {
[name]=
string(8) stdClass
}
Actual result:
--
bool(false)
string(8) stdClass
ReflectionClass Object
(
[namei� � ] = stdClass
)
object(ReflectionClass)#37 (1) {
[name]=
string(8) stdClass
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62366edit=1
Bug #53595 [Fbk-NoF]: soap client can't handle 'any' element in wsdl schema
Edit report at https://bugs.php.net/bug.php?id=53595edit=1
ID: 53595
Updated by: php-bugs@lists.php.net
Reported by: alex at liokumovich dot com
Summary: soap client can't handle 'any' element in wsdl schema
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: SOAP related
Operating System: Linux
PHP Version: 5.2.16
New Comment:
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.
Previous Comments:
[2011-11-15 20:52:21] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-12-22 22:53:22] alex at liokumovich dot com
Description:
if WSDL schema contain 'any' element soap client failed
part of wsdl schema:
wsdl:definitions targetNamespace=url
wsdl:documentationThe Webservice for Saving Orders/wsdl:documentation
wsdl:types
s:schema elementFormDefault=qualified targetNamespace=url
s:element name=SaveOrder
s:complexType
s:sequence
s:element minOccurs=0 maxOccurs=1 name=xmlOrder
s:complexType mixed=true
s:sequence
s:any/
/s:sequence
/s:complexType
/s:element
/s:sequence
/s:complexType
/s:element
Test script:
---
$url = 'url?wsdl';
$params = array(
'xmlOrder' =
array(
'OrderInfo' = array(
'OrderId'= ,
)
)
)
$client = new SoapClient($url, array('soap_version' = SOAP_1_2));
//changing soap version doesn't reflect result
$client-__getFunctions();
$result = $client-SaveOrder($params);
Expected result:
result from web service call
Actual result:
--
Fatal error: Uncaught SoapFault exception: [Sender] SOAP-ERROR: Encoding:
object
hasn't 'any' property in /xxx/script.php:78 Stack trace: #0
/xxx/script.php(78):
SoapClient-__call('SaveOrder', Array) #1 /xxx/script.php(78): SoapClient-
SaveOrder(Array) #2 {main} thrown in /xxx/script.php on line 78
--
Edit this bug report at https://bugs.php.net/bug.php?id=53595edit=1
Bug #19302 [Fbk-NoF]: Invalid access to memory location
Edit report at https://bugs.php.net/bug.php?id=19302edit=1 ID: 19302 Updated by: php-bugs@lists.php.net Reported by: phpteam at vip dot sina dot com Summary: Invalid access to memory location -Status: Feedback +Status: No Feedback Type: Bug Package: IIS related Operating System: win200 adv server PHP Version: 4.2.2 New Comment: 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. Previous Comments: [2010-09-22 00:34:27] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And use FastCGI with IIS please. [2010-09-21 22:34:27] blogmaster at cartercole dot com im also having this issue... im on http://cartercole.com an IIS6 with php and mysql [2009-11-20 13:11:11] machhi_c_m at yahoo dot com Please refer to the link below: http://technosharepoint.blogspot.com/ [2008-07-24 10:59:25] minhduan at newsplus dot com dot vn dfsdf [2008-05-16 19:44:29] awakennow at bellsouth dot net Solution: I checked the ISAPI filter section of IIS admin and found php still pointing there to the okd version. I had change it in the configuration settings. Once both the filter and the configuration mappings were pointed to php5isapi.dll the sites worked. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=19302 -- Edit this bug report at https://bugs.php.net/bug.php?id=19302edit=1
Req #20226 [Fbk-NoF]: can't do foo.php/path.inf via cgi (with patch)
Edit report at https://bugs.php.net/bug.php?id=20226edit=1
ID: 20226
Updated by: php-bugs@lists.php.net
Reported by: tom at tomclegg dot net
Summary: can't do foo.php/path.inf via cgi (with patch)
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package: CGI/CLI related
Operating System: Unix
PHP Version: 4.2.3
New Comment:
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.
Previous Comments:
[2010-12-29 17:50:54] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2002-11-03 05:36:42] tom at tomclegg dot net
I use php as a cgi usuing Apache's Action directive. If I put a script in
/u/joe/pub/example.php and visit http://joe/example.php/foo then Apache puts
/example.php/foo in PATH_INFO, and PHP tries to open
/u/joe/pub/example.php/foo. (Internal server error; premature end of script
headers)
This patch checks /u, /u/joe, /u/joe/pub, etc.; if one of them is a regular
file (in this case /u/joe/pub/example.php) then that file is used as the script
filename. Now the script runs, with the entire PATH_INFO passed to it. (It's
up to the script to figure out which part to ignore.)
--- main/fopen_wrappers.c.orig Fri Aug 23 01:00:49 2002
+++ main/fopen_wrappers.c Sun Nov 3 02:54:26 2002
@@ -388,6 +388,23 @@
SG(request_info).path_translated = NULL;
return FAILURE;
}
+
+ /* check for /home/joe/public_html/example.php/pathinfo */
+ if (1) {
+ char *s;
+ for (s=filename+1; *s; s++) {
+ if (*s == PHP_DIR_SEPARATOR *(s-1) !=
PHP_DIR_SEPARATOR) {
+ *s = 0;
+ if (0 == stat (filename, st)) {
+ if (S_ISREG(st.st_mode)) {
+ break;
+ }
+ }
+ *s = PHP_DIR_SEPARATOR;
+ }
+ }
+ }
+
fp = VCWD_FOPEN(filename, rb);
/* refuse to open anything that is not a regular file */
--
Edit this bug report at https://bugs.php.net/bug.php?id=20226edit=1
Bug #22427 [Fbk-NoF]: Missing Form Post Data
Edit report at https://bugs.php.net/bug.php?id=22427edit=1 ID: 22427 Updated by: php-bugs@lists.php.net Reported by: jroland at uow dot edu dot au Summary: Missing Form Post Data -Status: Feedback +Status: No Feedback Type: Bug Package: *General Issues Operating System: Windows XP / 2000 PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2012-10-17 14:39:15] vincentwansink at shaw dot ca I am having this problem now with version 5.4.0. I am shocked to see that this issue has been around since 2003 and it is still happening. I've been using PHP for about 8 years and never came across this before. Also this just started happening to me after I moved my site to a brand new server and upgraded to version 5.4 so I'm guessing there must be some unique configuration combination that causes this to happen. I am having it happen with small text fields (20 characters or less). Being able to rely on post back data is obviously critical to any PHP application so why is this bug still around? It's embarassing to have to tell my clients I don't know why it's doing that. [2010-07-07 10:52:52] paj...@php.net We don't support PHP 4 anymore and we never supported patched PHP (like with Suhosin). Please try again with a recent PHP version, unpatched. [2010-07-07 10:47:00] kernelu at gmail dot com Had the same problem (the submited data was truncated) and fixed it by editing the suhosin.ini file, something like this(uncommented some lines and increased the values): ; Filtering Options ;suhosin.filter.action = ;suhosin.cookie.max_array_depth = 100 ;suhosin.cookie.max_array_index_length = 64 ;suhosin.cookie.max_name_length = 64 ;suhosin.cookie.max_totalname_length = 256 ;suhosin.cookie.max_value_length = 1 ;suhosin.cookie.max_vars = 100 ;suhosin.cookie.disallow_nul = on suhosin.get.max_array_depth = 150 suhosin.get.max_array_index_length = 164 suhosin.get.max_name_length = 164 suhosin.get.max_totalname_length = 512 suhosin.get.max_value_length = 1024 suhosin.get.max_vars = 500 suhosin.get.disallow_nul = on suhosin.post.max_array_depth = 500 suhosin.post.max_array_index_length = 1024 suhosin.post.max_name_length = 164 suhosin.post.max_totalname_length = 1256 suhosin.post.max_value_length = 65 suhosin.post.max_vars = 1200 suhosin.post.disallow_nul = on suhosin.request.max_array_depth = 500 suhosin.request.max_array_index_length = 1024 suhosin.request.max_totalname_length = 1256 suhosin.request.max_value_length = 65 suhosin.request.max_vars = 1200 suhosin.request.max_varname_length = 164 suhosin.request.disallow_nul = on ;suhosin.upload.max_uploads = 25 ;suhosin.upload.disallow_elf = on ;suhosin.upload.disallow_binary = off ;suhosin.upload.remove_binary = off ;suhosin.upload.verification_script = ;suhosin.session.max_id_length = 128 [2010-02-03 10:22:15] lars at renoz dot dk Same problem here - $_POST is randomly incomplete or empty. I have only seen this with IE - from version 6 to 8. tcpdump shows a bit more of the story: user sends: POST /bla.php?id=bla ... Content-Length: 80 but there is no data in that packet. A bit later Apache reaches timeout, and closes the connection. At this point it send a 503 error to the user, but executes PHP with the incomplete post. After the user received the 503 error - the browser actually sends a packet with the missing post data. Strange and clearly a browser bug. It should be noted that the post is so small that there is plenty of room in the first packet. Now - the strange part is - why is PHP being executed? And why is PHP allowing it self to be executed. Content-Length is clearly invalid, and the conntection is closed (and PHP is setup to ignore aborted requests (ignore_user_abort is off). [2010-01-27 20:44:34] pierre at greywacke dot co dot za hi, i forgot to add the form submitted. i believe this could be in ie, but why? how can i prevent this from happening? form name=contact method=POST action=action.php enctype=multipart/form-data id=contact onSubmit=return Validatecontact(this); using php 5.2.9 - believe the problem to be client browser side as reported in other comments. The remainder of the comments for this report
Req #23141 [Fbk-NoF]: pg_fetch_all functionallity
Edit report at https://bugs.php.net/bug.php?id=23141edit=1 ID: 23141 Updated by: php-bugs@lists.php.net Reported by: php at seahat dot com Summary: pg_fetch_all functionallity -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: PostgreSQL related Operating System: All PHP Version: 4.3.0 New Comment: 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. Previous Comments: [2012-03-31 05:20:36] yohg...@php.net I'm not sure what do you mean by (preferrably a primary key) Filter by primary key? [2003-04-09 17:47:05] php at seahat dot com Short and sweet: I like the new pg_fetch_all() function. I would like it better if an option could be used to specify what column in the results to use for an associative array key (preferrably a primary key). -- Edit this bug report at https://bugs.php.net/bug.php?id=23141edit=1
Req #27986 [Fbk-NoF]: .lo unrecognized file suffix
Edit report at https://bugs.php.net/bug.php?id=27986edit=1
ID: 27986
Updated by: php-bugs@lists.php.net
Reported by: sandduneinfo at earthlink dot net
Summary: .lo unrecognized file suffix
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package: Compile Failure
Operating System: AIX 5.1
PHP Version: 4CVS, 5CVS (2004-04-16)
New Comment:
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.
Previous Comments:
[2011-01-01 23:37:17] j...@php.net
Is this still an issue with PHP 5.3.x ?
[2004-05-21 11:58:38] marino dot strazzullo at elsag dot it
On my AIX 4.3.3 i have resolved the invalid suffix problem:
Modify ./libtool at line 49 and change build_old_libs=no to
build_old_libs=yes, then execute make...
Bye
[2004-05-12 18:49:01] j...@php.net
Have you tried the fix suggested here yet?
http://marc.theaimsgroup.com/?l=php-installm=104327038604878w=2
I don't have access AIX so I have no idea if it works, but
it's worth a shot...
J
[2004-05-07 19:54:10] sandduneinfo at earthlink dot net
OK,
I made the modifications indicated, the only errors that remains is the error
about .lo being an unrecognized file extension - looked in libtool but not sure
where I make the change to accept the .lo extension. Need a little more
guidance and the make should succeed.
I would greatly appreciate a prompt response.
[2004-05-06 16:46:10] der...@php.net
Please try the patch below:
Index: ext/standard/array.c
===
RCS file: /repository/php-src/ext/standard/array.c,v
retrieving revision 1.199.2.32
diff -u -p -r1.199.2.32 array.c
--- ext/standard/array.c1 Apr 2004 19:07:01 - 1.199.2.32
+++ ext/standard/array.c6 May 2004 14:45:32 -
@@ -1692,7 +1692,7 @@ static void _phpi_pop(INTERNAL_FUNCTION_
zval **stack, /* Input stack */
**val; /* Value to be popped */
char *key = NULL;
- int key_len = 0;
+ uint key_len = 0;
ulong index;
/* Get the arguments and do error-checking */
Index: ext/standard/file.c
===
RCS file: /repository/php-src/ext/standard/file.c,v
retrieving revision 1.279.2.59
diff -u -p -r1.279.2.59 file.c
--- ext/standard/file.c 2 Apr 2004 16:54:44 - 1.279.2.59
+++ ext/standard/file.c 6 May 2004 14:45:34 -
@@ -909,7 +909,7 @@ static int parse_context_options(php_str
HashPosition pos, opos;
zval **wval, **oval;
char *wkey, *okey;
- int wkey_len, okey_len;
+ uint wkey_len, okey_len;
int ret = SUCCESS;
ulong num_key;
Index: ext/standard/info.c
===
RCS file: /repository/php-src/ext/standard/info.c,v
retrieving revision 1.218.2.15
diff -u -p -r1.218.2.15 info.c
--- ext/standard/info.c 15 Mar 2004 16:39:53 - 1.218.2.15
+++ ext/standard/info.c 6 May 2004 14:45:35 -
@@ -357,9 +357,7 @@ PHPAPI void php_print_info_htmlhead(TSRM
PUTS(head\n);
php_info_print_style();
PUTS(titlephpinfo()/title);
-/*
- php_printf(meta http-equiv=\Content-Type\ content=\text/html;
charset=%s\ /\n, charset);
-*/
+ php_printf(meta http-equiv=\Content-Type\ content=\text/html;
charset=iso-8859-1\ /\n);
PUTS(/head\n);
PUTS(bodydiv class=\center\\n);
}
@@ -472,7 +470,7 @@ PHPAPI void php_print_info(int flag TSRM
{
HashTable *url_stream_wrappers_hash;
char *stream_protocol, *stream_protocols_buf = NULL;
- int stream_protocol_len, stream_protocols_buf_len = 0;
+ uint stream_protocol_len, stream_protocols_buf_len = 0;
ulong num_key
Bug #30688 [Fbk-NoF]: imap_mail's rpath don't work
Edit report at https://bugs.php.net/bug.php?id=30688edit=1 ID: 30688 Updated by: php-bugs@lists.php.net Reported by: sirber at gmail dot com Summary: imap_mail's rpath don't work -Status: Feedback +Status: No Feedback Type: Bug Package: IMAP related Operating System: Gentoo Linux 2.6.9 PHP Version: 4.3.9 New Comment: 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. Previous Comments: [2012-07-07 20:03:50] s...@php.net Could you please address the comments on the pull by Johannes? [2012-04-11 23:17:06] johan...@php.net See also https://github.com/php/php-src/pull/52 [2011-08-04 20:44:53] ava3ar at gmail dot com There ya go patched it for you, can be pack ported to 5.3 if needed thanks to pajoye for putting patch on this patch has only been tested on amd64, so no idea if it will work on x86 or other, but i dont see a reason it wont work on x86 [2011-08-04 16:18:52] paj...@php.net The following patch has been added/updated: Patch Name: Patch-by-Keloran-ava3ar-at-gmail-com Revision: 1312474732 URL: https://bugs.php.net/patch-display.php?bug=30688patch=Patch-by-Keloran-ava3ar-at-gmail-comrevision=1312474732 [2010-03-20 21:46:01] mvanbeek at supporting-role dot co dot uk If this bug is not going to be fixed, then the parameter should be removed from the function, or the function should become a wrapper for mail(). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30688 -- Edit this bug report at https://bugs.php.net/bug.php?id=30688edit=1
Bug #33011 [Fbk-NoF]: shmop: can still open segment for reading after shmop_delete
Edit report at https://bugs.php.net/bug.php?id=33011edit=1 ID: 33011 Updated by: php-bugs@lists.php.net Reported by: joe at bs0 dot com Summary: shmop: can still open segment for reading after shmop_delete -Status: Feedback +Status: No Feedback Type: Bug Package: Semaphore related Operating System: win32 only PHP Version: 5.2.6 New Comment: 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. Previous Comments: [2013-02-18 00:11:37] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2010-10-17 19:28:46] fel...@php.net Could you attach the patch in this report? Thanks. [2008-06-07 02:58:13] pmvcallan at gmail dot com Same problem running apache 2, php 5.2.6 on windows. Attempted closing then deleting and deleting then closing the block, returns true in both cases. Still leaves the block and contents intact regardless. [2007-07-18 04:01:18] s...@php.net Just noting two things: one, the patch is no longer online and two, Ilia doesn't really 'do' Windows any more. I looked at it but don't have time to play right now, not least because I don't have a current copy of PHP on board. I _think_ it probably just needs a flag setting in shmctl() (in tsrm_win32.c) when it's called from shmop_delete() - not sure. Something like: shm-descriptor-shm_perm.mode = IPC_EXCL; - but again not sure, there's a copy flying around there somewhere. I'd need to test. [2007-07-13 20:55:38] jmccaskey at gmail dot com I'm experiencing this same issue on PHP 5.2.2 under Apache 2 on windows. How is it that this issue was opened years ago and is not fixed? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=33011 -- Edit this bug report at https://bugs.php.net/bug.php?id=33011edit=1
Bug #33693 [Fbk-NoF]: mssql uniqueidentifier in select crashes php
Edit report at https://bugs.php.net/bug.php?id=33693edit=1 ID: 33693 Updated by: php-bugs@lists.php.net Reported by: r dot vanicek at seznam dot cz Summary: mssql uniqueidentifier in select crashes php -Status: Feedback +Status: No Feedback Type: Bug Package: Sybase-ct (ctlib) related Operating System: Linux (Debian 3.1) PHP Version: 4.4.0 New Comment: 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. Previous Comments: [2010-09-23 11:43:13] paj...@php.net It is not marked as fixed but as no feedback. Also 5.2.1 is dead, dead and dead. Please try using 5.3.3 or 5.2.14. Also if you use sqlserver you should use mssql extensions or odbc instead of sybase_ct. [2010-09-23 11:35:04] t dot nickl at exse dot de This is not fixed in php 5.2.1. Did you fix it? Why is this closed? [2008-09-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-09-03 09:53:24] paj...@php.net Can you try using the latest 5.2.x and 5.3.0 snapshot? [2008-09-03 09:45:14] steveh at brendata dot co dot uk This is still an issue on the php 5.2.1, is it intended to fix this? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=33693 -- Edit this bug report at https://bugs.php.net/bug.php?id=33693edit=1
Bug #33997 [Fbk-NoF]: Returned: Bug #16069 - ICONV transliteration failure
Edit report at https://bugs.php.net/bug.php?id=33997edit=1 ID: 33997 Updated by: php-bugs@lists.php.net Reported by: RVaughn at pheedo dot com Summary: Returned: Bug #16069 - ICONV transliteration failure -Status: Feedback +Status: No Feedback Type: Bug Package: ICONV related Operating System: * PHP Version: 5.*, 6CVS (2009-04-25) New Comment: 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. Previous Comments: [2010-06-13 15:00:25] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-27 16:13:23] j...@php.net Still fails. [2005-08-08 00:10:15] sni...@php.net Assigning to Derick who's comment about my patch was It's funny and other comment about the iconv code this is a mess :) [2005-08-07 14:42:23] der...@php.net Please provide a location where we can download your failed test's .out and .exp file. [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=33997 -- Edit this bug report at https://bugs.php.net/bug.php?id=33997edit=1
Req #35397 [Fbk-NoF]: php-5.1.0-installer.exe fails without a valid C:
Edit report at https://bugs.php.net/bug.php?id=35397edit=1 ID: 35397 Updated by: php-bugs@lists.php.net Reported by: tcarta at hotmail dot com Summary: php-5.1.0-installer.exe fails without a valid C: -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: *General Issues Operating System: Windows XP PHP Version: 5.1.0 New Comment: 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. Previous Comments: [2013-02-18 00:18:17] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2010-12-22 12:55:35] johan...@php.net Please try with a recent version. [2005-11-25 17:52:25] tcarta at hotmail dot com Description: The php-5.1.0-installer.exe fails if I don't have a valid c: drive. My PC uses H: as the default drive while C: is used for a removable memory card. When installing PHP to h:\php, I get a message telling me: This software requires an additional 4327K bytes free on the C: drive to install. Please remove any unnecessary files and try again The C: drive is obviously hardcoded into the setup application, instead of the setup applicaton using the drive I want to install to (i.e. H:). Since I don't have a C: drive, the PHP installation fails altogether if I don't insert a memory card in C:. Reproduce code: --- Run the php-5.1.0-installer.exe on a PC that does not have a C: drive Expected result: The error message mentioned -- Edit this bug report at https://bugs.php.net/bug.php?id=35397edit=1
Bug #36663 [Fbk-NoF]: unexpected difference between zlib.output_compression and ob_gzhandler
Edit report at https://bugs.php.net/bug.php?id=36663edit=1 ID: 36663 Updated by: php-bugs@lists.php.net Reported by: atom at smasher dot org Summary: unexpected difference between zlib.output_compression and ob_gzhandler -Status: Feedback +Status: No Feedback Type: Bug Package: Output Control Operating System: FreeBSD PHP Version: 4.4.2 Private report: N New Comment: 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. Previous Comments: [2011-09-19 14:41:42] m...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-18 18:42:42] ka...@php.net Re-classified for it to be confirmed behavoir, please change back to a documentation issue and as To be documented if this indeed is expected behavoir. [2009-11-23 13:34:05] vr...@php.net I can confirm the behavior but could not find any place in the sources which explains it. [2006-03-09 16:46:57] atom at smasher dot org If nothing else, this would at least be a documentation bug. [2006-03-09 09:15:26] atom at smasher dot org Description: if php.ini has: output_handler = ob_gzhandler dynamically generated JPGs are output with gzip (Content-Encoding: gzip). if php.ini has (instead): zlib.output_compression = on dynamically generated JPGs are output without gzip. In both cases the HTTP request includes Accept-Encoding: gzip. It does seem stupid to attempt to compress a compressed image file, but I can't find any documentation that explains which way is the right way to do it, or how to override the default behavior. -- Edit this bug report at https://bugs.php.net/bug.php?id=36663edit=1
Req #38917 [Fbk-NoF]: OpenSSL: signing function for spkac
Edit report at https://bugs.php.net/bug.php?id=38917edit=1
ID: 38917
Updated by: php-bugs@lists.php.net
Reported by: zeph at purotesto dot it
Summary: OpenSSL: signing function for spkac
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package: OpenSSL related
Operating System: Irrilevant
PHP Version: trunk
New Comment:
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.
Previous Comments:
[2012-12-19 15:14:04] queenzeal at gmail dot com
If you want SPKAC support in PHP without having to recompile it, try the latest
Git version of phpseclib (http://phpseclib.sourceforge.net/). An example of how
to
use it:
http://www.frostjedi.com/phpbb3/viewtopic.php?p=389618#p389618
[2012-01-10 10:38:37] jason dot gerfen at gmail dot com
I have added the requested test case and it is included in the patch
as 026.phpt. I have also performed the required testing against the
Openssl 0.9.8x and 1.0.0x. It is attached to the original bug report
#38917. In addition to attaching the proposed patch I have created a
github repo to make maintenance on the patch simple for myself. The
URL is https://github.com/jas-/SPKAC-PHP-OpenSSL.
[2011-12-21 10:49:08] jason dot gerfen at gmail dot com
Once again, please disregard the last message. After researching the
documentation I found that where I had been using NULL with the
openssl_csr_sign() function allows for a CA option as well as the SPKAC
addition to the configargs optional array.
The patch was updated last night to include the 026.phpt test script, as well
as the five new functions to work with the SPKI provided by keygen tags.
How do patch inclusions work besides posting them to the php internals list?
[2011-12-14 22:10:52] jason dot gerfen at gmail dot com
Please disregard my previous comment. I did a little more digging and am under
the impression that adding the following to php_openssl_make_REQ() function
should allow me to create a self signed certificate using the SPKAC NID like so?
if (strcmp(strindex, SPKAC) == 0) {
if (!X509_NAME_add_entry_by_txt(subj, strindex, MBSTRING_ASC, (unsigned
char*)Z_STRVAL_PP(item), -1, -1, 0)){
php_error_docref(NULL TSRMLS_CC, E_WARNING, dn: add_entry_by_txt %s - %s
(failed), strindex, Z_STRVAL_PP(item));
return FAILURE;
}
}
Would you recommend another method? Please advise.
[2011-12-14 19:40:20] jason dot gerfen at gmail dot com
One other question about using SPKAC's when creating a x509. It seems the
current method using openssl_csr_new() which in turn calls the
php_openssl_make_REQ() to assign the specified DN attributes has no method of
adding the SPKAC field.
After digging around it seems logical to use the OBJ_create() and OBJ_* family
of functions to add NID. Please forgive me if I am way off here but any
direction you could point me in using the existing functions to output and sign
a certificate similar to the following command?
openssl ca -config /path/to/openssl.conf -days 180 -notext -batch \
-spkac /path/to/cert.pem -out /path/to/signed.pem -passin pass:'random'
My assumption is that I will need to create one specifically for this purpose
but would like your insight.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=38917
--
Edit this bug report at https://bugs.php.net/bug.php?id=38917edit=1
Bug #39485 [Fbk-NoF]: mkdir() fails when pathname have space(s) on the final
Edit report at https://bugs.php.net/bug.php?id=39485edit=1
ID: 39485
Updated by: php-bugs@lists.php.net
Reported by: v1d4l0k4 at gmail dot com
Summary: mkdir() fails when pathname have space(s) on the final
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: *Directory/Filesystem functions
Operating System: Windows XP (Win32 only)
PHP Version: 5.2.0
New Comment:
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.
Previous Comments:
[2010-07-14 03:50:30] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2006-11-29 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-11-21 21:03:31] tony2...@php.net
Cannot reproduce:
C:\php -r var_dump(mkdir('dirname '));
bool(true)
[2006-11-13 04:29:24] v1d4l0k4 at gmail dot com
Description:
The 'mkdir' function doesn't function correctly on Windows when the pathname
contain space(s) on the final. PHP returns a warning, and the directory isn't
created:
Warning: mkdir() [function.mkdir]: Invalid argument in X on line Y
Temporary fix: use trim() on the pathname
Besides, if the pathname contain space(s) on the start, the directory is
created when couldn't even so (in accordance with the behavior of Windows
Explorer).
Reproduce code:
---
?php
mkdir('pathname ');
mkdir(' pathname');
?
Expected result:
?php
mkdir('pathname '); // Succeeds, but trim() before, in accordance with the
behavior of Windows Explorer
mkdir(' pathname'); // Succeeds, but trim() before, in accordance with the
behavior of Windows Explorer
?
Actual result:
--
?php
mkdir('pathname '); // Fails
mkdir(' pathname'); // Succeeds even not being recommended
?
--
Edit this bug report at https://bugs.php.net/bug.php?id=39485edit=1
Req #41082 [Fbk-NoF]: url_rewriter.tags are wrong
Edit report at https://bugs.php.net/bug.php?id=41082edit=1
ID: 41082
Updated by: php-bugs@lists.php.net
Reported by: der-coole-carl at gmx dot net
Summary: url_rewriter.tags are wrong
-Status: Feedback
+Status: No Feedback
Type:Feature/Change Request
Package: *General Issues
PHP Version: 5.2.1
New Comment:
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.
Previous Comments:
[2012-03-29 09:34:12] der-coole-carl at gmx dot net
No, today I think this whole feature is bad.
[2012-03-29 09:27:53] yohg...@php.net
Do you still want this feature?
[2007-04-14 00:21:27] der-coole-carl at gmx dot net
Description:
it would be good if you can change
url_rewriter.tags from
a=href,area=href,frame=src,input=src,form=,fieldset=
to
a=href,area=href,frame=src,input=src,form=action,fieldset=
if i use session_use_trans_sid it doesn't put the SID in my forms.. that's
maybe you forgot the form=_action_
i don't know if it matters:
i use: ob_start(ob_gzhandler); to compress my code.. maybe this is relevant
Reproduce code:
---
?php
ini_set('session.use_trans_sid', 1);
?
form action=test.php method=post
input type=submit
/form
in this example the user have to deactivate cookies
Expected result:
i expect that the target url will be: test.php?phpsessid=1234
Actual result:
--
actual the target url is test.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=41082edit=1
Bug #40479 [Fbk-NoF]: zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=40479edit=1 ID: 40479 Updated by: php-bugs@lists.php.net Reported by: rrossi at maggioli dot it Summary: zend_mm_heap corrupted -Status: Feedback +Status: No Feedback Type: Bug Package: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: 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. Previous Comments: [2012-05-20 00:58:53] bj...@php.net [02:48] @nikic I think user comments should be blocked and there should be some big message at the top saying that people should report separate bugs for their issues [02:48] @nikic So if someone can edit the report to include a message at the top that would be great [02:48] @nikic It doesn't really help a lot if all zend_mm_heap corrupted reports go into one bug ^^ [2012-04-02 13:41:26] komanek at natur dot cuni dot cz For me it seems the solution is to compile PHP with --disable-zend-multibyte instead of --enable-zend-multibyte But I am not sure if it breaks something else, I didn't find much documentation on these options. [2012-03-30 18:47:46] nathan at gt dot net Also to add, USE_ZEND_ALLOC=0 did not resolve but gc_disable(); did [2012-03-30 18:46:12] nathan at gt dot net I've also confirmed the above testcase triggers it on 5.3.10 via CLI. Can provide full access to any php developer interested in taking a look, just email me. [2012-03-28 11:42:16] komanek at natur dot cuni dot cz Hi, I used the USE_ZEND_ALLOC=0 and got another segfault. But in this case in the apache error log is hopefuly something useful: *** glibc detected *** /usr/local/apache2/bin/httpd: double free or corruption (!prev): 0x051d6e10 *** === Backtrace: = /lib/libc.so.6[0x7f5a8e3709a8] /lib/libc.so.6(cfree+0x76)[0x7f5a8e372ab6] /usr/local/apache2/modules/libphp5.so(zend_multibyte_read_script+0x2e)[0x7f5a887be90e] /usr/local/apache2/modules/libphp5.so(open_file_for_scanning+0x90)[0x7f5a887bed60] /usr/local/apache2/modules/libphp5.so(compile_file+0x9c)[0x7f5a887bf92c] /usr/local/apache2/modules/libphp5.so[0x7f5a8866575a] /usr/local/apache2/modules/libphp5.so[0x7f5a8881c733] /usr/local/apache2/modules/libphp5.so(execute+0x209)[0x7f5a88813c49] /usr/local/apache2/modules/libphp5.so(zend_execute_scripts+0x17b)[0x7f5a887e52db] /usr/local/apache2/modules/libphp5.so(php_execute_script+0x198)[0x7f5a8878e0f8] /usr/local/apache2/modules/libphp5.so[0x7f5a8887348f] /usr/local/apache2/bin/httpd(ap_run_handler+0x4a)[0x443f5a] /usr/local/apache2/bin/httpd(ap_invoke_handler+0xce)[0x44747e] /usr/local/apache2/bin/httpd(ap_process_request+0x18e)[0x465ece] /usr/local/apache2/bin/httpd[0x462d78] /usr/local/apache2/bin/httpd(ap_run_process_connection+0x4a)[0x44b45a] /usr/local/apache2/bin/httpd[0x46abd0] /usr/local/apache2/bin/httpd[0x46aea4] /usr/local/apache2/bin/httpd(ap_mpm_run+0xbde)[0x46baee] /usr/local/apache2/bin/httpd(main+0x99a)[0x43063a] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f5a8e31b1a6] /usr/local/apache2/bin/httpd(apr_os_proc_mutex_put+0x49)[0x42f819] === Memory map: 0040-00493000 r-xp 08:01 442565 /usr/local/apache2/bin/httpd 00692000-00698000 rw-p 00092000 08:01 442565 /usr/local/apache2/bin/httpd 00698000-0069d000 rw-p 00698000 00:00 0 017e-053d4000 rw-p 017e 00:00 0 [heap] 7f5a8000-7f5a80021000 rw-p 7f5a8000 00:00 0 7f5a80021000-7f5a8400 ---p 7f5a80021000 00:00 0 7f5a8497c000-7f5a84992000 r-xp 08:01 835587 /lib/libgcc_s.so.1 7f5a84992000-7f5a84b92000 ---p 00016000 08:01 835587 /lib/libgcc_s.so.1 7f5a84b92000-7f5a84b93000 rw-p 00016000 08:01 835587 /lib/libgcc_s.so.1 7f5a84b9d000-7f5a84b9e000 r--s 08:11 78792612 /home/apache2/htdocs/horde/lib/core.php 7f5a84b9e000-7f5a84bc1000 r--p 08:11 78799575 /home/apache2/htdocs/horde/mnemo/locale/cs_CZ/LC_MESSAGES/mnemo.mo 7f5a84bc1000-7f5a84bc5000 r-xp 08:01 1884172 /lib/libnss_dns-2.7.so 7f5a84bc5000-7f5a84dc4000 ---p 4000 08:01 1884172 /lib/libnss_dns-2.7.so 7f5a84dc4000-7f5a84dc6000 rw-p 3000 08:01 1884172
Req #41459 [Fbk-NoF]: [PATCH] PDO::pgsqlGetNotify()
Edit report at https://bugs.php.net/bug.php?id=41459edit=1 ID: 41459 Updated by: php-bugs@lists.php.net Reported by: spher...@php.net Summary: [PATCH] PDO::pgsqlGetNotify() -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: PostgreSQL related Operating System: Mac OS X 10.4.9 PHP Version: 5CVS-2007-05-21 (CVS) Assigned To: yohgaki New Comment: 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. Previous Comments: [2012-03-31 05:36:59] yohg...@php.net It seems the patch URL is invalid now. Do you still have this problem and patch? [2007-10-22 08:14:31] spher...@php.net Changed patch address to http://spheroid.fi/tmp/pgsqlGetNotify.diff [2007-05-21 14:46:06] spher...@php.net Description: I read Wez was working on PDO::pgsqlGetNotify(), but since I couldn't find any implementation, I made a crude copypaste from ext/pgsql. The following patch should do it: http://spheroid.fi/pgsqlGetNotify.diff -- Edit this bug report at https://bugs.php.net/bug.php?id=41459edit=1
Bug #42266 [Fbk-NoF]: BLOB functions do not work on 64bit systems
Edit report at https://bugs.php.net/bug.php?id=42266edit=1 ID: 42266 Updated by: php-bugs@lists.php.net Reported by: karasek at ceskyserver dot cz Summary: BLOB functions do not work on 64bit systems -Status: Feedback +Status: No Feedback Type: Bug Package: InterBase related Operating System: Linux 64-bit PHP Version: 5.2.4 Assigned To: abies New Comment: 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. Previous Comments: [2011-09-12 09:50:04] mar...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-07 10:11:20] lester at lsces dot co dot uk Currently I have PHP5.2.9 and 10 running without any blob id problem on a number of 64 bit distributions. And 5.3 running on Vista64 as well again without displaying this bug. So I think we need a lot more information from people who DO have this problem still [2009-07-23 09:30:41] andre at spiceware dot co dot za I can confirm that php 5.2.1 was the last working version for BLOBS on 64 bit operating system as I have downloaded all the versions since then to check each one. I have recently compiled 5.3.0 with no joy too! [2009-06-08 10:10:57] lester at lsces dot co dot uk I think we needs some proper feedback on this problem. There WAS a problem with some builds of PHP from 5.2.0 to 5.2.5 relating to how the blob ID was handled after some re-engineering of the core PHP code. This resulted in a problem which was clearly visible when running ADOdb, since it could not access the BLOB_ID. Since 5.2.6 that problem has been fixed, and I'm currently running both windows and linux x64 machineswithout the back to get around the problem. So as far as I am concerned this bug has been cleared. So where are people still seeing it and how can we recreate that view of the problem? [2009-05-21 20:35:59] mkoeditz at gmx dot de Well, i've just installed openSUSE 10.3 with php 25.2.9 and Firebird 2.1. 32 bit system. Same error. So I think there is no focus on the platform but the php version. Regards Martin The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=42266 -- Edit this bug report at https://bugs.php.net/bug.php?id=42266edit=1
Bug #41770 [Fbk-NoF]: SSL: fatal protocol error due to buffer issues
Edit report at https://bugs.php.net/bug.php?id=41770edit=1
ID: 41770
Updated by: php-bugs@lists.php.net
Reported by: car...@php.net
Summary: SSL: fatal protocol error due to buffer issues
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.2.3
Assigned To: pajoye
New Comment:
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.
Previous Comments:
[2010-12-18 09:23:07] paj...@php.net
Please try using a recent PHP version (5.3+) and a decent openssl version
(0.9.8k+). We also need an URL against which we can reproduce the error, as
well as the script you use to do it.
[2010-12-18 00:42:14] ryandewhurst at gmail dot com
I have come across many PHP bug reports on this dating back to 2003 and every
single one tries to mask the problem rather than solve it. We will soon be in
2011, is there or have there been any fixes for this? The https server is
PayPal.
# php -v
PHP 5.1.6 (cli) (built: Mar 31 2010 02:44:37)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
CentOS 5.x
[2007-12-17 02:14:07] paul at cynergydata dot com
I'm using PHP 5.1.4 on a Windows XP Laptop running Apache 2.0 and I get the
error when using SoapClient. Here is my code:
$url = https://payments.cynergydata.com/SmartPayments/transact2.asmx?WSDL;;
$client = new SoapClient($url);
-- a pretty simple example going against an IIS server. I will try other
methods as I need to find a workaround for a client ASAP.
[2007-07-25 13:31:41] johnw at sussex dot ac dot uk
I get this bug too,using fsockopen('ssl://...') followed by fgets()
I'm using PHP 5.2.1 on Solaris 9 using OpenSSL/0.9.7b.
If I call @fgets(...) my application seems to work but it would be
better if the bug was fixed properly!
The ssl server I'm connecting to is an IIS one.
[2007-07-13 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=41770
--
Edit this bug report at https://bugs.php.net/bug.php?id=41770edit=1
Req #42738 [Fbk-NoF]: htmlspecialchars default quote_style set at runtime.
Edit report at https://bugs.php.net/bug.php?id=42738edit=1 ID: 42738 Updated by: php-bugs@lists.php.net Reported by: segalerez at gmail dot com Summary: htmlspecialchars default quote_style set at runtime. -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: *General Issues Operating System: Irrelevant PHP Version: 5.2.4 New Comment: 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. Previous Comments: [2010-04-06 19:30:53] ras...@php.net What do you mean by quote style here? quot; vs. #34; or do you really mean not encoding quotes at all vs. encoding them? [2007-09-23 03:18:45] segalerez at gmail dot com Description: I wish that PHP had an option to set a runtime variable that sets the default quote style for htmlspecialchars. Something like set_htmlspecialchars_quote_style(ENT_QUOTES); this way I could build a PHP component that wouldn't have to deal with the quote style at all. if the user wants to change to quote style of my component he could easily set this default style. Every page will always use one quote style, depending on wether it's an HTML or XHTML. -- Edit this bug report at https://bugs.php.net/bug.php?id=42738edit=1
Req #42445 [Fbk-NoF]: fopen url wrapper doesn't handle chunked encoding
Edit report at https://bugs.php.net/bug.php?id=42445edit=1
ID: 42445
Updated by: php-bugs@lists.php.net
Reported by: jerome at rainstormconsulting dot com
Summary: fopen url wrapper doesn't handle chunked encoding
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package: *General Issues
Operating System: Any
PHP Version: 5.2.3
New Comment:
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.
Previous Comments:
[2010-08-08 16:04:07] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-08-08 15:52:17] artnorm at gmail dot com
This problem might be solved today. When I read it right on HTTP context
options http://www.php.net/manual/en/context.http.php, chunked transfer
should now be supported.
[2007-08-27 14:46:13] jerome at rainstormconsulting dot com
Description:
Opening a URL via fopen()/fread() does not work properly if Transfer-
Encoding: chunked is used
Reproduce code:
---
?php
$fp =
fopen('http://www.bluestatecoffee.com/blog/topics/blue-state-coffee-news/feed/rss2',
'r');
$data = fread($fp, 45);
print htmlentities($data);
Expected result:
?xml version=1.0 encoding=UTF-8?
Actual result:
--
29d0 ?xml version=1.0 encoding=UTF-8?
--
Edit this bug report at https://bugs.php.net/bug.php?id=42445edit=1
Bug #42631 [Fbk-NoF]: mssql_connect causes stack smashing attack protection
Edit report at https://bugs.php.net/bug.php?id=42631edit=1
ID: 42631
Updated by: php-bugs@lists.php.net
Reported by: gabe at mudbugmedia dot com
Summary: mssql_connect causes stack smashing attack protection
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: MSSQL related
Operating System: Gentoo Linux 2.6.17-hardened-r1
PHP Version: 5.2.4
New Comment:
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.
Previous Comments:
[2010-10-09 00:18:09] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2007-09-12 14:30:53] gabe at mudbugmedia dot com
Same behavior occurs on the supplied dev link downloaded on 2007-09-12
configure settings for compile:
'./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' '--with-bz2' '--disable-calendar'
'--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-
exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--
disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--
without-iconv' '--disable-ipv6' '--disable-json' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql'
'--with-mssql' '--without-ncurses' '--with-openssl' '--with-openssl-
dir=/usr' '--disable-pcntl' '--disable-pdo' '--without-pgsql' '--
without-pspell' '--without-recode' '--disable-reflection' '--disable-
simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' '--
disable-sockets' '--disable-spl' '--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' '-
-disable-zip' '--with-zlib' '--disable-debug' '--without-cdb' '--
without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile'
'--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--
disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--
without-xpm-dir' '--with-gd' '--with-mysql=/usr' '--with-mysql-
sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline'
'--without-libedit' '--without-mm' '--without-sqlite' '--with-pic'
[2007-09-12 11:40:06] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-09-11 20:31:51] gabe at mudbugmedia dot com
Description:
When executing a PHP script over Apache 2.2 SAPI (not CGI),
mssql_connect() causes Apache to exit with the following in the
syslog:
apache2: stack smashing attack in function tds_write_packet -
terminated
This occurs only after successfully connecting to a valid MSSQL
server, but before authentication information is verified; supplying
invalid username/password will still cause the error to trigger.
However, entering in a non-listening IP to connect to will return
false and continue execution.
Gentoo developers identified this bug as PHP instead of Apache, as
Apache is not responsible for the calling of the tds_write_packet()
function
Bug originally submitted here, but was reclassified as being UPSTREAM:
http://bugs.gentoo.org/show_bug.cgi?id=191988
an strace of the process (capture started after initial connect
`netstat -p` after connection was the only way I could determine which
apache process to strace):
Process 11348 attached - interrupt to quit
poll([{fd=1027, events=POLLIN, revents=POLLIN}], 1, 30) = 1
read(1027, Host: kokiri.org\r\n, 8000) = 18
poll([{fd=1027, events=POLLIN, revents=POLLIN}], 1, 30) = 1
read(1027, \r\n, 8000)= 2
gettimeofday({1189537767, 899761}, NULL) = 0
gettimeofday({1189537767, 899905}, NULL) = 0
stat64(/www/kokiri.org/htdocs/findwork.php, {st_mode=S_IFREG|0664,
st_size=175, ...}) = 0
open(/www/.htaccess, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
open(/www
Bug #43098 [Fbk-NoF]: file_get_contents() freezes (probably caused by fopen())
Edit report at https://bugs.php.net/bug.php?id=43098edit=1 ID: 43098 Updated by: php-bugs@lists.php.net Reported by: harvie at email dot cz Summary: file_get_contents() freezes (probably caused by fopen()) -Status: Feedback +Status: No Feedback Type: Bug Package: HTTP related Operating System: Linux (Debian Etch) - php5-cli PHP Version: 5.2.4 New Comment: 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. Previous Comments: [2010-11-24 09:19:38] j...@php.net Does it happen with PHP 5.3.3? I still can not reproduce it. [2010-03-02 21:49:13] dyekimov at uniplat dot ru So, has anyone found a way out of this problem? Is it a known bug? [2007-10-26 10:49:02] harvie at email dot cz Yeah! Thats what i need... Something like default_poll_timeout setting... [2007-10-26 10:40:18] harvie at email dot cz j...@php.net: That is what i am saying, this will never comes to next iteration. If i wan't to do some kind of error check, it will never be executed, because whole program will stop at file_get_contents() and will not execute anything after this call. Thats the problem. This function will never return anything. With this timeout, this script have to print '#' at least once a second. But the default_socket_timeout stops waiting for connection but in this case the file_gets_contents() is already downloading when server drops the connection because of network unstability or service overload. Isn't there some kind of timeout, that will stop waiting for broken connection after specified time? [2007-10-26 08:16:58] j...@php.net It won't matter what you put in timeout if you wrap everything in a while(1) loop. Of course it just sits there, try adding some error checking there.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=43098 -- Edit this bug report at https://bugs.php.net/bug.php?id=43098edit=1
Bug #43511 [Fbk-NoF]: unlink() gives No error in... warning
Edit report at https://bugs.php.net/bug.php?id=43511edit=1
ID: 43511
Updated by: php-bugs@lists.php.net
Reported by: marius dot radvan at yahoo dot com
Summary: unlink() gives No error in... warning
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: *General Issues
Operating System: windows
PHP Version: 5.2.5
New Comment:
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.
Previous Comments:
[2011-04-05 23:21:46] sendspampl0x at live dot de
I am not sure if this is what fixed the bug in the end, but I used:
if(is_file($del_path)){
unlink($del_path);
}
Instead of:
unlink($del_path);
I changed a few other things as well, so I am really not sure what fixed it in
the end. I thought I would share though in case it might help.
[2011-02-17 12:01:12] paj...@php.net
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 the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Without any dep, uploaded files or not do not affect the way unlink work. But
temporary files during the processing of uploaded files may cause this error,
but
that's not a bug.
[2011-02-17 11:57:56] gheos at 24 dot fi
I try to rename .lnk files and get this no error bug.
I also get it if I try to copy them..
[2010-09-01 23:46:13] wytsep at hotmail dot com
I got this when I uploaded a file which exceeded the maximum file size which
was defined in HTML like this:
input type=hidden name=MAX_FILE_SIZE value=5
After removing the tag it worked.
(PHP version 5.3.0)
[2010-08-10 22:42:00] calicojack at gmail dot com
Getting this as of PHP Version 5.2.9-2 on Windows Server 2008.
if(ftp_put($connection, $dest, $source,FTP_ASCII)){
echo 'FTP Upload SUCCESS!';
ftp_close($connection);
unlink($source);
}
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=43511
--
Edit this bug report at https://bugs.php.net/bug.php?id=43511edit=1
Req #43224 [Fbk-NoF]: support real graceful reload of fastcgi
Edit report at https://bugs.php.net/bug.php?id=43224edit=1 ID: 43224 Updated by: php-bugs@lists.php.net Reported by: glen at delfi dot ee Summary: support real graceful reload of fastcgi -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: CGI/CLI related Operating System: PLD Linux PHP Version: 5.2.5RC2 Assigned To: dmitry New Comment: 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. Previous Comments: [2011-04-08 15:48:09] dmi...@php.net the listening socket is already set into SO_REUSEADDR mode, so it's not a problem to start new PHP FastCGI process(es) while another is not finished yet. [2008-11-16 16:09:20] glen at delfi dot ee ping? for now the patch only makes php-fcgi to close listening socket on SIGTERM, so if it continues to run, new processes are able to spawn to the same tcp port. http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?rev=1.8 [2008-07-29 09:22:33] glen at delfi dot ee Didn't know about SIGQUIT, but ok, you can keep the signal handlers, but closing listening sockets on SIGTERM does not break process managers, it will do only good. as for original behaviour, if you have some long running request running and you terminate fcgi processes with SIGTERM you can not start new fcgi processes on same tcp port (as the socket is still in use) so to summarize signal handlers would be: SIGTERM, SIGUSR1 - graceful shutdown -- listening sockets are closed, processing continues until scripts finish SIGINT, SIGQUIT (, SIGKILL) - immediate shutdown -- listening sockets are closed, processes are terminated unconditionally whether they are idle or not. [2008-07-29 09:00:33] dmi...@php.net FastCGI PHP SAPI supports only gracefull restart initiated by SIGTERM and SIGUSR1, however you still able to terminate worker processes with sending SIGINT/SIGQUIT to process group. I'm not going to change it as it may break behavior with some FastCGI managers. [2008-06-11 11:18:40] glen at delfi dot ee hi any progress with the patch? i can confirm that it works without problems since i initially created the patch. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=43224 -- Edit this bug report at https://bugs.php.net/bug.php?id=43224edit=1
Req #43948 [Fbk-NoF]: IMAP: Add imap_myrights() function
Edit report at https://bugs.php.net/bug.php?id=43948edit=1 ID: 43948 Updated by: php-bugs@lists.php.net Reported by: diegows at xtech dot com dot ar Summary: IMAP: Add imap_myrights() function -Status: Feedback +Status: No Feedback Type:Feature/Change Request Package: IMAP related PHP Version: trunk Assigned To: pajoye New Comment: 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. Previous Comments: [2010-08-17 16:52:01] p at rdus dot de We tracked the status of the uw imap c-client annotation patch here: https://issues.kolab.org/merge10 I resubmitted the patch three years ago (http://mailman2.u.washington.edu/pipermail/imap-uw/2007-March/001202.html) and it was stalled as Marc Crispin wanted to wait for the ANNOTATEMORE draft to become a real RFC (http://mailman2.u.washington.edu/pipermail/imap-uw/2007-March/001203.html). While this has happened in the meantime (http://mailman.rfc-editor.org/pipermail/rfc-dist/2009-February/002184.html) c-client development seems to have ceased in the meantime, too. For Kolab I'm pretty certain we will switch to the newer Horde_Imap_Client library. I already prepared it with the necessary extensions (https://issues.kolab.org/msg21509). Horde_Imap_Client seems to run faster than the c-client based code though I have to admit that this is just a result from the simple test script and no solid benchmark. As Hored_Imap_Client is not really released yet and would make a bunch of other updates necessary for the Kolab server we'd be quite happy though if annotation support would already work with the imap_* functions available within PHP. I know the situation concerning c-client is messy. Is there anything we can do in order to get the patch accepted? [2010-07-30 13:51:37] mkoppa...@php.net Updated the annotations patch to add HAVE_IMAP_ANNOTATIONS [2010-07-30 13:51:12] mkoppa...@php.net The following patch has been added/updated: Patch Name: imap_annotation.patch Revision: 1280490672 URL: http://bugs.php.net/patch-display.php?bug=43948patch=imap_annotation.patchrevision=1280490672 [2010-07-30 10:28:10] paj...@php.net Right, c-client needs to be patched. It does not sound too good to me but I would like to add some HAVE_ to the c-client patch for cleaner detection. I also dropped a mail to the the uw imap mailing list to ask what's the status of this patch (if has been actually proposed, rejected, etc.). [2010-07-29 20:15:43] mkoppa...@php.net It looks like c-client needs to be patched to support annotations: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/imap/ Can't find annotation support in upstream c-client 2007e. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=43948 -- Edit this bug report at https://bugs.php.net/bug.php?id=43948edit=1
Bug #43977 [Fbk-NoF]: chdir() not working with absolute path / CWD not properly reset
Edit report at https://bugs.php.net/bug.php?id=43977edit=1 ID: 43977 Updated by: php-bugs@lists.php.net Reported by: sysdev at gmx dot net Summary: chdir() not working with absolute path / CWD not properly reset -Status: Feedback +Status: No Feedback Type: Bug Package: IIS related Operating System: Windows Server 2003 PHP Version: 5.2.6 New Comment: 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. Previous Comments: [2010-07-23 19:41:57] paj...@php.net @dscotese at litmocracy dot com Please try using a recent PHP version and provide [2010-07-23 19:40:16] dscotese at litmocracy dot com I am using XAMPP and I just got the No error(errno 0) error on an attempt to change directory to /var/www/a_misspelled_dirname. The error should have been No such file or directory (errno 2). I thought this info might be useful, as I'm not using IIS at all. PHP Version 5.2.5 System Windows NT DAVESTOSHIBA 5.1 build 2600 Build Date Nov 8 2007 23:18:08 Configure Command cscript /nologo configure.js --enable-snapshot-build --with-gd=shared Server API Apache 2.0 Handler Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS Loaded Configuration File C:\xampp\apache\bin\php.ini PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 [2008-10-21 15:32:17] j...@php.net We are aware of PHP's problems with stability under IIS and are working to rectify the problem. Unfortunatly your bug report does not contain any extra useful information and we already have enough bug reports open about this issue. If you can provide more detailed information such as a reproducable crash or a backtrace please do so and reopen this bug. Otherwise please keep trying new releases as we are working to resolve the problems on this platform Thanks for your interest in PHP. [2008-05-26 08:09:49] php5 dot 20 dot cheef-daniel at spamgoumet dot com I checked it with php 5.2.5 and 5.2.6 + IIS + Win 2003 Server SP1. Same error on both versions, I even can't include files because of this. include(config.php) [function.include]: failed to open stream: No such file or directory config.php is in the same directory and has same rights than the calling index.php. getcwd, placed on top of index.php shows me everytime I run this script another dir out of the docroot. chdir(basename(__FILE__)) under/above getcwd fails with error 0 like in this bugreport. [2008-01-29 21:49:37] sysdev at gmx dot net Description: IIS 6 with PHP 5 SAPI: In some cases, the CWD of a PHP-script run is not properly reset to the script's directory. Its instead the directory of another previously run script. chdir() with an absulote path fails in these cases if the desired path is no child of the script's path itself, while chdir() with a relative path to the same destination succeedes. Reproduce code: --- Script located in d:\webshare\web3 echo 'divCWD is '.getcwd().'/div'; chdir( 'd:\\webshare\\web3' ); echo 'divCWD is '.getcwd().'/div'; chdir( 'd:\\webshare\\web3\\test' ); echo 'divCWD is '.getcwd().'/div'; Expected result: Script located in d:\webshare\web3 CWD is 'd:\webshare\web3' CWD is 'd:\webshare\web3' CWD is 'd:\webshare\web3\test' Actual result: -- Script located in d:\webshare\web3 CWD is 'd:\webshare\another\scripts\path' Warning: chdir() [function.chdir]: No such file or directory (errno 2) in D:\webshare\web3\test.php on line 4 CWD is 'd:\webshare\another\scripts\path' CWD is 'd:\webshare\web3\test' -- or sometimes -- Script located in d:\webshare\web3 CWD is 'd:\webshare\another\scripts\path' Warning: chdir() [function.chdir]: No error (errno 0) in D:\webshare\web3\test.php on line 4 CWD is 'd:\webshare\another\scripts\path' CWD is 'd:\webshare\web3\test' -- Edit this bug report at https://bugs.php.net/bug.php?id=43977edit=1
Bug #44454 [Fbk-NoF]: Unexpected exception thrown in foreach() statement
Edit report at https://bugs.php.net/bug.php?id=44454edit=1 ID: 44454 Updated by: php-bugs@lists.php.net Reported by: mfisc...@php.net Summary: Unexpected exception thrown in foreach() statement -Status: Feedback +Status: No Feedback Type: Bug Package: PDO related Operating System: * PHP Version: 5.*, 6CVS (2009-04-25) New Comment: 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. Previous Comments: [2011-01-04 17:22:20] rgagnon24 at gmail dot com Problem still exists in PHP 5.3 snapshot 201101041530 Patch uploaded to account for the changes in mysql_statement.c since the last time I patched PHP 5.2 [2011-01-04 13:37:07] u...@php.net Not a MySQL specific issue thus it should not be assigned to mysql, see my earlier comment: [2008-07-03 14:37 UTC] u...@php.net No comment on the cause just some observations. Issue exists with SQLite as well. [...] [2010-08-18 12:51:53] johan...@php.net Please try a 5.3 snapshot. [2010-06-03 20:58:10] rgagnon24 at gmail dot com I've attached a patch fix-mysql_statement.c-5.2.13.patch to resolve this problem. From: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html When used after mysql_store_result(), mysql_fetch_row() returns NULL when there are no more rows to retrieve. When used after mysql_use_result(), mysql_fetch_row() returns NULL when there are no more rows to retrieve or if an error occurred The patch simply does not raise an exception during a NULL result from mysql_fetch_row() since it only indicates the exhaustion of data. The condition added simply matches the use of either mysql_use_result() or mysql_store_result() called in pdo_mysql_stmt_execute(). When not buffered, mysql_use_result() is called. Therefore, the same check is performed after the fetch before deciding to raise an exception. Also, when un-buffered queries are used, the test script above would be invalid as you cannot perform another operation on a result-set when not all of the results have been retrieved. The patch was created against the released PHP 5.2.3 source code tarball. It's so small, you should be able to modify it easily for any version of the mysql_statement.c file. [2010-06-03 20:36:48] rgagnon24 at gmail dot com From: http://dev.mysql.com/doc/refman/5.0/en/mysql-errno.html Note that some functions like mysql_fetch_row() don't set mysql_errno() if they succeed. And: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html Note that error is not reset between calls to mysql_fetch_row() - Since all the SELECT'd rows are fetched ok, the error from the botched insert is still hanging around for mysql_errno() to find, and raise the exact same exception after the data is finished being iterated. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=44454 -- Edit this bug report at https://bugs.php.net/bug.php?id=44454edit=1
Bug #44383 [Fbk-NoF]: PHP DateTime not converted to xsd:datetime
Edit report at https://bugs.php.net/bug.php?id=44383edit=1 ID: 44383 Updated by: php-bugs@lists.php.net Reported by: kevin dot craft at gmail dot com Summary: PHP DateTime not converted to xsd:datetime -Status: Feedback +Status: No Feedback Type: Bug Package: SOAP related Operating System: * PHP Version: 5.*, 6 (2009-08-07 Assigned To: mj New Comment: 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. Previous Comments: [2013-01-21 18:37:58] thomas dot lallement at 9online dot fr For me, when you call $client-getCurrentDate(), the expected result would be to have a PHP DateTime object rather than a string. So the expected result should be: DateTime Object ( [date] = 2008-03-06 00:00:00 [timezone_type] = x [timezone] = /x ) What do you think about this? At least an option could be provide throught the SoapClient to permit this behavior. [2012-12-24 07:29:52] m...@php.net David, I applied your patch to 5.6.0-dev but all the new tests are failing due to empty responses from SoapServer. Do you have some cycles to look into this? [2012-05-03 10:33:48] andyidol at gmail dot com Please fix this! I beg you ) [2012-01-25 19:44:20] frozenf...@php.net I've encountered this issue today, and it would be really wonderful to have this patch applied. [2010-10-18 17:43:04] aldekein at myevil dot info It still does not work after 2.5 years in PHP 5.3.1 on Windows. Maybe this patch should be applied to official PHP branch? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=44383 -- Edit this bug report at https://bugs.php.net/bug.php?id=44383edit=1
Bug #45107 [Fbk-NoF]: setting ext_dir to ./ (and other ini settings) causes apache crash
Edit report at https://bugs.php.net/bug.php?id=45107edit=1 ID: 45107 Updated by: php-bugs@lists.php.net Reported by: admin at ifyouwantblood dot de Summary: setting ext_dir to ./ (and other ini settings) causes apache crash -Status: Feedback +Status: No Feedback Type: Bug Package: Reproducible crash Operating System: Win XP SP3 PHP Version: 6CVS-2008-05-27 (snap) New Comment: 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. Previous Comments: [2010-12-05 17:56:58] fel...@php.net Please try using this snapshot: http://snaps.php.net/php-trunk-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-05-27 14:13:43] admin at ifyouwantblood dot de Description: PHP6 snapshot: php6.0-win32-200805270630 Apache: 2.2.8 PHP runs as a module (php6apache2_2_filter.dll) my apache crashs directly after starting when i set the following ini-settings (based on php-ini-recommended) to this values: display_errors = On display_startup_errors = On extension_dir = ./ ;this has been the default value extension=non_existant.dll ;only extension if i either unset the extension or deactivate display_errors or display_startup_errors apache runs fine. -- Edit this bug report at https://bugs.php.net/bug.php?id=45107edit=1
Bug #44852 [Fbk-NoF]: PDO_OCI crashes
Edit report at https://bugs.php.net/bug.php?id=44852edit=1 ID: 44852 Updated by: php-bugs@lists.php.net Reported by: der...@php.net Summary: PDO_OCI crashes -Status: Feedback +Status: No Feedback Type: Bug Package: PDO related Operating System: Linux PHP Version: 5.*, 6CVS (2009-04-25) New Comment: 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. Previous Comments: [2013-01-16 04:24:02] s...@php.net See if this is resolved now that https://bugs.php.net/bug.php?id=57702 is fixed. [2009-04-25 15:01:13] j...@php.net See also bug #44589 [2008-04-28 09:14:12] der...@php.net Issue #44589 is the same, but has a bit more information. Keeping both open as they complement each other. (The other one has a test script) [2008-04-28 09:12:12] der...@php.net Description: PDO/OCI segfaults while describing columns. I gave a stab at a quick reproducing script, but did not manage unfortunately. I get this issue by running the WorkflowDatabaseTiein component test suite with: php -dmemory_limit=-1 UnitTest/src/runtests.php -v -D oracle://ezc:wee123@ezctest/ezctest WorkflowDatabaseTiein/tests/execution_test.php Reproduce code: --- Database schema: CREATE TABLE execution ( execution_id number NOT NULL, execution_next_thread_id number NOT NULL, execution_parent number NOT NULL, execution_started number NOT NULL, execution_threads clob, execution_variables clob, execution_waiting_for clob, workflow_id number NOT NULL ) CREATE SEQUENCE execution_execution_id_seq start with 1 increment by 1 nomaxvalue CREATE OR REPLACE TRIGGER execution_execution_id_trg before insert on execution for each row begin select execution_execution_id_seq.nextval into :new.execution_id from dual; end; ALTER TABLE execution ADD CONSTRAINT execution_pkey PRIMARY KEY ( execution_id ) CREATE INDEX execution_parent ON execution ( execution_parent ) CREATE TABLE execution_state ( execution_id number NOT NULL, node_activated_from clob NOT NULL, node_id number NOT NULL, node_state clob, node_thread_id number NOT NULL ) ALTER TABLE execution_state ADD CONSTRAINT execution_state_pkey PRIMARY KEY ( execution_id, node_id ) CREATE TABLE node ( node_class varchar2(255) NOT NULL, node_configuration clob, node_id number NOT NULL, workflow_id number NOT NULL ) CREATE SEQUENCE node_node_id_seq start with 1 increment by 1 nomaxvalue CREATE OR REPLACE TRIGGER node_node_id_trg before insert on node for each row begin select node_node_id_seq.nextval into :new.node_id from dual; end; ALTER TABLE node ADD CONSTRAINT node_pkey PRIMARY KEY ( node_id ) CREATE INDEX workflow_id ON node ( workflow_id ) CREATE TABLE node_connection ( in_node_id number NOT NULL, out_node_id number NOT NULL ) CREATE INDEX in_node_id ON node_connection ( in_node_id ) CREATE TABLE variable_handler ( class varchar2(255) NOT NULL, variable varchar2(255) NOT NULL, workflow_id number NOT NULL ) ALTER TABLE variable_handler ADD CONSTRAINT variable_handler_pkey PRIMARY KEY ( class, workflow_id ) CREATE TABLE workflow ( workflow_created number NOT NULL, workflow_id number NOT NULL, workflow_name varchar2(64) NOT NULL, workflow_version number DEFAULT 1 NOT NULL ) CREATE SEQUENCE workflow_workflow_id_seq start with 1 increment by 1 nomaxvalue CREATE OR REPLACE TRIGGER workflow_workflow_id_trg before insert on workflow for each row begin select workflow_workflow_id_seq.nextval into :new.workflow_id from dual; end; ALTER TABLE workflow ADD CONSTRAINT workflow_pkey PRIMARY KEY ( workflow_id ) CREATE UNIQUE INDEX name_version ON workflow ( workflow_name, workflow_version ) Actual result: -- Segfault: backtrace: #0 0xb7447574 in kghualloc () from /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libclntsh.so.10.1 No symbol table info available. #1 0xb73e865f in kohalc () from /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libclntsh.so.10.1 No symbol table info available. #2 0xb73e7f4f in kohalc () from /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libclntsh.so.10.1 No symbol table info available. #3 0xb73e8902 in kohalw () from /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libclntsh.so.10.1
Bug #45184 [Fbk-NoF]: algorithm to limit random numbers to a certain range is flawed
Edit report at https://bugs.php.net/bug.php?id=45184edit=1 ID: 45184 Updated by: php-bugs@lists.php.net Reported by: kala at sankya dot com Summary: algorithm to limit random numbers to a certain range is flawed -Status: Feedback +Status: No Feedback Type: Bug Package: Math related Operating System: Linux PHP Version: 5.2.6 Assigned To: pajoye New Comment: 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. Previous Comments: [2010-05-21 12:14:13] m...@php.net Should probably be in feedback state. [2008-06-18 16:21:40] paj...@php.net Would you be interested in improving our code? [2008-06-05 11:49:10] kala at sankya dot com Sorry the line int val = (i/divisor)*10; in the example program should be : int val = (i/divisor)*REQUESTED_RANGE; for the program to work correctly for any other range other than 10. [2008-06-05 11:30:09] kala at sankya dot com @pajoye : Yes I'm aware of the limitations of rand() (and LCG generators in general), and have used MT extensively. The problem here isn't with the RNG but with the algorithm used in converting the raw 31 bit random number to one within a given range. This algorithm is common to both the rand() and mt_rand() functions that take min/max arguments (both uses the RANGE_RANDOM macro defined in the file ext/standard/php_rand.h) . The only work around is to use the no argument variant to get a 31 bit number and and do the scaling yourself. (But obviously the better solution would be to fix the code itself :) ) [2008-06-05 10:37:10] paj...@php.net Have you tried to use mt_rand instead? Rand is known for having issues. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=45184 -- Edit this bug report at https://bugs.php.net/bug.php?id=45184edit=1
Bug #45477 [Fbk-NoF]: ldap_mod_del() fails to remove attribute
Edit report at https://bugs.php.net/bug.php?id=45477edit=1 ID: 45477 Updated by: php-bugs@lists.php.net Reported by: alexis dot robert at gmail dot com Summary: ldap_mod_del() fails to remove attribute -Status: Feedback +Status: No Feedback Type: Bug Package: LDAP related Operating System: * PHP Version: 5.2.6 New Comment: 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. Previous Comments: [2010-05-21 12:11:05] m...@php.net What's wrong with http://php.net/ldap_mod_replace ? [2010-04-25 15:58:25] alexis dot robert at gmail dot com Is it solved in the main tree ? Else, can somebody can review my patch and tell me how it is ? I know it's a bit old (and maybe it needs a resync) but I had a lot of work to do this past two years for my classes. Thanks in advance :) Alexis [2008-08-19 11:51:34] alexis dot robert at gmail dot com I've done a patch which fixes the bug. It creates a ldap_mod_deleteadd function which delete an attribute and adding it in the same LDAP request. Some parts of the code is imported from pam_ldap. This bug also appears with MS Active Directory (when you bind without admin rights). The syntax is pretty obvious (but not very clean asap, i wanted to know if you like it before making it as pretty as ldap_mod_replace) : ldap_mod_deleteadd(resource link, string dn, string attr, string old, string new[, boolean binary = false]) The boolean binary attribute is here for AD which uses an unicode encoded password (and so needs LDAP_MOD_BVALUES). Currently waiting for your insults :) Alexis (The patch is at : http://alexis.robertlan.eu.org/tmp/001-ldap_php-add-mod_deleteadd.diff - created by cvs diff) [2008-07-18 11:56:50] alexis dot robert at gmail dot com OK. I've done a *lot* of researchs (trying to make TLS/SSL work, and some other fun things -- I hate certificates) and I discovered by analysing with tcpdump/wireshark that the current Java program make the delete+add orders in the same request, when my PHP software makes it in two different requests. So, NDS refuses to let the users have no userPassword attribute for a short period of time : that is the reason of the Server unwilling to perform. As I don't think we can queue the requests in a FIFO-like stack in php_ldap's API, is it possible to send a LDIF using php_ldap ? That sounds to be a great solution. Thanks a lot Alexis [2008-07-11 15:59:51] alexis dot robert at gmail dot com I don't have any access to the LDAP server. I'll try to request them on Tuesday (if I had them, it would be the first thing I would check). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=45477 -- Edit this bug report at https://bugs.php.net/bug.php?id=45477edit=1
Bug #45813 [Fbk-NoF]: Segfault in error handling
Edit report at https://bugs.php.net/bug.php?id=45813edit=1
ID: 45813
Updated by: php-bugs@lists.php.net
Reported by: hnang...@php.net
Summary: Segfault in error handling
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.*, 6
New Comment:
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.
Previous Comments:
[2010-06-08 15:56:53] tony2...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-08-14 17:59:08] fel...@php.net
Using error_reporting(E_ALL ^ E_NOTICE); the crash/memleak doesnt happen.
[2008-08-14 17:46:41] j...@php.net
Propably just an issue with imap functions since most of the IMAP's
warnings/errors happen during request shutdown. Of course any other similarly
behaving stuff would cause the same..
[2008-08-14 16:21:47] fel...@php.net
It is reproducible also in 5_2. (2 memory leaks)
[2008-08-13 22:18:52] hnang...@php.net
Description:
When error reporting is set to E_ALL, calling ob_start() in an error handler
function causes a segfault when triggered by imap_open().
I don't know if this is an imap only issue, it didn't crash with a couple other
functions I tested.
PHP6 snapshot compiled with --with-imap --with-imap-ssl
Reproduce code:
---
?php
/* segfault on HEAD and memleak on 5_3 */
error_reporting(E_ALL);
set_error_handler('segfault');
function segfault() {
ob_start();
}
imap_open($a,$b,$c);
?
Actual result:
--
Segmentation fault
Backtrace:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6bd76d0 (LWP 32715)]
php_output_handler_create_internal (name=0x0, output_handler=0x8279240
php_output_handler_default_func, chunk_size=0, flags=112) at
/mnt/hd/gsoc/php6/Zend/zend.h:414
414 return ++pz-refcount__gc;
(gdb) bt
#0 php_output_handler_create_internal (name=0x0, output_handler=0x8279240
php_output_handler_default_func, chunk_size=0, flags=112) at
/mnt/hd/gsoc/php6/Zend/zend.h:414
#1 0x0827a2e8 in php_output_start_user (output_handler=0x0, chunk_size=0,
flags=112) at /mnt/hd/gsoc/php6/main/output.c:492
#2 0x0827a379 in zif_ob_start (ht=0, return_value=0x88000e4,
return_value_ptr=0x8835638, this_ptr=0x0, return_value_used=0) at
/mnt/hd/gsoc/php6/main/output.c:1346
#3 0x082edbb7 in zend_do_fcall_common_helper_SPEC (execute_data=0x88355e8) at
/mnt/hd/gsoc/php6/Zend/zend_vm_execute.h:323
#4 0x082ed088 in execute (op_array=0x8833570) at
/mnt/hd/gsoc/php6/Zend/zend_vm_execute.h:104
#5 0x082b400d in zend_call_function (fci=0xbf9a6044, fci_cache=0xbf9a5fcc) at
/mnt/hd/gsoc/php6/Zend/zend_execute_API.c:933
#6 0x082b4dc8 in call_user_function_ex (function_table=0x86ac4c0,
object_pp=0x0, function_name=0x87fff80, retval_ptr_ptr=0xbf9a60c0,
param_count=5, params=0x88000c8,
no_separation=1, symbol_table=0x0) at
/mnt/hd/gsoc/php6/Zend/zend_execute_API.c:729
#7 0x082c4d88 in zend_error (type=8, format=0x8604722 %s) at
/mnt/hd/gsoc/php6/Zend/zend.c:1632
#8 0x08268d33 in php_verror (docref=0x0, params=0x83b9100 , type=8,
format=0x85b8978 %s (errflg=%ld), args=0xbf9a618c hH\203\b\002) at
/mnt/hd/gsoc/php6/main/main.c:818
#9 0x08269233 in php_error_docref0 (docref=0x0, type=8, format=0x85b8978 %s
(errflg=%ld)) at /mnt/hd/gsoc/php6/main/main.c:839
#10 0x080f8c08 in zm_deactivate_imap (type=1, module_number=20) at
/mnt/hd/gsoc/php6/ext/imap/php_imap.c:1117
#11 0x082c5ae2 in module_registry_cleanup (module=0x8708728) at
/mnt/hd/gsoc/php6/Zend/zend_API.c:2487
#12 0x082d1936 in zend_hash_apply (ht=0x86abf40, apply_func=0x82c5ac0
module_registry_cleanup) at /mnt/hd/gsoc/php6/Zend/zend_hash.c:920
#13 0x082c3318 in zend_deactivate_modules () at
/mnt/hd/gsoc/php6/Zend/zend.c:1394
#14 0x08267ba6 in php_request_shutdown (dummy=0x0) at
/mnt/hd/gsoc/php6/main/main.c:1600
#15 0x08359aa4 in main (argc=2, argv=0xbf9a6674) at
/mnt/hd/gsoc/php6/sapi/cli/php_cli.c:1329
--
Edit this bug report at https://bugs.php.net/bug.php?id=45813edit=1
Bug #46025 [Fbk-NoF]: zend_bailout can deadlock APC
Edit report at https://bugs.php.net/bug.php?id=46025edit=1 ID: 46025 Updated by: php-bugs@lists.php.net Reported by: askalski at gmail dot com Summary: zend_bailout can deadlock APC -Status: Feedback +Status: No Feedback Type: Bug Package: Reproducible crash Operating System: redhat PHP Version: 5.2.6 Assigned To: gopalv New Comment: 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. Previous Comments: [2012-07-03 18:09:33] askalski at gmail dot com Recent versions of APC will also require the patch from bug #59281 in conjunction with the PHP-side patch on this ticket. [2012-05-18 14:55:44] zhangjiayin99 at gmail dot com This issue is still reproducable using php-fpm and PHP 5.3.10 with APC 3.1.9 [2011-08-17 21:57:09] pierre at archlinux dot de This issue is still reproducable using php-fpm and PHP 5.3.6 with APC 3.1.9 [2010-11-07 21:08:38] fel...@php.net Gopal, this issue has been already fixed? [2010-06-24 18:52:07] askalski at gmail dot com A note about the above patches: They work with the stable 3.0.19 release of APC, but not the beta 3.1.3p1. In the beta version, compilation was moved inside a HANDLE_BLOCK_INTERRUPTIONS/HANDLE_UNBLOCK_INTERRUPTIONS block, so the zend_bailout deferral is no longer safe. For example, a syntax error in the script will result in a partially compiled opcode array to be cached in APC. I don't yet have an alternate solution. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=46025 -- Edit this bug report at https://bugs.php.net/bug.php?id=46025edit=1
Bug #46353 [Fbk-NoF]: string concatenation leaks memory when using execute
Edit report at https://bugs.php.net/bug.php?id=46353edit=1
ID: 46353
Updated by: php-bugs@lists.php.net
Reported by: anders at freeones dot com
Summary: string concatenation leaks memory when using execute
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Linux 2.6.20-1.2320
PHP Version: 5.2.6
New Comment:
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.
Previous Comments:
[2010-11-02 17:33:20] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-08-18 12:31:07] and...@php.net
not a mysql thing, still no feedback
[2008-11-03 01:00:04] 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.
[2008-10-26 11:12:34] j...@php.net
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 the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2008-10-21 08:15:21] anders at freeones dot com
Description:
I run some code 5 million itteration yesterday, today I change my string
building to use single quotes and the dot operator. That version was able to do
aprox 25k itterations then the script died due memory leak.
Reproduce code:
---
# Makign a string like this leaks NOT memory
# $lInsert = Insert into {$this-mTable}
(datetime,entity_id,entity_type,domain,country,location,raws,uniques) .
# values
('{$this-getDateTime()}',{$this-getEntityId()},{$this-getEntityType()},{$this-getDomain()},
.
#
{$this-getCountry()},{$this-getLocation()},{$this-getRaws()},{$this-getUniques()});;
# Making a string liek this leaks memory when doign execute
$lInsert = 'Insert into '.$this-mTable.'
(datetime,entity_id,entity_type,domain,country,location,raws,uniques)' .
' values
('.$this-getDateTime().','.$this-getEntityId().','.$this-getEntityType().','.$this-getDomain().','
.$this-getCountry().','.$this-getLocation().','.$this-getRaws().','.$this-getUniques().');';
# $lInsert = Insert into {$this-mTable}
(datetime,entity_id,entity_type,domain,country,location,raws,uniques) .
#values
('{$lTimeStamp}',{$lEntityId},{$lEntityType},{$lDomain},{$lCountry},{$lLocation},{$lRaws},{$lUniques});
#
print memory_get_usage().\n;
$lStatement = $this-mDbh-prepare($lInsert);
if (MDB2::isError($lStatement)){
error_log($lStatement-getMessage().';query:'.$lInsert.'
'.$lStatement-userinfo);
$lResult = false;
} else {
$lResult = $lStatement-execute();
$lStatement-free();
}
Expected result:
See code comments
Actual result:
--
see code comments
--
Edit this bug report at https://bugs.php.net/bug.php?id=46353edit=1
Bug #47418 [Fbk-NoF]: number_format misbehaving with some values
Edit report at https://bugs.php.net/bug.php?id=47418edit=1
ID: 47418
Updated by: php-bugs@lists.php.net
Reported by: cu19 at gmx dot de
Summary: number_format misbehaving with some values
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: *Math Functions
Operating System: Win7
PHP Version: 5.3.1
New Comment:
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.
Previous Comments:
[2012-03-28 08:20:22] miguelzubiaga at ipronet dot es
Not a number_format() problem, a simple echo also fails.
?php echo 1.7 ?
expected: 1.7
result: 1.6:
using Apache/2.2.11 (Win32) DAV/2 PHP/5.2.9-2
Restarting apache fixes the problem temporarily
[2011-01-24 21:03:47] paj...@php.net
VC6 builds I suppose?
[2011-01-24 20:47:53] pjs67123 at yahoo dot com
Having the same problem on PHP 5.2.13 and Apache 2.2.14 on Windows 2003 Server.
?php
echo 1.7;
?
produces =
1.6:
This happens after running Apache for about a week and then consistently
happens EVERY time. Restarting Apache fixes the problem until about a week
later. I consider this to be a serious problem that renders PHP useless for
anything beyond casual applications.
[2010-11-30 23:23:13] carrieraglan at gmail dot com
Apache/2.2.11
PHP/5.2.10
$sql = SELECT FIELD_1 FROM DB2_TABLE WHERE ID = ?;
$cur = odbc_prepare($db_handle, $sql);
odbc_execute($cur, array(20382));
$field_1 = odbc_result($cur, FIELD_1);
$field_1 = trim($field_1);
print br.$field_1;
print br.number_format($field_1, 2, '.', '');
print br.number_format($field_1, 2, '.', ',');
Expected Result:
1.90E+001
19.00
19.00
Actual Result:
1.90E+001
18.:0
18.:0
[2010-07-17 05:53:42] adrianv at taly dot net
Code to reproduce this, where lib.php contains the my_number_format function as
described by cu19 at gmx dot de. Numbers are internally correct, but display
incorrectly.
?php
include_once(lib.php);
echo == Demo 1 == BR;
$deb = 10.50;
$crd = 1;
$tot = 0;
for ($t=1;$t=300;$t++) {
$tot += $deb - $crd;
echo $t $tot;
echo ;
echo strval($tot);
echo ;
echo sprintf('%F',$tot);
echo ;
echo number_format($tot,2);
echo ;
echo my_number_format($tot,2);
echo ;
echo BR;
}
?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=47418
--
Edit this bug report at https://bugs.php.net/bug.php?id=47418edit=1
Req #47476 [Fbk-NoF]: Overloading does not work internally
Edit report at https://bugs.php.net/bug.php?id=47476edit=1 ID: 47476 Updated by: php-bugs@lists.php.net Reported by: nullhility at gmail dot com Summary: Overloading does not work internally -Status: Feedback +Status: No Feedback Type:Feature/Change Request Package: Class/Object related PHP Version: 5.2.8 New Comment: 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. Previous Comments: [2011-04-08 20:39:58] j...@php.net Your pastebin stuff isn't available anymore, please put the examples straight into this report. [2009-02-22 19:34:05] nullhility at gmail dot com I re-evaluated the problem itself and found that the magic methods for overloading aren't called automatically from inside the object if the member has been initialized in the class regardless of access. I've made two examples of this internal call to overloading behavior, the first works, the second does not but the average user would expect it to. calls the magic methods directly: http://nullhility.pastebin.com/m5f55a558 expects the magic methods to be called directly: http://nullhility.pastebin.com/m654d81ea [2009-02-22 17:30:33] nullhility at gmail dot com Description: I was attempting to overload some object members when I came to the realization that members defined as unaccessible from inside an object are ones that have not been initialized at all. I was attempting to call a defined but not yet set private member from a method in the class, I expected the __get definition to execute and hopefully do a late member cast but PHP saw it as accessible, this caused a problem because the method was calling a NULL value. The way I see it is that a NULL, aside from still being a value itself, is pretty inaccessible as an actual value. My main concern is that calling an undefined member returns NULL but is also defined as inaccessible, yet calling a defined (but unset/not set) private/protected from within the object, though returning null, is accessible. In the end I know it's about scope and correctness, but is this issue up for change? Reproduce code: --- http://nullhility.pastebin.com/m486cded3 Expected result: Hello World! Hello Universe! Hello Everyone! Actual result: -- Hello World! Hello Everyone! -- Edit this bug report at https://bugs.php.net/bug.php?id=47476edit=1
Bug #47647 [Fbk-NoF]: Array types don't retain xsi:types for polymorphic types
Edit report at https://bugs.php.net/bug.php?id=47647edit=1 ID: 47647 Updated by: php-bugs@lists.php.net Reported by: e dot mortoray at ecircle dot com Summary: Array types don't retain xsi:types for polymorphic types -Status: Feedback +Status: No Feedback Type: Bug Package: SOAP related Operating System: Linux PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2010-06-20 21:32:38] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-03-13 15:33:31] e dot mortoray at ecircle dot com Description: The SOAPClient doesn't appear to handle Arrays containing polymorphic types correctly. In this case (using the Seapine TestTrack API) we have an array of type ArrayOfCField according to the WSDL. And if we obtain a result the XML encoding of this array looks like this: customFieldList xsi:type=SOAP-ENC:Array SOAP-ENC:arrayType=ttns:CField[1]item xsi:type=ttns:CDropdownFieldrecordid363/recordidnameCustomer/namevalueArgos (C1407)/value/item/customFieldList But when using var_dump on the resulting structure we can see that the CDropdownField (which derives from CField) is lost in the stored data. Subsequently that means when submitting the data back the Array does not contain the proper types. The resulting XML is this: customFieldList SOAP-ENC:arrayType=ns1:CField[1] xsi:type=ns1:ArrayOfCFielditem xsi:type=ns1:CFieldrecordid xsi:type=xsd:long363/recordidname xsi:type=xsd:stringCustomer/name/item/customFieldList Note that the first item is simply of type CField rather than CDropdownField. Needless to say this causes the server to reject the request. Related Bugs: 36575 Reproduce code: --- In the TestTrack API this is simply: $defect = $soap-editDefect( $cookie, $number, '', false ); $soap-saveDefect( $cookie, $defect ); Docs for the WSDL/API: http://labs.seapine.com/SDKRequests.php Expected result: The stored data and the returned data should retain the knowledge of the derived types. In this case the item in the array should be marked as a CDropdownField. It should be noted that if the data obtained is manually patched, then the return works. That is, setting the customFieldList such as: 'customFieldList' = array ( new SoapVar( array( 'recordid' = 363, 'name' = 'Customer', 'value' = 'Argos (C1407)', ), XSD_ANYTYPE, 'CDropdownField', 'urn:testtrack-interface' )) -- Edit this bug report at https://bugs.php.net/bug.php?id=47647edit=1
Bug #47948 [Fbk-NoF]: call_user_func_array() with autoload causes crash
Edit report at https://bugs.php.net/bug.php?id=47948edit=1
ID: 47948
Updated by: php-bugs@lists.php.net
Reported by: ehassler at synapsestudios dot com
Summary: call_user_func_array() with autoload causes crash
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Reproducible crash
Operating System: *
PHP Version: 5.2.9
New Comment:
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.
Previous Comments:
[2010-06-22 00:39:33] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-02-12 15:31:34] janssens dot cyril at gmail dot com
Same problem on Debian 5 32bit + php 5.2.6 when using recursive
call_user_func_array function.
The workaround is to use eval statement:
$object = 'foo';
$method = 'bar';
$args = array();//some arguments
$i=0;
$strArg='';
foreach ($args as $arg){
$varname = 'arg'.$i;
$$varname = $arg;
$strArg .= '$'.$varname.',';
$i++;
}
$strArg = substr($strArg,0,-1);
$cmd = '$_return = '.$object.'::'.$method.'('.$strArg.');';
eval($cmd);
//Enjoy :-)
return $_return;
Regards,
Cyril
[2010-01-11 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2010-01-08 16:27:47] muqker at muqker dot com
I didn't know about Edit Submission. However, I did not open this bug,
I just had the same problem and tried to provide a script to
reproduce. Should I use that anyway?
Yes, the crash is there. I am getting:
[Fri Jan 08 17:55:49 2010] [notice] child pid 3534 exit signal
Segmentation fault (11)
in apache2's error log and the browser reports that it receives Error
324 (net::ERR_EMPTY_RESPONSE): Unknown error.
php -n index.php ends with Segmentation Fault.
If I include explicitly the class that otherwise autoload tries to
load, or if I do not use call_user_func_array, but a normal call, then
the crash is gone.
Some system info:
PHP Version 5.2.6-3ubuntu4.2
Apache Version Apache/2.2.11 (Ubuntu) DAV/2 SVN/1.5.4 PHP/5.2.6-
3ubuntu4.2 with Suhosin-Patch
Apache API Version 20051115
Loaded Modules core mod_log_config mod_logio prefork http_core mod_so
mod_alias mod_auth_basic mod_authn_file mod_authz_default
mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex
mod_cgi mod_dav mod_dav_fs mod_dav_svn mod_authz_svn mod_deflate
mod_dir mod_env mod_mime mod_negotiation mod_php5 mod_rewrite
mod_setenvif mod_status
Linux dufus 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC
2009 i686
GNU C Library stable release version 2.9, by Roland McGrath et al.
Let me know if I can provide any other info.
[2010-01-03 20:54:56] johan...@php.net
When editing you have to use the Edit Submission tab to re-open it.
Are you sure the script you provided is correct - it works for me, as far as I
can tell, on 5.2 and 5.3 while there is a warning for a missing parameter:
$ php -n index.php
prearray(7) {
[0]=
array(7) {
[file]=
string(47) /tmp/test47948/muqker/index.php
[line]=
int(41)
[function]=
string(1) f
[class]=
string(1) A
[object]=
object(A)#2 (0) {
}
[type]=
string(2) -
[args]=
array(0) {
}
}
[1]=
array(7) {
[file]=
string(47) /tmp/test47948/muqker/index.php
[line]=
int(45)
[function]=
string(1) g
[class]=
string(1) A
[object]=
object(A)#2 (0) {
}
[type]=
string(2) -
[args]=
array(0) {
}
}
[2]=
array(7) {
[file]=
string(47) /tmp/test47948/muqker/index.php
[line]=
int(15)
[function]=
string(1) h
[class]=
string(1) A
[object]=
object(A)#2 (0) {
}
[type]=
string(2) -
[args]=
array(0) {
}
}
[3]=
array(7) {
[file]=
string(47) /tmp/test47948/muqker/index.php
[line]=
int(19)
[function]=
string(2) zz
[class]=
string(10) Controller
[object]=
object(Controller)#1 (0) {
}
[type]=
string(2) -
[args]=
array(0) {
}
}
[4]=
array(7) {
[file]=
string(47) /tmp/test47948/muqker
Bug #47492 [Fbk-NoF]: SOAP_SINGLE_ELEMENT_ARRAYS has no effect
Edit report at https://bugs.php.net/bug.php?id=47492edit=1
ID: 47492
Updated by: php-bugs@lists.php.net
Reported by: florian dot eberle at gmail dot com
Summary: SOAP_SINGLE_ELEMENT_ARRAYS has no effect
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: SOAP related
Operating System: Debian Lenny
PHP Version: 5.2CVS-2009-02-24 (CVS)
New Comment:
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.
Previous Comments:
[2012-06-13 12:42:55] jboffel at gmail dot com
Hi all,
I think for people without WSDL, you shouldn't expect
SOAP_SINGLE_ELEMENT_ARRAYS to work.
To know it, SoapClient need a XSD saying it could be or not more than one
result to decide it must be in array or not.
Just with SOAP answer it is technically impossible to make a difference between
an anwser that is just 1 element but could have N and an answer that is known
to be only 1.
Exemple :
body
brotherdetailage: 17/brotherdetail
/body
body
brotherdetailage: 17/brotherdetail
brotherdetailsister : 1/brotherdetail
/body
In first case, if you don't have a XSD to say brotherdetail is a type and have
rule maxOccurs = unbounded, how do you expect SoapClient will know it could
have been more than one detail ?
Of course with second example, SoapClient will now it could be because it'll
find more than one so it will naturally make an array...
[2010-11-04 08:08:54] timothee dot groleau at mig33global dot com
Oh duh, I forgot to add some version information:
$ php -version
PHP 5.3.3 (cli) (built: Oct 29 2010 14:24:39)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I'm on Mac OS, php was installed from macports
[2010-11-04 07:55:50] timothee dot groleau at mig33global dot com
Same problem here. xsi:type=ns2:Vector entries are not translated to arrays
if there is only one element inside. Example below:
soap client created like so:
$client = new soapclient(null, array(
'location' = $soap_ejb_service_url,
'uri' = $soap_ejb_service_name,
'features' = SOAP_SINGLE_ELEMENT_ARRAYS | SOAP_USE_XSI_ARRAY_TYPE,
'trace' = true)
);
$response = $client-__soapCall($function, $parameters);
raw soap response:
?xml version='1.0' encoding='UTF-8'?
SOAP-ENV:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
SOAP-ENV:Body
ns1:searchChatroomResponse xmlns:ns1=urn:fusion
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
return xmlns:ns2=http://xml.apache.org/xml-soap; xsi:type=ns2:Map
item
key xsi:type=xsd:stringtotalpages/key
value xsi:type=xsd:double1.0/value
/item
item
key xsi:type=xsd:stringtotalresults/key
value xsi:type=xsd:int1/value
/item
item
key xsi:type=xsd:stringchatrooms/key
value xsi:type=ns2:Vector
item xsi:type=ns2:Map
item
key xsi:type=xsd:stringname/key
value xsi:type=xsd:stringtim_test/value
/item
item
key xsi:type=xsd:stringid/key
value xsi:type=xsd:string6/value
/item
item
key xsi:type=xsd:stringstatus/key
value xsi:type=xsd:stringACTIVE/value
/item
item
key xsi:type=xsd:stringlanguage/key
value xsi:type=xsd:stringENG/value
/item
/item
/value
/item
item
key xsi:type=xsd:stringpage/key
value xsi:type=xsd:int1/value
/item
/return
/ns1:searchChatroomResponse
/SOAP-ENV:Body
/SOAP-ENV:Envelope
$response returned by php client:
array(4) {
[totalpages]=
float(1)
[totalresults]=
int(1)
[chatrooms]=
object(stdClass)#2 (1) {
[item]=
array(16) {
[name]=
string(8) tim_test
[id]=
string(1) 6
[status]=
string(6) ACTIVE
[language]=
string(3) ENG
}
}
[page]=
int(1)
}
[2010-06-20 21:27:41] fel...@php.net
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
Bug #47580 [Fbk-NoF]: MSSQL: Changed database context to when connecting
Edit report at https://bugs.php.net/bug.php?id=47580edit=1 ID: 47580 Updated by: php-bugs@lists.php.net Reported by: maxcamo at gmail dot com Summary: MSSQL: Changed database context to when connecting -Status: Feedback +Status: No Feedback Type: Bug Package: MSSQL related Operating System: Win2003 PHP Version: 5.2CVS-2009-03-05 (snap) New Comment: 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. Previous Comments: [2011-04-30 15:48:58] bguaitanele at gmail dot com I had this problem using php 5.2.6 and php 5.3. This happen with me because the mssql timeout in php configuration. this problem has 2 solutions: The right solution: Refactory your query because your query is taking too long time to respond to php. Case your query is fast, the problem can be the database. In my case was an alter index running and 2 jobs. The fast solution: increase the variable mssql.timeout in php.ini. I increased to 300s and my error stop. But, this is not recommended, because the connections in your application server will increase, More people will be hang the response of the server. Weel, hope this help [2011-02-05 21:20:40] paj...@php.net If you can try it on linux/unix with 5.3, please try it. If not I would suggest to use sqlsrv (http://sqlsrvphp.codeplex.com/) instead on Windows (and php 5.3). [2011-02-05 20:29:14] nkrsaxena at gmail dot com I am facing this problem, making me nuts :-X it shows mssql connection connected mssql selectdb fine but while running query says Changed database context to and script terminated the same is working fine 1. On MSSQL ternimal 2. php5.1.6 i tried different RPMS and manual installation with all dependencies but still no luck, even on Clean servers RHEL5 Please help... [2009-06-13 13:16:11] maxcamo at gmail dot com I've tried but i get the same problem Can be related to mssql time_wait tcp/ip? Thx Massimo [2009-06-02 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=47580 -- Edit this bug report at https://bugs.php.net/bug.php?id=47580edit=1
Bug #47581 [Fbk-NoF]: Calling __construct from an extended SoapClient class via variable broken
Edit report at https://bugs.php.net/bug.php?id=47581edit=1
ID: 47581
Updated by: php-bugs@lists.php.net
Reported by: starson dot hochschild at mtginfo dot com
Summary: Calling __construct from an extended SoapClient class
via variable broken
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: SOAP related
Operating System: Linux RedHat Enterprise V4
PHP Version: 5.2.9
New Comment:
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.
Previous Comments:
[2010-06-20 21:29:22] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-05 22:38:54] starson dot hochschild at mtginfo dot com
public function misSoap
should be
public function __construct
[2009-03-05 22:33:44] starson dot hochschild at mtginfo dot com
Description:
I just upgraded from 5.1.6 to 5.2.9.
Calling __construct from an extended SoapClient class via variable used to work
but this is no longer the case. Somehow it gets picked up by __call now.
Calling __construct from an extended SoapClient class explicitly still works.
Calling SoapClient from an extended SoapClient class via variable still works.
I did not include an example for this, though.
This is definitely not a show-stopper but it would be nice to have consistency.
I haven't noticed this with any other classes, but then again using a variable
to call __construct isn't exactly common.
Reproduce code:
---
?php
class SoapClientExplicit extends SoapClient {
public function misSoap($wsdl, $options = array()) {
parent::__construct($wsdl, $options);
}
}
class SoapClientVariable extends SoapClient {
public function misSoap($wsdl, $options = array()) {
$function = __FUNCTION__;
parent::$function($wsdl, $options);
}
}
echo __LINE__.\n;
$sce = new SoapClientExplicit('http://example.com/ns/func?wsdl');
echo __LINE__.\n;
$scv = new SoapClientVariable('http://example.com/ns/func?wsdl');
echo __LINE__.\n;
?
Expected result:
13
15
17
Actual result:
--
13
15
Fatal error: Uncaught SoapFault exception: [Client] Error finding uri
property in /path/to/script.php:10
Stack trace:
#0 [internal function]: SoapClient-__call('__construct', Array)
#1 /path/to/script.php(10): SoapClient-__construct('http://example...', Array)
#2 /path/to/script.php(16):
SoapClientVariable-__construct('http://example...', Array)
#3 {main}
thrown in /path/to/script.php on line 10
--
Edit this bug report at https://bugs.php.net/bug.php?id=47581edit=1
Bug #47719 [Fbk-NoF]: SOAP-ERROR: Encoding: Violation of encoding rules
Edit report at https://bugs.php.net/bug.php?id=47719edit=1 ID: 47719 Updated by: php-bugs@lists.php.net Reported by: oxomichael at hotmail dot com Summary: SOAP-ERROR: Encoding: Violation of encoding rules -Status: Feedback +Status: No Feedback Type: Bug Package: SOAP related Operating System: Windows PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2011-03-11 18:08:06] benjamin-richard at wanadoo dot fr Hi, did you find a solution to your problem ? i have the same on a PHP 5.3.3 Thanks [2010-06-20 21:32:25] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-03-19 16:04:01] oxomichael at hotmail dot com Description: I get an SOAP Error violation encoding From Windows XP with WAMPSERVER PHP5.2.9-r1 From Ubuntu 8.10 PHP 5.2.6 From Gentoo PHP 5.2.8 (I have the error but i have the return from webservice with LastResponse) Works Fine on Ubunutu 8.0.4 LTS PHP 5.2.4 (Production server) The webservice i request wait for an string compose as xml et send also a string as xml (see code example for what i send) Soap request : ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns1=https://webservices.infogreffe.fr/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;SOAP-ENV:Bodyns1:getProduitsWebServicesXMLparam0 xsi:type=xsd:stringlt;demandegt;lt;emetteurgt;lt;code_abonnegt;85000109lt;/code_abonnegt;lt;mot_passegt;166lt;/mot_passegt;lt;reference_clientgt;G0lt;/reference_clientgt;lt;code_requetegt;lt;type_profilgt;Alt;/type_profilgt;lt;origine_emetteurgt;IClt;/origine_emetteurgt;lt;nature_requetegt;Clt;/nature_requetegt;lt;type_documentgt;AClt;/type_documentgt;lt;type_requetegt;Slt;/type_requetegt;lt;mediagt;WSlt;/mediagt;lt;mode_diffusiongt;lt;mode type=XL/gt;lt;mode type=T/gt;lt;mode type=C/gt;lt;/mode_diffusiongt;lt;/code_requetegt;lt;/emetteurgt;lt;commandegt;lt;num_sirengt;494967938lt;/num_sirengt;lt;/commandegt;lt;/demandegt;/param0/ns1:getProduitsWebServicesXML/SOAP-ENV:Body/SOAP-ENV:Envelope Reproduce code: --- Code give as information because i can't have any debug information from webservice. Code URL : http://oxomichael.serveftp.net/michael/infogreffe.txt Expected result: ?xml version='1.0' encoding='UTF-8'?SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' xmlns:SOAP-ENC='http://schemas.xmlsoap.org/soap/encoding/' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema'SOAP-ENV:Bodyns0:getProduitsWebServicesXMLResponse xmlns:ns0='urn:local' SOAP-ENV:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'return xsi:type='xsd:string'liste_depot_actedepot_actenum_gestgreffe7803/greffedossier_millesime08/dossier_millesimedossier_statutB/dossier_statutdossier_chrono04241/dossier_chrono/num_gestnum_siren494967938/num_sirennum_depot17380/num_depotdate_depot2008-12-03/date_depotactedate_acte2008-11-24/date_actenum_acte01/num_actetype_actePG/type_actetype_acte_libellePROCES VERBAL D'ASSEMBLEE GENERALE ORDINAIRE/type_acte_libellenbpages_acte3/nbpages_actedecisionnatureCHANGEMENT DE COMMISSAIRES AUX COMPTES TITULAIRE ET SUPPLEANT/naturelibelle/libelle/decisionmode_diffusionmode type=C/modemode type=T/mode/mode_diffusion/acte/depot_actedepot_actenum_gestgreffe7501/greffedossier_millesime08/dossier_millesimedossier_statutB/dossier_statutdossier_chrono01601/dossier_chrono/num_gestnum_siren494967938/num_sirennum_depot86746/num_depotdate_depot2008-09-26/date_depotactedate_acte2008-09-25/date_actenum_acte01/num_actetype_acteRA/type_actetype_acte_libelleRAPPORT/type_acte_libellenbpages_acte6/nbpages_actedecisionnature/naturelibelle/libelle/decisionmode_diffusionmode type=T/modemode type=C/mode/mode_diffusion/acte/depot_actedepot_actenum_gestgreffe9401/greffedossier_millesime07/dossier_millesimedossier_statutB/dossier_statutdossier_chrono01328/dossier_chrono/num_gestnum_siren494967938/num_sirennum_depot4476/num_depotdate_depot2007-03-21/date_depotactedate_acte2007-02-19/date_actenum_acte01/num_actetype_acte04/type_actetype_acte_libelleSTATUTS
Bug #48147 [Fbk-NoF]: iconv with //IGNORE cuts the string
Edit report at https://bugs.php.net/bug.php?id=48147edit=1 ID: 48147 Updated by: php-bugs@lists.php.net Reported by: kulakov74 at yandex dot ru Summary: iconv with //IGNORE cuts the string -Status: Feedback +Status: No Feedback Type: Bug Package: ICONV related Operating System: Linux PHP Version: 5.*, 6CVS (2009-05-05) New Comment: 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. Previous Comments: [2012-10-27 09:26:12] ezy...@php.net I submitted an updated bug to glibc, which correctly describes the incorrect behavior in glibc http://sourceware.org/bugzilla/show_bug.cgi?id=13541 The facts of the matter are as follows: 1) glibc has inconsistent behavior about what the EILSEQ error code is supposed to mean, between its documentation and its behavior 2) glibc and libiconv have different behavior 3) A user of PHP who would like to use iconv to convert between two character sets while ignoring malformed characters *cannot do so* with the most recent versions of PHP (5.4+). (Trust me, I've tried.) In old versions of PHP, this functionality was available. Thus, this bug is a regression. If you want to blame upstream, that's fine by me, but I'm not optimistic on glibc getting updated any time in the near future, and there is a well understood (and implemented elsewhere) fix which gives us the correct behavior. [2012-01-08 12:33:12] paj...@php.net To me it looks like there is no bug (as stated in the redhat issues). Also even if there was one, it would not be a PHP bug but iconv's. Or do you have any information that shows that PHP is causing this problem here? [2011-12-23 00:49:31] ezy...@php.net I think I understand how to fix this bug, without modifying glibc. We need to modify our invocation of iconv in order to mirror the behavior of iconv_prog.c:process_block() when the '-c' flag is set (if we mimic the code closely enough, we also get an extra bonus of sensible block processing behavior, which is better than the horrible over-allocation iconv does right now). In particular, we need to handle the EILSEQ error code correctly. [2011-12-18 22:34:38] ezy...@php.net Upstream bugs: http://sources.redhat.com/bugzilla/show_bug.cgi?id=13517 http://sources.redhat.com/bugzilla/show_bug.cgi?id=13518 [2011-12-18 19:37:53] ezy...@php.net Not broken in latest version of libiconv ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n --version iconv (GNU libiconv 1.14) Copyright (C) 2000-2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Bruno Haible. ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n -f utf-8 -t iso-8859-1//IGNORE ~/iconv.html | wc -c 15312 ezyang@javelin:~/Desktop/libiconv-1.14/src$ iconv -f utf-8 -t iso-8859-1//IGNORE ~/iconv.html | wc -c iconv: illegal input sequence at position 8168 8157 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48147 -- Edit this bug report at https://bugs.php.net/bug.php?id=48147edit=1
Bug #49469 [Fbk-NoF]: session.hash_function = sha512 doesnt work
Edit report at https://bugs.php.net/bug.php?id=49469edit=1 ID: 49469 Updated by: php-bugs@lists.php.net Reported by: elfi_47 at gmx dot de Summary: session.hash_function = sha512 doesnt work -Status: Feedback +Status: No Feedback Type: Bug Package: Session related Operating System: openSuse 10.3 PHP Version: 5.3.0 New Comment: 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. Previous Comments: [2010-04-25 21:00:59] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-13 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-09-05 20:07:56] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-04 19:27:59] elfi_47 at gmx dot de Description: php 5.3 ignores session.hash_function = sha512. it sets automatically session.hash_function = 0 in hash_algos() sha512 is available. -- Edit this bug report at https://bugs.php.net/bug.php?id=49469edit=1
Bug #48122 [Fbk-NoF]: odbc_cursor() returns empty name
Edit report at https://bugs.php.net/bug.php?id=48122edit=1
ID: 48122
Updated by: php-bugs@lists.php.net
Reported by: theodoreb at goshen dot edu
Summary: odbc_cursor() returns empty name
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: ODBC related
Operating System: Gentoo Linux
PHP Version: 5.2.9
Assigned To: kalle
New Comment:
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.
Previous Comments:
[2011-08-20 18:05:11] ka...@php.net
Does this apply to 5.3 too?
[2011-05-05 17:37:43] theodoreb at goshen dot edu
patch failed to apply with the following error:
patching file php_odbc.c
Hunk #1 FAILED at 1470.
Hunk #2 succeeded at 1205 (offset -274 lines).
1 out of 2 hunks FAILED -- saving rejects to file php_odbc.c.rej
and from the php_odbc.c.rej file:
***
*** 1470,1477
if (max_len 0) {
cursorname = emalloc(max_len + 1);
rc =
SQLGetCursorName(result-stmt,cursorname,(SQLSMALLINT)max_len,len);
- if (rc != SQL_SUCCESS rc != SQL_SUCCESS_WITH_INFO) {
- charstate[6]; /* Not used */
SQLINTEGER error;/* Not used */
charerrormsg[SQL_MAX_MESSAGE_LENGTH];
SQLSMALLINT errormsgsize; /* Not used */
--- 1470,1477
if (max_len 0) {
cursorname = emalloc(max_len + 1);
rc =
SQLGetCursorName(result-stmt,cursorname,(SQLSMALLINT)max_len,len);
+ if ((rc != SQL_SUCCESS rc != SQL_SUCCESS_WITH_INFO) ||
!cursorname) {
+ charstate[6];
SQLINTEGER error;/* Not used */
charerrormsg[SQL_MAX_MESSAGE_LENGTH];
SQLSMALLINT errormsgsize; /* Not used */
[2011-01-17 16:50:34] ka...@php.net
Could you try the attached patch?
According to the ODBC specification available at MSDN, then its possible for
the SQLGetCursorName function to point to a NULL name where the length and
return codes still are correct, so if thats the case it would fallback to the
PHP cursor name which hopefully is the cause of this as I'm unable to reproduce
it
[2011-01-17 16:48:41] ka...@php.net
The following patch has been added/updated:
Patch Name: odbc-bug-48122
Revision: 1295279320
URL:
http://bugs.php.net/patch-display.php?bug=48122patch=odbc-bug-48122revision=1295279320
[2009-05-06 22:13:31] theodoreb at goshen dot edu
Thanks for responding.
I tried your code as follow:
error_reporting(E_ALL);
$conn = odbc_connect(mssql, login, passwd,SQL_CUR_USE_ODBC);
var_dump($conn, odbc_errormsg($conn));
$query = SELECT * FROM tablename;
$cur = odbc_exec($conn,$query);
var_dump(odbc_errormsg($conn));
echo odbc_cursor($cur);
var_dump(odbc_errormsg($conn));
Here is the result:
resource(16) of type (odbc link) string(0) string(0) string(0)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=48122
--
Edit this bug report at https://bugs.php.net/bug.php?id=48122edit=1
Bug #48318 [Fbk-NoF]: CLI doesn't build and embed SAPI doesn't load on OS X
Edit report at https://bugs.php.net/bug.php?id=48318edit=1 ID: 48318 Updated by: php-bugs@lists.php.net Reported by: valeriy dot zamarayev at gmail dot com Summary: CLI doesn't build and embed SAPI doesn't load on OS X -Status: Feedback +Status: No Feedback Type: Bug Package: Compile Failure Operating System: Mac OSX PHP Version: 5.*, 6CVS (2009-07-09) New Comment: 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. Previous Comments: [2010-06-29 14:13:25] alexk at commandprompt dot com No, the original problem is still there, no matter what version of PHP I test against (current 5.3.2, the snapshot from June 8th or most recent PHP5.3.3RC1). I still can build with --disable-cli passed at configure time, however the result is a bundle instead of a shared library. On Mac OS X there are difference between the two, in particular, it's impossible to link with -lphp5 against a bundle. The error message is: ld: in /usr/local/php5.3RC1//lib/libphp5.so, can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB). For more information, please, see this thread on stackoverflow; http://bit.ly/av8Oie Both PHC (php compiler) and PL/PHP (PHP stored procedures for PostgreSQL) seem to be affected by this on OS X. Is there a reason why embed is built as a bundle ? Can it be changed to the shared library (MH_DYNALIB) instead? [2010-06-08 15:40:58] tony2...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-18 20:05:57] valeriy dot zamarayev at gmail dot com The patch fixes three problems: 1. Missing 'extern's (the only change which will be noticeable on platforms other than Darwin, and looking at the code I think they were just forgotten, most variables have it, but these few ones don't. Just to make sure it doesn't break anything with ELF I tried this on Centos 5.2 - all ok). 2. Some 'special' configuration for darwin, which prevented it from using GNU libtool (no effect on other platforms) 3. 'environ' variable. (no effect on other platforms either, as it only works if crt_externs.h is present - the fix taken from GCC source) Maybe I should have submitted them all separately, so they don't look that awful to you? Anyway the patch is intended to show exact locations of the problems and suggested fixes, for the interested in OS X support in the upcoming 5.3, probably not for an immediate commit. Please treat it as an enhanced problem description. As for 5.2.9, I stumbled across the unresolved #44462 issue, among the others, so I moved to 5.3, and I didn't try to load the .so but basically the environ issue is there anyway, as is the 'special' darwin build case, which breaks linking (looks like it was made long ago to avoid accidentally using the Darwin specific 'libtool' program. [2009-05-18 18:47:37] j...@php.net Does this happen with PHP 5.2.9 ? That patch looks really awful. Something I'd never would want to commit since this all works absolutely fine on every other platform.. [2009-05-18 18:34:42] valeriy dot zamarayev at gmail dot com Description: Attempting to configure and build PHP with ./configure --enable- maintainer-ztc --enable-debug --enable-embed 1) fails to build CLI 2) the resulting libphp.so cannot be loaded in Darwin due to missing 'environ' global variable. Reproduce code: --- Try to build on OS X 10.5.6 using # ./buildconf # ./configure --enable-maintainer-ztc --enable-debug --enable-embed # make Expected result: The CLI binary is built successfully. The libphp5.so library can be loaded using dlopen(). Actual result: -- At the library link stage, multiple symbols are in conflict which have to be declared 'extern' in their '*.h' files. Unlike ELF, with Darwin's Mach-O format, common symbols are not allowed by default. So ELF is forgiving but Mach-O is not with regard to missing 'extern' specifier on global variables. This happens in multiple places in PHP code. At the CLI link stage, an attempt is made to link .o files using CC, though during the compilation libtool is used, so the .o files are hidden in .libs subdirectires, and .lo files should be used. If I correct this and do link successfully, the resulting CLI is fine
Bug #48187 [Fbk-NoF]: DateTime::diff() corrupting microtime() result
Edit report at https://bugs.php.net/bug.php?id=48187edit=1 ID: 48187 Updated by: php-bugs@lists.php.net Reported by: wavetrex at gmail dot com Summary: DateTime::diff() corrupting microtime() result -Status: Feedback +Status: No Feedback Type: Bug Package: Date/time related Operating System: Windows 2003 Server PHP Version: 5.3.0RC2 New Comment: 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. Previous Comments: [2011-01-30 11:26:12] s...@php.net Is it VC6-based build? If yes, could you try a VC9-based build instead? [2010-08-13 20:59:29] alpha_centurion at hotmail dot com Reproduced on Win32 XP SP3 with Apache 2.2.15 and php 5.3.2-Win32-VC6-x86 Only seems to impact web requests as same script (by jani) does not evidence the same error when run on the command line. [2010-08-10 07:01:03] jasonjoo dot god at gmail dot com my test script below: ?php date_default_timezone_set(Asia/Chongqing); echo microtime(true); echo \n; $now=new DateTime(); $now-diff(new DateTime()); echo microtime(true); ? and my os is win32/xp I found this isue can be reproduced under apache in handler mode, but it is no isue in command line mode(eg. php test.php). for example, I got its output like this: 1281415176.9756 1281402595.446 and the wrong one only change the part following dot my php version is 5.3.3 [2010-07-18 00:47:15] k.schroe...@php.net Automatic comment from SVN on behalf of k.schroeder Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301359 Log: Test for #48187 [2009-05-10 01:41:59] wavetrex at gmail dot com float(1241919300.3593) float(1241709350.3736) int(1241919300) int(1241919300) string(25) 2009-05-10T04:35:00+03:00 string(25) 2009-05-10T04:35:00+03:00 ( http://wt.ath.cx/jani.php ) Note: 1241709350 - this value seems to stay almost unchanged over time (look at my first submission: string(21) 0.25882200 1241709345 ) When I reported the difference was ~5 seconds, now it's over 200.000 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48187 -- Edit this bug report at https://bugs.php.net/bug.php?id=48187edit=1
Bug #48478 [Fbk-NoF]: Super-globals cannot be accessed with literal keys
Edit report at https://bugs.php.net/bug.php?id=48478edit=1 ID: 48478 Updated by: php-bugs@lists.php.net Reported by: arancaytar dot ilyaran at gmail dot com Summary: Super-globals cannot be accessed with literal keys -Status: Feedback +Status: No Feedback Type: Bug Package: Arrays related Operating System: Ubuntu 9.04 PHP Version: 6CVS-2009-06-05 (snap) New Comment: 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. Previous Comments: [2010-06-08 15:36:54] tony2...@php.net Please try using this snapshot: http://snaps.php.net/php-trunk-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-06 10:57:49] arancaytar dot ilyaran at gmail dot com Failed to add; this will also work: print $_SERVER[(binary)'SCRIPT_NAME']; That's pretty nasty to have to do consistently though. You could work around it by defining constants for all keys: define(SCRIPT_NAME, (binary)'SCRIPT_NAME'); print $_SERVER[SCRIPT_NAME]; But that's also ugly. It'd be more convenient if the keys were in Unicode by default. [2009-06-05 11:22:04] arancaytar dot ilyaran at gmail dot com Description: In the current snapshot of PHP6, the values stored in the internal $_SERVER and $_ENV super-globals cannot be accessed using literal string keys like $_SERVER['SCRIPT_NAME']. This is because the array keys in these super-globals are of type string, while literals in the script implicitly are of type unicode. This problem does not occur in $_GET, $_POST and $_REQUEST, because the request parameter names are implicitly in unicode too. Reproduce code: --- // This will fail and print a notice: print $_ENV['SHELL'] . \n; // This works: foreach($_ENV as $key = $value) if ($key == 'SHELL') print $_ENV[$key] . \n; // This will work: foreach ($_ENV as $key = $value) $_ENV[$key] = $value; print $_ENV['SHELL'] . \n; Expected result: /bin/bash /bin/bash /bin/bash Actual result: -- Notice: Undefined index: SHELL in - on line 2 /bin/bash /bin/bash -- Edit this bug report at https://bugs.php.net/bug.php?id=48478edit=1
Bug #48258 [Fbk-NoF]: imap_header crash without any response when to: or cc: is very long
Edit report at https://bugs.php.net/bug.php?id=48258edit=1 ID: 48258 Updated by: php-bugs@lists.php.net Reported by: rimgaudas dot laucius at delfi dot lt Summary: imap_header crash without any response when to: or cc: is very long -Status: Feedback +Status: No Feedback Type: Bug Package: IMAP related Operating System: linux-windows PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2010-11-11 21:42:51] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-01 01:50:36] freezehell at hotmail dot com Hi PHP, We are having exactly the same issue with Sugarcrm 4.51 email module which uses PHP Imap function to pull emails. Fedora 9 Apache/2.2.9 (Fedora) PHP 5.2.9 Apache throws a segmentation fault 11 error when IMAP tries to pull an email with long to or CC email address list. Please re-open this BUG. [2009-05-21 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. [2009-05-13 08:09:04] paj...@php.net Please install the debug symbols or compile PHP in debug mode. Which c-client do you use? If it is an old version (2007) please try using 2007e. [2009-05-13 08:01:40] rimgaudas dot laucius at delfi dot lt Description: failure noticed when to: was 14 KB long and another failure noticed when cc: was 34 KB long. here stacktrace (with php 5.2.8, but 5.2.9 crash as well): This GDB was configured as i686-pld-linux...(no debugging symbols found) Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run imaptest.php Starting program: /usr/bin/php imaptest.php (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1215653088 (LWP 26789)] [New Thread -1232208976 (LWP 26792)] [Thread -1232208976 (zombie) exited] test Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1215653088 (LWP 26789)] 0xb7938afc in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7938afc in memcpy () from /lib/tls/libc.so.6 #1 0xb6ed420f in rfc822_skip_comment () from /usr/lib/libc-client.so.2006k #2 0xb6ed4255 in rfc822_skip_comment () from /usr/lib/libc-client.so.2006k #3 0xb6ed4c0b in rfc822_output_address () from /usr/lib/libc-client.so.2006k #4 0xb6ed497d in rfc822_output_address_list () from /usr/lib/libc-client.so.2006k #5 0xb6fac3c2 in zif_imap_mime_header_decode () from /usr/lib/php/imap.so #6 0x0029 in ?? () #7 0x in ?? () (gdb) Quit -- Edit this bug report at https://bugs.php.net/bug.php?id=48258edit=1
Bug #47539 [Fbk-NoF]: MySQL module slow close
Edit report at https://bugs.php.net/bug.php?id=47539edit=1 ID: 47539 Updated by: php-bugs@lists.php.net Reported by: ian at ianhobson dot co dot uk Summary: MySQL module slow close -Status: Feedback +Status: No Feedback Type: Bug Package: MySQL related Operating System: win32 only -Win2K PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2010-08-19 20:56:58] ka...@php.net Does this happen with 5.3.x? And have you tried the VC9 versions from CLI? To see if there is any difference from the VC6 binaries you currently are using. [2009-03-03 11:21:47] ian at ianhobson dot co dot uk It looks as if this bug has been around since 5.2.2 See bugs 41968 and 41350. [2009-03-02 10:46:33] ian at ianhobson dot co dot uk I am fairly sure it is. I recall renaming the MySQL version (libmySQL.dll.save is still in the MySQL directory), and copy/pasting the php version in. All three copies of that file on my machine... a) Do not have any version information in the properties box. b) Are sized exactly 2076672 bytes. c) Are dated when I installed php and mySQl (except one which is dated the date I unpacked php5.2.9) The pathnames are D:\wamp\bin\php\php5.2.8 php 5.2.8 D:\wamp\bin\mysql\mysql5.1.30\binMySQl 5.1.30 D:\test php 5.2.9 libmySQL.dll.save is sized at 2,260,992 bytes [2009-03-02 09:26:54] johan...@php.net Which libmysql.dll is being used? The one which is part of the PHP distribution? [2009-03-01 21:55:16] ian at ianhobson dot co dot uk Description: If php_mysql.dll or php_mysqli.dll are enabled, the CLI takes 5 seconds to close. Reproduce code: --- @echo off time Y D:\wamp\bin\php\php5.2.8\php -r Echo 'Hi'; time Y Where Y is a file containing just a newline. Expected result: The times to be within a fraction of a second. How long should an echo take? Actual result: -- D:\Websites\ppg\testsop\testsphpx The current time is: 21:50:50.39 Enter the new time: HiThe current time is: 21:50:55.44 Enter the new time: D:\Websites\ppg\testsop\tests The times differ by over 5 seconds. Windows, AMD 3500+, with 3GB RAM and fast hard disk. -- Edit this bug report at https://bugs.php.net/bug.php?id=47539edit=1
Bug #48711 [Fbk-NoF]: metaphone() and sch, ch, gh
Edit report at https://bugs.php.net/bug.php?id=48711edit=1 ID: 48711 Updated by: php-bugs@lists.php.net Reported by: brettz9 at yahoo dot com Summary: metaphone() and sch, ch, gh -Status: Feedback +Status: No Feedback Type: Bug Package: Strings related Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: 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. Previous Comments: [2011-05-06 09:03:54] brettz9 at yahoo dot com The traditional flag was based on existing code (though not exposed publicly), presumably to distinguish which metaphone() algorithm was intended: the original BASIC implementation or later versions (see http://aspell.net/metaphone/)/PHP's own innovations. [2011-02-26 20:24:15] jthijssen at noxlogic dot nl Pierre, I've added a phpt testcase inside the patch (bug48711.phpt). Or do you mean a phpt for the extra metaphone parameter (probably a metaphone_variation.phpt)? [2011-02-26 20:18:33] paj...@php.net hi, Thanks for the patch! Can you add a test case for it please? [2011-02-26 19:54:08] jthijssen at noxlogic dot nl I've added a patch with the 4 items as described by brettz9. The first one introduces a traditional boolean flag in metaphone as a third optional parameter. I'm not 100% sure why this parameter is here. Either we should always convert CHR/SCH to X or to K. It makes the function much more complicated this way for end-users. [2009-08-03 01:00:02] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48711 -- Edit this bug report at https://bugs.php.net/bug.php?id=48711edit=1
Bug #48459 [Fbk-NoF]: unixODBC
Edit report at https://bugs.php.net/bug.php?id=48459edit=1 ID: 48459 Updated by: php-bugs@lists.php.net Reported by: bbenbouzid at lear dot com Summary: unixODBC -Status: Feedback +Status: No Feedback Type: Bug Package: ODBC related Operating System: AIX 5.2 PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2010-10-12 01:05:30] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-19 00:23:25] lucianom at gmail dot com I have the same problem. libtool: link: warning: library `/usr/local/mysql5/lib/libmysqlclient_r.la' was moved. libtool: link: warning: library `/usr/local/mysql5/lib/libz.la' was moved. /bin/sh /usr/src/php/php-5.2.9/libtool --silent --preserve-dup-deps -- mode=compile gcc -I/usr/dlc/odbc/include -Iext/odbc/ - I/usr/src/php/php-5.2.9/ext/odbc/ -DPHP_ATOM_INC -I/usr/src/php/php- 5.2.9/include -I/usr/src/php/php-5.2.9/main -I/usr/src/php/php-5.2.9 - I/usr/include/libxml2 -I/usr/src/php/php-5.2.9/ext/date/lib - I/usr/include/c-client -I/usr/src/php/php-5.2.9/ext/mbstring/oniguruma -I/usr/src/php/php-5.2.9/ext/mbstring/libmbfl -I/usr/src/php/php- 5.2.9/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql5/include - I/usr/src/php/php-5.2.9/TSRM -I/usr/src/php/php-5.2.9/Zend - D_REENTRANT -I/usr/include -I/usr/dlc/odbc/include - L/usr/dlc/odbc/lib -lodbc -DZTS -prefer-non-pic -c /usr/src/php/php- 5.2.9/ext/odbc/php_odbc.c -o ext/odbc/php_odbc.lo In file included from /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:37: /usr/src/php/php-5.2.9/ext/odbc/php_odbc_includes.h:226: error: expected specifier-qualifier-list before 'SQLHANDLE' /usr/src/php/php-5.2.9/ext/odbc/php_odbc_includes.h:242: error: expected specifier-qualifier-list before 'SQLHANDLE' /usr/src/php/php-5.2.9/ext/odbc/php_odbc_includes.h:285: error: expected declaration specifiers or '...' before 'SQLHANDLE' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c: In function '_free_odbc_result': /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:172: error: 'odbc_result' has no member named 'values' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:173: error: 'odbc_result' has no member named 'numcols' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:174: error: 'odbc_result' has no member named 'values' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:175: error: 'odbc_result' has no member named 'values' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:177: error: 'odbc_result' has no member named 'values' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:178: error: 'odbc_result' has no member named 'values' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:180: error: 'odbc_result' has no member named 'stmt' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:185: error: 'odbc_result' has no member named 'stmt' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c: In function 'safe_odbc_disconnect': /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:203: warning: passing argument 1 of 'SQLDisconnect' makes integer from pointer without a cast /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:206: warning: passing argument 1 of 'SQLTransact' makes integer from pointer without a cast /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:206: warning: passing argument 2 of 'SQLTransact' makes integer from pointer without a cast /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:207: warning: passing argument 1 of 'SQLDisconnect' makes integer from pointer without a cast /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c: In function '_close_odbc_conn': /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:227: error: 'odbc_result' has no member named 'conn_ptr' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:233: error: 'odbc_connection' has no member named 'hdbc' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:234: error: 'odbc_connection' has no member named 'hdbc' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:235: error: 'odbc_connection' has no member named 'henv' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c: In function '_close_odbc_pconn': /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:255: error: 'odbc_result' has no member named 'conn_ptr' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:261: error: 'odbc_connection' has no member named 'hdbc' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:262: error: 'odbc_connection' has no member named 'hdbc' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c:263: error: 'odbc_connection' has no member named 'henv' /usr/src/php/php-5.2.9/ext/odbc/php_odbc.c: At top level: /usr/src/php/php-5.2.9/ext/odbc
Bug #48634 [Fbk-NoF]: Calling ob_get_flush() inside an output handler causes crashes
Edit report at https://bugs.php.net/bug.php?id=48634edit=1 ID: 48634 Updated by: php-bugs@lists.php.net Reported by: gwy...@php.net Summary: Calling ob_get_flush() inside an output handler causes crashes -Status: Feedback +Status: No Feedback Type: Bug Package: Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version: 5.* (2009-07-25) New Comment: 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. Previous Comments: [2010-09-20 02:17:39] ka...@php.net Wasn't this fixed with the backport of the ob handling API in trunk? [2009-07-21 12:04:22] gwy...@php.net Correction: This does NOT happen in HEAD. [2009-07-18 01:42:45] gwy...@php.net Yes, it happens in all three branches. [2009-07-17 17:40:04] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:34:03] gwy...@php.net Description: The subject kind of says most of it. Under both GDB and Valgrind, PHP enters a massive recursion until it finally crashes by overrunning the stack, which is expected, according to a comment in a test that a fix needs to be backported from HEAD. So this bug is mostly about please backport this fix, I suppose. Reproduce code: --- See tests/output/ob_11.phpt Expected result: A fatal error saying you can't do that. Actual result: -- Endless recursion. -- Edit this bug report at https://bugs.php.net/bug.php?id=48634edit=1
Req #49203 [Fbk-NoF]: call_user_func_array when calling a parent constructor not from a user class
Edit report at https://bugs.php.net/bug.php?id=49203edit=1
ID: 49203
Updated by: php-bugs@lists.php.net
Reported by: magical...@php.net
Summary: call_user_func_array when calling a parent constructor
not from a user class
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package: Scripting Engine problem
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
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.
Previous Comments:
[2011-01-01 22:57:53] magical...@php.net
Rather simple: if a given class's constructor is named with the class name (and
not __construct), and is extended, then from the extending class:
- calling parent::__construct() will work
- calling call_user_func_array(array('parent', '__construct'), array()) won't
The behaviour would usually be assumed to be the same, but it is not.
[2011-01-01 22:47:06] j...@php.net
What is the FR here? Re-type if this is actually a bug. And rewrite the
summary, it isn't very informative. And update PHP version if this is still an
issue.
[2009-08-10 08:29:09] magical...@php.net
Ok, mysqli's contructor is not named __construct
Method [ internal:mysqli, ctor public method mysqli ] {
}
Still, one would expect that calling call_user_func_array(array('parent',
'__construct'), ...) acts the same as parent::__construct(...) (which works). I
guess somewhere the call to __construct must be redirected to the ctor...
[2009-08-10 07:48:18] col...@php.net
The problem is not about internal classes, but classes not defining a
__construct:
class A {
}
class B extends A {
public function __construct() {
echo here\n;
call_user_func(array('parent', '__construct'));
}
}
$x = new B;
seems like is_callable() returns true on array('parent', '__construct') and
shouldn't.
[2009-08-10 03:57:09] magical...@php.net
Description:
When using:
call_user_func_array(array('parent', '__construct'), $var);
This works if the parent is a user-defined class, but not if it's an
extension-provided class (the extended constructor gets called twice).
This is not easy to explain, see attached reproduce code for more details.
My initial code was (in a class extending mysqli):
private function __construct($params) {
call_user_func_array(array('parent', '__construct'), $params);
$this-set_charset('utf8');
}
Using this instead awfully fixes the problem:
parent::__construct($params[0], $params[1], $params[2], $params[3]);
Note that this wasn't possible in PHP 5.2.x
Warning: call_user_func_array(): First argument is expected to be a valid
callback, 'parent::__construct' was given in foo.php on line 5
Reproduce code:
---
?php
class B extends mysqli {
public function __construct($var) {
echo here\n;
call_user_func_array(array('parent', '__construct'), $var);
}
}
$x = new B(array('localhost', 'root'));
Expected result:
here
Actual result:
--
here
here
Warning: call_user_func_array() expects parameter 2 to be array, string given
in foo.php on line 6
--
Edit this bug report at https://bugs.php.net/bug.php?id=49203edit=1
Bug #48942 [Fbk-NoF]: open_basedir no working with [PATH=] in php.ini
Edit report at https://bugs.php.net/bug.php?id=48942edit=1 ID: 48942 Updated by: php-bugs@lists.php.net Reported by: marcos dot neves at gmail dot com Summary: open_basedir no working with [PATH=] in php.ini -Status: Feedback +Status: No Feedback Type: Bug Package: PHP options/info functions Operating System: debian PHP Version: 5.3.0 Assigned To: pajoye New Comment: 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. Previous Comments: [2011-07-23 06:19:08] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-07-17 09:04:07] paj...@php.net It should work in the main php.ini and in some extend in the .user.ini (using the new restricted open_basedir). I will take a look at it while fixing some other .user.ini issues. [2009-07-17 04:17:20] marcos dot neves at gmail dot com playing more, I found that the same bug happens if I configure open_basedir on .user.ini file. It look likes that open_basedir can't be configured in a context way, only in a global way. If thats true, I would be very sad, cause that could be a great feature for hosting companies. [2009-07-16 18:51:23] marcos dot neves at gmail dot com the bug happens using both spawn-fcgi or php-fpm. The php is different for each other. For example, with spawn-fcgi, I am using dotdeb.org php5.3 version, installed using apt-get. With php-fpm, I am using php5.3 Build from source. For webserver, I am using nginx. I both ways, if I change to configuration to this one, every things back to normal: [PATH=/var/www/my.domain.com] open_basedir=/var/www [2009-07-16 13:35:47] j...@php.net And exactly how is everything else configured? Like the path to the script you're accessing? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48942 -- Edit this bug report at https://bugs.php.net/bug.php?id=48942edit=1
Bug #48866 [Fbk-NoF]: ldap.conf TLS_REQCERT directive fails for ldaps
Edit report at https://bugs.php.net/bug.php?id=48866edit=1 ID: 48866 Updated by: php-bugs@lists.php.net Reported by: dev at lechat dot org Summary: ldap.conf TLS_REQCERT directive fails for ldaps -Status: Feedback +Status: No Feedback Type: Bug Package: LDAP related Operating System: win32 only - windows server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: 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. Previous Comments: [2012-01-12 16:47:21] mo at dgi dot no Hello! I'm still experiencing this issue in PHP 5.3.8 on IIS 7, Win 2008 R2. The most peculiar thing is that this issue also arises even though the server has installed the trusted root CA cert which have issued the LDAP-server cert. I also use the LDAP-servers FQDN which matches the cert. It strikes me as almost funny to have to disable cert-cheking on a cert i know is valid. Any one else been experiencing this? [2011-03-28 21:00:38] ocala at udistrital dot edu dot co OS: Windows 7 64 Bit. PHP Version 5.3.0 Apache Version 2.2.11 Blunded Like Wamp Wamp installed in C:\wamp Script running in G:\www\test.php LDAP Configuration file in C:\ldap.conf This settings allows a working ldaps:// connection to a Windows 2008 R2 [2011-03-21 14:26:51] lorenz dot ulrich at phz dot ch In my Windows 7 machine with PHP 5.3.1, TLS_REQCERT never in a file C:\ldap.conf (was C:\openldap\sysconf\ldap.conf for PHP 5.3) works fine for establishing StartTLS LDAP connections using port 389. [2011-01-27 12:10:46] julien dot moisan at agrostar dot fr Same trouble with PHP 5.3.0 with Windows when i move ldap.conf to c:/ that's work fine. [2010-11-10 16:53:06] tegwe002 at umn dot edu Based on other people's comments I did a little testing. Here's what I found out. System: PHP 5.3.3 Win32 vc6 x86 Windows server 2008 R2 Enterprise (no service pack) Apache 2.2.15 We too have our web-root (e) on a different drive than the system root (c). Since this machine is in production, I put one copy of the file in each location. I tried without reboot and had no joy. After reboot I was able to connect to ldap over ssl with no errors. Then I did a little testing to see which file was being used. I tried moving the test script between the c: and e: drives. The file must be in the root of the drive that the script is run from. So if you run scripts from more than one drive you'll need to copy the file to the root of each drive. I hope this helps someone else. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48866 -- Edit this bug report at https://bugs.php.net/bug.php?id=48866edit=1
Bug #49139 [Fbk-NoF]: proc_open requires double quotes
Edit report at https://bugs.php.net/bug.php?id=49139edit=1
ID: 49139
Updated by: php-bugs@lists.php.net
Reported by: david dot gausmann at measx dot com
Summary: proc_open requires double quotes
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
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.
Previous Comments:
[2012-03-13 12:55:54] david dot gausmann at measx dot com
This bug is still present in PHP 5.4.
According to my previous example I've replaced the command line by the php
interpreter and the reference to a script:
$cmd = 'd:\php-5.4.0\php.exe C:\xampp\htdocs\Neuer Ordner\script2.php';
If I execute your script with the command line above I will get the following
output:
-
D:\php-5.4.0php -f C:\xampp\htdocs\testx.php
string(0)
string(0)
string(93) Die Syntax für den Dateinamen, Verzeichnisnamen oder die
Datenträger
bezeichnung ist falsch.
exec:
Lorem ipsum
Array
(
[0] = Lorem ipsum
)
-
If I move the file script2.php to an other location (without any spaces in
it's path) then it works if I remove the double quotes from the parameter.
So the error only occurs if the parameters use double quotes, too.
In your example no parameters were used, so the error doesn't occured.
I've tested this with PHP 5.4 on Windows XP SP3.
[2011-02-09 12:22:15] paj...@php.net
@xandrani at googlemail dot com
'c:\program files\doxygen\bin\doxygen.exe C:\fred\doxyfile'
works fine with proc_open.
For the initial comment and other:
?php
echo PHP_EOL;
error_reporting(E_ALL|E_NOTICE);
$cmd = 'c:\\Program Files (x86)\\wcat\\wcutil.exe';
$des = array
(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w')
);
$resource = proc_open($cmd, $des, $pipes, null, $_ENV);
var_dump(stream_get_contents($pipes[0]));
var_dump(stream_get_contents($pipes[1]));
var_dump(stream_get_contents($pipes[2]));
echo PHP_EOL;
echo exec: . PHP_EOL;
echo exec($cmd, $ret);
echo PHP_EOL;
print_r($ret);
echo PHP_EOL;
gives me:
string(0)
string(441) Usage: wcutil [-s] [-d] [-x] [filename(*)]
-s(imple) Do not display CSV headers or average.
-x(ml) Xml output.
-d(rophighlow) Drop highest and lowest path runs.
Column details:
file - output filename
tps- transactions per second
kcpt - kilocycles per transaction (aka 'path')
bpt- bytes per transaction
cpu- percent CPU utilization
err- count of any errors
string(0)
exec:
Array
(
[0] = Usage: wcutil [-s] [-d] [-x] [filename(*)]
[1] = -s(imple) Do not display CSV headers or average.
[2] = -x(ml) Xml output.
[3] = -d(rophighlow) Drop highest and lowest path runs.
[4] =
[5] = Column details:
[6] = file - output filename
[7] = tps- transactions per second
[8] = kcpt - kilocycles per transaction (aka 'path')
[9] = bpt- bytes per transaction
[10] = cpu- percent CPU utilization
[11] = err- count of any errors
[12] =
)
which is correct.
Using 5.3.5 and 5.3-svn or trunk, on Windows 7/2003/2008.
Please try again and let me know if it still fails, using this exact sample
(can
be other command), or repost an example to reproduce it. I will also need to
know which windows version you use.
[2011-01-26 16:27:21] xc at ez dot no
Can someone speed up the fix? We have issue in our project based on this bug.
I assume second call in the example should work..
Related issue: https://issues.apache.org/jira/browse/ZETACOMP-48
Thanks.
[2010-04-23 08:46:52] David dot Gausmann at measx dot com
This is the same problem as mine:
$Command = 'c:\program files\doxygen\bin\doxygen.exe C:\fred\doxyfile';
$DescriptorSpecification = array
(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w')
);
$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null, $_ENV);
Works fine (because it has the nasty double quotes around everything).
[2010-04-23 02:22:47] xandrani at googlemail dot com
The double backward slashes didn't show correctly... but they are in my code
Bug #48713 [Fbk-NoF]: IMAP extension crashes PHP (internal reference #183257)
Edit report at https://bugs.php.net/bug.php?id=48713edit=1 ID: 48713 Updated by: php-bugs@lists.php.net Reported by: michael dot l at zend dot com Summary: IMAP extension crashes PHP (internal reference #183257) -Status: Feedback +Status: No Feedback Type: Bug Package: IMAP related Operating System: Windows PHP Version: 5.2.10 Assigned To: pajoye New Comment: 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. Previous Comments: [2010-08-28 15:19:06] paj...@php.net IIRC, this code works just fine here. Which version do you exactly? From where did you get it, which SAPI, etc. [2010-08-28 14:55:39] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2010-08-28 14:44:12] avi-phpbugs at dreamingking dot com This bug is still present in 5.2.14 and 5.3.3 (both VC6 and VC9 builds - TS and NTS). It looks like any of the calls in this extension when used with SSL (IMAP, POP, or NNTP) result in a crash on Windows - This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Can someone please help? [2009-07-07 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-06-29 19:59:44] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48713 -- Edit this bug report at https://bugs.php.net/bug.php?id=48713edit=1
Bug #49617 [Fbk-NoF]: Problem with references
Edit report at https://bugs.php.net/bug.php?id=49617edit=1
ID: 49617
Updated by: php-bugs@lists.php.net
Reported by: mstf at mstf dot name dot tr
Summary: Problem with references
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Reproducible crash
Operating System: *
PHP Version: 5.3, 6 (2009-09-22)
New Comment:
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.
Previous Comments:
[2010-05-19 15:46:28] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-22 09:45:00] j...@php.net
# build/php_5_2/sapi/cli/php -n t.php
Fatal error: Cannot create references to/from string offsets nor overloaded
objects in /home/jani/src/t.php on line 8
# build/php_5_3/sapi/cli/php -n t.php
Segmentation fault
# build/php_6/sapi/cli/php -n t.php
Segmentation fault
[2009-09-22 09:30:11] sjo...@php.net
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER (execute_data=0xb68040) at
zend_vm_execute.h:23568
23568 Z_DELREF_PP(EX_T(opline-result.u.var).var.ptr_ptr);
(gdb) bt
#0 0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
#1 0x003ec80e in execute (op_array=0xa109f0) at zend_vm_execute.h:104
#2 0x003bd57a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/Users/sjoerd/Sources/php-src-5.3/Zend/zend.c:1188
#3 0x0034193d in php_execute_script (primary_file=0xb7fc) at
/Users/sjoerd/Sources/php-src-5.3/main/main.c:2213
#4 0x0049650f in main (argc=4, argv=0xb8e8) at
/Users/sjoerd/Sources/php-src-5.3/sapi/cli/php_cli.c:1190
(gdb)
[2009-09-22 01:18:48] mstf at mstf dot name dot tr
Description:
Pointers problem.
Reproduce code:
---
$a = array('a' = array('b' = 'c'));
$b = $a;
$b = $b['a'];
$b = $b['b'];
$b = $b['c'];
echo $b;
Expected result:
NULL
Actual result:
--
Apache Send Error Report
Apache error.log:
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Child process is running
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Acquired the start mutex.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting 150 worker threads.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to listen on
port 80.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to listen on
port 443.
--
Edit this bug report at https://bugs.php.net/bug.php?id=49617edit=1
Bug #49260 [Fbk-NoF]: IPC msg_get_queue fails to retrieve common resource id across scripts
Edit report at https://bugs.php.net/bug.php?id=49260edit=1 ID: 49260 Updated by: php-bugs@lists.php.net Reported by: ivan dot barrios at gmail dot com Summary: IPC msg_get_queue fails to retrieve common resource id across scripts -Status: Feedback +Status: No Feedback Type: Bug Package: Semaphore related Operating System: MacOS v10.5.7 PHP Version: 5.2.10 New Comment: 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. Previous Comments: [2011-11-15 11:52:15] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-14 19:51:16] ivan dot barrios at gmail dot com Description: Identical PHP scripts function on Ubuntu 9.04 Desktop perfectly. Mac OSX configuration: PHP version: 5.2.10 sysvmsg version: $Revision: 1.20.2.3.2.8 $ sysvmsg package installed as an extension (.so file) Ubuntu configuration: PHP version: 5.2.10 sysvmsg version: $Revision: 1.20.2.3.2.7 $ sysvmsg package installed as an extension (.so file) Reproduce code: --- See http://www.phpfreaks.com/forums/index.php/topic,264945.0.html for source code: 2 files (msg_client.php, msg_server.php) Expected result: Code should print following text to PHP error log: queue_id says hello.\n COREPHP\n Actual result: -- Nothing gets printed because the $serverQueue in the Client script (msg_client.php) never gets loaded with the correct queue id for the Server. -- Edit this bug report at https://bugs.php.net/bug.php?id=49260edit=1
Bug #49326 [Fbk-NoF]: output_buffering can break unsecure transparent automatic SID adding
Edit report at https://bugs.php.net/bug.php?id=49326edit=1 ID: 49326 Updated by: php-bugs@lists.php.net Reported by: k dot triendl at m-box dot at Summary: output_buffering can break unsecure transparent automatic SID adding -Status: Feedback +Status: No Feedback Type: Bug Package: Session related Operating System: windows xp sp3 PHP Version: 5.2.10 New Comment: 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. Previous Comments: [2012-03-29 09:25:01] yohg...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-18 14:07:37] k dot triendl at m-box dot at Well, this is no satisfactory answer, I feel. There are situations where cookies can't be used; cookies are bound to a path. If one sets them for the root '/' then the session information is valid for the whole path. No other session can be created without destroying the old one. Users wouldn't be able to login into different databases at the same time or with different user credentials. Also, I don't see so much the security risk with SIDs in URLs as information via our application is read-only to the public and will be changed only in intranets. Additionally, sessions are time-limited. No matter the security risks it should be up to the application to decide whether it matters or not. Cookies have their own flaws. PHP offers the feature to append the SID automatically and therefore I'm urging that this bug gets fixed (php 5.3.x might have the same bug), otherwise the feature should be deprecated. Adding the SID manually is a tedious and error-prone work. [2009-09-16 08:02:00] j...@php.net You should really add the SID manually anyway, using session.use_trans_sid should be avoided always when your site is anything else but some intranet. (might be fixed, propably won't be ever) [2009-09-15 14:41:46] k dot triendl at m-box dot at Reproduce code: --- I've prepared a test case without external requirements: http://www.m-box.at/phpbug_49326/phpbug_49326.php.txt http://www.m-box.at/phpbug_49326/phpbug_49326.html.inc phpbug_49326.php.txt is the php script, remove the .txt extension; phpbug_49326.html.inc is the file included by the php script. Be sure to set 'output_buffering' to 4096 in the php.ini or the .htaccess file. Expected result: correct link to 'Impressum': a href=imprint.m-box?setmgrname=mboxobjamp;fcardid=4amp;reffcardid=3amp;PHPSESSID=bouq4a3sddqfeqp4hrobr4bur0Impressum/a Actual result: -- incorrect link to 'Impressum': a href=imprint.m-box?setmgrname=mboxobjamp;fcardid=4amp;reffcardid=3?PHPSESSID=bouq4a3sddqfeqp4hrobr4bur0Impressum/a [2009-09-04 11:41:36] j...@php.net Please provide a proper test case which does not have any external requirements. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49326 -- Edit this bug report at https://bugs.php.net/bug.php?id=49326edit=1
Bug #49392 [Fbk-NoF]: Many tests try to verify float to integer overflow result
Edit report at https://bugs.php.net/bug.php?id=49392edit=1 ID: 49392 Updated by: php-bugs@lists.php.net Reported by: cndougla at linux dot vnet dot ibm dot com Summary: Many tests try to verify float to integer overflow result -Status: Feedback +Status: No Feedback Type: Bug Package: *General Issues Operating System: * PHP Version: * New Comment: 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. Previous Comments: [2011-01-01 16:00:22] j...@php.net Can you update the list of failing tests with current PHP_5_3 / trunk ? [2009-08-27 18:45:27] cndougla at linux dot vnet dot ibm dot com Description: Many tests have input values like 10.5e10 that must be converted to integer values. On 32-bit systems, the conversion overflows. According to the PHP manual: --- If the float is beyond the boundaries of integer (usually +/- 2.15e+9 = 2^31), the result is undefined, since the float doesn't have enough precision to give an exact integer result. No warning, not even a notice will be issued when this happens! --- Therefore, the tests are attempting to verify undefined values. Reproduce code: --- We found a bunch of testcases with this issue by running in a ppc64 kernel / ppc32 userspace: ext/standard/tests/array/array_fill_variation1.phpt ext/standard/tests/array/array_keys_variation_002.phpt ext/standard/tests/general_functions/gettype_settype_variation2.phpt ext/standard/tests/strings/htmlspecialchars_decode_variation2.phpt ext/standard/tests/strings/pack.phpt ext/standard/tests/strings/sprintf_variation35.phpt ext/standard/tests/strings/sprintf_variation4.phpt ext/standard/tests/strings/sprintf_variation41.phpt ext/standard/tests/strings/strncasecmp_variation5.phpt ext/standard/tests/strings/strncmp_variation5.phpt ext/standard/tests/strings/strrpos_variation14.phpt ext/standard/tests/strings/strrpos_variation15.phpt ext/standard/tests/strings/vsprintf_variation15.phpt ext/standard/tests/strings/vsprintf_variation16.phpt ext/standard/tests/strings/vsprintf_variation4.phpt We also found the following test had issues on ppc64/ppc64: ext/standard/tests/strings/vsprintf_variation15_64bit.phpt Expected result: These tests should not be checking for the value of the direct or indirect overflow of a float to integer conversion. The tests should have the one or two subtests that do this removed. Actual result: -- The tests fail on some platforms, especially split 64/32-bit installations. -- Edit this bug report at https://bugs.php.net/bug.php?id=49392edit=1
Bug #49476 [Fbk-NoF]: $_ENV does not work
Edit report at https://bugs.php.net/bug.php?id=49476edit=1 ID: 49476 Updated by: php-bugs@lists.php.net Reported by: elmu at gmx dot de Summary: $_ENV does not work -Status: Feedback +Status: No Feedback Type: Bug Package: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-05 (snap) New Comment: 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. Previous Comments: [2010-06-08 15:32:22] tony2...@php.net Please try using this snapshot: http://snaps.php.net/php-trunk-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-22 21:19:57] elmue at gmx dot de Hello In version 22 sep 2009 it is even worse: print_r($_FILES); throws: Failed to decode _FILES array The last time I tested on PHP6 this did work. Now its broken. [2009-09-22 21:03:52] elmue at gmx dot de I repeated the test on build from 22 sep 2009 and the result is the same $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty. Even a print_r($_ENV) shows: Array ( ) This cannot be caused by input encoding because these variables have no special characters in them. On PHP5 the same array has plenty content! [2009-09-06 20:31:59] paj...@php.net ENV works just fine here. But there are changes about input encoding that have not been test at all. And all in all, the current status of php6 is not tested at all, unstable and needs heavy work to get to something usable (usable != stable). [2009-09-06 19:48:16] elmu at gmx dot de Note: It seems that the current PHP 6 has not yet been tested on Windows. All the bugs I found are related to filesystem or operation system. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49476 -- Edit this bug report at https://bugs.php.net/bug.php?id=49476edit=1
Bug #49605 [Fbk-NoF]: openssl.c ... discards qualifiers from pointer target type
Edit report at https://bugs.php.net/bug.php?id=49605edit=1 ID: 49605 Updated by: php-bugs@lists.php.net Reported by: terry at mackintoshweb dot com Summary: openssl.c ... discards qualifiers from pointer target type -Status: Feedback +Status: No Feedback Type: Bug Package: Compile Failure Operating System: Linux, 2.4.19 kernel PHP Version: 5.3.0 New Comment: 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. Previous Comments: [2010-05-09 23:18:06] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-28 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. [2009-09-20 10:47:02] paj...@php.net Which gcc and openssl version do you use? And can post a link to the full openssl build log please? There is no error in what you gave here, only warnings. [2009-09-20 04:22:56] terry at mackintoshweb dot com Description: Build fails Reproduce code: --- ./configure --with-snmp --with-pgsql=/usr/local/pgsql --with-gd --enable-calendar --with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --with-openssl --with-gnu-ld --with-jpeg-dir=/usr/local/lib make Actual result: -- /usr/src/php-5.3.0/ext/openssl/openssl.c: In function `zif_openssl_seal': /usr/src/php-5.3.0/ext/openssl/openssl.c:4113: warning: passing arg 2 of `EVP_SealInit' discards qualifiers from pointer target type /usr/src/php-5.3.0/ext/openssl/openssl.c: In function `zif_openssl_open': /usr/src/php-5.3.0/ext/openssl/openssl.c:4203: warning: passing arg 2 of `EVP_OpenInit' discards qualifiers from pointer target type /usr/src/php-5.3.0/ext/openssl/openssl.c: In function `zif_openssl_digest': /usr/src/php-5.3.0/ext/openssl/openssl.c:4529: void value not ignored as it ought to be make: *** [ext/openssl/openssl.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=49605edit=1
Bug #49479 [Fbk-NoF]: move_uploaded_file is dead
Edit report at https://bugs.php.net/bug.php?id=49479edit=1 ID: 49479 Updated by: php-bugs@lists.php.net Reported by: elmue at gmx dot de Summary: move_uploaded_file is dead -Status: Feedback +Status: No Feedback Type: Bug Package: Filesystem function related Operating System: Windows PHP Version: 6SVN-2009-09-06 (snap) New Comment: 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. Previous Comments: [2010-06-08 15:30:42] tony2...@php.net 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. [2009-09-06 01:13:27] elmue at gmx dot de Description: On PHP 6 VC6 from 3.sept.2009 the function move_uploaded_file() is completely dead. Tested on Windows XP with Xampp, Apache 2.2.9 is_file($_FILES[UploadFile][tmp_name]) returns true that means that the files has been uploaded correctly. The array $_FILES is filled with correct values. The destination file for move_uploaded_file() is a valid path with filename but the file is never moved. The same script works fine on PHP 5. -- Edit this bug report at https://bugs.php.net/bug.php?id=49479edit=1
Bug #50475 [Fbk-NoF]: DateTime::setISODate followed by DateTime::setTime
Edit report at https://bugs.php.net/bug.php?id=50475edit=1
ID: 50475
Updated by: php-bugs@lists.php.net
Reported by: nandobrt at gmail dot com
Summary: DateTime::setISODate followed by DateTime::setTime
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Date/time related
Operating System: Windows XP
PHP Version: 5.3SVN-2009-12-15 (snap)
Assigned To: derick
New Comment:
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.
Previous Comments:
[2011-01-24 01:47:34] s...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Seems to work fine on a fresh checkout.
[2010-07-18 01:29:53] k.schroe...@php.net
Automatic comment from SVN on behalf of k.schroeder
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301361
Log: Test for #50475
[2010-03-19 00:55:28] Eric at Deplagne dot name
same with php 5.3.1 on debian squeeze
[2010-01-19 13:05:37] yoarvi at gmail dot com
date_isodate_set should reset the have_relative flag once it has updated the
date/time value.
The following patch (5.3 svn tree) includes a fix and a test case for this bug:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -3033,6 +3033,8 @@
timelib_update_ts(dateobj-time, NULL);
+ dateobj-time-have_relative = 0;
+
RETURN_ZVAL(object, 1, 0);
}
/* }}} */
Index: ext/date/tests/bug50475.phpt
===
--- ext/date/tests/bug50475.phpt(revision 0)
+++ ext/date/tests/bug50475.phpt(revision 0)
@@ -0,0 +1,16 @@
+--TEST--
+Bug #50475 (DateTime::setISODate followed by DateTime::setTime)
+--FILE--
+?php
+date_default_timezone_set('Asia/Calcutta');
+
+$date = new DateTime('18-01-2009 00:00:00');
+$date-setISODate(2009, 6, 1);
+echo $date-format('Y-m-d H:i:s') . \n;
+$date-setTime(8, 0);
+echo $date-format('Y-m-d H:i:s') . \n;
+?
+--EXPECT--
+2009-02-02 00:00:00
+2009-02-02 08:00:00
+
[2009-12-15 03:23:53] nandobrt at gmail dot com
Description:
Calling setTime on a DateTime object after having called setISODate will change
its date.
Reproduce code:
---
$date = new DateTime();
$date-setISODate(2009, 6);
echo $date-format('Y-m-d H:i:s') . br /;
$date-setTime(8, 0);
echo $date-format('Y-m-d H:i:s');
Expected result:
2009-02-02 01:11:15
2009-02-02 08:00:00
Actual result:
--
2009-02-02 01:11:15
2009-03-06 08:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=50475edit=1
Bug #49606 [Fbk-NoF]: empty( $this-variable )
Edit report at https://bugs.php.net/bug.php?id=49606edit=1
ID: 49606
Updated by: php-bugs@lists.php.net
Reported by: clin dot isbut at gmail dot com
Summary: empty( $this-variable )
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Windows Xp
PHP Version: 5.3.0
New Comment:
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.
Previous Comments:
[2010-03-07 18:14:08] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-30 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.
[2009-09-22 10:15:47] j...@php.net
I still can not reproduce this with the class extending mysqli. Please try the
snapshot. (And next time, DO NOT use the Add comment tab when you add
comments to your _own_ report! Use the Edit Submission tab!)
[2009-09-20 18:25:21] clin dot isbut at gmail dot com
Sorry, expected and actual result are as this:
Expected result:
Publish_date: 45678
publish IS NOT EMPTY!
Actual result:
---
Publish_date: 45678
publish IS EMPTY!
[2009-09-20 18:14:32] clin dot isbut at gmail dot com
Ok, I found the root of problems. Seems it fails when the class extends mysqli
class (?¿). See this:
Reproduce code:
---
FooClass.php
class FooClass extends mysqli
{
var $publish_date;
function __construct()
{
}
function foo( $var )
{
$this-publish_date = $var;
echo Publish_date:.$this-publish_date.br;
if( empty( $this-publish_date ) )
echo publish IS EMPTY!br;
else
echo publish IS NOT EMPTY!br;
}
}
Index.php
include (FooClass.php);
$obj = new FooClass();
$obj-foo( '45678' );
Expected result:
Publish_date: 45678
publish IS NOT EMPTY!
Actual result:
---
Publish_date: 45678
publish IS NOT EMPTY!
I expect this time you can reproduce it.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=49606
--
Edit this bug report at https://bugs.php.net/bug.php?id=49606edit=1
Bug #49633 [Fbk-NoF]: $_FILES cannot be accessed
Edit report at https://bugs.php.net/bug.php?id=49633edit=1 ID: 49633 Updated by: php-bugs@lists.php.net Reported by: elmue at gmx dot de Summary: $_FILES cannot be accessed -Status: Feedback +Status: No Feedback Type: Bug Package: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-22 (snap) New Comment: 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. Previous Comments: [2010-06-08 15:32:05] tony2...@php.net 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. [2009-09-22 21:23:17] elmue at gmx dot de Description: In version 22 sep 2009: print_r($_FILES); throws: Failed to decode _FILES array and Could not convert binary string to Unicode string (converter UTF-8 failed on bytes (0xF3) at offset 60) But there is no character F3 in the filename! -- Edit this bug report at https://bugs.php.net/bug.php?id=49633edit=1
Bug #49273 [Fbk-NoF]: setcookie() segfaults the php process when adding a positive expires value
Edit report at https://bugs.php.net/bug.php?id=49273edit=1
ID: 49273
Updated by: php-bugs@lists.php.net
Reported by: moisadoru at gmail dot com
Summary: setcookie() segfaults the php process when adding a
positive expires value
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: HTTP related
Operating System: Ubuntu linux 9.10alpha3 64bit
PHP Version: 6SVN-2009-08-16 (snap)
New Comment:
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.
Previous Comments:
[2011-07-03 04:22:01] geiss...@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-16 18:00:48] moisadoru at gmail dot com
This bug is also present in the latest SVN (r287372)
[2009-08-16 16:58:56] moisadoru at gmail dot com
Description:
When setting a cookie with setcookie(), if the expires parameter is a positive
integer, the PHP child process segfaults.
Environment; Apache 2.2.12, PHP 6.0-200908152030, Ubuntu 9.10 alpha3 linux
kernel 2.6.31 64bit.
Reproduce code:
---
?php
header('Set-Cookie: cookie1=foo1; expires=Sun, 16-Aug-2009 16:39:00 GMT;
secure; HttpOnly', TRUE, 200); // works
setcookie('cookie2', 'foo2',); // works
setcookie('cookie3', 'foo3', -3600); // works
setcookie('cookie4', 'foo4', 3600); // segfaults
echo 'pre';
print_r($_COOKIE);
?
Expected result:
$_COOKIE array dumped to screen
Actual result:
--
Apache error log:
[Sun Aug 16 19:06:38 2009] [notice] child pid 22565 exit signal Segmentation
fault (11)
--
Edit this bug report at https://bugs.php.net/bug.php?id=49273edit=1
Req #49658 [Fbk-NoF]: Default save.session_path and mm_create() warning
Edit report at https://bugs.php.net/bug.php?id=49658edit=1 ID: 49658 Updated by: php-bugs@lists.php.net Reported by: jeff at macloue dot com Summary: Default save.session_path and mm_create() warning -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: Session related Operating System: Slackware 13.0 PHP Version: 5.2.11 New Comment: 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. Previous Comments: [2012-03-31 04:28:48] yohg...@php.net I didn't get warning with 5.3.11-dev. Do you still have issue? [2009-09-24 12:35:08] jeff at macloue dot com Description: php -n throws a warning: PHP Warning: PHP Startup: mm_create(0, /session_mm_cli1000) failed, err mm:core: failed to open semaphore file (Permission denied) in Unknown on line 0 Expected result: This bug was previously submitted as #49401. Despite marked bogus it can be very annoying and also it doesn't seem logical to make the default built-in configuration to throw a warning on most/all the platforms. I also did some investigation on that libmm used by PHP session extension and found that creating the semaphore file is not a must on many platforms but it is kind of recommended and fail-safe way. I don't see any big trouble if libmm's semaphores are created in $TMP or /tmp directory instead of blank - at least it will make PHP _safer_ on many platforms without adding much risks. Of course the best way imho will be to make some ./configure switch for setting default session.save_path value or smth like that. -- Edit this bug report at https://bugs.php.net/bug.php?id=49658edit=1
