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.

Hi,

I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue.

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

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.

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!

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

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.

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.