Bug #53695 [Bgs]: Bugs are not outputed when using php-fpm

2011-02-01 Thread szoftos at freemail dot hu
Edit report at http://bugs.php.net/bug.php?id=53695edit=1

 ID: 53695
 User updated by:szoftos at freemail dot hu
 Reported by:szoftos at freemail dot hu
 Summary:Bugs are not outputed  when using php-fpm
 Status: Bogus
 Type:   Bug
 Package:FPM related
 Operating System:   FreeBSD
 PHP Version:5.3.5
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Okay, this is still a bug, and not a bogus one.



I changed the configuration, right now these are all the config lines
for the given virtualhost:





[virtualhost]

chroot = /usr/local/www/

chdir = /vhosts/virtualhost/htdocs

listen = /usr/local/www/var/run/sockets/virtualhost.php.sock

listen.owner = www

listen.group = www

listen.mode = 0660

user = username

group = groupname

pm = dynamic

pm.max_children = 50

pm.start_servers = 1

pm.min_spare_servers = 1

pm.max_spare_servers = 5

pm.max_requests = 200

request_terminate_timeout = 1m

request_slowlog_timeout = 30s

slowlog = /var/log/php-fpm-slow.log

catch_workers_output = yes

php_admin_flag[register_globals] = off

php_admin_value[variables_order] = GPCES

php_admin_value[date.timezone] = Europe/Budapest

php_admin_flag[always_populate_raw_post_data] = on

php_admin_value[open_basedir] = /vhosts/virtualhost/htdocs

php_admin_value[doc_root] = /vhosts/virtualhost/htdocs

php_admin_value[upload_tmp_dir] = /vhosts/virtualhost/htdocs/tmp

php_admin_flag[zlib.output_compression] = on

php_admin_flag[safe_mode] = on

php_admin_value[disable_functions] =
escapeshellarg,escapeshellcmd,exec,passthru,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,system

php_admin_flag[magic_quotes_gpc] = on

php_admin_flag[magic_quotes_runtime] = off

php_admin_flag[magic_quotes_sybase] = off

php_admin_value[session.save_path] =
/vhosts/virtualhost/htdocs/admin/tmp

php_admin_value[safe_mode_exec_dir] =
/vhosts/virtualhost/safe_mode_exec_dir

php_admin_value[memory_limit] = 32M

php_admin_flag[short_open_tag] = on

php_admin_value[default_charset] = UTF-8

php_admin_value[error_reporting] = E_ALL  ~E_NOTICE

php_admin_flag[display_errors] = On

php_admin_flag[display_startup_errors] = On





As you can see, all without quotes now. The mentioned example code runs
now with the same results: no output at all, when commenting out the
phpinfo() from it.



Please reopen the bug, as this is _not_ a bogus report.



Cheers,

Laszlo


Previous Comments:

[2011-01-29 15:10:14] szoftos at freemail dot hu

Ah, thank you, i'll try the configuration without quotes. However, I was
thinking that the php_admin_value should be set in the same way as for
the mod_php module in apache. In there, one has to use quotes.



Maybe this should be a remark for php-fpm's config.


[2011-01-29 12:11:42] f...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

You must not use double (or simple) quotes arround E_ALL as constants
are 

interpreted by the php core ini parser (quotes inhibits this
conversion)



php_admin_value[error_reporting] = E_ALL is not well understood. 



php_admin_value[error_reporting] = E_ALL is correctely converted.


[2011-01-10 08:16:48] f...@php.net

Are you sure it's related to php fpm ?



Here is the content of a test file:

?php asdlk;k; ?



Calling from CLI: nothing, white page

Calling from FPM: the same



Here is the content of another test file:

?php nofunc(); ?



Calling from CLI: Fatal error: Call to undefined function nofunc() in 

/html/error.php on line 1

Calling from FPM: Fatal error: Call to undefined function nofunc() in 

/html/error.php on line 1



The behaviour is the same with CLI or FPM. 



@kalle:

can you reproduce the problem ?


