Bug #62266 [Asn->Csd]: Custom extension segfaults during xmlParseFile with FPM SAPI

From: Date: Tue, 07 Oct 2014 23:24:25 +0000
Subject: Bug #62266 [Asn->Csd]: Custom extension segfaults during xmlParseFile with FPM SAPI
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-187934@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=62266&edit=1

 ID:                 62266
 Updated by:         stas@php.net
 Reported by:        lance dot lovette at gmail dot com
 Summary:            Custom extension segfaults during xmlParseFile with
                     FPM SAPI
-Status:             Assigned
+Status:             Closed
 Type:               Bug
 Package:            XML related
 Operating System:   CentOS release 6.2 (Final)
 PHP Version:        5.4Git-2012-06-08 (snap)
 Assigned To:        cataphract
 Block user comment: N
 Private report:     N

 New Comment:

Automatic comment on behalf of cataphract
Revision: http://git.php.net/?p=php-src-security.git;a=commit;h=503358c1797e0f7b05fb49f22dd44bc7f517069f
Log: Fix bug #62266


Previous Comments:
------------------------------------------------------------------------
[2012-06-12 15:09:49] 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 (https://gist.github.com/2896852 ).

It seems to me that all the custom handlers (php_libxml_error_handler, 
php_libxml_input_buffer_create_filename, 
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?

------------------------------------------------------------------------
[2012-06-11 20:36:40] cataphract@php.net

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-11 20:15:02] 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 
same.

------------------------------------------------------------------------
[2012-06-09 16:33:00] cataphract@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/



------------------------------------------------------------------------
[2012-06-09 16:32:31] cataphract@php.net

Automatic comment on behalf of cataphract
Revision: http://git.php.net/?p=php-src.git;a=commit;h=503358c1797e0f7b05fb49f22dd44bc7f517069f
Log: Fix bug #62266

------------------------------------------------------------------------


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=62266


--
Edit this bug report at https://bugs.php.net/bug.php?id=62266&edit=1


Thread (7 messages)

« previous php.bugs (#187934) next »