Bug #65426 [Opn]: DBA fails to compile with DB 6.0
Edit report at https://bugs.php.net/bug.php?id=65426edit=1 ID: 65426 User updated by:pierre at archlinux dot de Reported by:pierre at archlinux dot de Summary:DBA fails to compile with DB 6.0 Status: Open Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.5.1 Block user comment: N Private report: N New Comment: Thanks for te hint. You are probably right. I guess BDB support needs to be dropped in the long run unless someone continues to maintain DB5. Previous Comments: [2013-08-09 08:18:34] m...@php.net I've limited knowledge of licensing, but BDB 6 is licensed under GNU AGPL v3. Looks like a problem. [2013-08-09 07:24:01] pierre at archlinux dot de Description: Compiling PHP with DB 6.0.20 fails with: checking for DB4 major version... configure: error: Header contains different version It just seems to affect the test of the configure script; the API is probably the same. I have attached a patch that makes PHP work with DB 6. This might not be the correct way to solve this issue though. -- Edit this bug report at https://bugs.php.net/bug.php?id=65426edit=1
[PHP-BUG] Bug #65426 [NEW]: DBA fails to compile with DB 6.0
From: pierre at archlinux dot de Operating system: Linux PHP version: 5.5.1 Package: DBM/DBA related Bug Type: Bug Bug description:DBA fails to compile with DB 6.0 Description: Compiling PHP with DB 6.0.20 fails with: checking for DB4 major version... configure: error: Header contains different version It just seems to affect the test of the configure script; the API is probably the same. I have attached a patch that makes PHP work with DB 6. This might not be the correct way to solve this issue though. -- Edit bug report at https://bugs.php.net/bug.php?id=65426edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65426r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65426r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65426r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65426r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65426r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65426r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65426r=needscript Try newer version: https://bugs.php.net/fix.php?id=65426r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65426r=support Expected behavior: https://bugs.php.net/fix.php?id=65426r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65426r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65426r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65426r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65426r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65426r=dst IIS Stability: https://bugs.php.net/fix.php?id=65426r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65426r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65426r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65426r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65426r=mysqlcfg
Bug #62886 [Com]: PHP-FPM may segfault/hang on startup
Edit report at https://bugs.php.net/bug.php?id=62886edit=1
ID: 62886
Comment by: pierre at archlinux dot de
Reported by:pierre at archlinux dot de
Summary:PHP-FPM may segfault/hang on startup
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Arch Linux
PHP Version:5.4.6
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
It also crashes with the imap extension disabled. But it seems the number of
enabled extensions might matter.
Anyway, we have a backtrace and the commit that introduced this issue.
Previous Comments:
[2012-09-17 09:55:04] daniel at bashgeek dot net
Have the same problem on my end with a couple of servers. For me the problem is
solved as soon as I disable the IMAP extension of PHP. Maybe it has something
todo with this extension?
[2012-09-12 16:32:02] jeffrey dot ness at rackspace dot com
I am also noticing this issue with our 5.3.16 packages:
# php-fpm -v
PHP 5.3.16 (fpm-fcgi) (built: Aug 20 2012 10:39:20)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
# for i in {1..100}; do php-fpm ; killall php-fpm; done
Segmentation fault
Segmentation fault
Segmentation fault
# dmesg | grep php-fpm
php-fpm[30800]: segfault at 7f7d199f4cd0 ip 7f7d24a43b83 sp
7fffdd48fb20 error 4 in ld-
2.12.so[7f7d24a35000+2]
php-fpm[31599]: segfault at 7f50f17c3cd0 ip 7f50fc812b83 sp
7fff09f13120 error 4 in ld-
2.12.so[7f50fc804000+2]
php-fpm[32009]: segfault at 7f3005f59cc0 ip 7f3010938b83 sp
7fffb291c3a0 error 4 in ld-
2.12.so[7f301092a000+2]
php-fpm[32313]: segfault at 7f17094a4cc0 ip 7f1713e83b83 sp
7fffaab94e20 error 4 in ld-
2.12.so[7f1713e75000+2]
php-fpm[32585]: segfault at 7f60ad427cc0 ip 7f60b7e06b83 sp
744e06a0 error 4 in ld-
2.12.so[7f60b7df8000+2]
[2012-08-24 09:06:27] pierre at archlinux dot de
I have attached php.ini and php-fpm.conf as patches (sorry, didn't fint another
way to attach those)
Here is what is different from the configuration shipped with PHP 5.4.6:
The php-fpm.conf is the plain upstream one with this patch applied:
https://projects.archlinux.de/svntogit/packages.git/tree/trunk/php-fpm.conf.in.patch?h=packages/php
php.ini is a copy of php.ini-production with this patch applied:
https://projects.archlinux.de/svntogit/packages.git/tree/trunk/php.ini.patch?h=packages/php
On top of that I applied the following changes locally:
http://paste.xinu.at/Hp6/
[2012-08-24 08:46:19] f...@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.
I also need your FPM configuration and your php.ini please
thanks
[2012-08-24 08:37:27] pierre at archlinux dot de
I rebuild with debug symbols and got the following trace:
Core was generated by `php-fpm'.
Program terminated with signal 11, Segmentation fault.
#0 0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2
(gdb) bt
#0 0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2
#1 0x7fc96970cb31 in __run_exit_handlers () from /lib/libc.so.6
#2 0x7fc96970cbb5 in exit () from /lib/libc.so.6
#3 0x008cb754 in fpm_signals_sighandler_exit_ok (pid=10) at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_signals.c:254
#4 signal handler called
#5 0x7fc96b2cf3c7 in munmap () from /lib/ld-linux-x86-64.so.2
#6 0x7fc96b2ceb4d in _dl_unmap () from /lib/ld-linux-x86-64.so.2
#7 0x7fc96b2cba1f in _dl_close_worker () from /lib/ld-linux-x86-64.so.2
#8 0x7fc96b2cc18c in _dl_close () from /lib/ld-linux-x86-64.so.2
#9 0x7fc96b2c6736 in _dl_catch_error () from /lib/ld-linux-x86-64.so.2
#10 0x7fc969fee5fc in ?? () from /lib/libdl.so.2
#11 0x7fc969fee10f in dlclose () from /lib/libdl.so.2
#12 0x00773e2c in module_destructor (module=0x1ba6050) at
/build/src/php-5.4.6/Zend/zend_API.c:2284
#13 0x0077c30f in zend_hash_apply_deleter (ht=0xfb5240
module_registry, p=0x1ba5ff0) at /build/src/php-5.4.6/Zend/zend_hash.c:650
#14 0x0077c4aa in zend_hash_graceful_reverse_destroy (ht=0xfb5240
module_registry) at /build/src/php-5.4.6/Zend/zend_hash.c:687
#15 0x00771f97 in zend_destroy_modules () at
/build/src/php-5.4.6/Zend/zend_API.c:1797
#16 0x00768e9e in zend_shutdown () at
/build/src/php-5.4.6
Bug #62886 [Fbk-Asn]: PHP-FPM may segfault/hang on startup
Edit report at https://bugs.php.net/bug.php?id=62886edit=1
ID: 62886
User updated by:pierre at archlinux dot de
Reported by:pierre at archlinux dot de
Summary:PHP-FPM may segfault/hang on startup
-Status: Feedback
+Status: Assigned
Type: Bug
Package:FPM related
Operating System: Arch Linux
PHP Version:5.4.6
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
I rebuild with debug symbols and got the following trace:
Core was generated by `php-fpm'.
Program terminated with signal 11, Segmentation fault.
#0 0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2
(gdb) bt
#0 0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2
#1 0x7fc96970cb31 in __run_exit_handlers () from /lib/libc.so.6
#2 0x7fc96970cbb5 in exit () from /lib/libc.so.6
#3 0x008cb754 in fpm_signals_sighandler_exit_ok (pid=10) at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_signals.c:254
#4 signal handler called
#5 0x7fc96b2cf3c7 in munmap () from /lib/ld-linux-x86-64.so.2
#6 0x7fc96b2ceb4d in _dl_unmap () from /lib/ld-linux-x86-64.so.2
#7 0x7fc96b2cba1f in _dl_close_worker () from /lib/ld-linux-x86-64.so.2
#8 0x7fc96b2cc18c in _dl_close () from /lib/ld-linux-x86-64.so.2
#9 0x7fc96b2c6736 in _dl_catch_error () from /lib/ld-linux-x86-64.so.2
#10 0x7fc969fee5fc in ?? () from /lib/libdl.so.2
#11 0x7fc969fee10f in dlclose () from /lib/libdl.so.2
#12 0x00773e2c in module_destructor (module=0x1ba6050) at
/build/src/php-5.4.6/Zend/zend_API.c:2284
#13 0x0077c30f in zend_hash_apply_deleter (ht=0xfb5240
module_registry, p=0x1ba5ff0) at /build/src/php-5.4.6/Zend/zend_hash.c:650
#14 0x0077c4aa in zend_hash_graceful_reverse_destroy (ht=0xfb5240
module_registry) at /build/src/php-5.4.6/Zend/zend_hash.c:687
#15 0x00771f97 in zend_destroy_modules () at
/build/src/php-5.4.6/Zend/zend_API.c:1797
#16 0x00768e9e in zend_shutdown () at
/build/src/php-5.4.6/Zend/zend.c:823
#17 0x006d5151 in php_module_shutdown () at
/build/src/php-5.4.6/main/main.c:2346
#18 0x008c7e23 in fpm_php_cleanup (which=2, arg=0x0) at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_php.c:199
#19 0x008bc629 in fpm_cleanups_run (type=2) at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_cleanup.c:45
#20 0x008cf1df in fpm_unix_init_main () at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_unix.c:312
#21 0x008bb2df in fpm_init (argc=1, argv=0x7fff252a4a98, config=0x0,
prefix=0x0, pid=0x0, test_conf=0, run_as_root=0) at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm.c:59
#22 0x008c7221 in main (argc=1, argv=0x7fff252a4a98) at
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_main.c:1800
Previous Comments:
[2012-08-23 22:55:51] f...@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.
COuld you please provide the full backtrace please ?
if it's possible, it would be great to enable debug symbols at compilation time
thx
[2012-08-23 15:41:13] larue...@php.net
fat, could you please look at this one?
[2012-08-22 08:26:25] pierre at archlinux dot de
Description:
Since PHP 5.4.5 starting php-fpm will either result in a segmentation fault or
it will hang under certain conditions.
It is a little hard to reproduce but it seems it is related to using modules.
There more modules get loaded via php.ini the more likely this bug will get
triggered ( 30%); with no modules loaded I was not able to trigger it.
I started from 5.4.6 and reverted patches applied to sapi/fpm. Once I reverted
commit c2f33fb1293cbcdc94daefb8583ca13e98b5c826, php would no longer crash or
hang.
See
http://git.php.net/?p=php-src.git;a=commit;h=c2f33fb1293cbcdc94daefb8583ca13e98b5c826
Test script:
---
Configure php with a bunch of modules and run something like this:
for i in {1..100};do sudo php-fpm;sleep 0.5;sudo killall php-fpm;sleep 0.5;done
watch dmesg for segfaults like
php-fpm[32571]: segfault at 7f4eabe93cf8 ip 7f4eae9b1ed6 sp
7fff87d69310 error 4 in ld-2.16.so[7f4eae9a3000+21000]
gdb will tell you 0x7fe0412c1ed6 in _dl_fini () from
/lib/ld-linux-x86-64.so.2
Sometimes php-fpm will hang and has to be killed with kill -9
Bug #62886 [Fbk-Asn]: PHP-FPM may segfault/hang on startup
Edit report at https://bugs.php.net/bug.php?id=62886edit=1 ID: 62886 User updated by:pierre at archlinux dot de Reported by:pierre at archlinux dot de Summary:PHP-FPM may segfault/hang on startup -Status: Feedback +Status: Assigned Type: Bug Package:FPM related Operating System: Arch Linux PHP Version:5.4.6 Assigned To:fat Block user comment: N Private report: N New Comment: I have attached php.ini and php-fpm.conf as patches (sorry, didn't fint another way to attach those) Here is what is different from the configuration shipped with PHP 5.4.6: The php-fpm.conf is the plain upstream one with this patch applied: https://projects.archlinux.de/svntogit/packages.git/tree/trunk/php-fpm.conf.in.patch?h=packages/php php.ini is a copy of php.ini-production with this patch applied: https://projects.archlinux.de/svntogit/packages.git/tree/trunk/php.ini.patch?h=packages/php On top of that I applied the following changes locally: http://paste.xinu.at/Hp6/ Previous Comments: [2012-08-24 08:46:19] f...@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. I also need your FPM configuration and your php.ini please thanks [2012-08-24 08:37:27] pierre at archlinux dot de I rebuild with debug symbols and got the following trace: Core was generated by `php-fpm'. Program terminated with signal 11, Segmentation fault. #0 0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2 (gdb) bt #0 0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2 #1 0x7fc96970cb31 in __run_exit_handlers () from /lib/libc.so.6 #2 0x7fc96970cbb5 in exit () from /lib/libc.so.6 #3 0x008cb754 in fpm_signals_sighandler_exit_ok (pid=10) at /build/src/php-5.4.6/sapi/fpm/fpm/fpm_signals.c:254 #4 signal handler called #5 0x7fc96b2cf3c7 in munmap () from /lib/ld-linux-x86-64.so.2 #6 0x7fc96b2ceb4d in _dl_unmap () from /lib/ld-linux-x86-64.so.2 #7 0x7fc96b2cba1f in _dl_close_worker () from /lib/ld-linux-x86-64.so.2 #8 0x7fc96b2cc18c in _dl_close () from /lib/ld-linux-x86-64.so.2 #9 0x7fc96b2c6736 in _dl_catch_error () from /lib/ld-linux-x86-64.so.2 #10 0x7fc969fee5fc in ?? () from /lib/libdl.so.2 #11 0x7fc969fee10f in dlclose () from /lib/libdl.so.2 #12 0x00773e2c in module_destructor (module=0x1ba6050) at /build/src/php-5.4.6/Zend/zend_API.c:2284 #13 0x0077c30f in zend_hash_apply_deleter (ht=0xfb5240 module_registry, p=0x1ba5ff0) at /build/src/php-5.4.6/Zend/zend_hash.c:650 #14 0x0077c4aa in zend_hash_graceful_reverse_destroy (ht=0xfb5240 module_registry) at /build/src/php-5.4.6/Zend/zend_hash.c:687 #15 0x00771f97 in zend_destroy_modules () at /build/src/php-5.4.6/Zend/zend_API.c:1797 #16 0x00768e9e in zend_shutdown () at /build/src/php-5.4.6/Zend/zend.c:823 #17 0x006d5151 in php_module_shutdown () at /build/src/php-5.4.6/main/main.c:2346 #18 0x008c7e23 in fpm_php_cleanup (which=2, arg=0x0) at /build/src/php-5.4.6/sapi/fpm/fpm/fpm_php.c:199 #19 0x008bc629 in fpm_cleanups_run (type=2) at /build/src/php-5.4.6/sapi/fpm/fpm/fpm_cleanup.c:45 #20 0x008cf1df in fpm_unix_init_main () at /build/src/php-5.4.6/sapi/fpm/fpm/fpm_unix.c:312 #21 0x008bb2df in fpm_init (argc=1, argv=0x7fff252a4a98, config=0x0, prefix=0x0, pid=0x0, test_conf=0, run_as_root=0) at /build/src/php-5.4.6/sapi/fpm/fpm/fpm.c:59 #22 0x008c7221 in main (argc=1, argv=0x7fff252a4a98) at /build/src/php-5.4.6/sapi/fpm/fpm/fpm_main.c:1800 [2012-08-23 22:55:51] f...@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. COuld you please provide the full backtrace please ? if it's possible, it would be great to enable debug symbols at compilation time thx [2012-08-23 15:41:13] larue...@php.net fat, could you please look at this one? [2012-08-22 08:26:25] pierre at archlinux dot de
[PHP-BUG] Bug #62886 [NEW]: PHP-FPM may segfault/hang on startup
From: pierre at archlinux dot de
Operating system: Arch Linux
PHP version: 5.4.6
Package: FPM related
Bug Type: Bug
Bug description:PHP-FPM may segfault/hang on startup
Description:
Since PHP 5.4.5 starting php-fpm will either result in a segmentation fault
or it will hang under certain conditions.
It is a little hard to reproduce but it seems it is related to using
modules. There more modules get loaded via php.ini the more likely this bug
will get triggered ( 30%); with no modules loaded I was not able to
trigger it.
I started from 5.4.6 and reverted patches applied to sapi/fpm. Once I
reverted commit c2f33fb1293cbcdc94daefb8583ca13e98b5c826, php would no
longer crash or hang.
See
http://git.php.net/?p=php-src.git;a=commit;h=c2f33fb1293cbcdc94daefb8583ca13e98b5c826
Test script:
---
Configure php with a bunch of modules and run something like this:
for i in {1..100};do sudo php-fpm;sleep 0.5;sudo killall php-fpm;sleep
0.5;done
watch dmesg for segfaults like
php-fpm[32571]: segfault at 7f4eabe93cf8 ip 7f4eae9b1ed6 sp
7fff87d69310 error 4 in ld-2.16.so[7f4eae9a3000+21000]
gdb will tell you 0x7fe0412c1ed6 in _dl_fini () from
/lib/ld-linux-x86-64.so.2
Sometimes php-fpm will hang and has to be killed with kill -9.
--
Edit bug report at https://bugs.php.net/bug.php?id=62886edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62886r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62886r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62886r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62886r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62886r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62886r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62886r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62886r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62886r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62886r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62886r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62886r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62886r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62886r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62886r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62886r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62886r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62886r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62886r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62886r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62886r=mysqlcfg
Bug #60761 [Com]: zlib.output_compression fails on refresh
Edit report at https://bugs.php.net/bug.php?id=60761edit=1
ID: 60761
Comment by: pierre at archlinux dot de
Reported by:valentiny510 at yahoo dot es
Summary:zlib.output_compression fails on refresh
Status: Closed
Type: Bug
Package:*Compression related
Operating System: xp
PHP Version:5.4.0RC5
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
I just tested this with 5.4.4RC1. While output compression is now on for more
than just one request, there is another drawback: I have several pools defined
via fpm. One of them has php_flag[zlib.output_compression] = on.
Once the vhost using this pool is accessed output compression is turned on for
all fpm pool and cannot be turned off. Even worse:
ini_get('zlib.output_compression') still reports false.
If you then use the ob_gzhandler you get output handler 'ob_gzhandler'
conflicts with 'zlib output compression'
Previous Comments:
[2012-05-15 07:47:47] m...@php.net
Should be fixed in 5.4 and master.
[2012-05-15 07:45:37] m...@php.net
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=0ad53bfd7da12a92a46c08e3fff579a15026b88b
Log: fix bug #60761 zlib.output_compression fails on refresh
[2012-05-12 13:42:53] pierre at archlinux dot de
I can still reproduce this bug on Arch Linux using PHP 5.4.3 (php-fpm). Which
additional information do you guys need? It seems pretty obvious to me.
[2012-04-15 02:27:15] adunar at gmail dot com
The bug also happens with the cli-server SAPI (both Windows and Ubuntu).
Here are a few (bash) commands that will reproduce this bug (assumes
zlib.output_compression = On in your php.ini)
echo ?php echo '---'; bug.php
php -S 127.0.0.1: /dev/null 21
curl --header Accept-Encoding: gzip http://localhost:/bug.php 2
/dev/null | wc -m
curl --header Accept-Encoding: gzip http://localhost:/bug.php 2
/dev/null | wc -m
# fg, then ctrl+c to kill php -S
If output_compression is working correctly, the two curl commands should print
the same number (approx. 16).
However with PHP 5.4, the second (and subsequent) curl commands print the size
of the original uncompressed output (31).
[2012-04-14 23:56:24] adunar at gmail dot com
I am experiencing the same problem, using PHP 5.4.0 with the PHP-FPM
SAPI on Ubuntu.
zlib appears to only compress the output for the first request from
a particular worker process.
With the default settings it takes a few refreshes to run into the bug.
To reproduce immediately, set pm.start_servers = 1 in php-fpm.conf.
Afterwards, running /etc/init.d/php5-fpm reload allows another
request to be compressed before it stops working again.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60761
--
Edit this bug report at https://bugs.php.net/bug.php?id=60761edit=1
Bug #60761 [Com]: zlib.output_compression fails on refresh
Edit report at https://bugs.php.net/bug.php?id=60761edit=1 ID: 60761 Comment by: pierre at archlinux dot de Reported by:valentiny510 at yahoo dot es Summary:zlib.output_compression fails on refresh Status: Assigned Type: Bug Package:*Compression related Operating System: xp PHP Version:5.4.0RC5 Assigned To:mattficken Block user comment: N Private report: N New Comment: I can still reproduce this bug on Arch Linux using PHP 5.4.3 (php-fpm). Which additional information do you guys need? It seems pretty obvious to me. Previous Comments: [2012-04-15 02:27:15] adunar at gmail dot com The bug also happens with the cli-server SAPI (both Windows and Ubuntu). Here are a few (bash) commands that will reproduce this bug (assumes zlib.output_compression = On in your php.ini) echo ?php echo '---'; bug.php php -S 127.0.0.1: /dev/null 21 curl --header Accept-Encoding: gzip http://localhost:/bug.php 2 /dev/null | wc -m curl --header Accept-Encoding: gzip http://localhost:/bug.php 2 /dev/null | wc -m # fg, then ctrl+c to kill php -S If output_compression is working correctly, the two curl commands should print the same number (approx. 16). However with PHP 5.4, the second (and subsequent) curl commands print the size of the original uncompressed output (31). [2012-04-14 23:56:24] adunar at gmail dot com I am experiencing the same problem, using PHP 5.4.0 with the PHP-FPM SAPI on Ubuntu. zlib appears to only compress the output for the first request from a particular worker process. With the default settings it takes a few refreshes to run into the bug. To reproduce immediately, set pm.start_servers = 1 in php-fpm.conf. Afterwards, running /etc/init.d/php5-fpm reload allows another request to be compressed before it stops working again. [2012-04-09 12:50:09] paj...@php.net Matt, please take a look at this bug. [2012-03-29 04:23:46] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=bcfcfb2fc5f358ebfdc76a773b20b3fc056b20c0 Log: Fix bug #61519 test fails, should pass - ext/zlib/tests/bug60761.phpt [2012-03-27 16:26:35] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=bcfcfb2fc5f358ebfdc76a773b20b3fc056b20c0 Log: Fix bug #61519 test fails, should pass - ext/zlib/tests/bug60761.phpt 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=60761 -- Edit this bug report at https://bugs.php.net/bug.php?id=60761edit=1
Bug #60986 [Com]: pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info'
Edit report at https://bugs.php.net/bug.php?id=60986edit=1 ID: 60986 Comment by: pierre at archlinux dot de Reported by:j0inty at stollfuss dot net Summary:pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info' Status: Open Type: Bug Package:PCRE related Operating System: Linux PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: This also affects the 5.3 branch. The problem is the use of the pcre_info function which was deprecated and repalced by pcre_fullinfo 12 years ago. This function was now removed with pcre 8.30. I only found one real use of it and some exports; I have attached a patch that might work. Note the I have no idea about php internals; so this might be entirely stupid or dangerous. Also note that you might not be able to compile the apache module as apache itself seems also to be incompatible with pcre 8.30 Greetings, Pierre Previous Comments: [2012-02-06 10:06:44] j0inty at stollfuss dot net Description: Hi, If you try to compile the current RC7 of php 5.4.0 the Linker crash with the following message. ext/pcre/php_pcre.o: In function `pcre_get_compiled_regex_cache': php_pcre.c:(.text+0xb8f): undefined reference to `pcre_info' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Fehler 1 The reason is the new libpcre-8.30 which was today in my update list. dev-libs/libpcre-8.30-r2 You can find a full build.log posted on http://paste.pocoo.org/show/546652/ . regards j0inty -- Edit this bug report at https://bugs.php.net/bug.php?id=60986edit=1
Bug #46025 [Com]: zend_bailout can deadlock APC
Edit report at https://bugs.php.net/bug.php?id=46025edit=1 ID: 46025 Comment by: pierre at archlinux dot de 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: This issue is still reproducable using php-fpm and PHP 5.3.6 with APC 3.1.9 Previous Comments: [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. [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. 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
#46025 [Com]: zend_bailout can deadlock APC
ID: 46025
Comment by: pierre at archlinux dot de
Reported By: askalski at gmail dot com
Status: Suspended
Bug Type: Reproducible crash
Operating System: redhat
PHP Version: 5.2.6
New Comment:
This problem is still reproducable with version 5.2.9. The cgi version
is affected, too (as expected).
Previous Comments:
[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
[2008-09-08 21:16:43] j...@php.net
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;
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=46025edit=1