[2011-01-10 01:41:19] ka...@php.net

Hmm, I wonder if php-fpm is actually parsing the error_reporting
constants with their numeric bitfields to mask it correctly, could be
wrong here. Any thoughts fat?


[2011-01-08 13:01:47] szoftos at freemail dot hu

Description:

Hi, when i was trying to see an error message because of a syntax error
(or any other error) using php-fpm, it simply won't output. Sometimes i
get nothing, and other times i get an '500 Server error'.



When i use php-cli, i get the error message.



my configure line (comes from freebsd ports): './configure'
'--with-layout=GNU

Bug #53695 [Bgs]: Bugs are not outputed when using php-fpm

2011-01-29 Thread szoftos at freemail dot hu
Edit report at http://bugs.php.net/bug.php?id=53695edit=1

 ID: 53695
 User updated by:szoftos at freemail dot hu
 Reported by:szoftos at freemail dot hu
 Summary:Bugs are not outputed  when using php-fpm
 Status: Bogus
 Type:   Bug
 Package:FPM related
 Operating System:   FreeBSD
 PHP Version:5.3.5
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Ah, thank you, i'll try the configuration without quotes. However, I was
thinking that the php_admin_value should be set in the same way as for
the mod_php module in apache. In there, one has to use quotes.



Maybe this should be a remark for php-fpm's config.


Previous Comments:

[2011-01-29 12:11:42] f...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

You must not use double (or simple) quotes arround E_ALL as constants
are 

interpreted by the php core ini parser (quotes inhibits this
conversion)



php_admin_value[error_reporting] = E_ALL is not well understood. 



php_admin_value[error_reporting] = E_ALL is correctely converted.


[2011-01-10 08:16:48] f...@php.net

Are you sure it's related to php fpm ?



Here is the content of a test file:

?php asdlk;k; ?



Calling from CLI: nothing, white page

Calling from FPM: the same



Here is the content of another test file:

?php nofunc(); ?



Calling from CLI: Fatal error: Call to undefined function nofunc() in 

/html/error.php on line 1

Calling from FPM: Fatal error: Call to undefined function nofunc() in 

/html/error.php on line 1



The behaviour is the same with CLI or FPM. 



@kalle:

can you reproduce the problem ?


[2011-01-10 01:41:19] ka...@php.net

Hmm, I wonder if php-fpm is actually parsing the error_reporting
constants with their numeric bitfields to mask it correctly, could be
wrong here. Any thoughts fat?


[2011-01-08 13:01:47] szoftos at freemail dot hu

Description:

Hi, when i was trying to see an error message because of a syntax error
(or any other error) using php-fpm, it simply won't output. Sometimes i
get nothing, and other times i get an '500 Server error'.



When i use php-cli, i get the error message.



my configure line (comes from freebsd ports): './configure'
'--with-layout=GNU' '--localstatedir=/var'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--enable-libxml' '--with-libxml-dir=/usr/local'
'--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr'
'--program-prefix=' '--enable-fpm' '--with-fpm-user=www'
'--with-fpm-group=www' '--with-regex=php' '--with-zend-vm=CALL'
'--enable-zend-multibyte' '--prefix=/usr/local'
'--mandir=/usr/local/man' '--infodir=/usr/local/info/'
'--build=amd64-portbld-freebsd8.1' 



The following extensions are compiled in:

[root@wwwjail ~]# cat /var/db/ports/php5-extensions/options

# This file is auto-generated by 'make config'.

# No user-servicable parts inside!

# Options for php5-extensions-1.4

_OPTIONS_READ=php5-extensions-1.4

WITHOUT_BCMATH=true

WITH_BZ2=true

WITH_CALENDAR=true

WITH_CTYPE=true

WITHOUT_CURL=true

WITHOUT_DBA=true

WITH_DOM=true

WITH_EXIF=true

WITHOUT_FILEINFO=true

WITHOUT_FILTER=true

WITHOUT_FRIBIDI=true

WITH_FTP=true

WITH_GD=true

