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
