Edit report at https://bugs.php.net/bug.php?id=61557&edit=1
ID: 61557
Updated by: dmitry@php.net
Reported by: ondrej@php.net
Summary: Crasher (SIGSEGV) bug in tt-rss backend.php
-Status: Open
+Status: Assigned
Type: Bug
Package: *XML functions
Operating System: Linux i386
PHP Version: 5.4.0
-Assigned To:
+Assigned To: dmitry
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2012-08-22 15:16:14] f dot ruske at gmail dot com
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.
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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