WITH_GETTEXT=true

WITH_GMP=true

WITH_HASH=true

WITH_ICONV=true

WITH_IMAP=true

WITHOUT_INTERBASE=true

WITH_JSON=true

WITHOUT_LDAP=true

WITH_MBSTRING=true

WITHOUT_MCRYPT=true

WITHOUT_MSSQL=true

WITH_MYSQL=true

WITHOUT_MYSQLI=true

WITHOUT_ODBC=true

WITH_OPENSSL=true

WITHOUT_PCNTL=true

WITH_PDF=true

WITH_PDO=true

WITH_PDO_SQLITE=true

WITHOUT_PGSQL=true

WITH_POSIX=true

WITH_PSPELL=true

WITHOUT_READLINE=true

WITHOUT_RECODE=true

WITH_SESSION=true

WITHOUT_SHMOP=true

WITH_SIMPLEXML=true

WITHOUT_SNMP=true

WITH_SOAP=true

WITHOUT_SOCKETS=true

WITH_SQLITE=true

WITHOUT_SYBASE_CT=true

WITHOUT_SYSVMSG=true

WITHOUT_SYSVSEM=true

WITHOUT_SYSVSHM=true

WITHOUT_TIDY=true

WITH_TOKENIZER=true

WITHOUT_WDDX=true

WITH_XML=true

WITH_XMLREADER=true

WITH_XMLRPC=true

WITH_XMLWRITER=true

WITHOUT_XSL=true

WITHOUT_YAZ=true

WITH_ZIP=true

WITH_ZLIB=true



The related php-fpm.conf snippet is:

php_admin_value[error_reporting] = E_ALL

php_admin_flag[display_errors] = On

php_admin_flag[display_startup_errors] = On



Test script:
---
?php

asdlkl;k

phpinfo();

?



Expected result:

PHP Parse error:  syntax error, unexpected T_STRING in test.php on line
3



Actual result:
--
Nothing, or a '500 Internal

[PHP-BUG] Bug #53695 [NEW]: Bugs are not outputed when using php-fpm

2011-01-08 Thread szoftos at freemail dot hu
From: 
Operating system: FreeBSD
PHP version:  5.3.5
Package:  FPM related
Bug Type: Bug
Bug description:Bugs are not outputed  when using php-fpm

Description:

Hi, when i was trying to see an error message because of a syntax error (or
any other error) using php-fpm, it simply won't output. Sometimes i get
nothing, and other times i get an '500 Server error'.



When i use php-cli, i get the error message.



my configure line (comes from freebsd ports): './configure'
'--with-layout=GNU' '--localstatedir=/var'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--enable-libxml' '--with-libxml-dir=/usr/local'
'--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr' '--program-prefix='
'--enable-fpm' '--with-fpm-user=www' '--with-fpm-group=www'
'--with-regex=php' '--with-zend-vm=CALL' '--enable-zend-multibyte'
'--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd8.1' 



The following extensions are compiled in:

[r...@wwwjail ~]# cat /var/db/ports/php5-extensions/options

# This file is auto-generated by 'make config'.

# No user-servicable parts inside!

# Options for php5-extensions-1.4

_OPTIONS_READ=php5-extensions-1.4

WITHOUT_BCMATH=true

WITH_BZ2=true

WITH_CALENDAR=true

WITH_CTYPE=true

WITHOUT_CURL=true

WITHOUT_DBA=true

WITH_DOM=true

WITH_EXIF=true

WITHOUT_FILEINFO=true

WITHOUT_FILTER=true

WITHOUT_FRIBIDI=true

WITH_FTP=true

WITH_GD=true

WITH_GETTEXT=true

WITH_GMP=true

WITH_HASH=true

WITH_ICONV=true

WITH_IMAP=true

WITHOUT_INTERBASE=true

WITH_JSON=true

WITHOUT_LDAP=true

WITH_MBSTRING=true

WITHOUT_MCRYPT=true

WITHOUT_MSSQL=true

WITH_MYSQL=true

