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
