from:"askalski at gmail dot com"

[PHP-BUG] Bug #65822 [NEW]: crash on shutdown because of zend extension cleanup order

2013-10-02 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: Linux
PHP version:  5.4.20
Package:  Reproducible crash
Bug Type: Bug
Bug description:crash on shutdown because of zend extension cleanup order

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first,
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions()
zend_shutdown_extensions() functions) that if multiple zend extensions
are loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override
the same Zend structure.  For example, loading both OpCache 7.0.2 and
APC 3.1.13 will cause a segfault on shutdown because of improper cleanup
order of orig_interned_strings_start, old_interned_strings_start, and
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules
and extensions here; I'm reporting the bug because it points at an issue
in PHP itself.  The specific use case for loading both APC and OpCache
is to use OpCache for opcodes and APC with apc.cache_by_default=0 for
the apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache "prefork" mode.  Send
SIGTERM to one of the workers (or simply send enough requests to make
Apache reap the worker), and watch for the Segmentation fault in
Apache's error_log.


Expected result:

No crash.

Actual result:
--
Segmentation fault.

-- 
Edit bug report at https://bugs.php.net/bug.php?id=65822&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65822&r=trysnapshot54
Try a snapshot (PHP 5.5):   
https://bugs.php.net/fix.php?id=65822&r=trysnapshot55
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65822&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65822&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65822&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65822&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65822&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65822&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65822&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65822&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65822&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65822&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65822&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65822&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65822&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65822&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65822&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65822&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65822&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65822&r=mysqlcfg

Bug #65822 [Com]: crash on shutdown because of zend extension cleanup order

2013-10-03 Thread askalski at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=65822&edit=1

 ID: 65822
 Comment by: askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:crash on shutdown because of zend extension cleanup
 order
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

Spent some time digging into this.  It's not as simple as calling 
zend_shutdown_extensions before zend_destroy_modules; there are a few issues at 
play which complicate matters.

The two Zend Extensions I investigated (OpCache and XDebug) implement both the 
zend_extension and zend_module API.  Both of these extensions load the 
zend_module portion by calling zend_startup_module in the zend_extension 
startup function.  Also, it is possible to load modules at runtime using the 
dl() userland function.

Consequently, the shutdown order is not a simple matter of "extensions first, 
then modules".  Because startup order of extensions and modules can be 
interleaved, this precise order must be recorded during initialization.  The 
implementation might be something as simple as a stack of enumerated values: { 
MODULE, MODULE, MODULE, MODULE, EXTENSION, MODULE, EXTENSION, MODULE }


Previous Comments:

[2013-10-02 22:09:12] askalski at gmail dot com

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first, 
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions() 
zend_shutdown_extensions() functions) that if multiple zend extensions are 
loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override the 
same Zend structure.  For example, loading both OpCache 7.0.2 and APC 3.1.13 
will cause a segfault on shutdown because of improper cleanup order of 
orig_interned_strings_start, old_interned_strings_start, and 
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules and 
extensions here; I'm reporting the bug because it points at an issue in PHP 
itself.  The specific use case for loading both APC and OpCache is to use 
OpCache for opcodes and APC with apc.cache_by_default=0 for the 
apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache "prefork" mode.  Send SIGTERM to 
one of the workers (or simply send enough requests to make Apache reap the 
worker), and watch for the Segmentation fault in Apache's error_log.


Expected result:

No crash.

Actual result:
--
Segmentation fault.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65822&edit=1

Bug #65822 [Com]: crash on shutdown because of zend extension cleanup order

2013-10-07 Thread askalski at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=65822&edit=1

 ID: 65822
 Comment by: askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:crash on shutdown because of zend extension cleanup
 order
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

Turns out it's not so simple.  It never is...

Modules need to be shutdown before the global function/class tables are 
destroyed.  Extensions need to be shutdown after.  Consequently there is no 
valid way to interleave extension and module shutdown.

Because this issue likely stems from APC meddling with PHP internals in a 
manner in which modules were never intended to meddle, I see no real reason to 
act upon this ticket... with one exception:

One thing that still ought to be fixed is zend_shutdown_extensions() should 
apply zend_extension_shutdown over the zend_extensions list in *reverse* order, 
not forward order.  (This would involve adding a zend_llist_reverse_apply_* 
family of functions to zend_llist.c)


Previous Comments:

[2013-10-03 16:00:22] askalski at gmail dot com

Spent some time digging into this.  It's not as simple as calling 
zend_shutdown_extensions before zend_destroy_modules; there are a few issues at 
play which complicate matters.

The two Zend Extensions I investigated (OpCache and XDebug) implement both the 
zend_extension and zend_module API.  Both of these extensions load the 
zend_module portion by calling zend_startup_module in the zend_extension 
startup function.  Also, it is possible to load modules at runtime using the 
dl() userland function.

Consequently, the shutdown order is not a simple matter of "extensions first, 
then modules".  Because startup order of extensions and modules can be 
interleaved, this precise order must be recorded during initialization.  The 
implementation might be something as simple as a stack of enumerated values: { 
MODULE, MODULE, MODULE, MODULE, EXTENSION, MODULE, EXTENSION, MODULE }

----
[2013-10-02 22:09:12] askalski at gmail dot com

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first, 
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions() 
zend_shutdown_extensions() functions) that if multiple zend extensions are 
loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override the 
same Zend structure.  For example, loading both OpCache 7.0.2 and APC 3.1.13 
will cause a segfault on shutdown because of improper cleanup order of 
orig_interned_strings_start, old_interned_strings_start, and 
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules and 
extensions here; I'm reporting the bug because it points at an issue in PHP 
itself.  The specific use case for loading both APC and OpCache is to use 
OpCache for opcodes and APC with apc.cache_by_default=0 for the 
apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache "prefork" mode.  Send SIGTERM to 
one of the workers (or simply send enough requests to make Apache reap the 
worker), and watch for the Segmentation fault in Apache's error_log.


Expected result:

No crash.

Actual result:
--
Segmentation fault.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65822&edit=1

Bug #65822 [Csd]: crash on shutdown because of zend extension cleanup order

2013-10-08 Thread askalski at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=65822&edit=1

 ID: 65822
 User updated by:askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:crash on shutdown because of zend extension cleanup
 order
 Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.20
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Thanks; wasn't aware this had been fixed on APC trunk.  Just noticed now that 
APC has been moved from subversion to git - this made my day.

Unaware of the already-committed fixes, I had started on a parallel development 
path of configuration to disable opcode caching and interned strings.  One 
thing I did in my version of the patch which you might consider:

In PHP_MINIT_FUNCTION(apc), I have it call zend_get_extension("Zend OPcache") 
to see if opcache is loaded, and if so, force-disable opcode caching and 
interned strings.

It's a minor convenience, but could help to avoid questions in the future.


Previous Comments:

[2013-10-08 11:20:31] larue...@php.net

actually, this is a knew issue.

and already be fixed both in opcache: 
https://github.com/php/php-src/commit/0aa342e903bf012efe03db1e9f1fe4ed54225e76

and apc: http://svn.php.net/viewvc?view=revision&revision=330859

please try with the latest snapshot

----
[2013-10-07 18:30:24] askalski at gmail dot com

Turns out it's not so simple.  It never is...

Modules need to be shutdown before the global function/class tables are 
destroyed.  Extensions need to be shutdown after.  Consequently there is no 
valid way to interleave extension and module shutdown.

Because this issue likely stems from APC meddling with PHP internals in a 
manner in which modules were never intended to meddle, I see no real reason to 
act upon this ticket... with one exception:

