ID:               18863
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Feedback
+Status:           No Feedback
 Bug Type:         Unknown/Other Function
 Operating System: RHAT Linux (i386 and Alpha)
 PHP Version:      4.1.2
 New Comment:

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:
------------------------------------------------------------------------

[2002-10-10 06:47:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



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

[2002-10-10 00:25:33] [EMAIL PROTECTED]

I have just compiled and tested this on RH7.2 ans 4.2.4-dev and the
same behaviour still exists.

If you run php -v enough times (in my case 58 times) you end up with a
whole bunch of semaphore arrays that have not been cleaned up and php
dying when run fit rom the command line with:

$ php -v
Content-type: text/html

PHP Fatal error:  Unable to start session mm module in Unknown on line
0

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

[2002-08-12 09:51:30] [EMAIL PROTECTED]

IIRC, this was fixed someday...  if it works with 4.2.2 than it's no
longer a bug. Please try a (non-STABLE) snapshot from
http://snaps.php.net and reopen this report if the problem still
persists.

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

[2002-08-12 00:34:48] [EMAIL PROTECTED]


I've been contacted by a php user in the wild who told me that by
simply issuing 'php -v', a semaphore that php opens for session
management is not closed on exit.

This becomes bad news because the ipc system on linux is a global
resource and not based per user, so it's possible for a local user to
DOS the box by running php -v repeatidly.

[test@alpha3 test]$ ipcs > l
[test@alpha3 test]$ php -v
Content-type: text/html
4.1.2
[test@alpha3 test]$ ipcs > ll
[test@alpha3 test]$ diff l ll
9a10,11
> 0x00000000 65538      test      600        1         
> 0x00000000 98307      test      600        1         

I tried to trace this out between 4.1.2 and 4.2.2 (4.2.2 does not
exhibit this behaviour) but I can find no obvious differances in the
codepaths between versions. This behaviour seems to be present all the
way back to 4.0.6 from the little additional checking I made.

Please see 
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71097
For a more detailed analysis

The RH 4.1.2 configure incantation:
./configure --prefix=/usr --with-config-file-path=/etc
--enable-force-cgi-redirect --disable-debug --enable-pic
--disable-rpath --enable-inline-optimization --with-bz2 --with-db3
--with-curl --with-dom=/usr --with-exec-dir=/usr/bin
--with-freetype-dir=/usr --with-png-dir=/usr --with-gd
--enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext
--with-ncurses --with-gmp --with-iconv --with-jpeg-dir=/usr --with-mm
--with-openssl --with-png --with-pspell --with-regex=system --with-xml
--with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath
--enable-debugger --enable-exif --enable-ftp --enable-magic-quotes
--enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm
--enable-discard-path --enable-track-vars --enable-trans-sid
--enable-yp --enable-wddx --without-oci8 --with-imap=shared
--with-imap-ssl --with-kerberos=/usr/kerberos --with-ldap=shared
--with-mysql=shared,/usr --with-pgsql=shared --with-snmp=shared,/usr
--with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=shared
--enable-memory-limit --enable-bcmath --enable-shmop
--enable-versioning --enable-calendar --enable-dbx --enable-dio
--enable-mbstring --enable-mbstr-enc-trans --enable-force-cgi-redirect


Phil
=--=

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


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

Reply via email to