Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: f dot ruske at gmail dot com Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: We had the same problem on a highly loaded server running 5.4.x. / Redhat 2/3 Segmentation Faults on Requests using XML- functions after the first request. Now running 5.4.6 with the patch provided here and the problems are gone. Previous Comments: [2012-08-07 20:05:50] niki at guldbrand dot net Is there any status update on getting this fixed/included ? As I'm also hitting this issue on ArchLinux x86_64 with php 5.4.5. And the patch attached to this bug works nicely here too. /Niki [2012-05-14 12:38:15] bugs-php at antipoul dot fr OK, I've applied this patch on top of all others patches from Debian testing package. After 4h07 compiling (yes, I have a small Via C7 ;) ), I got the package working. Final result: the patch solves the problem. I'm happy. Many thanks to you! [2012-05-11 21:52:38] i dot am dot jack dot mail at gmail dot com I've also experienced this problem after switching to 5.4. Looked into it, and here's what I was able to find : This only happens to CGI/FPM. The first time I trigger a request it works, the second time it crashes. Explains why it appears to work sometimes and others not : it works only once per process. Then it segfaults, a new one is started, repeat. This seems to be linked to the use of libxml_use_internal_errors (w/ TRUE). Apparently the first time it will set an internal error handler in PHP, which remains set after processing the request is done. Then, when another request is processed and libxml_use_internal_errors hasn't been called, that handler can be triggered, only the memory has been reset, resulting in the segfault. As far as I can tell, seems this was introduced with d8bddb9665637d96f20dc4a2ae5668ba376f3b17 which made it that CGI/FPM would not setup/reset libxml callbacks on each request but only once. Only it also included the callback for "structured errors," which shouldn't be affected/should still be reset on each new request. I'll attach a patch that should fix this, resetting the callback for each request. Also, I'm not sure/haven't looked into it, but looking at the backtrace I believe that https://bugs.php.net/bug.php?id=61325 might be another manifestation of the same problem. [2012-05-06 20:11:09] j dot nespolo at gmail dot com Hi, I am affected by the same bug, although I wasn't able to generate a backtrace (app running on an openvz container). My setup is as follows: - Debian Sid (fully updated as of 2012/05/06) - latest tt-rss master (last updated on 2012/05/06), https://github.com/gothfox/Tiny-Tiny-RSS - mysql-server 5.1.62-1 - lighttpd 1.4.30-1 with the following modules enabled: auth, fastcgi, fastcgi-php - php 5.4.2-1 The feed reader displays the headings, but shortly after they disappear. The time they survive is quite variable. When this happens, lighttpd's log then says: 2012-05-06 20:06:46: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 20184 socket: unix:/tmp/php.socket-0 2012-05-06 20:06:46: (mod_fastcgi.c.3352) response not received, request sent: 1381 on socket: unix:/tmp/php.socket-0 for /tt-rss/backend.php?, closing connection Thanks a lot, J [2012-04-01 16:38:25] bugs-php at antipoul dot fr Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. 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=61557 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: niki at guldbrand dot net Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Is there any status update on getting this fixed/included ? As I'm also hitting this issue on ArchLinux x86_64 with php 5.4.5. And the patch attached to this bug works nicely here too. /Niki Previous Comments: [2012-05-14 12:38:15] bugs-php at antipoul dot fr OK, I've applied this patch on top of all others patches from Debian testing package. After 4h07 compiling (yes, I have a small Via C7 ;) ), I got the package working. Final result: the patch solves the problem. I'm happy. Many thanks to you! [2012-05-11 21:52:38] i dot am dot jack dot mail at gmail dot com I've also experienced this problem after switching to 5.4. Looked into it, and here's what I was able to find : This only happens to CGI/FPM. The first time I trigger a request it works, the second time it crashes. Explains why it appears to work sometimes and others not : it works only once per process. Then it segfaults, a new one is started, repeat. This seems to be linked to the use of libxml_use_internal_errors (w/ TRUE). Apparently the first time it will set an internal error handler in PHP, which remains set after processing the request is done. Then, when another request is processed and libxml_use_internal_errors hasn't been called, that handler can be triggered, only the memory has been reset, resulting in the segfault. As far as I can tell, seems this was introduced with d8bddb9665637d96f20dc4a2ae5668ba376f3b17 which made it that CGI/FPM would not setup/reset libxml callbacks on each request but only once. Only it also included the callback for "structured errors," which shouldn't be affected/should still be reset on each new request. I'll attach a patch that should fix this, resetting the callback for each request. Also, I'm not sure/haven't looked into it, but looking at the backtrace I believe that https://bugs.php.net/bug.php?id=61325 might be another manifestation of the same problem. [2012-05-06 20:11:09] j dot nespolo at gmail dot com Hi, I am affected by the same bug, although I wasn't able to generate a backtrace (app running on an openvz container). My setup is as follows: - Debian Sid (fully updated as of 2012/05/06) - latest tt-rss master (last updated on 2012/05/06), https://github.com/gothfox/Tiny-Tiny-RSS - mysql-server 5.1.62-1 - lighttpd 1.4.30-1 with the following modules enabled: auth, fastcgi, fastcgi-php - php 5.4.2-1 The feed reader displays the headings, but shortly after they disappear. The time they survive is quite variable. When this happens, lighttpd's log then says: 2012-05-06 20:06:46: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 20184 socket: unix:/tmp/php.socket-0 2012-05-06 20:06:46: (mod_fastcgi.c.3352) response not received, request sent: 1381 on socket: unix:/tmp/php.socket-0 for /tt-rss/backend.php?, closing connection Thanks a lot, J [2012-04-01 16:38:25] bugs-php at antipoul dot fr Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. [2012-03-30 06:46:28] reeze dot xia at gmaill dot com I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. 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=61557 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: bugs-php at antipoul dot fr Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: OK, I've applied this patch on top of all others patches from Debian testing package. After 4h07 compiling (yes, I have a small Via C7 ;) ), I got the package working. Final result: the patch solves the problem. I'm happy. Many thanks to you! Previous Comments: [2012-05-11 21:52:38] i dot am dot jack dot mail at gmail dot com I've also experienced this problem after switching to 5.4. Looked into it, and here's what I was able to find : This only happens to CGI/FPM. The first time I trigger a request it works, the second time it crashes. Explains why it appears to work sometimes and others not : it works only once per process. Then it segfaults, a new one is started, repeat. This seems to be linked to the use of libxml_use_internal_errors (w/ TRUE). Apparently the first time it will set an internal error handler in PHP, which remains set after processing the request is done. Then, when another request is processed and libxml_use_internal_errors hasn't been called, that handler can be triggered, only the memory has been reset, resulting in the segfault. As far as I can tell, seems this was introduced with d8bddb9665637d96f20dc4a2ae5668ba376f3b17 which made it that CGI/FPM would not setup/reset libxml callbacks on each request but only once. Only it also included the callback for "structured errors," which shouldn't be affected/should still be reset on each new request. I'll attach a patch that should fix this, resetting the callback for each request. Also, I'm not sure/haven't looked into it, but looking at the backtrace I believe that https://bugs.php.net/bug.php?id=61325 might be another manifestation of the same problem. [2012-05-06 20:11:09] j dot nespolo at gmail dot com Hi, I am affected by the same bug, although I wasn't able to generate a backtrace (app running on an openvz container). My setup is as follows: - Debian Sid (fully updated as of 2012/05/06) - latest tt-rss master (last updated on 2012/05/06), https://github.com/gothfox/Tiny-Tiny-RSS - mysql-server 5.1.62-1 - lighttpd 1.4.30-1 with the following modules enabled: auth, fastcgi, fastcgi-php - php 5.4.2-1 The feed reader displays the headings, but shortly after they disappear. The time they survive is quite variable. When this happens, lighttpd's log then says: 2012-05-06 20:06:46: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 20184 socket: unix:/tmp/php.socket-0 2012-05-06 20:06:46: (mod_fastcgi.c.3352) response not received, request sent: 1381 on socket: unix:/tmp/php.socket-0 for /tt-rss/backend.php?, closing connection Thanks a lot, J [2012-04-01 16:38:25] bugs-php at antipoul dot fr Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. [2012-03-30 06:46:28] reeze dot xia at gmaill dot com I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. [2012-03-29 20:27:47] ond...@php.net Description: Long description can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666200 The trace ends with: #0 zend_llist_add_element (l=0xbf96013c, element=0x9e961d0) at /build/buildd-php5_5.4.0-3-i386-2XGvJx/php5-5.4.0/Zend/zend_llist.c:39 Expected result: Not crash Actual result: -- http://bugs.debian.org/cgi-bin/bugreport.cgi? msg=45;filename=backtrace2;att=1;bug=666200 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: i dot am dot jack dot mail at gmail dot com Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I've also experienced this problem after switching to 5.4. Looked into it, and here's what I was able to find : This only happens to CGI/FPM. The first time I trigger a request it works, the second time it crashes. Explains why it appears to work sometimes and others not : it works only once per process. Then it segfaults, a new one is started, repeat. This seems to be linked to the use of libxml_use_internal_errors (w/ TRUE). Apparently the first time it will set an internal error handler in PHP, which remains set after processing the request is done. Then, when another request is processed and libxml_use_internal_errors hasn't been called, that handler can be triggered, only the memory has been reset, resulting in the segfault. As far as I can tell, seems this was introduced with d8bddb9665637d96f20dc4a2ae5668ba376f3b17 which made it that CGI/FPM would not setup/reset libxml callbacks on each request but only once. Only it also included the callback for "structured errors," which shouldn't be affected/should still be reset on each new request. I'll attach a patch that should fix this, resetting the callback for each request. Also, I'm not sure/haven't looked into it, but looking at the backtrace I believe that https://bugs.php.net/bug.php?id=61325 might be another manifestation of the same problem. Previous Comments: [2012-05-06 20:11:09] j dot nespolo at gmail dot com Hi, I am affected by the same bug, although I wasn't able to generate a backtrace (app running on an openvz container). My setup is as follows: - Debian Sid (fully updated as of 2012/05/06) - latest tt-rss master (last updated on 2012/05/06), https://github.com/gothfox/Tiny-Tiny-RSS - mysql-server 5.1.62-1 - lighttpd 1.4.30-1 with the following modules enabled: auth, fastcgi, fastcgi-php - php 5.4.2-1 The feed reader displays the headings, but shortly after they disappear. The time they survive is quite variable. When this happens, lighttpd's log then says: 2012-05-06 20:06:46: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 20184 socket: unix:/tmp/php.socket-0 2012-05-06 20:06:46: (mod_fastcgi.c.3352) response not received, request sent: 1381 on socket: unix:/tmp/php.socket-0 for /tt-rss/backend.php?, closing connection Thanks a lot, J [2012-04-01 16:38:25] bugs-php at antipoul dot fr Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. [2012-03-30 06:46:28] reeze dot xia at gmaill dot com I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. [2012-03-29 20:27:47] ond...@php.net Description: Long description can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666200 The trace ends with: #0 zend_llist_add_element (l=0xbf96013c, element=0x9e961d0) at /build/buildd-php5_5.4.0-3-i386-2XGvJx/php5-5.4.0/Zend/zend_llist.c:39 Expected result: Not crash Actual result: -- http://bugs.debian.org/cgi-bin/bugreport.cgi? msg=45;filename=backtrace2;att=1;bug=666200 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: j dot nespolo at gmail dot com Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Hi, I am affected by the same bug, although I wasn't able to generate a backtrace (app running on an openvz container). My setup is as follows: - Debian Sid (fully updated as of 2012/05/06) - latest tt-rss master (last updated on 2012/05/06), https://github.com/gothfox/Tiny-Tiny-RSS - mysql-server 5.1.62-1 - lighttpd 1.4.30-1 with the following modules enabled: auth, fastcgi, fastcgi-php - php 5.4.2-1 The feed reader displays the headings, but shortly after they disappear. The time they survive is quite variable. When this happens, lighttpd's log then says: 2012-05-06 20:06:46: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 20184 socket: unix:/tmp/php.socket-0 2012-05-06 20:06:46: (mod_fastcgi.c.3352) response not received, request sent: 1381 on socket: unix:/tmp/php.socket-0 for /tt-rss/backend.php?, closing connection Thanks a lot, J Previous Comments: [2012-04-01 16:38:25] bugs-php at antipoul dot fr Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. [2012-03-30 06:46:28] reeze dot xia at gmaill dot com I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. [2012-03-29 20:27:47] ond...@php.net Description: Long description can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666200 The trace ends with: #0 zend_llist_add_element (l=0xbf96013c, element=0x9e961d0) at /build/buildd-php5_5.4.0-3-i386-2XGvJx/php5-5.4.0/Zend/zend_llist.c:39 Expected result: Not crash Actual result: -- http://bugs.debian.org/cgi-bin/bugreport.cgi? msg=45;filename=backtrace2;att=1;bug=666200 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: bugs-php at antipoul dot fr Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. Previous Comments: [2012-03-30 06:46:28] reeze dot xia at gmaill dot com I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. [2012-03-29 20:27:47] ond...@php.net Description: Long description can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666200 The trace ends with: #0 zend_llist_add_element (l=0xbf96013c, element=0x9e961d0) at /build/buildd-php5_5.4.0-3-i386-2XGvJx/php5-5.4.0/Zend/zend_llist.c:39 Expected result: Not crash Actual result: -- http://bugs.debian.org/cgi-bin/bugreport.cgi? msg=45;filename=backtrace2;att=1;bug=666200 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557&edit=1 ID: 61557 Comment by: reeze dot xia at gmaill dot com Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. Previous Comments: [2012-03-29 20:27:47] ond...@php.net Description: Long description can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666200 The trace ends with: #0 zend_llist_add_element (l=0xbf96013c, element=0x9e961d0) at /build/buildd-php5_5.4.0-3-i386-2XGvJx/php5-5.4.0/Zend/zend_llist.c:39 Expected result: Not crash Actual result: -- http://bugs.debian.org/cgi-bin/bugreport.cgi? msg=45;filename=backtrace2;att=1;bug=666200 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557&edit=1