One thing that still ought to be fixed is zend_shutdown_extensions() should 
apply zend_extension_shutdown over the zend_extensions list in *reverse* order, 
not forward order.  (This would involve adding a zend_llist_reverse_apply_* 
family of functions to zend_llist.c)

----
[2013-10-03 16:00:22] askalski at gmail dot com

Spent some time digging into this.  It's not as simple as calling 
zend_shutdown_extensions before zend_destroy_modules; there are a few issues at 
play which complicate matters.

The two Zend Extensions I investigated (OpCache and XDebug) implement both the 
zend_extension and zend_module API.  Both of these extensions load the 
zend_module portion by calling zend_startup_module in the zend_extension 
startup function.  Also, it is possible to load modules at runtime using the 
dl() userland function.

Consequently, the shutdown order is not a simple matter of "extensions first, 
then modules".  Because startup order of extensions and modules can be 
interleaved, this precise order must be recorded during initialization.  The 
implementation might be something as simple as a stack of enumerated values: { 
MODULE, MODULE, MODULE, MODULE, EXTENSION, MODULE, EXTENSION, MODULE }

----------------
[2013-10-02 22:09:12] askalski at gmail dot com

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first, 
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions() 
zend_shutdown_extensions() functions) that if multiple zend extensions are 
loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override the 
same Zend structure.  For example, loading both OpCache 7.0.2 and APC 3.1.13 
will cause a segfault on shutdown because of improper cleanup order of 
orig_interned_strings_start, old_interned_strings_start, and 
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules and 
extensions here; I'm reporting the bug because it points at an issue in PHP 
itself.  The specific use case for loading both APC and OpCache is to use 
OpCache for opcodes and APC with apc.cache_by_default=0 for the 
apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache "prefork" mode.  Send SIGTERM to 
one of the workers (or simply send enough requests to make Apache reap the

Bug #46025 [Com]: zend_bailout can deadlock APC

2013-03-13 Thread askalski at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=46025&edit=1

 ID: 46025
 Comment by: askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:zend_bailout can deadlock APC
 Status: No Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   redhat
 PHP Version:5.2.6
 Assigned To:gopalv
 Block user comment: N
 Private report: N

 New Comment:

I haven't tested against PHP 5.4 yet; I wonder if some of the lack of attention 
can be attributed to the planned bundling of Zend Optimizer+ with 5.5.  The 
patch works (at least on the versions I've tested), but one drawback of the 
patch as written is that it breaks API compatibility.  Modules need to be 
rebuilt against the updated Zend/zend.h header file to honor the new 
HANDLE_BLOCK_INTERRUPTIONS behavior.


Previous Comments:

[2013-03-14 02:13:21] hardos at gmail dot com

Any updates on this bug?. We faced a similar issue in production with php 
5.3.10 
and different versions of APC (3.0.19 and 3.1.9). We could take in and try out 
the 
patches provided, but a  review of the patches / feedback to the bug would be 
great. Any reason they haven't been taken in ?


[2013-02-18 00:33:55] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

----
[2012-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




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=46025&edit=1

[PHP-BUG] Bug #64467 [NEW]: Segmentation fault after imap_reopen failure

2013-03-20 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: Ubuntu 12.04 LTS
PHP version:  master-Git-2013-03-20 (Git)
Package:  IMAP related
Bug Type: Bug
Bug description:Segmentation fault after imap_reopen failure

Description:

Versions: 5.2, 5.3, 5.4, also confirmed on latest git master
(78acb84b6e8fc07974283ce30c24596444d18cf7)

PHP will crash with a Segmentation Fault after imap_reopen() fails with the
error message "imap_reopen(): Couldn't re-open stream ..."

When the UW-IMAP function 'mail_open' returns NIL after having been passed
a valid MAILSTREAM pointer, this means UW-IMAP closed and freed the
MAILSTREAM.  However, PHP ignores this and returns FALSE without zeroing
out imap_le_struct->imap_stream and calling zend_list_delete on the
resource.

Because the resource was not freed, mail_close_it (the resource destructor)
gets called on an invalid pointer during request shutdown.  If you're
lucky, this crashes PHP with a Segmentation Fault.  (If you're unlucky,
you've got a corrupt PHP interpreter handling new requests...)


Test script:
---



Expected result:

No crash.

Actual result:
--
$ /tmp/z/bin/php -v
PHP 5.6.0-dev (cli) (built: Mar 20 2013 12:13:31) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.6.0-dev, Copyright (c) 1998-2013 Zend Technologies


$ /tmp/z/bin/php imap-crash.php 
imap_open returned: resource(4) of type (imap)

Warning: imap_reopen(): Couldn't re-open stream in /tmp/imap-crash.php on
line 10
imap_reopen returned: bool(false)
Segmentation fault (core dumped)


-- 
Edit bug report at https://bugs.php.net/bug.php?id=64467&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=64467&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=64467&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=64467&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=64467&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=64467&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64467&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=64467&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=64467&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64467&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=64467&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64467&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64467&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=64467&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64467&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=64467&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=64467&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64467&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64467&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64467&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=64467&r=mysqlcfg

Bug #46025 [Com]: zend_bailout can deadlock APC

2012-07-03 Thread askalski at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=46025&edit=1

 ID: 46025
 Comment by: askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:zend_bailout can deadlock APC
 Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   redhat
 PHP Version:5.2.6
 Assigned To:gopalv
 Block user comment: N
 Private report: N

 New Comment:

Recent versions of APC will also require the patch from bug #59281 in 
conjunction with the PHP-side patch on this ticket.


Previous Comments:

[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.


[2010-05-31 06:54:14] askalski at gmail dot com

I uploaded patches against the latest 5.1, 5.2, and 5.3 versions of PHP, for 
sites with production issues that can't afford to wait years for an upstream 
fix.




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=46025&edit=1

#46025 [Sus]: zend_bailout can deadlock APC

2009-10-21 Thread askalski at gmail dot com

 ID:   46025
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
 Status:   Suspended
 Bug Type: Reproducible crash
 Operating System: redhat
 PHP Version:  5.2.6
 New Comment:

We are using a modified 5.2 in production, so a patch against 5.2.11
(the latest release in that series) would be good.

Thanks,

Andy


Previous Comments:


[2009-10-21 18:01:00] sh...@php.net

Lucas Nealan and I are working on fixing some items in the signals
patch, and would like to push forward on this getting integrated in
core.  Would you be willing to try the patch for PHP to see if it
corrects your problem?  It would be of great use to know that it fixes
your specific issue.  If so let me know which specific version of PHP
you want a patch against and I'll make sure we get you the latest one
that cleanly patches against it.



[2009-02-27 20:09:27] pierre at archlinux dot de

This problem is still reproducable with version 5.2.9. The cgi version
is affected, too (as expected).



[2009-02-15 00:01:20] dan at archlinux dot org

Any progress here? This is definitely reproducible and we have seen it
on archlinux.org about once every 3 or 4 days- it kind of stinks. Is
there any current workaround besides increasing the timeout value and
hoping for the best?

Running:
Apache 2.2.11
PHP 5.2.8
APC 3.0.19



[2008-09-09 00:46:09] scott...@php.net

This is essentially what http://wiki.php.net/rfc/zendsignals is for, it
was considered for PHP 5.3 but has been deferred for the moment.



[2008-09-08 23:56:04] askalski at gmail dot com

Reproduced with latest checkouts from both the PHP_5_2 and PHP_5_3
tags.

X-Powered-By: PHP/5.2.7-dev
X-Powered-By: PHP/5.3.0alpha3-dev



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46025

-- 
Edit this bug report at http://bugs.php.net/?id=46025&edit=1

#43466 [NEW]: mcrypt_generic_init requires IV in ECB mode

2007-11-30 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: Ubuntu
PHP version:  5.2.5
PHP Bug Type: mcrypt related
Bug description:  mcrypt_generic_init requires IV in ECB mode

Description:

mcrypt_generic_init() issues a PHP warning when an empty IV is supplied
(good), even in ECB mode (not so good).

>From the PHP documentation: "IV is ignored in ECB."

Since the IV is ignored in ECB mode, PHP should not issue any IV-related
warnings.

(Also tested php5.2-200711302330)


Reproduce code:
---



Expected result:

I expect the code to run without any warnings.


Actual result:
--
Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 0,
needed: 8 in /tmp/php-5.2.5/ecb-test.php on line 3


-- 
Edit bug report at http://bugs.php.net/?id=43466&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=43466&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=43466&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=43466&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=43466&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43466&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=43466&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=43466&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43466&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43466&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=43466&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43466&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=43466&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=43466&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43466&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=43466&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43466&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43466&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=43466&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=43466&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=43466&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43466&r=mysqlcfg

#46025 [NEW]: zend_bailout can deadlock APC

2008-09-08 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: redhat
PHP version:  5.2.6
PHP Bug Type: Reproducible crash
Bug description:  zend_bailout can deadlock APC

Description:

A zend_bailout (longjmp) is allowed while HANDLE_BLOCK_INTERRUPTIONS is in
effect.  When this happens while APC has its shared memory segment locked,
it results in corruption of the segment and deadlocking of the mutex.  An
Apache restart is required to get things moving again.

Tested with PHP 5.2.6 and 4.4.8 with APC 3.0.19 using pthread mutexes.

In our particular case, this is happening when a script hits the
max_execution_time timeout during an include().

Although APC is involved, I am submitting this as a PHP bug because the
fix (zend_bailout / HANDLE_BLOCK_INTERRUPTIONS) is completely PHP-side.


Reproduce code:
---



Expected result:

Defer the zend_bailout until HANDLE_UNBLOCK_INTERRUPTIONS is called.


Actual result:
--
Deadlock of the entire web server, requiring an Apache restart.


-- 
Edit bug report at http://bugs.php.net/?id=46025&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=46025&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=46025&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=46025&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46025&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=46025&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=46025&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46025&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46025&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=46025&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46025&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=46025&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=46025&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46025&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=46025&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46025&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46025&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=46025&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=46025&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=46025&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46025&r=mysqlcfg

#46025 [Opn]: zend_bailout can deadlock APC

2008-09-08 Thread askalski at gmail dot com

 ID:   46025
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: redhat
 PHP Version:  5.2.6
 New Comment:

To assist with implementing a fix:

I wrote up a local fix that uses two executor globals:

/* HANDLE_BLOCK_INTERRUPTIONS nesting depth */
zend_uint blocking_interruptions;
/* true if a bailout was deferred while interruptions were blocked
*/
zend_bool deferred_bailout;

In my testing, I quickly realized that APC in conjunction with Zend was
making nested calls to HANDLE_BLOCK_INTERRUPTIONS(), so to keep from
unblocking prematurely, it was necessary to track nesting depth.

Example from my debugging:

Block 0 /tmp/APC-3.0.19/php_apc.c:559
Block 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1876
Unblock 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1913
Unblock 0 /tmp/APC-3.0.19/php_apc.c:592

My updated macros:

#define HANDLE_BLOCK_INTERRUPTIONS()if
(!EG(blocking_interruptions)++) { if (zend_block_interruptions) {
zend_block_interruptions(); } }
#define HANDLE_UNBLOCK_INTERRUPTIONS()  if
(EG(blocking_interruptions) && !--EG(blocking_interruptions)) { if
(zend_unblock_interruptions) { zend_unblock_interruptions(); } if
(EG(deferred_bailout)) { zend_bailout(); } }

And my mod to _zend_bailout:

if (EG(blocking_interruptions))
{
EG(deferred_bailout) = 1;
return;
}
EG(deferred_bailout) = 0;


Previous Comments:


[2008-09-08 15:23:59] askalski at gmail dot com

Description:

A zend_bailout (longjmp) is allowed while HANDLE_BLOCK_INTERRUPTIONS is
in effect.  When this happens while APC has its shared memory segment
locked, it results in corruption of the segment and deadlocking of the
mutex.  An Apache restart is required to get things moving again.

Tested with PHP 5.2.6 and 4.4.8 with APC 3.0.19 using pthread mutexes.

In our particular case, this is happening when a script hits the
max_execution_time timeout during an include().

Although APC is involved, I am submitting this as a PHP bug because the
fix (zend_bailout / HANDLE_BLOCK_INTERRUPTIONS) is completely PHP-side.


Reproduce code:
---



Expected result:

Defer the zend_bailout until HANDLE_UNBLOCK_INTERRUPTIONS is called.


Actual result:
--
Deadlock of the entire web server, requiring an Apache restart.






-- 
Edit this bug report at http://bugs.php.net/?id=46025&edit=1

#46025 [Fbk->Opn]: zend_bailout can deadlock APC

2008-09-08 Thread askalski at gmail dot com

 ID:   46025
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: redhat
 PHP Version:  5.2.6
 New Comment:

Reproduced with latest checkouts from both the PHP_5_2 and PHP_5_3
tags.

X-Powered-By: PHP/5.2.7-dev
X-Powered-By: PHP/5.3.0alpha3-dev


Previous Comments:


[2008-09-08 21:16:43] [EMAIL PROTECTED]

Can you reproduce this with latest CVS checkout of PHP_5_2 (and 
preferrably PHP_5_3) ??



[2008-09-08 20:50:12] askalski at gmail dot com

To assist with implementing a fix:

I wrote up a local fix that uses two executor globals:

/* HANDLE_BLOCK_INTERRUPTIONS nesting depth */
zend_uint blocking_interruptions;
/* true if a bailout was deferred while interruptions were blocked
*/
zend_bool deferred_bailout;

In my testing, I quickly realized that APC in conjunction with Zend was
making nested calls to HANDLE_BLOCK_INTERRUPTIONS(), so to keep from
unblocking prematurely, it was necessary to track nesting depth.

Example from my debugging:

Block 0 /tmp/APC-3.0.19/php_apc.c:559
Block 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1876
Unblock 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1913
Unblock 0 /tmp/APC-3.0.19/php_apc.c:592

My updated macros:

#define HANDLE_BLOCK_INTERRUPTIONS()if
(!EG(blocking_interruptions)++) { if (zend_block_interruptions) {
zend_block_interruptions(); } }
#define HANDLE_UNBLOCK_INTERRUPTIONS()  if
(EG(blocking_interruptions) && !--EG(blocking_interruptions)) { if
(zend_unblock_interruptions) { zend_unblock_interruptions(); } if
(EG(deferred_bailout)) { zend_bailout(); } }

And my mod to _zend_bailout:

if (EG(blocking_interruptions))
{
EG(deferred_bailout) = 1;
return;
}
EG(deferred_bailout) = 0;



[2008-09-08 15:23:59] askalski at gmail dot com

Description:

A zend_bailout (longjmp) is allowed while HANDLE_BLOCK_INTERRUPTIONS is
in effect.  When this happens while APC has its shared memory segment
locked, it results in corruption of the segment and deadlocking of the
mutex.  An Apache restart is required to get things moving again.

Tested with PHP 5.2.6 and 4.4.8 with APC 3.0.19 using pthread mutexes.

In our particular case, this is happening when a script hits the
max_execution_time timeout during an include().

Although APC is involved, I am submitting this as a PHP bug because the
fix (zend_bailout / HANDLE_BLOCK_INTERRUPTIONS) is completely PHP-side.


Reproduce code:
---



Expected result:

Defer the zend_bailout until HANDLE_UNBLOCK_INTERRUPTIONS is called.


Actual result:
--
Deadlock of the entire web server, requiring an Apache restart.






-- 
Edit this bug report at http://bugs.php.net/?id=46025&edit=1

#42498 [Com]: Memory leak

2009-01-19 Thread askalski at gmail dot com

 ID:   42498
 Comment by:   askalski at gmail dot com
 Reported By:  doppelbauer at gmx dot net
 Status:   No Feedback
 Bug Type: IMAP related
 Operating System: any
 PHP Version:  5.2.4
 New Comment:

This leak is fixed by the latest 5.2 CVS


Previous Comments:


[2007-09-11 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".



[2007-09-03 09:14:20] 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 ,
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.





[2007-08-31 15:55:47] doppelbauer at gmx dot net

Description:

It seams, there there is a memory leak in
"imap_rfc822_parse_adrlist()". 

A solution would be, to call "mail_free_address()" from the c-client
library, after "rfc822_parse_adrlist()".







-- 
Edit this bug report at http://bugs.php.net/?id=42498&edit=1

Bug #46025 [Sus]: zend_bailout can deadlock APC

2010-05-30 Thread askalski at gmail dot com

Edit report at http://bugs.php.net/bug.php?id=46025&edit=1

 ID:   46025
 User updated by:  askalski at gmail dot com
 Reported by:  askalski at gmail dot com
 Summary:  zend_bailout can deadlock APC
 Status:   Suspended
 Type: Bug
 Package:  Reproducible crash
 Operating System: redhat
 PHP Version:  5.2.6

 New Comment:

I uploaded patches against the latest 5.1, 5.2, and 5.3 versions of PHP,
for sites with production issues that can't afford to wait years for an
upstream fix.


Previous Comments:

[2009-10-21 18:42:04] askalski at gmail dot com

We are using a modified 5.2 in production, so a patch against 5.2.11
(the latest release in that series) would be good.



Thanks,



Andy


[2009-10-21 18:01:00] sh...@php.net

Lucas Nealan and I are working on fixing some items in the signals
patch, and would like to push forward on this getting integrated in
core.  Would you be willing to try the patch for PHP to see if it
corrects your problem?  It would be of great use to know that it fixes
your specific issue.  If so let me know which specific version of PHP
you want a patch against and I'll make sure we get you the latest one
that cleanly patches against it.


[2009-02-27 20:09:27] pierre at archlinux dot de

This problem is still reproducable with version 5.2.9. The cgi version
is affected, too (as expected).


[2009-02-15 00:01:20] dan at archlinux dot org

Any progress here? This is definitely reproducible and we have seen it
on archlinux.org about once every 3 or 4 days- it kind of stinks. Is
there any current workaround besides increasing the timeout value and
hoping for the best?



Running:

Apache 2.2.11

PHP 5.2.8

APC 3.0.19


[2008-09-09 00:46:09] scott...@php.net

This is essentially what http://wiki.php.net/rfc/zendsignals is for, it
was considered for PHP 5.3 but has been deferred for the moment.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=46025


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46025&edit=1

Bug #46025 [Com]: zend_bailout can deadlock APC

2010-06-24 Thread askalski at gmail dot com

Edit report at http://bugs.php.net/bug.php?id=46025&edit=1

 ID:   46025
 Comment by:   askalski at gmail dot com
 Reported by:  askalski at gmail dot com
 Summary:  zend_bailout can deadlock APC
 Status:   Suspended
 Type: Bug
 Package:  Reproducible crash
 Operating System: redhat
 PHP Version:  5.2.6

 New Comment:

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.


Previous Comments:

[2010-05-31 06:54:14] askalski at gmail dot com

I uploaded patches against the latest 5.1, 5.2, and 5.3 versions of PHP,
for sites with production issues that can't afford to wait years for an
upstream fix.


[2009-10-21 18:42:04] askalski at gmail dot com

We are using a modified 5.2 in production, so a patch against 5.2.11
(the latest release in that series) would be good.



Thanks,



Andy


[2009-10-21 18:01:00] sh...@php.net

Lucas Nealan and I are working on fixing some items in the signals
patch, and would like to push forward on this getting integrated in
core.  Would you be willing to try the patch for PHP to see if it
corrects your problem?  It would be of great use to know that it fixes
your specific issue.  If so let me know which specific version of PHP
you want a patch against and I'll make sure we get you the latest one
that cleanly patches against it.


[2009-02-27 20:09:27] pierre at archlinux dot de

This problem is still reproducable with version 5.2.9. The cgi version
is affected, too (as expected).


[2009-02-15 00:01:20] dan at archlinux dot org

Any progress here? This is definitely reproducible and we have seen it
on archlinux.org about once every 3 or 4 days- it kind of stinks. Is
there any current workaround besides increasing the timeout value and
hoping for the best?



Running:

Apache 2.2.11

PHP 5.2.8

APC 3.0.19




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=46025


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46025&edit=1

Bug #46685 [Com]: SSL code should use select

2010-07-21 Thread askalski at gmail dot com

Edit report at http://bugs.php.net/bug.php?id=46685&edit=1

 ID:   46685
 Comment by:   askalski at gmail dot com
 Reported by:  scott dot php at scottrix dot co dot uk
 Summary:  SSL code should use select
 Status:   Assigned
 Type: Bug
 Package:  OpenSSL related
 Operating System: *
 PHP Version:  5.*, 6
 Assigned To:  rasmus

 New Comment:

Any progress on this ticket?  We've begun encountering this bug somewhat
regularly, whenever one of our third-party SOAP services has problems. 
The symptom is our entire cluster of PHP servers redlines the CPU for
the duration of the SOAP outage.



Do you still need a test case reduction?  I have reproduced the issue in
the latest PHP 5.2 and 5.3 releases.



In the meantime, I am going to look over the original submitter's
proposed patch, and use that to fix our immediate problem.


Previous Comments:

[2009-11-27 18:44:53] paj...@php.net

assigned to Rasmus, looks like he is willing to figure out the cause and
improve this patch.


[2008-11-26 13:36:31] scott dot php at scottrix dot co dot uk

Seems to me you don't understand, I could easily have found this with a
code walk and would not have any test case.  The way you are using the
SSL libraries is (IMO and the openssl examples) wrong.  Doesn't matter
if it has any effects on running scripts, it is still wrong.  I DO
understand that you will want a test to show it has been fixed, but this
isn't possible with all coding problems as I'm sure you know, the main
thing from a change like this is that it doesn't break any of the
existing tests and regression tests that you already have. (or anybody
else code that is out there)



The only test I have that shows the problem is an strace on a running
script.  I don't have permission to release that script and you don't
have the server pages and software that the script runs against, so
would be useless anyway.  I would try to create one, but I personally
don't know PHP so can't.  Given the problem I would imagine that any PHP
script that is talking SSL and having to wait for data to come back
would have the same problem (viewable by strace output).



Anyway, if you NEED more to be able to apply a patch and test it, then I
guess you can close this bug.  The important thing for me is that I have
tried to get someone upstream interested in writing better code, and
that it is searchable so that others that experience the problem can
find it and try my fix.


[2008-11-26 13:19:34] paj...@php.net

You get it wrong.



A patch can and will be applied when tests are provided as well. The
goal is not only to be able to reproduce a possible issue, but also to
be sure about the patch is trying to fix.



You do not want to provide them and I'm not sure your patch is the right
to do it (as already said, that does not mean it is wrong). So this bug
has now in a "no feedback" status, until you have figured out that what
I asked is relevent.



That's a relatively simple process, isn't it?


[2008-11-26 13:13:58] scott dot php at scottrix dot co dot uk

I didn't submit the patch to help me, I already have the fix for the
problem.  If you aren't interested then that is fine.  Just thought I'd
try and give something back to you guys.  Next time I won't bother.


[2008-11-26 13:07:36] paj...@php.net

your choice >  no feedback.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=46685


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46685&edit=1

Bug #46685 [Com]: SSL code should use select

2010-07-21 Thread askalski at gmail dot com

Edit report at http://bugs.php.net/bug.php?id=46685&edit=1

 ID:   46685
 Comment by:   askalski at gmail dot com
 Reported by:  scott dot php at scottrix dot co dot uk
 Summary:  SSL code should use select
 Status:   Assigned
 Type: Bug
 Package:  OpenSSL related
 Operating System: *
 PHP Version:  5.*, 6
 Assigned To:  rasmus

 New Comment:

I made a somewhat different patch.  As far as I can tell, the
busy-waiting only happens during the call to php_openssl_enable_crypto,
where the socket is forced nonblocking to support the connect timeout. 
My patch exposes the WANT_READ/WANT_WRITE error code through the return
value of handle_ssl_error(), and adds a select() to the SSL_connect
loop, using a deadline-based timeout calculation.



The diff is against 5.2.9, which is the version I need to fix.  It seems
to apply cleanly against 5.2.13, but I haven't tested it.  (I would need
to create a separate patch for 5.3, though.)



diff --git a/ext/openssl/xp_ssl.c b/ext/openssl/xp_ssl.c

index c31a505..e0a72b1 100644

--- a/ext/openssl/xp_ssl.c

+++ b/ext/openssl/xp_ssl.c

@@ -92,19 +92,25 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init

char *ebuf = NULL, *wptr = NULL;

size_t ebuf_size = 0;

unsigned long code, ecode;

-   int retry = 1;

+   int retry = 0;

 

switch(err) {

case SSL_ERROR_ZERO_RETURN:

/* SSL terminated (but socket may still be active) */

-   retry = 0;

break;

case SSL_ERROR_WANT_READ:

case SSL_ERROR_WANT_WRITE:

/* re-negotiation, or perhaps the SSL layer needs more

 * packets: retry in next iteration */

errno = EAGAIN;

-   retry = is_init ? 1 : sslsock->s.is_blocked;

+   if (is_init || sslsock->s.is_blocked) {

+   /* Return the actual error code, rather than 
just "1".  The
SSL_connect

+* call is non-blocking for connect_timeout 
support ("blocking with
timeout"

+* from the outside perspective.)  The caller 
needs to know whether
to

+* 'select' on read or write.

+*/

+   retry = err;

+   }

break;

case SSL_ERROR_SYSCALL:

if (ERR_peek_error() == 0) {

@@ -115,7 +121,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init

}

SSL_set_shutdown(sslsock->ssl_handle,
SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN);

stream->eof = 1;

-   retry = 0;

} else {

char *estr = 
php_socket_strerror(php_socket_errno(), NULL, 0);

 

@@ -123,7 +128,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init

"SSL: %s", estr);

 

efree(estr);

-   retry = 0;

}

break;

}

@@ -137,7 +141,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init

switch (ERR_GET_REASON(ecode)) {

case SSL_R_NO_SHARED_CIPHER:

php_error_docref(NULL TSRMLS_CC, 
E_WARNING,
"SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used.  This
could be because the server is missing an SSL certificate (local_cert
context option)");

-   retry = 0;

break;

 

default:

@@ -175,7 +178,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init

}

}



-   retry = 0;

errno = 0;

}

return retry;

@@ -391,12 +393,9 @@ static inline int
php_openssl_enable_crypto(php_stream *stream,

php_stream_xport_crypto_param *cparam

TSRMLS_DC)

 {

-   int n, retry = 1;

+   int n, retry;

 

if (cparam->inputs.activate && !sslsock->ssl_active) {

-   float timeout = sslsock->connect_timeout.tv_sec +
sslsock->connect_timeout.tv_usec / 100;

-

Bug #35090 [Bgs]: file i/o is not buffered

2010-08-12 Thread askalski at gmail dot com

Edit report at http://bugs.php.net/bug.php?id=35090&edit=1

 ID: 35090
 User updated by:askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:file i/o is not buffered
 Status: Bogus
 Type:   Bug
 Package:Filesystem function related
 Operating System:   linux
-PHP Version:5CVS-2005-11-03 (snap)
+PHP Version:5.3.3
 Block user comment: N

 New Comment:

I guess that's one way to deal with it.  At least then it would be clear
to PHP developers that each fwrite() makes a separate system call.



Even better would be for PHP to use the C stdio library for file i/o,
and take advantage of the buffering it offers by default.  Even back in
the 1970's when C was created, they had already figured out that
buffered I/O was a good thing, and consequently built it into stdio...



(I'm surprised to see feedback on a bug ticket that was closed as
"Bogus" almost five years ago.  Ultimately, this is pretty low on my
list of "reasons PHP execution is so painfully slow"; it's just
something I spotted when doing an strace to troubleshoot an unrelated
issue.  That's why I never bothered to pursue it further.)


Previous Comments:

[2010-08-12 12:59:41] surfchen at gmail dot com

So we need to add a note on the documentation say that this function not
supported 

with filesystem wrapper, right?

----------------
[2005-11-03 23:40:24] askalski at gmail dot com

> instead it uses the system's file io buffering function

> to set the buffer.



Assuming you're talking about setvbuf() and not kernel

level write-behind caching, this statement is false.



The file is opened by _php_stream_fopen():



fd = open(realpath, open_flags, 0666);



(It is never subsequently wrapped with fdopen())



At this point, the stream is not buffered at all.



When I later call stream_set_write_buffer(), it hits

php_stdiop_set_option():



case PHP_STREAM_OPTION_WRITE_BUFFER:

if (data->file == NULL) {

return -1;

}

/* setvbuf happens down here */



Because there is no FILE* handle (data->file), setvbuf()

is never called for the stream.



One of either the documentation
(http://us3.php.net/stream_set_write_buffer)

or the PHP source is wrong.


[2005-11-03 21:34:16] 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

PHP does not do any buffering itself, instead it uses the system's file
io buffering function to set the buffer. 

There is already a feature request open to enable in-php buffering.


[2005-11-03 21:29:08] der...@php.net

Can you please answer why this is not a bug Wez? I forgot the reason :)

----------------
[2005-11-03 19:16:09] askalski at gmail dot com

Description:

The documentation for stream_set_write_buffer() says that fwrite()s are
buffered at 8K by default.  In reality, it does not buffer at all.  Any
attempt to call stream_set_write_buffer() on a regular file handle
results in failure.



Reproduce code:
---
$fh = fopen("asdf", "w");



// write some data using the default buffering

for ($i = 0; $i < 5; $i++)

fwrite($fh, "test");



// demonstrate that stream_set_write_buffer fails

$n = stream_set_write_buffer($fh, 8192);

if ($n != 0)

echo "stream_set_write_buffer failed\n";



// write some more data to demonstrate the failure

for ($i = 0; $i < 5; $i++)

fwrite($fh, "again");



fclose($fh);



Expected result:

PHP should buffer its I/O, and strace should log a single write(). 
stream_set_write_buffer() should not fail on regular files.



Actual result:
--
Output:



stream_set_write_buffer failed





Abridged strace output:



open("/tmp/php5-200511031730/asdf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0

lseek(3, 0, SEEK_CUR)   = 0

write(3, "test", 4) = 4

write(3, "test", 4) = 4

write(3, "test", 4) = 4

write(3, "test", 4) = 4

write(3, "test", 4) = 4

write(1, "stream_set_write_buffer failed\n", 31) = 31

write(3, "again", 5)= 5

write(3, &q

#35079 [NEW]: stream_set_blocking(true) toggles, not enables blocking

2005-11-02 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: linux
PHP version:  5.0.5
PHP Bug Type: Filesystem function related
Bug description:  stream_set_blocking(true) toggles, not enables blocking

Description:

main/streams/plain_wrapper.c (5.0.5)
main/streams.c (4.4 and earlier)

In several places, the ^= operator is used to turn off a flag.  This is
incorrect.  For example, stream_set_blocking() on a plain file hits this
code in php_stdiop_set_option():

if (value)
flags ^= O_NONBLOCK;
else
flags |= O_NONBLOCK;

This should be:

if (value)
flags &= ~O_NONBLOCK;
else
flags |= O_NONBLOCK;

The same error is repeated elsewhere in the code.


Reproduce code:
---
$fp = fopen("test", "w");

stream_set_blocking($fp, true);
stream_set_blocking($fp, true);
stream_set_blocking($fp, true);
stream_set_blocking($fp, true);

fclose($fp);


Expected result:

The stream should remain in blocking mode throughout the script
execution.


Actual result:
--
Here is abridged strace output showing the errant behavior.  Notice how
O_NONBLOCK is being turned on and off alternately.

open("/home/askalski/test", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
fcntl64(4, F_SETFL, O_WRONLY)   = 0
fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
fcntl64(4, F_SETFL, O_WRONLY)   = 0
close(4)= 0


-- 
Edit bug report at http://bugs.php.net/?id=35079&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=35079&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=35079&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=35079&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35079&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35079&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=35079&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=35079&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=35079&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35079&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=35079&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=35079&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=35079&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35079&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=35079&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35079&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=35079&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35079&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=35079&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=35079&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=35079&r=mysqlcfg

#35079 [Fbk->Opn]: stream_set_blocking(true) toggles, not enables blocking

2005-11-03 Thread askalski at gmail dot com

 ID:   35079
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: linux
 PHP Version:  5.0.5
 New Comment:

Still broken. (php-200511031730)


Previous Comments:


[2005-11-03 15:48:11] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2005-11-03 05:55:11] askalski at gmail dot com

Description:

main/streams/plain_wrapper.c (5.0.5)
main/streams.c (4.4 and earlier)

In several places, the ^= operator is used to turn off a flag.  This is
incorrect.  For example, stream_set_blocking() on a plain file hits this
code in php_stdiop_set_option():

if (value)
flags ^= O_NONBLOCK;
else
flags |= O_NONBLOCK;

This should be:

if (value)
flags &= ~O_NONBLOCK;
else
flags |= O_NONBLOCK;

The same error is repeated elsewhere in the code.


Reproduce code:
---
$fp = fopen("test", "w");

stream_set_blocking($fp, true);
stream_set_blocking($fp, true);
stream_set_blocking($fp, true);
stream_set_blocking($fp, true);

fclose($fp);


Expected result:

The stream should remain in blocking mode throughout the script
execution.


Actual result:
--
Here is abridged strace output showing the errant behavior.  Notice how
O_NONBLOCK is being turned on and off alternately.

open("/home/askalski/test", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
fcntl64(4, F_SETFL, O_WRONLY)   = 0
fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
fcntl64(4, F_SETFL, O_WRONLY)   = 0
close(4)= 0






-- 
Edit this bug report at http://bugs.php.net/?id=35079&edit=1

#35090 [NEW]: file i/o is not buffered

2005-11-03 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: linux
PHP version:  5CVS-2005-11-03 (snap)
PHP Bug Type: Filesystem function related
Bug description:  file i/o is not buffered

Description:

The documentation for stream_set_write_buffer() says that fwrite()s are
buffered at 8K by default.  In reality, it does not buffer at all.  Any
attempt to call stream_set_write_buffer() on a regular file handle results
in failure.


Reproduce code:
---
$fh = fopen("asdf", "w");

// write some data using the default buffering
for ($i = 0; $i < 5; $i++)
fwrite($fh, "test");

// demonstrate that stream_set_write_buffer fails
$n = stream_set_write_buffer($fh, 8192);
if ($n != 0)
echo "stream_set_write_buffer failed\n";

// write some more data to demonstrate the failure
for ($i = 0; $i < 5; $i++)
fwrite($fh, "again");

fclose($fh);


Expected result:

PHP should buffer its I/O, and strace should log a single write(). 
stream_set_write_buffer() should not fail on regular files.


Actual result:
--
Output:

stream_set_write_buffer failed


Abridged strace output:

open("/tmp/php5-200511031730/asdf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)   = 0
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(1, "stream_set_write_buffer failed\n", 31) = 31
write(3, "again", 5)= 5
write(3, "again", 5)= 5
write(3, "again", 5)= 5
write(3, "again", 5)= 5
write(3, "again", 5)= 5
close(3)= 0


-- 
Edit bug report at http://bugs.php.net/?id=35090&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=35090&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=35090&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=35090&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35090&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35090&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=35090&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=35090&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=35090&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35090&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=35090&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=35090&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=35090&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35090&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=35090&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35090&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=35090&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35090&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=35090&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=35090&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=35090&r=mysqlcfg

#35090 [Bgs]: file i/o is not buffered

2005-11-03 Thread askalski at gmail dot com

 ID:   35090
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: linux
 PHP Version:  5CVS-2005-11-03 (snap)
 New Comment:

> instead it uses the system's file io buffering function
> to set the buffer.

Assuming you're talking about setvbuf() and not kernel
level write-behind caching, this statement is false.

The file is opened by _php_stream_fopen():

fd = open(realpath, open_flags, 0666);

(It is never subsequently wrapped with fdopen())

At this point, the stream is not buffered at all.

When I later call stream_set_write_buffer(), it hits
php_stdiop_set_option():

case PHP_STREAM_OPTION_WRITE_BUFFER:
if (data->file == NULL) {
return -1;
}
/* setvbuf happens down here */

Because there is no FILE* handle (data->file), setvbuf()
is never called for the stream.

One of either the documentation
(http://us3.php.net/stream_set_write_buffer)
or the PHP source is wrong.


Previous Comments:


[2005-11-03 21:34:16] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

PHP does not do any buffering itself, instead it uses the system's file
io buffering function to set the buffer. 
There is already a feature request open to enable in-php buffering.



[2005-11-03 21:29:08] [EMAIL PROTECTED]

Can you please answer why this is not a bug Wez? I forgot the reason :)

----

[2005-11-03 19:16:09] askalski at gmail dot com

Description:

The documentation for stream_set_write_buffer() says that fwrite()s are
buffered at 8K by default.  In reality, it does not buffer at all.  Any
attempt to call stream_set_write_buffer() on a regular file handle
results in failure.


Reproduce code:
---
$fh = fopen("asdf", "w");

// write some data using the default buffering
for ($i = 0; $i < 5; $i++)
fwrite($fh, "test");

// demonstrate that stream_set_write_buffer fails
$n = stream_set_write_buffer($fh, 8192);
if ($n != 0)
echo "stream_set_write_buffer failed\n";

// write some more data to demonstrate the failure
for ($i = 0; $i < 5; $i++)
fwrite($fh, "again");

fclose($fh);


Expected result:

PHP should buffer its I/O, and strace should log a single write(). 
stream_set_write_buffer() should not fail on regular files.


Actual result:
--
Output:

stream_set_write_buffer failed


Abridged strace output:

open("/tmp/php5-200511031730/asdf", O_WRONLY|O_CREAT|O_TRUNC, 0666) =
3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)   = 0
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(3, "test", 4) = 4
write(1, "stream_set_write_buffer failed\n", 31) = 31
write(3, "again", 5)= 5
write(3, "again", 5)= 5
write(3, "again", 5)= 5
write(3, "again", 5)= 5
write(3, "again", 5)= 5
close(3)= 0






-- 
Edit this bug report at http://bugs.php.net/?id=35090&edit=1

#39362 [NEW]: imap_open retries 3 times on failed auth

2006-11-03 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: Linux
PHP version:  5CVS-2006-11-03 (snap)
PHP Bug Type: IMAP related
Bug description:  imap_open retries 3 times on failed auth

Description:

imap_open will retry 3 times on bad credentials.  Some IMAP or POP servers
delay on successive bad logins, making a failed imap_open take very long. 
Worse, some servers will lock the user out because of repeated failed
login attempts.

Somewhere during module initialization, this call needs to be made:

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);


Reproduce code:
---
imap_open("{mailserver/pop}", "user", "badpass");


Expected result:

It should try logging in only once.


Actual result:
--
It tries logging in three times (watch with a packet sniffer or strace).

write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "QUIT\r\n", 6) = 6
read(0, "+OK Sayonara\r\n", 8192)   = 14
write(1, "\nWarning: imap_open(): Couldn\'t "..., 104) = 104


-- 
Edit bug report at http://bugs.php.net/?id=39362&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39362&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39362&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39362&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39362&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39362&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39362&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39362&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39362&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39362&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39362&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39362&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39362&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39362&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39362&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39362&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39362&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39362&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39362&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39362&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39362&r=mysqlcfg

#39362 [Bgs->Opn]: imap_open retries 3 times on failed auth

2006-11-03 Thread askalski at gmail dot com

 ID:   39362
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
-Status:   Bogus
+Status:   Open
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5CVS-2006-11-03 (snap)
 New Comment:

I'm sorry if I did not make this clear enough in the original bug
report.

This is very much a bug in PHP.  While you're correct in saying
c-client controls the number of retries it makes, it's up to PHP to
change MAXLOGINTRIALS from its default of 3 to 1.

There is no way to work around this from a PHP script, because the
mail_parameters() function is not exposed through the PHP imap module. 
The only way is for PHP to make a mail_parameters() call in
ext/imap/php_imap.c during module initialization.


Previous Comments:


[2006-11-03 20:03:22] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

PHP does not control the number of retries performed, that is 
something the imap (c-client) library controls.



[2006-11-03 15:47:18] askalski at gmail dot com

Description:

imap_open will retry 3 times on bad credentials.  Some IMAP or POP
servers delay on successive bad logins, making a failed imap_open take
very long.  Worse, some servers will lock the user out because of
repeated failed login attempts.

Somewhere during module initialization, this call needs to be made:

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);


Reproduce code:
---
imap_open("{mailserver/pop}", "user", "badpass");


Expected result:

It should try logging in only once.


Actual result:
--
It tries logging in three times (watch with a packet sniffer or
strace).

write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "QUIT\r\n", 6) = 6
read(0, "+OK Sayonara\r\n", 8192)   = 14
write(1, "\nWarning: imap_open(): Couldn\'t "..., 104) = 104






-- 
Edit this bug report at http://bugs.php.net/?id=39362&edit=1

#39362 [Asn]: imap_open retries 3 times on failed auth

2006-11-04 Thread askalski at gmail dot com

 ID:   39362
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
 Status:   Assigned
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5CVS-2006-11-03 (snap)
 Assigned To:  iliaa
 New Comment:

Is there really any point in retrying with the same failed credentials?
 The only reasonable setting for MAXLOGINTRIALS in this case is 1. 
(There is no benefit in setting it any higher in PHP, so it wouldn't
make sense to add the ability to control it.)


Previous Comments:


[2006-11-04 19:11:31] [EMAIL PROTECTED]

Actually this is more of a feature request to add the ability 
to control the number of retries, something the current API 
does not allow.



[2006-11-03 20:48:44] askalski at gmail dot com

I'm sorry if I did not make this clear enough in the original bug
report.

This is very much a bug in PHP.  While you're correct in saying
c-client controls the number of retries it makes, it's up to PHP to
change MAXLOGINTRIALS from its default of 3 to 1.

There is no way to work around this from a PHP script, because the
mail_parameters() function is not exposed through the PHP imap module. 
The only way is for PHP to make a mail_parameters() call in
ext/imap/php_imap.c during module initialization.



[2006-11-03 20:03:22] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

PHP does not control the number of retries performed, that is 
something the imap (c-client) library controls.



[2006-11-03 15:47:18] askalski at gmail dot com

Description:

imap_open will retry 3 times on bad credentials.  Some IMAP or POP
servers delay on successive bad logins, making a failed imap_open take
very long.  Worse, some servers will lock the user out because of
repeated failed login attempts.

Somewhere during module initialization, this call needs to be made:

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);


Reproduce code:
---
imap_open("{mailserver/pop}", "user", "badpass");


Expected result:

It should try logging in only once.


Actual result:
--
It tries logging in three times (watch with a packet sniffer or
strace).

write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "QUIT\r\n", 6) = 6
read(0, "+OK Sayonara\r\n", 8192)   = 14
write(1, "\nWarning: imap_open(): Couldn\'t "..., 104) = 104






-- 
Edit this bug report at http://bugs.php.net/?id=39362&edit=1

#37157 [Fbk->Opn]: force-cgi-redirect is not checked under FastCGI

2006-04-29 Thread askalski at gmail dot com

 ID:   37157
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5CVS-2006-04-21 (snap)
 Assigned To:  dmitry
 New Comment:

Yes.  I've been through the cgi_main source code, which goes something
like this:

main()
{
...
/* this check here doesn't help in fastcgi mode */
do_force_redirect_check();
...

while (accept_fastcgi_connection())
{
import_cgi_environment();

/* but here it would */
}

...
}


Previous Comments:


[2006-04-29 12:45:59] [EMAIL PROTECTED]

Have you set "cgi.force_redirect=1" in your php.ini?



[2006-04-21 22:02:45] askalski at gmail dot com

Description:

The FastCGI version of PHP does not perform the force-cgi-redirect
check for page requests.

If I request http://localhost/cgi-bin/php, PHP
tries to parse the PHP binary in /cgi-bin as
if it was a script.

If cgi.fix_pathinfo is turned off, users can
bypass .htaccess security.

See also bug #22846.


Reproduce code:
---
PHP was configured with:

./configure --enable-fastcgi --enable-force-cgi-redirect


My /cgi-bin/php is a wrapper script that sets up
FastCGI environment variables:

#! /bin/sh

export PHPRC=/etc/apache
export PHP_FCGI_CHILDREN=4
export PHP_FCGI_MAX_REQUESTS=512

exec /usr/local/bin/php


Expected result:

Security Alert! The PHP CGI cannot be accessed directly.

This PHP CGI binary was compiled with force-cgi-redirect enabled. This
means that a page will only be served up if the REDIRECT_STATUS CGI
variable is set, e.g. via an Apache Action directive.

For more information as to why this behaviour exists, see the manual
page for CGI security.

For more information about changing this behaviour or re-enabling this
webserver, consult the installation file that came with this
distribution, or visit the manual page.


Actual result:
--
export PHPRC=/etc/apache
export PHP_FCGI_CHILDREN=4
export PHP_FCGI_MAX_REQUESTS=512

exec /usr/local/bin/php






-- 
Edit this bug report at http://bugs.php.net/?id=37157&edit=1

#37157 [NEW]: force-cgi-redirect is not checked under FastCGI

2006-04-21 Thread askalski at gmail dot com

From: askalski at gmail dot com
Operating system: Linux
PHP version:  5CVS-2006-04-21 (snap)
PHP Bug Type: CGI related
Bug description:  force-cgi-redirect is not checked under FastCGI

Description:

The FastCGI version of PHP does not perform the force-cgi-redirect check
for page requests.

If I request http://localhost/cgi-bin/php, PHP
tries to parse the PHP binary in /cgi-bin as
if it was a script.

If cgi.fix_pathinfo is turned off, users can
bypass .htaccess security.

See also bug #22846.


Reproduce code:
---
PHP was configured with:

./configure --enable-fastcgi --enable-force-cgi-redirect


My /cgi-bin/php is a wrapper script that sets up
FastCGI environment variables:

#! /bin/sh

export PHPRC=/etc/apache
export PHP_FCGI_CHILDREN=4
export PHP_FCGI_MAX_REQUESTS=512

exec /usr/local/bin/php


Expected result:

Security Alert! The PHP CGI cannot be accessed directly.

This PHP CGI binary was compiled with force-cgi-redirect enabled. This
means that a page will only be served up if the REDIRECT_STATUS CGI
variable is set, e.g. via an Apache Action directive.

For more information as to why this behaviour exists, see the manual page
for CGI security.

For more information about changing this behaviour or re-enabling this
webserver, consult the installation file that came with this distribution,
or visit the manual page.


Actual result:
--
export PHPRC=/etc/apache
export PHP_FCGI_CHILDREN=4
export PHP_FCGI_MAX_REQUESTS=512

exec /usr/local/bin/php


-- 
Edit bug report at http://bugs.php.net/?id=37157&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=37157&r=trysnapshot44
Try a CVS snapshot (PHP 5.1): 
http://bugs.php.net/fix.php?id=37157&r=trysnapshot51
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=37157&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37157&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=37157&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=37157&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37157&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37157&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=37157&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37157&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=37157&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=37157&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37157&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=37157&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37157&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37157&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=37157&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=37157&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=37157&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37157&r=mysqlcfg

[PHP-BUG] Bug #55395 [NEW]: php soap extension passes unsafe zvals to user functions, corrupting memory

2011-08-10 Thread askalski at gmail dot com

From: 
Operating system: linux
PHP version:  5.4SVN-2011-08-11 (snap)
Package:  SOAP related
Bug Type: Bug
Bug description:php soap extension passes unsafe zvals to user functions, 
corrupting memory

Description:

The PHP SOAP extension passes unsafe zvals as arguments to user functions
(for example, __doRequest.)  If that user function saves a reference to
those zvals, it leads to memory corruption, generally resulting in a
segmentation fault.

Two example problems from ext/soap/soap.c.  The whole SOAP extension needs
to be audited for this:

(1) Allocating a zval on the stack, then passing a pointer to that zval
into a user function:
  zval param0;
  params[0] = ¶m0;
  call_user_function(..., params ...);

(2) Failing to duplicate string buffers:

  // 'buf' is freed while references to its zval potentially still exist
  xmlDocDumpMemory(request, (xmlChar**)&buf, &buf_size);
  ZVAL_STRINGL(params[0], buf, buf_size, 0); // needs to be ", 1);"
  call_user_function(..., params ...);
  xmlFree(buf);

  static int do_request(..., char *location, ...) {
  // 'location' is malloc memory that may be freed before the zval
  ZVAL_STRING(params[1], location, 0); // needs to be ", 1);"
  call_user_function(..., params ...);


Test script:
---
 $request,
'location' => $location,
'action' => $action,
'version' => $version,
'one_way' => $one_way);
debug_zval_dump($params); // Before
return "";
}
}
$x = new CorruptSoap(NULL, array('location' => 'http://location/', 'uri' =>
'http://uri/'));
$x->Test();
debug_zval_dump($params); // After
?>


