Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 24373 - mod_php + apache2 + LFS == segfaults
Summary: mod_php + apache2 + LFS == segfaults
Status: RESOLVED LATER
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: PHP Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-13 01:24 UTC by SpanKY
Modified: 2005-05-12 13:37 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2003-07-13 01:24:23 UTC
if you build mod_php for apache2 while you have -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE in your CFLAGS then apache will segfault when you attempt 
to have apache serv anything 
 
i would post a gdb run but when doing so gdb claims 'program exited normally' ... 
which it did i guess since apache caught the signal to die and did so accordingly ... 
 
note that: 
mod_php + apache1 + LFS == work 
apache2 + LFS == work 
mod_php + apache2 + LFS == work 
 
so i'd suggest adding this to the mod_php ebuild: 
use apache2 && filter-flags -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2003-07-16 00:49:02 UTC
So just to clarify:
trying to force large file support using CFLAGS breaks mod_php with apache2, but it still does proper large file support anyway if you don't include the CFLAGS?
Comment 2 SpanKY gentoo-dev 2003-07-16 14:52:43 UTC
i didnt bother investigating whether php still accessed things with large file flags 
because it was kinda late and i just wanted the damn thing to work :) 
 
ill play around with the machine to find out 
Comment 3 SpanKY gentoo-dev 2003-07-20 17:20:28 UTC
yes, the files are accessed in large file mode as far as i can tell from looking at the 
output of an extensive strace run 
 
so i guess if you just filter it out it should be fine 
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2003-08-11 10:00:33 UTC
Fixed in CVS.
Comment 5 Jason Stubbs (RETIRED) gentoo-dev 2004-08-13 02:10:23 UTC
Sorry!

Unfortunately, php can not handle large files without those defines. I haven't tested for the exact limit, but it is either 2GB or 4GB - ie max positive of either a signed or unsigned 32 bit integer. Anyway, if this could be applied only for mod_php, rather than php as well, I'd be happy too.
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2004-08-13 03:03:02 UTC
jstubbs: that's a direct contradiction of spanky's experimental results.

both of you post up your versions of testing scripts, and i'll evaluate it myself before changing things.
Comment 7 Jason Stubbs (RETIRED) gentoo-dev 2004-08-15 19:28:17 UTC
jason@maguro ~/logger $ dd if=/dev/zero of=bigfile bs=1024 count=5242880
5242880+0 records in
5242880+0 records out
jason@maguro ~/logger $ ls -sh bigfile
5.1G bigfile
jason@maguro ~/logger $ php -r 'fopen("bigfile", "r");'

Warning: fopen(bigfile): failed to open stream: File too large in Command line code on line 1


[ebuild   R   ] dev-php/php-5.0.1  -adabas -bcmath +berkdb -birdstep -bzlib -calendar -cdb -cpdflib +crypt -ctype -curl -curlwrappers -db2 +dba -dbase -dbm -dbmaker -dbx -dio -empress -empress-bcs -esoob -exif -fam -fdftk -filepro -flatfile -frontbase -ftp +gd -gd-external -gdbm -gmp -hyperwave-api +iconv -imap -informix -ingres -inifile -interbase -iodbc +jpeg -ldap -libedit -mcve -memlimit -mhash -mime -ming -mnogosearch -msession -msql -mssql +mysql -mysqli +ncurses -nis +nls -oci8 -odbc -oracle7 -ovrimos -pcntl -pcre -pfpro+png -posix -postgres -qdbm +readline -recode -sapdb -sasl -session -shared -sharedmem -simplexml -snmp -soap -sockets -solid -spell -spl -sqlite +ssl -sybase -sybase-ct -sysvipc -tidy +tiff -tokenizer +truetype -wddx -xml2 -xmlrpc -xpm -xsl +zlib 0 kB
Comment 8 Jason Stubbs (RETIRED) gentoo-dev 2004-08-15 19:29:14 UTC
BTW, the same thing happened with 4.3.8
Comment 9 SpanKY gentoo-dev 2004-08-15 19:56:27 UTC
i said mod_php + apache2, not the cmdline php ...

