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: ondrej@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] ondrej@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