Expected result:

The before/after debug_zval_dump output should look the same, with slightly
different (but valid) reference counts.


Actual result:
--
Before the stack gets smashed:

array(5) refcount(1){
  ["request"]=>
  string(375) "
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://uri/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
" refcount(5)
  ["location"]=>
  string(16) "http://location/"; refcount(5)
  ["action"]=>
  string(16) "http://uri/#Test"; refcount(5)
  ["version"]=>
  long(1) refcount(5)
  ["one_way"]=>
  long(0) refcount(5)
}

After the stack has been smashed:

array(5) refcount(2){
  ["request"]=>
  NULL refcount(0)
  ["location"]=>
  NULL refcount(0)
  ["action"]=>
  NULL refcount(0)
  ["version"]=>
  NULL refcount(10153504)
  ["one_way"]=>
  NULL refcount(0)
}


-- 
Edit bug report at https://bugs.php.net/bug.php?id=55395&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55395&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55395&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55395&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55395&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55395&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55395&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55395&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55395&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55395&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55395&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55395&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55395&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55395&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55395&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55395&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55395&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55395&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55395&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55395&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55395&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55395&r=mysqlcfg

[PHP-BUG] Bug #60152 [NEW]: HANDLE_BLOCK_INTERRUPTIONS mismatch in _apc_store