WITHOUT_MYSQLI=true

WITHOUT_ODBC=true

WITH_OPENSSL=true

WITHOUT_PCNTL=true

WITH_PDF=true

WITH_PDO=true

WITH_PDO_SQLITE=true

WITHOUT_PGSQL=true

WITH_POSIX=true

WITH_PSPELL=true

WITHOUT_READLINE=true

WITHOUT_RECODE=true

WITH_SESSION=true

WITHOUT_SHMOP=true

WITH_SIMPLEXML=true

WITHOUT_SNMP=true

WITH_SOAP=true

WITHOUT_SOCKETS=true

WITH_SQLITE=true

WITHOUT_SYBASE_CT=true

WITHOUT_SYSVMSG=true

WITHOUT_SYSVSEM=true

WITHOUT_SYSVSHM=true

WITHOUT_TIDY=true

WITH_TOKENIZER=true

WITHOUT_WDDX=true

WITH_XML=true

WITH_XMLREADER=true

WITH_XMLRPC=true

WITH_XMLWRITER=true

WITHOUT_XSL=true

WITHOUT_YAZ=true

WITH_ZIP=true

WITH_ZLIB=true



The related php-fpm.conf snippet is:

php_admin_value[error_reporting] = E_ALL

php_admin_flag[display_errors] = On

php_admin_flag[display_startup_errors] = On



Test script:
---
?php

asdlkl;k

phpinfo();

?



Expected result:

PHP Parse error:  syntax error, unexpected T_STRING in test.php on line 3



Actual result:
--
Nothing, or a '500 Internal server error' result.

-- 
Edit bug report at http://bugs.php.net/bug.php?id=53695edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53695r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53695r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53695r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53695r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53695r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53695r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=53695r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=53695r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=53695r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=53695r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=53695r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=53695r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=53695r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53695r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=53695r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53695r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=53695r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=53695r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=53695r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=53695r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=53695r=mysqlcfg



#47479 [NEW]: Again: setlocale() ignores translation setting

2009-02-23 Thread szoftos at freemail dot hu
From: szoftos at freemail dot hu
Operating system: FreeBSD 7.0
PHP version:  5.2.9RC3
PHP Bug Type: Gettext related
Bug description:  Again: setlocale() ignores translation setting

Description:

Okay, i am posting this again, beacuse of my other bug was marked bogus,
and i still think it's not:

on BSD systems, setlocale itself is not usable for gettext without
putenv(). If I don't use putenv() with setlocale() (which is not enabled by
default in safe_mode=on for $LANG), my own translations are not useable
with gettext.

