Since a while (can't remember with which apache or php5 it started) I was actually unable to use the roundcube webmail client for uploading attachments. After searching for the actual reason why this is the case I found out that roundcube is actually using the "fileinfo" php extension to find out the actual mime-type of a file when uploading it to its interface. After some more searching and wading through apache log files and roundcube/php5 source code I identified that the actual apache2 instance crashes with a segfault like the following in the apache error_log: -- cut here -- [Sun Apr 28 17:01:09.309285 2013] [core:notice] [pid 32606:tid 140214578493440] AH00052: child pid 32611 exit signal Segmentation fault (11) -- cut here -- After some more debugging and starting apache using gdb it turns out that I see the following backtrace: -- cut here -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f84167fc700 (LWP 32480)] 0x00007f842639c309 in file_check_mem () from /usr/lib64/apache2/modules/libphp5.so (gdb) bt #0 0x00007f842639c309 in file_check_mem () from /usr/lib64/apache2/modules/libphp5.so #1 0x00007f842639e58c in ?? () from /usr/lib64/apache2/modules/libphp5.so #2 0x00007f842639e4d6 in file_softmagic () from /usr/lib64/apache2/modules/libphp5.so #3 0x00007f842639bcd2 in file_buffer () from /usr/lib64/apache2/modules/libphp5.so #4 0x00007f842639d25c in ?? () from /usr/lib64/apache2/modules/libphp5.so #5 0x00007f842639d005 in magic_stream () from /usr/lib64/apache2/modules/libphp5.so #6 0x00007f842638f396 in ?? () from /usr/lib64/apache2/modules/libphp5.so #7 0x00007f842638f6e6 in zif_mime_content_type () from /usr/lib64/apache2/modules/libphp5.so #8 0x00007f84268161ae in ?? () from /usr/lib64/apache2/modules/libphp5.so #9 0x00007f842681b979 in ?? () from /usr/lib64/apache2/modules/libphp5.so #10 0x00007f842681510f in execute () from /usr/lib64/apache2/modules/libphp5.so #11 0x00007f84267cdbef in zend_execute_scripts () from /usr/lib64/apache2/modules/libphp5.so #12 0x00007f842670b829 in php_execute_script () from /usr/lib64/apache2/modules/libphp5.so #13 0x00007f842689251b in ?? () from /usr/lib64/apache2/modules/libphp5.so #14 0x000000000044eea6 in ap_invoke_handler () #15 0x00000000004646ea in ap_process_async_request () #16 0x000000000046474f in ap_process_request () #17 0x00000000004612bb in ?? () #18 0x0000000000459198 in ap_process_connection () #19 0x000000000046e3aa in ?? () #20 0x00007f842f7dbf3b in start_thread () from /lib64/libpthread.so.0 -- cut here -- I then generated a test php script like: -- cut here -- <?php $finfo = finfo_open(FILEINFO_MIME); if($finfo) { $mime_type = finfo_file($finfo, "/tmp/blah.txt"); echo $mime_type . "\n"; finfo_close($finfo); } ?> -- cut here -- and also just using @mime_content_type() function of php: -- cut here -- <?php $mime_type = @mime_content_type("/tmp/blah.txt"); echo $mime_type . "\n"; ?> -- cut here -- both script instantly crashes apache2 here as soon as I generate a /tmp/blah.txt text file. Interesting enough, when executing these scripts from command-line rather than via apache2 doesn't crash. So it seems the bug only exists when executing these scripts via apache. After enabling some more debugging the following message pops up in the apache error_log: -- cut here -- /var/tmp/portage/dev-lang/php-5.4.14/work/sapis-build/apache2/ext/fileinfo/libmagic/funcs.c(315) : Block 0x7f493c92e310 status: Invalid pointer: ((thread_id=0x00000000) != (expected=0x51173700)) -- cut here -- This seems to clearly point out that something is not working as expected. So let me summarize: 1) both above example php scripts crash apache as soon as there exists a /tmp/blah.txt file 2) the crash only happens when executed via apache. cmd-line execution of the php scripts work fine and return the correct mime-type 3) the crash log seems to point out that the fileinfo module seems to be involved. Question now: Can anyone else reproduce the problem? Here I have an uptodate gentoo system. see emerge --info attached. -- cut here -- Portage 2.1.11.62 (default/linux/amd64/13.0, gcc-4.7.2, glibc-2.17, 3.8.10-gentoo x86_64) ================================================================= System uname: Linux-3.8.10-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E3-1230_V2_@_3.30GHz-with-gentoo-2.2 KiB Mem: 8220504 total, 2628260 free KiB Swap: 8384444 total, 8373572 free Timestamp of tree: Sun, 28 Apr 2013 07:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.7.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.8 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo x-portage Installed sets: @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-pipe -O3 -march=native -mtune=native -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind /var/www/localhost/htdocs/roundcube" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-pipe -O3 -march=native -mtune=native -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl amd64 apache2 bash-completion berkdb bzip2 chroot cli cracklib crypt cxx dri fortran gdbm gif gnutls gpm iconv idn iproute2 ipv6 jbig jpeg jpeg2k logrotate mmx modules mpeg mudflap multilib ncurses nls nptl openmp pam pcre png readline session sse sse2 ssl tcpd threads tiff unicode urandom vim-syntax zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias authn_core authz_core unixd socache_shmcb" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="mdraid" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5 php5-4 php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.2" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS -- cut here --
Just an additional comment/note after having debugged the situation even further. When reconfiguring apache and php for fpm (fastcgi) support and then trying to run the above mentioned php scripts everything seems to work fine as well and they do not crash apache anymore. So somehow the problem seem to be related to using mod_php with apache.
I can confirm this issue, on my system I can reproduce it with the example
Some further comments on how I managed to work around the problem by switching apache2 from mod_php to php-fpm usage: 1) edited /etc/portage/package.use and added use flag "fpm" to dev-lang/php 2) remerged php by "emerge php" 3) installed fastcgi module via "emerge mod_fastcgi_handler" 4) edited /etc/conf.d/apache2 added "-D FASTCGI_HANDLER" and removed "-D PHP5" 5) edited /etc/php/fpm-php5.4/php-fpm.conf and changed "listen" statement to use a socket via "listen = /var/run/php-fpm.sock" 6) edited /etc/apache2/modules.d/20_mod_fastcgi_handler.conf and added AddHandler fcgi:/var/run/php-fpm.sock .php .php5 .phtml .phps DirectoryIndex index.php index.phtml at the end of the <IfDefine> 7) restarted apache and started php-fpm After switching to php-fpm using this procedure the apache crashes are instantly gone and my example scripts work as expected. Thus, I highly suspect mod_php being the cultrip.
Did you create an upstream bug at bugs.php.net yet? If not, please do so and reference the bug here.
I reported this bug on php.net, which might be related. https://bugs.php.net/bug.php?id=64836 Sadly I cannot reproduce it anymore...
I can confirm that downgrading sys-apps/file to 5.11 and then upgrade again to current version (5.12-r1) solves the issue. This is documented in the upstream bug by R Biegel. Sadly I was too hasty in trying out to see whether it could also be fixed by only re-emerging the current version of sys-apps/file. Anyway, this seems to be the workaround.
I can confirm , that the problem still exists (also with the newer sys-apps/file-5.15). Also a downgrade of sys-apps/file does not help every time. The problem also exists with a combination of latest stable apache2 and php-5.5.7 (amd64).
Small update: this code works: -- cut here -- <?php $finfo = finfo_open(FILEINFO_MIME); if($finfo) { $mime_type = finfo_file($finfo, "/tmp/blah.txt"); echo $mime_type . "\n"; finfo_close($finfo); } ?> -- cut here -- but the following code produces a crash (segfault): -- cut here -- <?php $mime_type = @mime_content_type("/tmp/blah.txt"); echo $mime_type . "\n"; ?> -- cut here --
I removed " -D SVN -D DAV" from /etc/conf.d/apache2 and now mediawiki no longer segfaults apache. I'm using the following versions of stuff people mention on a hardened 64-bit system: sys-apps/file-5.1.7 www-servers/apache-2.2.27 dev-lang/php-5.5.12 I don't mind since I'm not really using subversion anymore. This is just a very weird interaction bug.
Wow ... what a strange behavior. I have only removed the SVN module from apache conf. Now my mediawiki also comes back. Thanks for this hint! Possible someone figure out the root cause of such problem.
I've run into this bug, or something very similar today. I upgraded our mediawiki to 1.23.1, and lost the ability to load CSS (at the very least). Turns out that Apache was crashing when doing the call to load.php inside of the mediawiki.legacy.shared module. After pouring through the code, it's this line here: return finfo_file( finfo_open( FILEINFO_MIME_TYPE ), $realpath ); I isolated the above down to this: # cat test.php <?php var_dump( finfo_file( finfo_open( FILEINFO_MIME_TYPE ), __FILE__ ) ); ?> This file's not important, but it does need to exist. Executing that in a browser causes the empty response error (read, crash). As found above, if you remove SVN from the /etc/conf.d/apache2 file, the above PHP code works. Calling the code from the command line does NOT reproduce this issue. It must be through www-servers/apache + dev-vcs/subversion and the apache2 conf.d file having -D SVN enabled. I'm running the stable versions of: dev-lang/php-5.3.28-r3 www-servers/apache-2.2.27 dev-vcs/subversion-1.7.14 My /etc/conf.d/apache2 configuration: APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D PHP5 -D PROXY -D DAV -D DAV_FS -D SVN -D AUTHN_PAM -D LDAP -D AUTHNZ_LDAP" I'll be happy to post my emerge --info if it's relevant.
I stumbled upon the same issue when I updated my Mediawiki to the latest version (1.23.5). My PHP Version is 5.4.34-pl0-gentoo (apache2handler) And MySQL 5.5.40-log When I turned off Apache dependency on SVN from /etc/conf.d/apache2 then Mediawiki loaded stylesheets effortlessly. When the SVN dependency is turned on then the stylesheet does not load. It is very odd that SVN somehow affects Mediawiki and runs into segfaults. I really need to use SVN on my server and I would not like to switch the SVN on/off whenever I need to use it, yet I cannot do that my wiki page is in use all the time. I tried to recomple php, apache, svn-dav, but with no success. I really hope that some of you can come up with a reasonable solution for that.
(In reply to Andres from comment #12) > I stumbled upon the same issue when I updated my Mediawiki to the latest > version (1.23.5). > My PHP Version is 5.4.34-pl0-gentoo (apache2handler) > And MySQL 5.5.40-log > > When I turned off Apache dependency on SVN from /etc/conf.d/apache2 then > Mediawiki loaded stylesheets effortlessly. When the SVN dependency is turned > on then the stylesheet does not load. > > It is very odd that SVN somehow affects Mediawiki and runs into segfaults. > > I really need to use SVN on my server and I would not like to switch the SVN > on/off whenever I need to use it, yet I cannot do that my wiki page is in > use all the time. > > I tried to recomple php, apache, svn-dav, but with no success. > > I really hope that some of you can come up with a reasonable solution for > that. Now I decided to dig in to Mediawiki PHP code and I commented out the mime_content_type(). Mediawiki already had fileinfo() php function present so i needed to comment out following lines in following Mediawiki files: 901-912:./includes/MimeMagic.php 146-149:./includes/libs/CSSMin.php 1034-1036:./includes/libs/lessc.inc.php Now I turned on Apache SVN dependency and php did not run into segfault. And best of all - now it is possible to use SVN again. I hope I pulled together the solution as the possible solution in changing the PHP code was already suggested by Thomas Wabner.
(In reply to Andres from comment #13) > (In reply to Andres from comment #12) > > I stumbled upon the same issue when I updated my Mediawiki to the latest > > version (1.23.5). > > My PHP Version is 5.4.34-pl0-gentoo (apache2handler) > > And MySQL 5.5.40-log > > > > When I turned off Apache dependency on SVN from /etc/conf.d/apache2 then > > Mediawiki loaded stylesheets effortlessly. When the SVN dependency is turned > > on then the stylesheet does not load. > > > > It is very odd that SVN somehow affects Mediawiki and runs into segfaults. > > > > I really need to use SVN on my server and I would not like to switch the SVN > > on/off whenever I need to use it, yet I cannot do that my wiki page is in > > use all the time. > > > > I tried to recomple php, apache, svn-dav, but with no success. > > > > I really hope that some of you can come up with a reasonable solution for > > that. > > Now I decided to dig in to Mediawiki PHP code and I commented out the > mime_content_type(). Mediawiki already had fileinfo() php function present > so i needed to comment out following lines in following Mediawiki files: > 901-912:./includes/MimeMagic.php > 146-149:./includes/libs/CSSMin.php > 1034-1036:./includes/libs/lessc.inc.php > > Now I turned on Apache SVN dependency and php did not run into segfault. And > best of all - now it is possible to use SVN again. > > I hope I pulled together the solution as the possible solution in changing > the PHP code was already suggested by Thomas Wabner. Sorry. It was too early to tell, because I forgot to clean browser cache. An d the problem still remains.
(In reply to Andres from comment #14) > (In reply to Andres from comment #13) > > (In reply to Andres from comment #12) > > > I stumbled upon the same issue when I updated my Mediawiki to the latest > > > version (1.23.5). > > > My PHP Version is 5.4.34-pl0-gentoo (apache2handler) > > > And MySQL 5.5.40-log > > > > > > > Now I decided to dig in to Mediawiki PHP code and I commented out the > > mime_content_type(). Mediawiki already had fileinfo() php function present > > so i needed to comment out following lines in following Mediawiki files: > > 901-912:./includes/MimeMagic.php > > 146-149:./includes/libs/CSSMin.php > > 1034-1036:./includes/libs/lessc.inc.php > > > > Now I turned on Apache SVN dependency and php did not run into segfault. And > > best of all - now it is possible to use SVN again. > > > > I hope I pulled together the solution as the possible solution in changing > > the PHP code was already suggested by Thomas Wabner. > > Sorry. It was too early to tell, because I forgot to clean browser cache. An > d the problem still remains. The easy way to fix this issue for end-users is to disable the fileinfo extension, either by disabling the (by default enabled) 'fileinfo' USE flag for dev-lang/php and recompile, or by editing the php.ini file. I did not find any php application in my environment that actually required the extension to be available.
(In reply to Tom Hendrikx from comment #15) > (In reply to Andres from comment #14) > > (In reply to Andres from comment #13) > > > (In reply to Andres from comment #12) > > > > I stumbled upon the same issue when I updated my Mediawiki to the latest > > > > version (1.23.5). > > > > My PHP Version is 5.4.34-pl0-gentoo (apache2handler) > > > > And MySQL 5.5.40-log > > > > > > > > > > Now I decided to dig in to Mediawiki PHP code and I commented out the > > > mime_content_type(). Mediawiki already had fileinfo() php function present > > > so i needed to comment out following lines in following Mediawiki files: > > > 901-912:./includes/MimeMagic.php > > > 146-149:./includes/libs/CSSMin.php > > > 1034-1036:./includes/libs/lessc.inc.php > > > > > > Now I turned on Apache SVN dependency and php did not run into segfault. And > > > best of all - now it is possible to use SVN again. > > > > > > I hope I pulled together the solution as the possible solution in changing > > > the PHP code was already suggested by Thomas Wabner. > > > > Sorry. It was too early to tell, because I forgot to clean browser cache. An > > d the problem still remains. > > The easy way to fix this issue for end-users is to disable the fileinfo > extension, either by disabling the (by default enabled) 'fileinfo' USE flag > for dev-lang/php and recompile, or by editing the php.ini file. > > I did not find any php application in my environment that actually required > the extension to be available. Now I did a core dump debug with gdb and the backtrace is following: GNU gdb (Gentoo 7.7.1 p1) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from apache2...(no debugging symbols found)...done. [New LWP 28905] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/apache2 -D CGI -D SSL -D PHP5 -D SVN -D DAV -D SVN_AUTHZ -D STATUS -D'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f1c7236bd0a in ?? () from /usr/lib64/apache2/modules/libphp5.so (gdb) bt full #0 0x00007f1c7236bd0a in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #1 0x00007f1c7236b4b7 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #2 0x00007f1c7236bab3 in file_softmagic () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #3 0x00007f1c72367c43 in file_buffer () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #4 0x00007f1c72368440 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #5 0x00007f1c7235e762 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #6 0x00007f1c7266797f in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #7 0x00007f1c72620c2f in execute () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #8 0x00007f1c725b1cf8 in zend_call_function () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #9 0x00007f1c725b20c0 in call_user_function_ex () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #10 0x00007f1c7232427f in php_pcre_replace_impl () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #11 0x00007f1c723248a0 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #12 0x00007f1c72324e83 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #13 0x00007f1c7266797f in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #14 0x00007f1c72620c2f in execute () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #15 0x00007f1c725b1cf8 in zend_call_function () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #16 0x00007f1c725b20c0 in call_user_function_ex () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #17 0x00007f1c7232427f in php_pcre_replace_impl () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #18 0x00007f1c723248a0 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #19 0x00007f1c72324e83 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #20 0x00007f1c7266797f in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #21 0x00007f1c72620c2f in execute () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #22 0x00007f1c725c09a7 in zend_execute_scripts () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #23 0x00007f1c72560d50 in php_execute_script () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #24 0x00007f1c7266975d in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #25 0x000000000043b248 in ap_run_handler () No symbol table info available. #26 0x000000000043b6ae in ap_invoke_handler () No symbol table info available. #27 0x00000000004485a0 in ap_process_request () No symbol table info available. #28 0x00000000004455a0 in ?? () No symbol table info available. #29 0x0000000000441918 in ap_run_process_connection () No symbol table info available. #30 0x000000000044cf5f in ?? () No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #31 0x000000000044d67c in ?? () No symbol table info available. #32 0x000000000044e1d2 in ap_mpm_run () No symbol table info available. #33 0x000000000042676d in main () No symbol table info available.
Now I went for full world update and the gdb report is as following: GNU gdb (Gentoo 7.7.1 p1) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from apache2...(no debugging symbols found)...done. [New LWP 20615] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/apache2 -D CGI -D SSL -D PHP5 -D DAV -D SVN -D SVN_AUTHZ -D STATUS -D'. Program terminated with signal SIGABRT, Aborted. #0 0x00007fd8bb705555 in raise () from /lib64/libc.so.6 (gdb) bt full #0 0x00007fd8bb705555 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fd8bb7069cb in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007fd8bb746cb0 in ?? () from /lib64/libc.so.6 No symbol table info available. #3 0x00007fd8bb74c956 in ?? () from /lib64/libc.so.6 No symbol table info available. #4 0x00007fd8bb74d78c in ?? () from /lib64/libc.so.6 No symbol table info available. #5 0x00007fd8b2d02ca3 in ?? () from /usr/lib64/libmagic.so.1 No symbol table info available. #6 0x00007fd8b208b385 in finfo_resource_destructor () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #7 0x00007fd8b22fc61e in list_entry_destructor () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #8 0x00007fd8b22fa3a3 in zend_hash_del_key_or_index () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #9 0x00007fd8b22fc737 in _zend_list_delete () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #10 0x00007fd8b2394ee0 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #11 0x00007fd8b234e16f in execute () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #12 0x00007fd8b22df238 in zend_call_function () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #13 0x00007fd8b22df600 in call_user_function_ex () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #14 0x00007fd8b205176f in php_pcre_replace_impl () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #15 0x00007fd8b2051d90 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #16 0x00007fd8b2052373 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #17 0x00007fd8b2394ebf in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #18 0x00007fd8b234e16f in execute () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #19 0x00007fd8b22df238 in zend_call_function () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #20 0x00007fd8b22df600 in call_user_function_ex () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #21 0x00007fd8b205176f in php_pcre_replace_impl () from /usr/lib64/apache2/modules/libphp5.so ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #22 0x00007fd8b2051d90 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #23 0x00007fd8b2052373 in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #24 0x00007fd8b2394ebf in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #25 0x00007fd8b234e16f in execute () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #26 0x00007fd8b22edee7 in zend_execute_scripts () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #27 0x00007fd8b228e280 in php_execute_script () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #28 0x00007fd8b2396c9d in ?? () from /usr/lib64/apache2/modules/libphp5.so No symbol table info available. #29 0x000000000043b248 in ap_run_handler () No symbol table info available. #30 0x000000000043b6ae in ap_invoke_handler () No symbol table info available. #31 0x00000000004485a0 in ap_process_request () No symbol table info available. #32 0x00000000004455a0 in ?? () No symbol table info available. #33 0x0000000000441918 in ap_run_process_connection () No symbol table info available. #34 0x000000000044cf5f in ?? () No symbol table info available. #35 0x000000000044d67c in ?? () No symbol table info available. #36 0x000000000044e1d2 in ap_mpm_run () No symbol table info available. #37 0x000000000042676d in main () No symbol table info available. So the segfault problem transformed into SIGABRT. Any suggestions?
*** Bug 509516 has been marked as a duplicate of this bug. ***
I'm going to mark a bunch of these as duplicates of the bug that has the most information (and an upstream bug -- unfortunately closed). The problem seems to be bundled libmagic code in PHP that can conflict with other stuff. And the solution is probably to unbundle that code. *** This bug has been marked as a duplicate of bug 471682 ***
(In reply to Andres from comment #12) > I stumbled upon the same issue when I updated my Mediawiki to the latest > version (1.23.5). > My PHP Version is 5.4.34-pl0-gentoo (apache2handler) > And MySQL 5.5.40-log > > When I turned off Apache dependency on SVN from /etc/conf.d/apache2 then > Mediawiki loaded stylesheets effortlessly. When the SVN dependency is turned > on then the stylesheet does not load. > > It is very odd that SVN somehow affects Mediawiki and runs into segfaults. > > I really need to use SVN on my server and I would not like to switch the SVN > on/off whenever I need to use it, yet I cannot do that my wiki page is in > use all the time. > > I tried to recomple php, apache, svn-dav, but with no success. > > I really hope that some of you can come up with a reasonable solution for > that. Thanks a ton for this tip - disabling dav_svn and dav helped fix the problem, on a FreeBSD box I'm running Phabricator!
