Bug 195562 - sysutils/php56-fileinfo 5.6.3 crashes apache
Summary: sysutils/php56-fileinfo 5.6.3 crashes apache
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Alex Dupre
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-01 20:42 UTC by gbromov
Modified: 2019-09-11 10:27 UTC (History)
5 users (show)

See Also:


Attachments
Disable libmagic on subversion (367 bytes, patch)
2019-09-11 10:27 UTC, info
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description gbromov 2014-12-01 20:42:56 UTC
Overview:

On amd64 version, when using php56-fileinfo extension, and apache have both mod_dav_svn and mod_php5 modules loaded, it crashes with Segmentation fault (11).

Steps to Reproduce: 

1. Install fresh amd64 version of 10.1-RELEASE, apache24,  mod_dav_svn, mod_php56, php56-fileinfo

2. Write a simple php script in apache DocumentRoot
<?php
$fi = new finfo(FILEINFO_MIME);
echo $fi->file('/etc/rc.conf');
?>

3. Open it in a browser.

Actual Results:

Empty page (No data received) is shown, and httpd.core is saved on the server.

Additional Information:

* If I comment out

LoadModule dav_svn_module     libexec/apache24/mod_dav_svn.so
LoadModule authz_svn_module   libexec/apache24/mod_authz_svn.so

entries in httpd.conf the page opens successfully.

* Even when

extension=fileinfo.so

is the only entry in /usr/local/etc/php/extensions.ini, it doesn't seem to makes any difference

* It seems to be working fine on i386 system.

* Stack trace from the coredump file:
#0  0x0000000801c1f40c in sbrk () from /lib/libc.so.7
#1  0x0000000801c1f7af in sbrk () from /lib/libc.so.7
#2  0x0000000801c2adf5 in free () from /lib/libc.so.7
#3  0x000000080755a953 in magic_version () from /usr/lib/libmagic.so.4
#4  0x00000008089dea4b in finfo_objects_free () from /usr/local/lib/php/20131226-zts-debug/fileinfo.so
#5  0x0000000807e04b80 in zend_objects_store_del_ref_by_handle_ex (handle=1, handlers=0x808ead3f0, tsrm_ls=0x8028cba80) at zend_objects_API.c:226
#6  0x0000000807e04709 in zend_objects_store_del_ref (zobject=0x8029b7568, tsrm_ls=0x8028cba80) at zend_objects_API.c:178
#7  0x0000000807dafda0 in _zval_dtor_func (zvalue=0x8029b7568, __zend_filename=0x807f165e1 "Zend/zend_execute.h", __zend_lineno=79) at zend_variables.c:57
#8  0x0000000807d9b40c in _zval_dtor (zvalue=0x8029b7568, __zend_filename=0x807f165e1 "Zend/zend_execute.h", __zend_lineno=79) at zend_variables.h:35
#9  0x0000000807d970eb in i_zval_ptr_dtor (zval_ptr=0x8029b7568, __zend_filename=0x807f1761f "/usr/ports/www/mod_php56/work/php-5.6.3/Zend/zend_variables.c",
    __zend_lineno=188, tsrm_ls=0x8028cba80) at zend_execute.h:79
#10 0x0000000807d96a57 in _zval_ptr_dtor (zval_ptr=0x8029b7908, __zend_filename=0x807f1761f "/usr/ports/www/mod_php56/work/php-5.6.3/Zend/zend_variables.c",
    __zend_lineno=188) at zend_execute_API.c:427
#11 0x0000000807db01f1 in _zval_ptr_dtor_wrapper (zval_ptr=0x8029b7908) at zend_variables.c:188
#12 0x0000000807dcd551 in i_zend_hash_bucket_delete (ht=0x8028fa768, p=0x8029b78f0) at zend_hash.c:182
#13 0x0000000807dcda9d in zend_hash_bucket_delete (ht=0x8028fa768, p=0x8029b78f0) at zend_hash.c:192
#14 0x0000000807dce13d in zend_hash_reverse_apply (ht=0x8028fa768, apply_func=0x807d95ed0 <zval_call_destructor>, tsrm_ls=0x8028cba80) at zend_hash.c:733
#15 0x0000000807d95dcf in shutdown_destructors (tsrm_ls=0x8028cba80) at zend_execute_API.c:217
#16 0x0000000807db5446 in zend_call_destructors (tsrm_ls=0x8028cba80) at zend.c:947
#17 0x0000000807cd6e4c in php_request_shutdown (dummy=0x0) at main.c:1826
#18 0x0000000807e99272 in php_apache_request_dtor (r=0x802b4e0a0, tsrm_ls=0x8028cba80) at sapi_apache2.c:507
#19 0x0000000807e97c66 in php_handler (r=0x802b4e0a0) at sapi_apache2.c:679
#20 0x000000000044f8c7 in ap_invoke_handler ()
#21 0x0000000000463fef in ap_process_async_request ()
#22 0x0000000000464099 in ap_process_request ()
#23 0x0000000000460f81 in ap_expr_yyrealloc ()
#24 0x0000000000459956 in ap_process_connection ()
#25 0x000000000046b233 in ap_set_etag ()
#26 0x000000000046ade1 in ap_set_etag ()
#27 0x000000000046a6be in ap_set_etag ()
#28 0x00000000004365ad in ap_run_mpm ()
#29 0x000000000042fb8f in main ()
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-12-02 21:02:39 UTC
Fix Summary and assign.
Comment 2 Willem Jan Withagen 2015-09-17 07:32:45 UTC
I'm running php55, and ran into the same problem.
Removing the dav_svn_module is the solution for this.

Probably the dav_svn_module needs to be rebuild as well, to be compatible with the newly installed mod_php core.

This is in the mod_dav_svn package.

But doing so did not resolve the issue.
So there is a real mismatch between mod_fileinfo and mod_dav_svn
Comment 3 Jan Strobl 2016-03-17 13:22:09 UTC
I'm just facing the same problem, in latest ports version (i.e. php56-5.6.19). Googling led me to this:
https://bugs.php.net/bug.php?id=66095

It seems to be the same problem, the bundled libmagic conflicts with system one. 

The mechanism and also suggested patch is described there. As this could be relevant to only OSs with system-included libmagic (like FreeBSD) and not for majority, maybe we shouldn't wait for official PHP correction and create a local patch in ports?
Comment 4 Walter Schwarzenfeld freebsd_triage 2018-01-12 02:44:20 UTC
Maintainer feedback?
Comment 5 info 2019-09-11 10:27:27 UTC
Created attachment 207376 [details]
Disable libmagic on subversion

I do believe patching php should be the better way forward, how-ever with a lack of alternatives...

Quirk (PoC) of disabling libmagic on subversion will cause the error to go away. Since libmagic is marked optional [1] there should be no harm disabling it. 

[1] https://svn.apache.org/repos/asf/subversion/trunk/INSTALL