2011-10-27 Thread askalski at gmail dot com

From: 
Operating system: n/a
PHP version:  Irrelevant
Package:  APC
Bug Type: Bug
Bug description:HANDLE_BLOCK_INTERRUPTIONS mismatch in _apc_store

Description:

The _apc_store function (php_apc.c) fails to HANDLE_UNBLOCK_INTERRUPTIONS()
when returning the "Unable to allocate memory for pool." error.   (Verified
that the issue exists in the 3.1.9 sources.)

Test script:
---
n/a

Expected result:

n/a

Actual result:
--
n/a

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60152&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60152&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60152&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60152&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60152&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60152&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60152&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60152&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60152&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60152&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60152&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60152&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60152&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60152&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60152&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60152&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60152&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60152&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60152&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60152&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60152&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60152&r=mysqlcfg

[PHP-BUG] Bug #65822 [NEW]: crash on shutdown because of zend extension cleanup order

Bug #65822 [Com]: crash on shutdown because of zend extension cleanup order

Bug #65822 [Com]: crash on shutdown because of zend extension cleanup order

Bug #65822 [Csd]: crash on shutdown because of zend extension cleanup order

Bug #46025 [Com]: zend_bailout can deadlock APC

[PHP-BUG] Bug #64467 [NEW]: Segmentation fault after imap_reopen failure