Since i use safe_mode, I'd not prefer enabling the setting of $LANG
variable with putenv(). What I've seen during php ktracing, is that
setlocale() only reads the original language settings from
/usr/share/locale/*, but my own translations are not looked up.

Is there any way to fix that functionality? Maybe it's more BSD related
than I think. KEEP IN MIND: If you would like to build a multi-langual site
with gettext, and the language have to be switched on-the-fly, you HAVE TO
set te $LANG variable on each run. I was told to set it at runtime, but
this is NOT an ELIGIBLE solution.

Please don't mark it bogus, because this is a real problem with
safe_mode=on.

Reproduce code:
---
You can simply try the gettext module's own tests to test it in BSD.
They all will fail, because those tests aren't usint putenv().


-- 
Edit bug report at http://bugs.php.net/?id=47479edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47479r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47479r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47479r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47479r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47479r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47479r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47479r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47479r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47479r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47479r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47479r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47479r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47479r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47479r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47479r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47479r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47479r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47479r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47479r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47479r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47479r=mysqlcfg



#47479 [Com]: Again: setlocale() ignores translation setting

2009-02-23 Thread szoftos at freemail dot hu
 ID:   47479
 Comment by:   szoftos at freemail dot hu
 Reported By:  szoftos at freemail dot hu
 Status:   Open
 Bug Type: Gettext related
 Operating System: FreeBSD 7.0
 PHP Version:  5.2.9RC3
 New Comment:

umm, sorry, i was mistyped.

I was told to set it at _startup_, but that's not good enough. I have
to set it runtime.


Previous Comments:


[2009-02-23 13:11:41] szoftos at freemail dot hu

Description:

Okay, i am posting this again, beacuse of my other bug was marked
bogus, and i still think it's not:

on BSD systems, setlocale itself is not usable for gettext without
putenv(). If I don't use putenv() with setlocale() (which is not enabled
by default in safe_mode=on for $LANG), my own translations are not
useable with gettext.

Since i use safe_mode, I'd not prefer enabling the setting of $LANG
variable with putenv(). What I've seen during php ktracing, is that
setlocale() only reads the original language settings from
/usr/share/locale/*, but my own translations are not looked up.

Is there any way to fix that functionality? Maybe it's more BSD related
than I think. KEEP IN MIND: If you would like to build a multi-langual
site with gettext, and the language have to be switched on-the-fly, you
HAVE TO set te $LANG variable on each run. I was told to set it at
runtime, but this is NOT an ELIGIBLE solution.

Please don't mark it bogus, because this is a real problem with
safe_mode=on.

Reproduce code:
---
You can simply try the gettext module's own tests to test it in BSD.
They all will fail, because those tests aren't usint putenv().






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



#47451 [Bgs]: setlocale() ignores setting

2009-02-20 Thread szoftos at freemail dot hu
 ID:   47451
 User updated by:  szoftos at freemail dot hu
 Reported By:  szoftos at freemail dot hu
 Status:   Bogus
 Bug Type: Gettext related
 Operating System: FreeBSD 7.0
 PHP Version:  5.2.9RC2
 New Comment:

Yeah, but what if you would like to change your language on the fly,
like changing languages on your site? And that's just one virtualhost,
what if every virtualhost would like to use another setting of $LANG ...
?


Previous Comments:


[2009-02-19 21:45:58] j...@php.net

If you can't use putenv() then you need to set the environment 
variables prior to running PHP / starting the webserver. No bug here.



[2009-02-19 16:04:20] szoftos at freemail dot hu

Description:

Hello,

on BSD systems, setlocale itself is not usable for gettext without
putenv(). If I don't use putenv() with setlocale() (which is not enabled
by default in safe_mode for $LANG), my own translations are not useable
with gettext.

Since i use safe_mode, I'd not prefer enabling the setting of $LANG
variablewith putenv(). What I've seen during php ktracing, is that
setlocale() only reads the original language settings from
/usr/share/locale/*, but my own translations are not looked up.

Is there any way to fix that functionality? Maybe it's more BSD related
than I think.

Reproduce code:
---
You can simply try the gettext module's own tests to test it in BSD.
They all will fail, because those tests aren't usint putenv().



Expected result:

I expect not to use the putenv() with safe_mode=on :)






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



#47451 [Bgs]: setlocale() ignores setting

2009-02-20 Thread szoftos at freemail dot hu
 ID:   47451
 User updated by:  szoftos at freemail dot hu
 Reported By:  szoftos at freemail dot hu
 Status:   Bogus
 Bug Type: Gettext related
 Operating System: FreeBSD 7.0
 PHP Version:  5.2.9RC2
 New Comment:

I think this is still a bug, and not a bogus one.

For your translation to use, you HAVE to set the correct $LANG variable
_runtime_. When you are using more than one translation, and would like
to change translations on the fly, $LANG variable has to be changed to
the apropriate setting each time.

Without that, translations will not work with gettext.


Previous Comments:


[2009-02-20 09:27:49] szoftos at freemail dot hu

Yeah, but what if you would like to change your language on the fly,
like changing languages on your site? And that's just one virtualhost,
what if every virtualhost would like to use another setting of $LANG ...
?



[2009-02-19 21:45:58] j...@php.net

If you can't use putenv() then you need to set the environment 
variables prior to running PHP / starting the webserver. No bug here.



[2009-02-19 16:04:20] szoftos at freemail dot hu

Description:

Hello,

on BSD systems, setlocale itself is not usable for gettext without
putenv(). If I don't use putenv() with setlocale() (which is not enabled
by default in safe_mode for $LANG), my own translations are not useable
with gettext.

Since i use safe_mode, I'd not prefer enabling the setting of $LANG
variablewith putenv(). What I've seen during php ktracing, is that
setlocale() only reads the original language settings from
/usr/share/locale/*, but my own translations are not looked up.

Is there any way to fix that functionality? Maybe it's more BSD related
than I think.

Reproduce code:
---
You can simply try the gettext module's own tests to test it in BSD.
They all will fail, because those tests aren't usint putenv().



Expected result:

I expect not to use the putenv() with safe_mode=on :)






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



#47451 [NEW]: setlocale() ignores setting

2009-02-19 Thread szoftos at freemail dot hu
From: szoftos at freemail dot hu
Operating system: FreeBSD 7.0
PHP version:  5.2.9RC2
PHP Bug Type: Gettext related
Bug description:  setlocale() ignores setting

Description:

Hello,

on BSD systems, setlocale itself is not usable for gettext without
putenv(). If I don't use putenv() with setlocale() (which is not enabled by
default in safe_mode for $LANG), my own translations are not useable with
gettext.

Since i use safe_mode, I'd not prefer enabling the setting of $LANG
variablewith putenv(). What I've seen during php ktracing, is that
setlocale() only reads the original language settings from
/usr/share/locale/*, but my own translations are not looked up.

Is there any way to fix that functionality? Maybe it's more BSD related
than I think.

Reproduce code:
---
You can simply try the gettext module's own tests to test it in BSD. They
all will fail, because those tests aren't usint putenv().



Expected result:

I expect not to use the putenv() with safe_mode=on :)


-- 
Edit bug report at http://bugs.php.net/?id=47451edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47451r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47451r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47451r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47451r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47451r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47451r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47451r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47451r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47451r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47451r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47451r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47451r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47451r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47451r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47451r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47451r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47451r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47451r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47451r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47451r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47451r=mysqlcfg



#45049 [Fbk-Opn]: spawn-fcgi sometimes cannot resolve symlinks

2008-05-22 Thread szoftos at freemail dot hu
 ID:   45049
 User updated by:  szoftos at freemail dot hu
 Reported By:  szoftos at freemail dot hu
-Status:   Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: FreeBSD
 PHP Version:  5.2.6
 New Comment:

Hello,

original configuration snippet follows:

$HTTP[host] =~ ^crxforum\.flix\.hu$|^crxforum\.localhost$ {
server.document-root =
/var/www/crxforum.flix.hu/crxforum.flix.hu
fastcgi.server= ( .php =
((
  socket = /tmp/crxforum.flix.hu.php.sock,
  broken-scriptfilename = enable,
 ))
)
accesslog.filename =
/var/log/lighttpd/crxforum.flix.hu-access.log
server.errorlog = /var/log/lighttpd/crxforum.flix.hu-error.log
server.error-handler-404 = /404.php
$HTTP[url] =~ ^(/images/|/skins/|/js/) {
expire.url = (  = access 1 years )
}
}


Previous Comments:


[2008-05-22 08:42:34] [EMAIL PROTECTED]

Please provide the actual fastcgi.server part of your lighttpd.conf.
Also, how did you compile/configure PHP itself? (OTOH, *bsd has lot of
problems dealing with symlinks, just search this bug db..:)



[2008-05-20 09:37:40] szoftos at freemail dot hu

Description:

Hello,

recently i changed my operating system from linux to freebsd, which has
its default documentroot in /usr/local/www, and linux had it in
/var/www. i moved my files to /usr/local/www, but i made a symlink into
/var:

'cd /var'

'ln -s ../usr/local/www www'

lighttpd has its old configs, locating files in /var/www, but this
shouldn't be a problem with the symlink.

php got its settings locating files in /usr/local/www, and i got
sometimes a mystical response from the fcgi-php: 'No input file
specified.'

i lowered the spawned processes to 2 (sadly i couldn't lower it to 1),
and traced one of the two processes. one of them was the faulty, and i
had luck: i have seen that lighttpd passed /var/www (normally) to
php-fcgi, and somehow php-fcgi couldn't really resolve the symlink.

the problem solved when i changed /var/www to /usr/local/www in
lighty's configuration.

this looks like a problem to me, and it is not unique. i had this
situation with one of my other virtualhosts too. the spawned processes
are resolving that symlink good in most of the time, but then one
process stops resolving it right, and produces the message, as i have
written.

this should be a problem. 

i have gone to lighttpd developers, and they told me its a php problem.
the original bugreport is here:
http://trac.lighttpd.net/trac/ticket/1668

Reproduce code:
---
You can reproduce if you use the same settings as i mentioned above.






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



#45049 [NEW]: spawn-fcgi sometimes cannot resolve symlinks

2008-05-20 Thread szoftos at freemail dot hu
From: szoftos at freemail dot hu
Operating system: FreeBSD
PHP version:  5.2.6
PHP Bug Type: CGI related
Bug description:  spawn-fcgi sometimes cannot resolve symlinks

Description:

Hello,

recently i changed my operating system from linux to freebsd, which has
its default documentroot in /usr/local/www, and linux had it in /var/www. i
moved my files to /usr/local/www, but i made a symlink into /var:

'cd /var'

'ln -s ../usr/local/www www'

lighttpd has its old configs, locating files in /var/www, but this
shouldn't be a problem with the symlink.

php got its settings locating files in /usr/local/www, and i got sometimes
a mystical response from the fcgi-php: 'No input file specified.'

i lowered the spawned processes to 2 (sadly i couldn't lower it to 1), and
traced one of the two processes. one of them was the faulty, and i had
luck: i have seen that lighttpd passed /var/www (normally) to php-fcgi, and
somehow php-fcgi couldn't really resolve the symlink.

the problem solved when i changed /var/www to /usr/local/www in lighty's
configuration.

this looks like a problem to me, and it is not unique. i had this
situation with one of my other virtualhosts too. the spawned processes are
resolving that symlink good in most of the time, but then one process stops
resolving it right, and produces the message, as i have written.

this should be a problem. 

i have gone to lighttpd developers, and they told me its a php problem.
the original bugreport is here:
http://trac.lighttpd.net/trac/ticket/1668

Reproduce code:
---
You can reproduce if you use the same settings as i mentioned above.


-- 
Edit bug report at http://bugs.php.net/?id=45049edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45049r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45049r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45049r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45049r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45049r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45049r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45049r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45049r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45049r=support
Expected behavior:http://bugs.php.net/fix.php?id=45049r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45049r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45049r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45049r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45049r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45049r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45049r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45049r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45049r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45049r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45049r=mysqlcfg



#40023 [NEW]: memory_limit configuration seems to be ignored

2007-01-04 Thread szoftos at freemail dot hu
From: szoftos at freemail dot hu
Operating system: Linux 2.4.33
PHP version:  5.2.0
PHP Bug Type: PHP options/info functions
Bug description:  memory_limit configuration seems to be ignored

Description:

the memory_limit in php.ini won't be taken in use in php 5.2.0

i have set up to 8M in the configuration file, but when i get a phpinfo(),
there is no memory_limit option in the configuration options.

ini_get also won't return any value, and i have experienced that in this
way one script can eat up all memory, causing messages like this in the
kernel log:

kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
kernel: VM: killing process php
kernel: VM: killing process mysqld

meanwhile the whole machine hangs.

i'm using lighttpd, with fastcgi extension. php is running under the
username of the virtualhost's user.

i have tested this with another virtualhost on the server, i couldn't see
it on the other site too.

php compile options:

'./configure' '--enable-mbstring' '--disable-static' '--disable-debug'
'--enable-pic' '--enable-inline-optimization'
'--with-config-file-path=/etc/php5' '--enable-magic-quotes'
'--enable-debugger' '--enable-track-vars' '--enable-safe-mode'
'--with-regex=system' '--with-versioning' '--enable-sysvsem'
'--enable-sysvshm' '--with-mod_charset' '--enable-force-cgi-redirect'
'--without-mm' '--enable-trans-sid' '--with-dbase' '--with-filepro'
'--enable-yp' '--enable-ftp' '--with-xml' '--with-mysql=shared,/usr'
'--with-iconv' '--with-gettext' '--with-zlib=/usr' '--with-gd=shared,/usr'
'--with-mysql-sock=/tmp/mysql.sock' '--enable-gd-native-ttf' '--with-png'
'--with-ttf' '--with-jpeg-dir=/usr' '--with-freetype-dir=/usr'
'--with-xpm-dir=/usr' '--enable-fastcgi' '--enable-cgi'
'--enable-discard-path'

Reproduce code:
---
?
phpinfo();

ini_get('memory_limit');
?


-- 
Edit bug report at http://bugs.php.net/?id=40023edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=40023r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=40023r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=40023r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40023r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=40023r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=40023r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40023r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40023r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=40023r=support
Expected behavior:http://bugs.php.net/fix.php?id=40023r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=40023r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=40023r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40023r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=40023r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40023r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40023r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=40023r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=40023r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=40023r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40023r=mysqlcfg


#40023 [Bgs]: memory_limit configuration seems to be ignored

2007-01-04 Thread szoftos at freemail dot hu
 ID:   40023
 User updated by:  szoftos at freemail dot hu
 Reported By:  szoftos at freemail dot hu
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Linux 2.4.33
 PHP Version:  5.2.0
 New Comment:

Hello Tony,

Thanks for replying me in such a short time. I am recompiling now the
php with that configuration option.

I was planning to add ulimit memory restriction to the php interpreter,
but now i'll try it that way.

Thanks again,
Laszlo


Previous Comments:


[2007-01-04 16:31:10] [EMAIL PROTECTED]

In PHP = 5.2.0 you need to add --enable-memory-limit to the configure
line first.
In later versions memory limit will be always enabled.



[2007-01-04 16:28:44] szoftos at freemail dot hu

Description:

the memory_limit in php.ini won't be taken in use in php 5.2.0

i have set up to 8M in the configuration file, but when i get a
phpinfo(), there is no memory_limit option in the configuration
options.

ini_get also won't return any value, and i have experienced that in
this way one script can eat up all memory, causing messages like this
in the kernel log:

kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
kernel: VM: killing process php
kernel: VM: killing process mysqld

meanwhile the whole machine hangs.

i'm using lighttpd, with fastcgi extension. php is running under the
username of the virtualhost's user.

i have tested this with another virtualhost on the server, i couldn't
see it on the other site too.

php compile options:

'./configure' '--enable-mbstring' '--disable-static' '--disable-debug'
'--enable-pic' '--enable-inline-optimization'
'--with-config-file-path=/etc/php5' '--enable-magic-quotes'
'--enable-debugger' '--enable-track-vars' '--enable-safe-mode'
'--with-regex=system' '--with-versioning' '--enable-sysvsem'
'--enable-sysvshm' '--with-mod_charset' '--enable-force-cgi-redirect'
'--without-mm' '--enable-trans-sid' '--with-dbase' '--with-filepro'
'--enable-yp' '--enable-ftp' '--with-xml' '--with-mysql=shared,/usr'
'--with-iconv' '--with-gettext' '--with-zlib=/usr'
'--with-gd=shared,/usr' '--with-mysql-sock=/tmp/mysql.sock'
'--enable-gd-native-ttf' '--with-png' '--with-ttf'
'--with-jpeg-dir=/usr' '--with-freetype-dir=/usr' '--with-xpm-dir=/usr'
'--enable-fastcgi' '--enable-cgi' '--enable-discard-path'

Reproduce code:
---
?
phpinfo();

ini_get('memory_limit');
?






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