i'll see if i cant test this again to see if it happens with mod_php-5.x
Comment 10 Jason Stubbs (RETIRED) gentoo-dev 2004-08-16 04:08:05 UTC
Yes, I know. The fix for this bug, however, removes the appropriate -D_* from dev-php/php as well by way of php-sapi.eclass. I don't mind if it's removed from mod_php, but removing it from php as well I think is a bit heavy handed.
Comment 11 SpanKY gentoo-dev 2004-08-16 08:22:14 UTC
my current toolchain and with mod_php-5.0.1 i'm not able to reproduce this anymore

so we could just remove the filter-flags completely since i'm sure the gcc/glibc combo i used when i filed this bug are way past dead now
Comment 12 Jesse Adelman 2004-11-12 15:31:21 UTC
OK, just went through a minor circle of hell teasing out why I coulnd't serve file > 2GB in size from Apache (2.0.52-r1) with mod_php. After strace-ing Apache with and without mod_php, found that mod_php was the source of the issue. After modifying the php eclass at /usr/portage/eclass/php-sapi.eclass, commenting out the filter-flags which filtered the LFS CFLAGS, I re-emerged mod_php (stable version 4.3.9) after adding -D_FILE_OFFSET_BITS=64 to the CFLAGS in /etc/make.conf. Viola, happily viewing a 7.8 GB video from my mythtv box via VLC on a Windows 2000 client.

So, while it would be better to have a "lfs" USE flag going forward, can we at least remove the filter-flags for lfs in this eclass, please? Thanks! 
Comment 13 fury 2004-12-13 19:13:17 UTC
I would like to see a LFS support added into this too for the same reason as Jesse
Comment 14 Christian Parpart (RETIRED) gentoo-dev 2005-01-13 03:55:18 UTC
for PHP 4 we added LFS support as we just wanted it in apache, this enforced us to enable it for mod_php 4 as well, or it would die otherwise;

masked packages will be committed in a second, but do not use them *ALONE*, that is, if you wanna test them, you have to unmask the whole new apache-herd related commits (see package.mask); update apache including apr/apr-util-0.9.5 and recompile everything that directly and/or indirectly depends on apr.
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-03-08 17:26:24 UTC
could the posters on this bug please test that LFS support works with the latest mod_php/apache packages?
Comment 16 Jesse Adelman 2005-04-23 23:58:47 UTC
Works for me! Thank you all for your work. :)
Comment 17 Sebastian Bergmann (RETIRED) gentoo-dev 2005-05-10 01:17:20 UTC
LFS support has been dropped. It will return when Apache 2.2 is released.
Comment 18 Jesse Adelman 2005-05-10 11:44:45 UTC
Um, what?!? Why is it dropped when it works fine?!?
Comment 19 Christian Parpart (RETIRED) gentoo-dev 2005-05-10 12:01:55 UTC
I really really dislike the move-back, and I've not been the one who fought for it, but obviousely, there must be no other way.

trapni@battousai gentoo-x86 $ head -n14 dev-libs/apr/ChangeLog
# ChangeLog for dev-libs/apr
# Copyright 2000-2005 Gentoo Foundation; Distributed under the GPL v2
# $Header: /var/cvsroot/gentoo-x86/dev-libs/apr/ChangeLog,v 1.28 2005/05/09 14:44:25 beu Exp $

*apr-0.9.6-r3 (09 May 2005)
*apr-0.9.5-r3 (09 May 2005)

  09 May 2005; Elfyn McBratney <beu@gentoo.org> +apr-0.9.5-r3.ebuild,
  +apr-0.9.6-r3.ebuild:
  Rev bumps that remove LFS support from APR (has caused too many issues for
  mid-release introduction). The Apache tool-stack (net-www/apache,
  devs-libs/apr (this package) and dev-libs/apr-util) will need to be rebuilt
  once emerging this update.
Comment 20 Jesse Adelman 2005-05-10 12:40:42 UTC
OK. There must be some silly bureaucratic reason, because there certainly is no technical reason for this "roll back". But I thought Gentoo, and the Gentoo buracracy's, purpose was to move technology forward, not backward? It would seem from the _apr_ bug changelog entry that the bug is with apr, not the net-www/apache package?

To compound things, apr is masked as *unstable*, so this decision, which rolls back a *stable* package, is done for a *masked* package? How silly is that? This is why a LFS USE flag would be key right now...