Bug #46025 [Com]: zend_bailout can deadlock APC

#46025 [Sus]: zend_bailout can deadlock APC

#43466 [NEW]: mcrypt_generic_init requires IV in ECB mode

#46025 [NEW]: zend_bailout can deadlock APC

#46025 [Opn]: zend_bailout can deadlock APC

#46025 [Fbk->Opn]: zend_bailout can deadlock APC

#42498 [Com]: Memory leak

Bug #46025 [Sus]: zend_bailout can deadlock APC

Bug #46025 [Com]: zend_bailout can deadlock APC

Bug #46685 [Com]: SSL code should use select

Bug #46685 [Com]: SSL code should use select

Bug #35090 [Bgs]: file i/o is not buffered

#35079 [NEW]: stream_set_blocking(true) toggles, not enables blocking

#35079 [Fbk->Opn]: stream_set_blocking(true) toggles, not enables blocking

#35090 [NEW]: file i/o is not buffered

#35090 [Bgs]: file i/o is not buffered

#39362 [NEW]: imap_open retries 3 times on failed auth

#39362 [Bgs->Opn]: imap_open retries 3 times on failed auth

#39362 [Asn]: imap_open retries 3 times on failed auth

#37157 [Fbk->Opn]: force-cgi-redirect is not checked under FastCGI

#37157 [NEW]: force-cgi-redirect is not checked under FastCGI

[PHP-BUG] Bug #55395 [NEW]: php soap extension passes unsafe zvals to user functions, corrupting memory

[PHP-BUG] Bug #60152 [NEW]: HANDLE_BLOCK_INTERRUPTIONS mismatch in _apc_store

29 matches

Site Navigation

Mail list logo

Footer information