|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #62266 Custom extension segfaults during xmlParseFile with FPM SAPI
Submitted: 2012-06-08 17:45 UTC Modified: 2012-06-12 15:09 UTC
From: lance dot lovette at gmail dot com Assigned: cataphract
Status: Assigned Package: XML related
PHP Version: 5.4Git-2012-06-08 (snap) OS: CentOS release 6.2 (Final)
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-06-08 17:45 UTC] lance dot lovette at gmail dot com
I have a custom extension that has been in use since 2001. When I upgraded to PHP 
5.4 it caused php-fpm to segfault. The extension uses xmlParseFile to load an XML 
configuration file in MINIT. The CLI build of PHP does NOT segfault and functions 
as expected.

Test script:
I created a trivial extension that calls xmlParseFile in MINIT:

Expected result:
I expect xmlParseFile to succeed.

Actual result:
Output from configure, a gdb backtrace and a list of modules 
and phpinfo when the crashing extension is disabled:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-08 17:56 UTC]
I'll take a look as this was very likely caused by a change I made.
 [2012-06-08 17:56 UTC]
-Assigned To: +Assigned To: cataphract
 [2012-06-09 16:32 UTC]
Automatic comment on behalf of cataphract
Log: Fix bug #62266
 [2012-06-09 16:33 UTC]
Please try using this snapshot:
For Windows:

 [2012-06-09 16:33 UTC]
-Status: Assigned +Status: Feedback
 [2012-06-11 20:15 UTC] lance dot lovette at gmail dot com
-Status: Feedback +Status: Assigned
 [2012-06-11 20:15 UTC] lance dot lovette at gmail dot com
I expected that change to resolve the issue, but it did not. It's now skipping the 
call to _php_libxml_external_entity_loader but the stack trace is otherwise the 
 [2012-06-11 20:36 UTC]
Ah. Then this was caused by d8bddb9. xmlParserInputBufferCreateFilenameDefault() et al. are called purposely on MINIT (before: RINIT) and your extension is loading after libxml.

This can be fixed in two ways. We can either call the original handler from the custom handler if the modules are not initialized, like we now do on _php_libxml_pre_ext_ent_loader, or we can try to set the custom handlers lazily and once on RINIT (not complicated since we don't have to worry about threaded SAPIs, which always do initialization on every RINIT).

Both options are ok for MINIT. The first option has the advantage it has predictable behavior on RINIT (whether your extension is request activated before or after the libxml ext, you don't get the custom handlers), but it may have BC impact (some modules may have been relying on the custom handlers and on being loaded after libxml -- which I think they can guarantee if the declare a dependency on the libxml module).
 [2012-06-12 15:09 UTC] lance dot lovette at gmail dot com
I didn't realize 5.1 added module dependency checks so I updated the source to 
include them ( ).

It seems to me that all the custom handlers (php_libxml_error_handler, 
php_libxml_output_buffer_create_filename) should check for module activation 
same as _php_libxml_pre_ext_ent_loader. Of course, setting the custom handlers 
lazily in the first request would prevent the need for all those checks. As for 
BC, how could this be working for any other extension?

BTW, do you know exactly what is causing the root issue in the streams IO 
functions and why zend_register_resource segfaults when updating the hash table? 
Are streams not initialized until after module activation?
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Wed Apr 16 18:01:53 2014 UTC