Bug #65905 [Com]: [16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: Unknown: No such file or dir

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65905&edit=1

 ID: 65905
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:[16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: 
 Unknown: No such file or dir
 Status: No Feedback
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

WHAT FEEDBACK?

do you guys really not realize that the problem is the lacking knowledge of the 
involved script and so if i could give fedback the problem would not exist?


Previous Comments:

[2013-10-24 04:05:01] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.


[2013-10-17 05:04:01] spam2 at rhsoft dot net

> Not enough information was provided for us to be able to handle this bug

explain me how should i get more information?
*i need* more information from this damned error hanlder to handle *my bug* in 
one of 50 files

the error-handler has in *any case* contain the information of the affected 
script which is obviously thrown away - how comes that __FILE__ of the 
originally called script is thrown away and the error-handler only becomes a 
completly useless "in unknown"

so there are two choices:
* fi the error handler / scripting language that it contains informations
* shut up the error-hanlder in cases it has nothing useful to say

the whole error-reporting is broken
give out script names or shut up at all!

https://bugs.php.net/bug.php?id=65359
https://bugs.php.net/bug.php?id=65455


[2013-10-16 22:48:45] s...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Perhaps someone marked your other bug as 'spam' due to inappropriate content? I 
don't know. Anyway, I think you've made your point.

If you want some PHP language change to be made, please submit a testcase so we 
know exactly what is bugging you.

(If you have an application architectural issue, there are better places to 
resolve it than by logging a bug)

--------------------
[2013-10-15 23:35:24] spam2 at rhsoft dot net

Description:

you can call it as spam and request sample-code as often you want
*this* is fundamentally broken and if i would have a clue wich of some thousand 
scripts was triggred by a smarter error message i would be able to fix it

[16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning:  Unknown: No such file or 
directory in Unknown on line 0

PHP's whole error-handling is broken!
why? because it is *unacceptable* that the information which script was 
initailly called is thrown away before the error-handler and this happens on 
serveral places

Expected result:

at least the full qualified path of the inital script called on the server and 
in this case also the not found filename which was supplied and if you are so 
gently the called function too (fopen, fwrite, file.)

Actual result:
--
unknown in unknown on unknown






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

Bug #65786 [Com]: Unknown: No such file or directory in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65786&edit=1

 ID: 65786
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: No such file or directory in Unknown on
 line 0
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

the whole error-reporting is bullshit
give out script names or shut up at all!

https://bugs.php.net/bug.php?id=65359
https://bugs.php.net/bug.php?id=65455


Previous Comments:

[2013-09-29 23:18:16] spam2 at rhsoft dot net

> To properly diagnose the problem, we need a short but complete 
> example script to be able to reproducethis bug ourselves. 

you realize that the intention for my bugreprot is that with this idiotic 
"unknown in unknown on unknown" i can't smell which of a lot of thousands 
scripts on a server was called because PHP refues to give out *anything* 
helpful like *filenames* and in tjis case *name of the file which was not 
found*?

so you are asking for the inforamtion i woud like to have if the 
error-reporting of PHP would not be that broken


[2013-09-29 22:55:53] yohg...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

You should attach short and complete reproducible script.

Script name and/or line are not available sometimes.

----
[2013-09-29 14:15:14] spam2 at rhsoft dot net

Description:

what about log the *filename* which does not exist or at least the SERVER_NAME 
in which context the error happens or shut up with meaningless messages at all?

the whole php error-handling is full of such crap messages
there must not be "unknown in unknown" - what terrible language design

[29-Sep-2013 15:37:37 Europe/Vienna] PHP Warning: Unknown: No such file or 
directory in Unknown on line 0

Test script:
---
i don't know because these unhelpful error messages

Expected result:

giving informations or shutdown the error-message at all

Actual result:
--
unhelpful crap messages






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

Bug #65786 [Fbk->Opn]: Unknown: No such file or directory in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65786&edit=1

 ID: 65786
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: No such file or directory in Unknown on
 line 0
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

> To properly diagnose the problem, we need a short but complete 
> example script to be able to reproducethis bug ourselves. 

you realize that the intention for my bugreprot is that with this idiotic 
"unknown in unknown on unknown" i can't smell which of a lot of thousands 
scripts on a server was called because PHP refues to give out *anything* 
helpful like *filenames* and in tjis case *name of the file which was not 
found*?

so you are asking for the inforamtion i woud like to have if the 
error-reporting of PHP would not be that broken


Previous Comments:

[2013-09-29 22:55:53] yohg...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

You should attach short and complete reproducible script.

Script name and/or line are not available sometimes.

----
[2013-09-29 14:15:14] spam2 at rhsoft dot net

Description:

what about log the *filename* which does not exist or at least the SERVER_NAME 
in which context the error happens or shut up with meaningless messages at all?

the whole php error-handling is full of such crap messages
there must not be "unknown in unknown" - what terrible language design

[29-Sep-2013 15:37:37 Europe/Vienna] PHP Warning: Unknown: No such file or 
directory in Unknown on line 0

Test script:
---
i don't know because these unhelpful error messages

Expected result:

giving informations or shutdown the error-message at all

Actual result:
--
unhelpful crap messages






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

[PHP-BUG] Bug #65786 [NEW]: Unknown: No such file or directory in Unknown on line 0

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5.4.20
Package:  Filesystem function related
Bug Type: Bug
Bug description:Unknown: No such file or directory in Unknown on line 0

Description:

what about log the *filename* which does not exist or at least the
SERVER_NAME in which context the error happens or shut up with meaningless
messages at all?

the whole php error-handling is full of such crap messages
there must not be "unknown in unknown" - what terrible language design

[29-Sep-2013 15:37:37 Europe/Vienna] PHP Warning: Unknown: No such file or
directory in Unknown on line 0

Test script:
---
i don't know because these unhelpful error messages

Expected result:

giving informations or shutdown the error-message at all

Actual result:
--
unhelpful crap messages

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

Bug #64010 [Com]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64010&edit=1

 ID: 64010
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:htmlentities fundamentally broken in 5.4
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

and again a broken backend on a production server running E_ALL reporting 
because the braindead idiot who made this change was not smart enugh to throw a 
*warning* if it returs an empty string while the input was not empty

how stupid can developers act?


Previous Comments:

[2013-01-17 18:41:04] spam2 at rhsoft dot net

and last but not least WTF did whoever implemented the bullshit returning an 
emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that 
admins/developers which are running in E_ALL | E_STRICT since years smell if 
there something is still broken and need to get fixed?


[2013-01-17 13:35:36] spam2 at rhsoft dot net

and if you guys would be smart there would be an php.ini setting to specify the 
bahvior globally and/or per  instead hardcode incompatible changes 
breaking nearly ANY code written without wrappers


[2013-01-17 13:33:21] spam2 at rhsoft dot net

as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume 
that any input is UTF8 as default


[2013-01-17 13:23:21] ras...@php.net

If your page is ISO-8859-1 and you are using that as your internal encoding as 
well, then you need to specify that. Otherwise it leads to security issues. And 
since most people don't use ISO-8859-1 anymore, the safer default is to make 
sure 
we don't output invalid UTF-8 byte sequences when the developer has not 
specified 
the encoding.


[2013-01-17 13:08:28] spam2 at rhsoft dot net

and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it 
is fundamentally broken to return empty strings in a random number of funtions




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=64010


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

[PHP-BUG] Bug #65455 [NEW]: in Unknown on line 0

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: 
PHP version:  5.4.17
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:in Unknown on line 0

Description:

$response = imap_fetch_overview($mbox, $range);
Notice: Unknown: Sequence out of range (errflg=2) in Unknown on line 0

this is the same crap as https://bugs.php.net/bug.php?id=65359

and now do not tell me like in the othe rbugreport there is no script
running and nobody knows file / line of the call


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

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

> We don't have a reliable REQUEST_URI or such available. 
> We only have the version in $_SERVER which might be changed 
> by the user

which is more realiable as "in unknown"

> A way to improve the error might be saving the place 
> where a session is started, while that costs a tiny 
> bit of memory and CPU

the cost is not measureable and does even not exist in theory


Previous Comments:

[2013-08-10 21:14:44] johan...@php.net

We don't have a reliable REQUEST_URI or such available. We only have the 
version in $_SERVER which might be changed by the user. 

In shutdown we also have no idea of what might have been the "main" script - a 
SAPI can execute multiple files in a row (as auto_[ap|pre]pend_file do), 
apache_filter is an example.

A way to improve the error might be saving the place where a session is 
started, while that costs a tiny bit of memory and CPU.

--------------------
[2013-08-10 21:02:33] spam2 at rhsoft dot net

> This is not feasible option. If PHP should detect invalid 
> session data assignment, PHP should monitor every writes to 
> variable

WTF - nobody needs to monitor anything to know the script
which is called - the design flaw is that this information
well known as long the script is running is *thrown away*
before the last possible event triggering an error and over
years nobody spent a second to fix this

> Anyway, I may be able to add REQUEST_URI to the error. 
> Do you want it? 

that is what i request all the time

> It can be  retrieved via custom error handler, though.

not a option in case of *600* vhosts

> Another feasible option for you is that define user 
> error handler that ignores this error

another option would be fix PHP's internal error handler
that it shuts up in case it has nothing useful to say


[2013-08-10 20:50:36] yohg...@php.net

> so again: we do not need a *incompatible* new session handler, we need proper 
error-reporting and "in unknown" is always a *major bug* and design flaw

This is not feasible option. If PHP should detect invalid session data 
assignment, PHP should monitor every writes to variable, not only $_SESSION 
array, during execution only for "register_globals" limited serialize handler. 
There is no such API in PHP. If we made it, it slows down PHP and nobody is 
willing to do. (Technically, Zend engine provides handler for assignment. By 
using the API, anyone can make a module that detects invalid writes to 
$_SESSION)

It seems current documentation does not state that users are not able to save 
numeric index session vars (and other special chars). However, older documents 
explicitly states numeric session vars are prohibited/unsupported. It's our 
document bug, but this is the way it supposed to work.

Therefore, correct way of fixing this "*major bug* and design flaw" is 
introducing new serialize handler that is *not* bonded to register_globals. 

Anyway, I may be able to add REQUEST_URI to the error. Do you want it? It can 
be 
retrieved via custom error handler, though.  

Another feasible option for you is that define user error handler that ignores 
this error. Since we are not going to add new serialize handler to released 
branch, it would be most feasible option for you. Or write your own module that 
monitor assignments and raise error for invalid.


[2013-08-10 10:53:36] spam2 at rhsoft dot net

yes it is *saved* after script execution

but that is no excuse not store the script path and throw it out in the error 
message so someone knows which of the some hundret thousands scripts on the 
server is triggering the error to debug whatever application

so again: we do not need a *incompatible* new session handler, we need proper 
error-reporting and "in unknown" is always a *major bug* and design flaw


[2013-08-10 10:45:47] yohg...@php.net

Assigning numeric array index valid operation while it was not valid to have 
numeric variable names. That's the reason why old serializer do not allow to 
save 
such data. Session data is usually saved *after* scripts execution.

My patch should be 

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

> This is not feasible option. If PHP should detect invalid 
> session data assignment, PHP should monitor every writes to 
> variable

WTF - nobody needs to monitor anything to know the script
which is called - the design flaw is that this information
well known as long the script is running is *thrown away*
before the last possible event triggering an error and over
years nobody spent a second to fix this

> Anyway, I may be able to add REQUEST_URI to the error. 
> Do you want it? 

that is what i request all the time

> It can be  retrieved via custom error handler, though.

not a option in case of *600* vhosts

> Another feasible option for you is that define user 
> error handler that ignores this error

another option would be fix PHP's internal error handler
that it shuts up in case it has nothing useful to say


Previous Comments:

[2013-08-10 20:50:36] yohg...@php.net

> so again: we do not need a *incompatible* new session handler, we need proper 
error-reporting and "in unknown" is always a *major bug* and design flaw

This is not feasible option. If PHP should detect invalid session data 
assignment, PHP should monitor every writes to variable, not only $_SESSION 
array, during execution only for "register_globals" limited serialize handler. 
There is no such API in PHP. If we made it, it slows down PHP and nobody is 
willing to do. (Technically, Zend engine provides handler for assignment. By 
using the API, anyone can make a module that detects invalid writes to 
$_SESSION)

It seems current documentation does not state that users are not able to save 
numeric index session vars (and other special chars). However, older documents 
explicitly states numeric session vars are prohibited/unsupported. It's our 
document bug, but this is the way it supposed to work.

Therefore, correct way of fixing this "*major bug* and design flaw" is 
introducing new serialize handler that is *not* bonded to register_globals. 

Anyway, I may be able to add REQUEST_URI to the error. Do you want it? It can 
be 
retrieved via custom error handler, though.  

Another feasible option for you is that define user error handler that ignores 
this error. Since we are not going to add new serialize handler to released 
branch, it would be most feasible option for you. Or write your own module that 
monitor assignments and raise error for invalid.

----------------
[2013-08-10 10:53:36] spam2 at rhsoft dot net

yes it is *saved* after script execution

but that is no excuse not store the script path and throw it out in the error 
message so someone knows which of the some hundret thousands scripts on the 
server is triggering the error to debug whatever application

so again: we do not need a *incompatible* new session handler, we need proper 
error-reporting and "in unknown" is always a *major bug* and design flaw


[2013-08-10 10:45:47] yohg...@php.net

Assigning numeric array index valid operation while it was not valid to have 
numeric variable names. That's the reason why old serializer do not allow to 
save 
such data. Session data is usually saved *after* scripts execution.

My patch should be able to applied to PHP 5.4 cleanly. If you want it to be 
fixed 
seriously, apply my patch and use php_serialize. Beware that it won't work if 
you 
mix serializers on shared session data.

----------------
[2013-08-10 10:34:43] spam2 at rhsoft dot net

yeah, introduce new things and let the broken untouched broken is the way of 
PHP which leaded to all the troubles over the last 10 years - hence the real 
bug is that the info wich script was called is thrown away before the 
error_handler is raised and burry this problem with a new session_handler does 
not solve it

*there must not* be any place inside PHP where the error-handler says "in 
unknown" - it doe snot matter if the script has finished by raise the error, 
the fact is that the REQUEST has a URL and the error handler comes after the 
script was executed - so PHP has to store whereever the script path or fix the 
error_handler that it shut's up if it has nothing helpful to say


[2

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

yes it is *saved* after script execution

but that is no excuse not store the script path and throw it out in the error 
message so someone knows which of the some hundret thousands scripts on the 
server is triggering the error to debug whatever application

so again: we do not need a *incompatible* new session handler, we need proper 
error-reporting and "in unknown" is always a *major bug* and design flaw


Previous Comments:

[2013-08-10 10:45:47] yohg...@php.net

Assigning numeric array index valid operation while it was not valid to have 
numeric variable names. That's the reason why old serializer do not allow to 
save 
such data. Session data is usually saved *after* scripts execution.

My patch should be able to applied to PHP 5.4 cleanly. If you want it to be 
fixed 
seriously, apply my patch and use php_serialize. Beware that it won't work if 
you 
mix serializers on shared session data.

----
[2013-08-10 10:34:43] spam2 at rhsoft dot net

yeah, introduce new things and let the broken untouched broken is the way of 
PHP which leaded to all the troubles over the last 10 years - hence the real 
bug is that the info wich script was called is thrown away before the 
error_handler is raised and burry this problem with a new session_handler does 
not solve it

*there must not* be any place inside PHP where the error-handler says "in 
unknown" - it doe snot matter if the script has finished by raise the error, 
the fact is that the REQUEST has a URL and the error handler comes after the 
script was executed - so PHP has to store whereever the script path or fix the 
error_handler that it shut's up if it has nothing helpful to say


[2013-08-10 10:30:40] yohg...@php.net

> it is not possible to have request-uri

This one is workable option.


[2013-08-10 10:25:48] yohg...@php.net

> what we need is *NOT* a new session handler beause numeric indexes are 
braindead and so what we need is a clean error message

If I fixed the issue in current serialize handler, it will break apps. 
Therefore, new one is needed.

The reason you didn't get the error message is it was slightly failed.

I cannot do anything but introduce new serialize handler.

----------------
[2013-08-10 09:57:18] spam2 at rhsoft dot net

what we need is *NOT* a new session handler beause numeric indexes are 
braindead and so what we need is a clean error message and *NOBODY* can tell me 
that it is not possible to have request-uri and/or path of the script which is 
executed and if this is the case why in the world are tese data thrown away 
instead held in memory to give useful error messages

*OR* remove this idiotic warning from the code without forcing us to lower the 
error_reporting

"in Unknown on line 0" is laughable and PHP should simply sht up if it has 
nothing helful like file and line-numver to say - period




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=65359


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

Bug #65359 [Asn]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

yeah, introduce new things and let the broken untouched broken is the way of 
PHP which leaded to all the troubles over the last 10 years - hence the real 
bug is that the info wich script was called is thrown away before the 
error_handler is raised and burry this problem with a new session_handler does 
not solve it

*there must not* be any place inside PHP where the error-handler says "in 
unknown" - it doe snot matter if the script has finished by raise the error, 
the fact is that the REQUEST has a URL and the error handler comes after the 
script was executed - so PHP has to store whereever the script path or fix the 
error_handler that it shut's up if it has nothing helpful to say


Previous Comments:

[2013-08-10 10:30:40] yohg...@php.net

> it is not possible to have request-uri

This one is workable option.


[2013-08-10 10:25:48] yohg...@php.net

> what we need is *NOT* a new session handler beause numeric indexes are 
braindead and so what we need is a clean error message

If I fixed the issue in current serialize handler, it will break apps. 
Therefore, new one is needed.

The reason you didn't get the error message is it was slightly failed.

I cannot do anything but introduce new serialize handler.

----
[2013-08-10 09:57:18] spam2 at rhsoft dot net

what we need is *NOT* a new session handler beause numeric indexes are 
braindead and so what we need is a clean error message and *NOBODY* can tell me 
that it is not possible to have request-uri and/or path of the script which is 
executed and if this is the case why in the world are tese data thrown away 
instead held in memory to give useful error messages

*OR* remove this idiotic warning from the code without forcing us to lower the 
error_reporting

"in Unknown on line 0" is laughable and PHP should simply sht up if it has 
nothing helful like file and line-numver to say - period

------------
[2013-08-10 09:41:15] spam2 at rhsoft dot net

> See intern...@php.net archive for details. 
> It is under discussion now. If you would 
> like to see this in released version, you 
> should speak out now

i am not allowed to speak out on internals because the can not handle clear 
words and prefers endless discussions in cas of proposed backward compatibility 
changes and so i am blocked

however i do not understand the disussion - this is a bug and a regression 
somewhere because we have since 10 years "error_reporting = E_ALL | E_STRICT" 
and these messages are coming since the upgrade to PHP 5.4


[2013-08-10 09:21:12] yohg...@php.net

Related to Bug #42725




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=65359


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

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

what we need is *NOT* a new session handler beause numeric indexes are 
braindead and so what we need is a clean error message and *NOBODY* can tell me 
that it is not possible to have request-uri and/or path of the script which is 
executed and if this is the case why in the world are tese data thrown away 
instead held in memory to give useful error messages

*OR* remove this idiotic warning from the code without forcing us to lower the 
error_reporting

"in Unknown on line 0" is laughable and PHP should simply sht up if it has 
nothing helful like file and line-numver to say - period


Previous Comments:

[2013-08-10 09:41:15] spam2 at rhsoft dot net

> See intern...@php.net archive for details. 
> It is under discussion now. If you would 
> like to see this in released version, you 
> should speak out now

i am not allowed to speak out on internals because the can not handle clear 
words and prefers endless discussions in cas of proposed backward compatibility 
changes and so i am blocked

however i do not understand the disussion - this is a bug and a regression 
somewhere because we have since 10 years "error_reporting = E_ALL | E_STRICT" 
and these messages are coming since the upgrade to PHP 5.4


[2013-08-10 09:21:12] yohg...@php.net

Related to Bug #42725


[2013-08-10 09:08:08] yohg...@php.net

Related to Bug #49622


[2013-08-10 08:25:40] yohg...@php.net

Related to bug #43980


[2013-08-10 08:18:21] yohg...@php.net

Related to Bug #51127
Related to Bug #25630




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=65359


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

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

> See intern...@php.net archive for details. 
> It is under discussion now. If you would 
> like to see this in released version, you 
> should speak out now

i am not allowed to speak out on internals because the can not handle clear 
words and prefers endless discussions in cas of proposed backward compatibility 
changes and so i am blocked

however i do not understand the disussion - this is a bug and a regression 
somewhere because we have since 10 years "error_reporting = E_ALL | E_STRICT" 
and these messages are coming since the upgrade to PHP 5.4


Previous Comments:

[2013-08-10 09:21:12] yohg...@php.net

Related to Bug #42725


[2013-08-10 09:08:08] yohg...@php.net

Related to Bug #49622


[2013-08-10 08:25:40] yohg...@php.net

Related to bug #43980


[2013-08-10 08:18:21] yohg...@php.net

Related to Bug #51127
Related to Bug #25630


[2013-08-10 08:11:35] yohg...@php.net

> I was suggested to releasing new "php_serialize" serialize handler for 5.5 
(and 
5.4) that removes this limitation.

Sorry for broken English.
This should be something like

I proposed to release new ""php_serialize" serialize handler for 5.5 (and 
5.4) that removes this limitation to intern...@php.net.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=65359


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

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

so you tell me i will get the mails below twice a hour until PHP 5.6 is 
finished and rolled out on my servers? seriously?

and *yes* we are in production with error_reporting E_ALL + E_STRICT since 10 
years for currently 600 domains and yes since we devleop our own cms-systems it 
is reasonable to get such notifies because they are practically bugfree

 Original-Nachricht 
Betreff: Cron   php /scripts/rh_watchdog.php
Datum: Fri,  9 Aug 2013 11:30:01 +0200 (CEST)
Von: Cron Daemon 
An: root

[09-Aug-2013 11:00:35 Europe/Vienna] PHP Notice:  Unknown: Skipping numeric key 
1 in Unknown on line 0


Previous Comments:

[2013-08-09 09:11:28] yohg...@php.net

I'll commit new serialize handler "php_serialize" to master as the default in a 
few days.

This solves your problem, but the fix is only in Next PHP.


[2013-08-01 07:48:27] yohg...@php.net

I have plan to clean up encoding setting mess also.
I can understand your irritation :)

Anyway, if you are managing hundreds of domains, you should participate testing 
new minor version release process. Speak out what is going to be your problem 
to 
internals ML.


[2013-07-31 06:32:45] spam2 at rhsoft dot net

well, i see this first time after we upgraded to PHP 5.4 where no longer 
register_globals is available while we disabled it 10 years ago which took a 
lot of time prepare because the braindead change in htmlentities() return empty 
strings without any warnings if ISO-8859-1 is used and not explicit set as 
param (thanks again for such lowbrained backward compatibility break without a 
global setting to fix it)

and yes we have watchdogs mailing twice a hour any php-warning and E_ALL in 
production since years.


[2013-07-31 06:12:24] yohg...@php.net

This error is raised at R_SHUTDOWN (Request Shutdown) that is all script 
execution is *finished*. Therefore, there is no way to know which script caused 
this.

Current session module uses special serializer that do not accept numeric key. 
e.g. $_SESSION[1] = 'foo'; This limitation is came from register_globals.

I think it's safe that remove this limitation, but I have to look code again. I 
also have plan to use plain serializer for session.

--------
[2013-07-30 20:02:27] spam2 at rhsoft dot net

uhm at least the full path of the invoked script should be known
hence it would be even better if it only says the folder
but wild guessing on a server with 600 domains?

"so there's no active script anymore"

but someone / something invoked a script in which 
context whatever code runs




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=65359


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

Bug #65359 [Asn]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Assigned
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

well, i see this first time after we upgraded to PHP 5.4 where no longer 
register_globals is available while we disabled it 10 years ago which took a 
lot of time prepare because the braindead change in htmlentities() return empty 
strings without any warnings if ISO-8859-1 is used and not explicit set as 
param (thanks again for such lowbrained backward compatibility break without a 
global setting to fix it)

and yes we have watchdogs mailing twice a hour any php-warning and E_ALL in 
production since years.


Previous Comments:

[2013-07-31 06:12:24] yohg...@php.net

This error is raised at R_SHUTDOWN (Request Shutdown) that is all script 
execution is *finished*. Therefore, there is no way to know which script caused 
this.

Current session module uses special serializer that do not accept numeric key. 
e.g. $_SESSION[1] = 'foo'; This limitation is came from register_globals.

I think it's safe that remove this limitation, but I have to look code again. I 
also have plan to use plain serializer for session.


[2013-07-30 20:02:27] spam2 at rhsoft dot net

uhm at least the full path of the invoked script should be known
hence it would be even better if it only says the folder
but wild guessing on a server with 600 domains?

"so there's no active script anymore"

but someone / something invoked a script in which 
context whatever code runs


[2013-07-30 12:12:55] johan...@php.net

This error happens while encoding the session after request end, so there's no 
active script anymore. Not sure we can make it more verbose.

--------
[2013-07-30 11:35:52] spam2 at rhsoft dot net

Description:

PHP Notice:  Unknown: Skipping numeric key 1 in Unknown on line 0

it is ridiculous that PHP is thowing warnings and does not know at least the 
realpath of the executed script to choose one of the 600 possible involved 
vhosts







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

Bug #65359 [Com]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=65359&edit=1

 ID: 65359
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:Unknown: Skipping numeric key 1 in Unknown on line 0
 Status: Open
 Type:   Bug
 Package:Session related
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

uhm at least the full path of the invoked script should be known
hence it would be even better if it only says the folder
but wild guessing on a server with 600 domains?

"so there's no active script anymore"

but someone / something invoked a script in which 
context whatever code runs


Previous Comments:

[2013-07-30 12:12:55] johan...@php.net

This error happens while encoding the session after request end, so there's no 
active script anymore. Not sure we can make it more verbose.

----
[2013-07-30 11:35:52] spam2 at rhsoft dot net

Description:

PHP Notice:  Unknown: Skipping numeric key 1 in Unknown on line 0

it is ridiculous that PHP is thowing warnings and does not know at least the 
realpath of the executed script to choose one of the 600 possible involved 
vhosts







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

[PHP-BUG] Bug #65359 [NEW]: Unknown: Skipping numeric key 1 in Unknown on line 0

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: 
PHP version:  5.4.17
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Unknown: Skipping numeric key 1 in Unknown on line 0

Description:

PHP Notice:  Unknown: Skipping numeric key 1 in Unknown on line 0

it is ridiculous that PHP is thowing warnings and does not know at least
the realpath of the executed script to choose one of the 600 possible
involved vhosts


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

Bug #48880 [Com]: Random Appearing open_basedir problem

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=48880&edit=1

 ID: 48880
 Comment by: spam2 at rhsoft dot net
 Reported by:brwarner at rogers dot com
 Summary:Random Appearing open_basedir problem
 Status: Closed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   *
 PHP Version:5.3SVN-2009-07-27 (snap)
 Block user comment: N
 Private report: N

 New Comment:

https://github.com/zend-dev/ZendOptimizerPlus/issues/94
"opcache.use_cwd = 0" reintroduces https://bugs.php.net/bug.php?id=48880


Previous Comments:

[2013-05-11 15:19:30] spam2 at rhsoft dot net

easy to reproduce: 

* ab -c 30 -n 5 http://first-host/
* hit reload with disabled cache in your browser on the second vhost


[2013-05-11 15:14:18] spam2 at rhsoft dot net

i see this randomly with Apache 2.4.4 and PHP 5.4.14/5.4.15 on Fedora x86_64 
and it seems for me that this problem came back a short time ago because it is 
very new for me and i have this only seen with a PHP6-snapshot years ago until 
now


[2009-07-31 21:10:11] ras...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2009-07-31 21:09:46] s...@php.net

Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=286602
Log: Fix bug #48880
The ini entry was being corrupted because it wasn't being set
on the ACTIVATE and DEACTIVATE stages.


[2009-07-31 03:34:00] starcraftmazter at gmail dot com

I think this bug is closely related to 48744
http://bugs.php.net/bug.php?id=48744

To say what I said in the other bug report,

I can confirm that I have a very similar issue. I have been running PHP
with open_basedir for quite some time. I upgraded to php 5.3.0 recently,
previously having ran php 5.2.5. Immediately after installing the newly
compiled version, the issues began.

The problem as I experience it, is that the "open_basedir" setting seems
to be composed of random, non latin1 characters (displayed as symbols by
the browser). I cannot draw any reasons as to which users are affected
by this or why, but it does not happen to everyone - it is seemingly
random.

I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages
the open_basedir. I am using Apache 2.2.6.

My compile string is as follows;

'./configure' '--prefix=/usr/local'
'--with-apxs2=/usr/local/apache/bin/apxs' '--enable-bcmath'
'--enable-calendar' '--enable-exif' '--enable-ftp'
'--enable-gd-native-ttf' '--enable-libxml' '--enable-mbstring'
'--enable-soap' '--enable-sockets' '--enable-zip' '--with-bz2'
'--with-curl=/opt/curlssl/' '--with-curlwrappers'
'--with-freetype-dir=/usr' '--with-gd' '--with-gettext'
'--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr'
'--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64'
'--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/'
'--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/'
'--with-openssl-dir=/usr' '--with-pic' '--with-png-dir=/usr'
'--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib'
'--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-mysql'
'--with-mysqli' '--with-pgsql' '--with-sqlite=shared'
'--enable-pdo=shared' '--with-pdo-sqlite=shared'
'--with-pdo-mysql=shared' '--with-pdo-pgsql=shared'
'--with-magickwand=/usr/local/bin'

You can check other relevant settings here:
http://liway.com/test.php

For reference, here is the screenshot of the exact error message which
one of the accounts is getting, which shows the open_basedir setting
being composed of weird characters.
http://img75.imageshack.us/img75/6261/screenshot1a.png
The situation involves phpbb3 trying to include parts of itself, so I am
confident that it should be allowed, as it's in the same directory or
close directories within a single account home folder.

The second screenshot is of the relevant open_basedir setting in the
httpd.conf file. I have checked the settings ag

Bug #48880 [Com]: Random Appearing open_basedir problem

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=48880&edit=1

 ID: 48880
 Comment by: spam2 at rhsoft dot net
 Reported by:brwarner at rogers dot com
 Summary:Random Appearing open_basedir problem
 Status: Closed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   *
 PHP Version:5.3SVN-2009-07-27 (snap)
 Block user comment: N
 Private report: N

 New Comment:

easy to reproduce: 

* ab -c 30 -n 5 http://first-host/
* hit reload with disabled cache in your browser on the second vhost


Previous Comments:

[2013-05-11 15:14:18] spam2 at rhsoft dot net

i see this randomly with Apache 2.4.4 and PHP 5.4.14/5.4.15 on Fedora x86_64 
and it seems for me that this problem came back a short time ago because it is 
very new for me and i have this only seen with a PHP6-snapshot years ago until 
now


[2009-07-31 21:10:11] ras...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2009-07-31 21:09:46] s...@php.net

Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=286602
Log: Fix bug #48880
The ini entry was being corrupted because it wasn't being set
on the ACTIVATE and DEACTIVATE stages.


[2009-07-31 03:34:00] starcraftmazter at gmail dot com

I think this bug is closely related to 48744
http://bugs.php.net/bug.php?id=48744

To say what I said in the other bug report,

I can confirm that I have a very similar issue. I have been running PHP
with open_basedir for quite some time. I upgraded to php 5.3.0 recently,
previously having ran php 5.2.5. Immediately after installing the newly
compiled version, the issues began.

The problem as I experience it, is that the "open_basedir" setting seems
to be composed of random, non latin1 characters (displayed as symbols by
the browser). I cannot draw any reasons as to which users are affected
by this or why, but it does not happen to everyone - it is seemingly
random.

I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages
the open_basedir. I am using Apache 2.2.6.

My compile string is as follows;

'./configure' '--prefix=/usr/local'
'--with-apxs2=/usr/local/apache/bin/apxs' '--enable-bcmath'
'--enable-calendar' '--enable-exif' '--enable-ftp'
'--enable-gd-native-ttf' '--enable-libxml' '--enable-mbstring'
'--enable-soap' '--enable-sockets' '--enable-zip' '--with-bz2'
'--with-curl=/opt/curlssl/' '--with-curlwrappers'
'--with-freetype-dir=/usr' '--with-gd' '--with-gettext'
'--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr'
'--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64'
'--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/'
'--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/'
'--with-openssl-dir=/usr' '--with-pic' '--with-png-dir=/usr'
'--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib'
'--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-mysql'
'--with-mysqli' '--with-pgsql' '--with-sqlite=shared'
'--enable-pdo=shared' '--with-pdo-sqlite=shared'
'--with-pdo-mysql=shared' '--with-pdo-pgsql=shared'
'--with-magickwand=/usr/local/bin'

You can check other relevant settings here:
http://liway.com/test.php

For reference, here is the screenshot of the exact error message which
one of the accounts is getting, which shows the open_basedir setting
being composed of weird characters.
http://img75.imageshack.us/img75/6261/screenshot1a.png
The situation involves phpbb3 trying to include parts of itself, so I am
confident that it should be allowed, as it's in the same directory or
close directories within a single account home folder.

The second screenshot is of the relevant open_basedir setting in the
httpd.conf file. I have checked the settings against those in the
virtual hosts of other accounts where open_basedir works without errors,
and I can confirm that they are absolutely identical (apart from the
actual home directory).
http://img75.imageshack.us/img75/626/screenshot2w.png

Needless to say,

Bug #48880 [Com]: Random Appearing open_basedir problem

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=48880&edit=1

 ID: 48880
 Comment by: spam2 at rhsoft dot net
 Reported by:brwarner at rogers dot com
 Summary:Random Appearing open_basedir problem
 Status: Closed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   *
 PHP Version:5.3SVN-2009-07-27 (snap)
 Block user comment: N
 Private report: N

 New Comment:

i see this randomly with Apache 2.4.4 and PHP 5.4.14/5.4.15 on Fedora x86_64 
and it seems for me that this problem came back a short time ago because it is 
very new for me and i have this only seen with a PHP6-snapshot years ago until 
now


Previous Comments:

[2009-07-31 21:10:11] ras...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2009-07-31 21:09:46] s...@php.net

Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=286602
Log: Fix bug #48880
The ini entry was being corrupted because it wasn't being set
on the ACTIVATE and DEACTIVATE stages.


[2009-07-31 03:34:00] starcraftmazter at gmail dot com

I think this bug is closely related to 48744
http://bugs.php.net/bug.php?id=48744

To say what I said in the other bug report,

I can confirm that I have a very similar issue. I have been running PHP
with open_basedir for quite some time. I upgraded to php 5.3.0 recently,
previously having ran php 5.2.5. Immediately after installing the newly
compiled version, the issues began.

The problem as I experience it, is that the "open_basedir" setting seems
to be composed of random, non latin1 characters (displayed as symbols by
the browser). I cannot draw any reasons as to which users are affected
by this or why, but it does not happen to everyone - it is seemingly
random.

I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages
the open_basedir. I am using Apache 2.2.6.

My compile string is as follows;

'./configure' '--prefix=/usr/local'
'--with-apxs2=/usr/local/apache/bin/apxs' '--enable-bcmath'
'--enable-calendar' '--enable-exif' '--enable-ftp'
'--enable-gd-native-ttf' '--enable-libxml' '--enable-mbstring'
'--enable-soap' '--enable-sockets' '--enable-zip' '--with-bz2'
'--with-curl=/opt/curlssl/' '--with-curlwrappers'
'--with-freetype-dir=/usr' '--with-gd' '--with-gettext'
'--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr'
'--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64'
'--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/'
'--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/'
'--with-openssl-dir=/usr' '--with-pic' '--with-png-dir=/usr'
'--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib'
'--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-mysql'
'--with-mysqli' '--with-pgsql' '--with-sqlite=shared'
'--enable-pdo=shared' '--with-pdo-sqlite=shared'
'--with-pdo-mysql=shared' '--with-pdo-pgsql=shared'
'--with-magickwand=/usr/local/bin'

You can check other relevant settings here:
http://liway.com/test.php

For reference, here is the screenshot of the exact error message which
one of the accounts is getting, which shows the open_basedir setting
being composed of weird characters.
http://img75.imageshack.us/img75/6261/screenshot1a.png
The situation involves phpbb3 trying to include parts of itself, so I am
confident that it should be allowed, as it's in the same directory or
close directories within a single account home folder.

The second screenshot is of the relevant open_basedir setting in the
httpd.conf file. I have checked the settings against those in the
virtual hosts of other accounts where open_basedir works without errors,
and I can confirm that they are absolutely identical (apart from the
actual home directory).
http://img75.imageshack.us/img75/626/screenshot2w.png

Needless to say, this is a very serious issue, as open_basedir is an
extremely important security measure for those of us who don't run
suPHP, and now it is impossible to use it because of these problems.

I'm available daily for testing, hope this bug report

Bug #54410 [Com]: Path-related magic constants empty when CLI invoked with -H switch

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=54410&edit=1

 ID: 54410
 Comment by: spam2 at rhsoft dot net
 Reported by:vedad at kajtaz dot net
 Summary:Path-related magic constants empty when CLI invoked
 with -H switch
 Status: Not a bug
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   FreeBSD 7.1
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

so this is now 2 years old and the only repsonse about -H switch doe snot 
exists is simply bogus


Previous Comments:

[2013-04-10 10:04:50] spam2 at rhsoft dot net

besides the fact that this affects also 5.4.13 and there is a -H flag
i had yesterday the same problem in CLI-scripts with using __DIR__ and __FILE__ 
inside of __construct() which i can not really reproduce with my sample code 
below and it did only happen in CLI mode

workaround because i get the same info with the class-name BUT a workaround:
FAILED: $this->module_basedir = basename(dirname(__FILE__));
WORKED: $this->module_basedir = substr(__CLASS__, 3);


[harry@rh:~]$ php --help | grep Hide
 -H Hide any passed arguments from external tools
__

[wwwcron@rh:~]$ umask 006; nice -n 19 ionice -c 3 php -H 
/www/beta.rhsoft.net/classloader/index.php

Warning: require(/modules/test/api_test.php): failed to open stream: No such 
file or directory in  on line 8

Fatal error: require(): Failed opening required '/modules/test/api_test.php' 
(include_path='.:/Volumes/dune/www-servers/phpincludes:/usr/share/pear:/usr/share/php')
 in  on line 8
__

[wwwcron@rh:~]$ umask 006; nice -n 19 ionice -c 3 php 
/www/beta.rhsoft.net/classloader/index.php
DIRNAME: /mnt/data/www/beta.rhsoft.net/classloader/modules/test  test
__

SAMPLE CODE:

[harry@rh:/www/beta.rhsoft.net/classloader]$ cat index.php 
test->test('test');
 class api_class
 {
  public function __get($subclass)
  {
   require(__DIR__ . '/modules/' . $subclass . '/api_' . $subclass . '.php');
   $class_name = 'cl_' . $subclass;
   $this->$subclass = new $class_name();
   return $this->$subclass;
  }
 }
?>

[harry@rh:/www/beta.rhsoft.net/classloader]$ cat modules/test/api_test.php 
cl_api = &$GLOBALS['cl_api'];
   echo 'DIRNAME: ' . dirname(__FILE__) . '  ';
  }

  public function test($input_value)
  {
   return $input_value;
  }
 }
?>


[2011-06-06 10:14:15] vedad at kajtaz dot net

Hi,

The -H flag does exist, and is documented.

http://php.net/manual/en/features.commandline.options.php

 -H   Hide any passed arguments from external tools.

Regards,


[2011-06-05 23:23:40] il...@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

there is no -H flag, Using an un-known flag triggers an error condition, which 
causes PHP to only show the available list of flags and not execute the script.


[2011-03-28 17:28:05] vedad at kajtaz dot net

Description:

When invoking a script with CLI -H switch, __FILE__ and some other magic 
constants 
resolve to empty strings.

Test script:
---
# cat > /tmp/test.php

^D

# php /tmp/test.php
'/tmp/test.php'

# php -H /tmp/test.php
''








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

Bug #54410 [Com]: Path-related magic constants empty when CLI invoked with -H switch

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=54410&edit=1

 ID: 54410
 Comment by: spam2 at rhsoft dot net
 Reported by:vedad at kajtaz dot net
 Summary:Path-related magic constants empty when CLI invoked
 with -H switch
 Status: Not a bug
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   FreeBSD 7.1
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

besides the fact that this affects also 5.4.13 and there is a -H flag
i had yesterday the same problem in CLI-scripts with using __DIR__ and __FILE__ 
inside of __construct() which i can not really reproduce with my sample code 
below and it did only happen in CLI mode

workaround because i get the same info with the class-name BUT a workaround:
FAILED: $this->module_basedir = basename(dirname(__FILE__));
WORKED: $this->module_basedir = substr(__CLASS__, 3);


[harry@rh:~]$ php --help | grep Hide
 -H Hide any passed arguments from external tools
__

[wwwcron@rh:~]$ umask 006; nice -n 19 ionice -c 3 php -H 
/www/beta.rhsoft.net/classloader/index.php

Warning: require(/modules/test/api_test.php): failed to open stream: No such 
file or directory in  on line 8

Fatal error: require(): Failed opening required '/modules/test/api_test.php' 
(include_path='.:/Volumes/dune/www-servers/phpincludes:/usr/share/pear:/usr/share/php')
 in  on line 8
__

[wwwcron@rh:~]$ umask 006; nice -n 19 ionice -c 3 php 
/www/beta.rhsoft.net/classloader/index.php
DIRNAME: /mnt/data/www/beta.rhsoft.net/classloader/modules/test  test
__

SAMPLE CODE:

[harry@rh:/www/beta.rhsoft.net/classloader]$ cat index.php 
test->test('test');
 class api_class
 {
  public function __get($subclass)
  {
   require(__DIR__ . '/modules/' . $subclass . '/api_' . $subclass . '.php');
   $class_name = 'cl_' . $subclass;
   $this->$subclass = new $class_name();
   return $this->$subclass;
  }
 }
?>

[harry@rh:/www/beta.rhsoft.net/classloader]$ cat modules/test/api_test.php 
cl_api = &$GLOBALS['cl_api'];
   echo 'DIRNAME: ' . dirname(__FILE__) . '  ';
  }

  public function test($input_value)
  {
   return $input_value;
  }
 }
?>


Previous Comments:

[2011-06-06 10:14:15] vedad at kajtaz dot net

Hi,

The -H flag does exist, and is documented.

http://php.net/manual/en/features.commandline.options.php

 -H   Hide any passed arguments from external tools.

Regards,


[2011-06-05 23:23:40] il...@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

there is no -H flag, Using an un-known flag triggers an error condition, which 
causes PHP to only show the available list of flags and not execute the script.


[2011-03-28 17:28:05] vedad at kajtaz dot net

Description:

When invoking a script with CLI -H switch, __FILE__ and some other magic 
constants 
resolve to empty strings.

Test script:
---
# cat > /tmp/test.php

^D

# php /tmp/test.php
'/tmp/test.php'

# php -H /tmp/test.php
''








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

Bug #64582 [Opn]: file_get_contents() handles redirects wrong

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64582&edit=1

 ID: 64582
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:file_get_contents() handles redirects wrong
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

i know that, but it is not that easy to generate everytime a full qualified URL 
and since any other http-client translates the ../ PHP should act the same way


Previous Comments:

[2013-04-04 15:53:58] johan...@php.net

RFC 2616 Section 14.30 requires "a single absolute URI." for the location 
header. Any relative location is not standards compliant.


[2013-04-04 14:55:58] spam2 at rhsoft dot net

Description:

[line "182"] [id "950103"] [msg "path traversal attack"] [data "../"] [hostname 
"test.test.rh"] [uri "/contentlounge/updateservice/cms_demo/cms//../cms.php"] 
[unique_id "UV2MrQoAAGMAAE356XkF"]


in the folder /cms is a simple index.php with header('Location: ../cms.php');
every normal browser translates path and does not trigger modsec
php triggers the "path traversal"-rule


Expected result:

call the URL /contentlounge/updateservice/cms_demo/cms/cms.php

Actual result:
--
calling the URL /contentlounge/updateservice/cms_demo/cms//../cms.php






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

[PHP-BUG] Bug #64582 [NEW]: file_get_contents() handles redirects wrong

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5.4.13
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:file_get_contents() handles redirects wrong

Description:

[line "182"] [id "950103"] [msg "path traversal attack"] [data "../"]
[hostname "test.test.rh"] [uri
"/contentlounge/updateservice/cms_demo/cms//../cms.php"] [unique_id
"UV2MrQoAAGMAAE356XkF"]


in the folder /cms is a simple index.php with header('Location:
../cms.php');
every normal browser translates path and does not trigger modsec
php triggers the "path traversal"-rule


Expected result:

call the URL /contentlounge/updateservice/cms_demo/cms/cms.php

Actual result:
--
calling the URL /contentlounge/updateservice/cms_demo/cms//../cms.php

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

Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=60723&edit=1

 ID: 60723
 Comment by: spam2 at rhsoft dot net
 Reported by:olemarkus at gentoo dot org
 Summary:error_log error time has changed to UTC ignoring
 default timezo
 Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Gentoo Linux
 PHP Version:5.3.9
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

i do not see anything fixed 
errorlog still contains the timezone

PHP 5.3.21 as also 5.4.11

[28-Jan-2013 16:22:38 Europe/Vienna] PHP Parse error:  syntax error, unexpected 
end of file in Command line code on line 1

the sysadmin knows his timezone well enough...


Previous Comments:

[2012-10-10 21:19:40] pixelchutes at gmail dot com

Should hopefully be released in 5.3.18, since 5.3.17 was released just a few 
days 
before the patch was committed (13-Sep-2012 vs 23-Sep-2012). Glad to hear this 
has been resolved, thanks!


[2012-09-24 03:04:55] larue...@php.net

hey, committed to 5.3 5.4 branches, will fixed in next release, thanks


[2012-09-24 03:01:30] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=923511d364ad84500bb097aca15385129ce6e336
Log: Fixed bug #60723 (error_log error time has changed to UTC ignoring default 
timezo)


[2012-09-24 03:01:10] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=923511d364ad84500bb097aca15385129ce6e336
Log: Fixed bug #60723 (error_log error time has changed to UTC ignoring default 
timezo)


[2012-09-24 02:59:23] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=923511d364ad84500bb097aca15385129ce6e336
Log: Fixed bug #60723 (error_log error time has changed to UTC ignoring default 
timezo)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60723


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

Bug #64010 [Com]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64010&edit=1

 ID: 64010
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:htmlentities fundamentally broken in 5.4
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

and last but not least WTF did whoever implemented the bullshit returning an 
emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that 
admins/developers which are running in E_ALL | E_STRICT since years smell if 
there something is still broken and need to get fixed?


Previous Comments:

[2013-01-17 13:35:36] spam2 at rhsoft dot net

and if you guys would be smart there would be an php.ini setting to specify the 
bahvior globally and/or per  instead hardcode incompatible changes 
breaking nearly ANY code written without wrappers


[2013-01-17 13:33:21] spam2 at rhsoft dot net

as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume 
that any input is UTF8 as default


[2013-01-17 13:23:21] ras...@php.net

If your page is ISO-8859-1 and you are using that as your internal encoding as 
well, then you need to specify that. Otherwise it leads to security issues. And 
since most people don't use ISO-8859-1 anymore, the safer default is to make 
sure 
we don't output invalid UTF-8 byte sequences when the developer has not 
specified 
the encoding.


[2013-01-17 13:08:28] spam2 at rhsoft dot net

and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it 
is fundamentally broken to return empty strings in a random number of funtions

----
[2013-01-17 12:40:25] spam2 at rhsoft dot net

WTF - why can i not submit a simple zip containing the spmale input 
base64_encoded in a seperate file because here you have only the
option to attach patches




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=64010


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

[PHP-BUG] Bug #64011 [NEW]: PHP 5.4 BREAKS get_html_translation_table()

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: 
PHP version:  5.4.10
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:PHP 5.4 BREAKS get_html_translation_table()

Description:

the 5.4 return value can not be seriously

hopefully at least "Returns the translation table used by 
htmlspecialchars() and htmlentities()" is NOT true

however, this breaks dialogs for special chars using
this table and insert the enitity in the HTML code

realize that not every page out there is UTF8 and never will be
_

PHP 5.4:

php -r "print_r(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES,
'ISO8859-1'));"
Array
(
["] => "
[&] => &
['] => '
[<] => <
[>] => >
)
_

PHP 5.3:

php -r "print_r(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES,
'ISO8859-1'));"
Array
(
[ ] =>  
[¡] => ¡
[¢] => ¢
[£] => £
[¤] => ¤
[Â¥] => ¥
[¦] => ¦
[§] => §
[¨] => ¨
[©] => ©
[ª] => ª
[«] => «
[¬] => ¬
[­] => ­
[®] => ®
[¯] => ¯
[°] => °
[±] => ±
[²] => ²
[³] => ³
[´] => ´
[µ] => µ
[¶] => ¶
[·] => ·
[¸] => ¸
[¹] => ¹
[º] => º
[»] => »
[¼] => ¼
[½] => ½
[¾] => ¾
[¿] => ¿
[À] => [Á] => Á
[Â] => Â
[Ã] => Ã
[Ä] => Ä
[Å] => Å
[Æ] => Æ
[Ç] => Ç
[È] => È
[É] => É
[Ê] => Ê
[Ë] => Ë
[Ì] => Ì
[Í] => Í
[Î] => Î
[Ï] => Ï
[Ð] => Ð
[Ñ] => Ñ
[Ò] => Ò
[Ó] => Ó
[Ô] => Ô
[Õ] => Õ
[Ö] => Ö
[×] => ×
[Ø] => Ø
[Ù] => Ù
[Ú] => Ú
[Û] => Û
[Ü] => Ü
[Ý] => Ý
[Þ] => Þ
[ß] => ß
[à] => à
[á] => á
[â] => â
[ã] => ã
[ä] => ä
[Ã¥] => å
[æ] => æ
[ç] => ç
[è] => è
[é] => é
[ê] => ê
[ë] => ë
[ì] => ì
[í] => í
[î] => î
[ï] => ï
[ð] => ð
[ñ] => ñ
[ò] => ò
[ó] => ó
[ô] => ô
[õ] => õ
[ö] => ö
[÷] => ÷
[ø] => ø
[ù] => ù
[ú] => ú
[û] => û
[ü] => ü
[ý] => ý
[þ] => þ
[ÿ] => ÿ
[&] => &
["] => "
['] => '
[<] => <
[>] => >
)


Test script:
---
php -r "print_r(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES,
'ISO8859-1'));"

Expected result:

the full entity table like it worked for many years

Actual result:
--
a crippled array

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

Bug #64010 [Com]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64010&edit=1

 ID: 64010
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:htmlentities fundamentally broken in 5.4
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

and if you guys would be smart there would be an php.ini setting to specify the 
bahvior globally and/or per  instead hardcode incompatible changes 
breaking nearly ANY code written without wrappers


Previous Comments:

[2013-01-17 13:33:21] spam2 at rhsoft dot net

as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume 
that any input is UTF8 as default


[2013-01-17 13:23:21] ras...@php.net

If your page is ISO-8859-1 and you are using that as your internal encoding as 
well, then you need to specify that. Otherwise it leads to security issues. And 
since most people don't use ISO-8859-1 anymore, the safer default is to make 
sure 
we don't output invalid UTF-8 byte sequences when the developer has not 
specified 
the encoding.


[2013-01-17 13:08:28] spam2 at rhsoft dot net

and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it 
is fundamentally broken to return empty strings in a random number of funtions

----
[2013-01-17 12:40:25] spam2 at rhsoft dot net

WTF - why can i not submit a simple zip containing the spmale input 
base64_encoded in a seperate file because here you have only the
option to attach patches

----
[2013-01-17 12:36:29] spam2 at rhsoft dot net

Description:

> Like htmlspecialchars(), htmlentities() takes an optional third 
> argument encoding which defines encoding used in conversion. If 
> omitted, the default value for this argument is ISO-8859-1 in 
> versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards

and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back 

[harry@rh:/downloads/htmlentities]$ ./test.php 

strlen($input):
4464

strlen(htmlentities($input, ENT_QUOTES)):
0

strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522


Test script:
---
#!/usr/bin/php


Expected result:

NON-EMPTY reuturn value







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

Bug #64010 [Com]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64010&edit=1

 ID: 64010
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:htmlentities fundamentally broken in 5.4
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume 
that any input is UTF8 as default


Previous Comments:

[2013-01-17 13:23:21] ras...@php.net

If your page is ISO-8859-1 and you are using that as your internal encoding as 
well, then you need to specify that. Otherwise it leads to security issues. And 
since most people don't use ISO-8859-1 anymore, the safer default is to make 
sure 
we don't output invalid UTF-8 byte sequences when the developer has not 
specified 
the encoding.


[2013-01-17 13:08:28] spam2 at rhsoft dot net

and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it 
is fundamentally broken to return empty strings in a random number of funtions

----
[2013-01-17 12:40:25] spam2 at rhsoft dot net

WTF - why can i not submit a simple zip containing the spmale input 
base64_encoded in a seperate file because here you have only the
option to attach patches

----
[2013-01-17 12:36:29] spam2 at rhsoft dot net

Description:

> Like htmlspecialchars(), htmlentities() takes an optional third 
> argument encoding which defines encoding used in conversion. If 
> omitted, the default value for this argument is ISO-8859-1 in 
> versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards

and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back 

[harry@rh:/downloads/htmlentities]$ ./test.php 

strlen($input):
4464

strlen(htmlentities($input, ENT_QUOTES)):
0

strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522


Test script:
---
#!/usr/bin/php


Expected result:

NON-EMPTY reuturn value







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

Bug #64010 [Com]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64010&edit=1

 ID: 64010
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:htmlentities fundamentally broken in 5.4
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it 
is fundamentally broken to return empty strings in a random number of funtions


Previous Comments:

[2013-01-17 12:40:25] spam2 at rhsoft dot net

WTF - why can i not submit a simple zip containing the spmale input 
base64_encoded in a seperate file because here you have only the
option to attach patches


[2013-01-17 12:36:29] spam2 at rhsoft dot net

Description:

> Like htmlspecialchars(), htmlentities() takes an optional third 
> argument encoding which defines encoding used in conversion. If 
> omitted, the default value for this argument is ISO-8859-1 in 
> versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards

and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back 

[harry@rh:/downloads/htmlentities]$ ./test.php 

strlen($input):
4464

strlen(htmlentities($input, ENT_QUOTES)):
0

strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522


Test script:
---
#!/usr/bin/php


Expected result:

NON-EMPTY reuturn value







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

Bug #64010 [Com]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=64010&edit=1

 ID: 64010
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:htmlentities fundamentally broken in 5.4
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

WTF - why can i not submit a simple zip containing the spmale input 
base64_encoded in a seperate file because here you have only the
option to attach patches


Previous Comments:

[2013-01-17 12:36:29] spam2 at rhsoft dot net

Description:

> Like htmlspecialchars(), htmlentities() takes an optional third 
> argument encoding which defines encoding used in conversion. If 
> omitted, the default value for this argument is ISO-8859-1 in 
> versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards

and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back 

[harry@rh:/downloads/htmlentities]$ ./test.php 

strlen($input):
4464

strlen(htmlentities($input, ENT_QUOTES)):
0

strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522


Test script:
---
#!/usr/bin/php


Expected result:

NON-EMPTY reuturn value







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

[PHP-BUG] Bug #64010 [NEW]: htmlentities fundamentally broken in 5.4

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5.4.10
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:htmlentities fundamentally broken in 5.4

Description:

> Like htmlspecialchars(), htmlentities() takes an optional third 
> argument encoding which defines encoding used in conversion. If 
> omitted, the default value for this argument is ISO-8859-1 in 
> versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards

and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back 

[harry@rh:/downloads/htmlentities]$ ./test.php 

strlen($input):
4464

strlen(htmlentities($input, ENT_QUOTES)):
0

strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522


Test script:
---
#!/usr/bin/php


Expected result:

NON-EMPTY reuturn value


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

[PHP-BUG] Bug #64000 [NEW]: PLEASE can someone update this

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5.4.10
Package:  Compile Failure
Bug Type: Bug
Bug description:PLEASE can someone update this

Description:

this extension was not updated over many years and at least with recent
operating systems / php v ersions it does no longer compile :-(

/bin/sh /home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/libtool
--mode=compile x86_64-redhat-linux-gcc  -I.
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2 -DPHP_ATOM_INC
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/include
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/main
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2
-I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM
-I/usr/include/php/Zend -I/usr/include/php/ext
-I/usr/include/php/ext/date/lib  -DHAVE_CONFIG_H  -O3 -march=corei7
-mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -fopenmp
-mfpmath=sse -pipe -fstack-protector --param=ssp-buffer-size=4 -mfpmath=sse
-D_FORTIFY_SOURCE=2 -fexceptions   -c
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c -o id3.lo 
libtool: compile:  x86_64-redhat-linux-gcc -I.
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2 -DPHP_ATOM_INC
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/include
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/main
-I/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2
-I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM
-I/usr/include/php/Zend -I/usr/include/php/ext
-I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -O3 -march=corei7
-mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -fopenmp
-mfpmath=sse -pipe -fstack-protector --param=ssp-buffer-size=4 -mfpmath=sse
-D_FORTIFY_SOURCE=2 -fexceptions -c
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c  -fPIC -DPIC
-o .libs/id3.o
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:196:1: error:
unknown type name 'function_entry'
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: braces around scalar initializer [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: (near initialization for 'id3_functions[0]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: initialization makes integer from pointer without a cast [enabled
by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: (near initialization for 'id3_functions[0]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2: error:
initializer element is not computable at load time
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2: error:
(near initialization for 'id3_functions[0]')
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: excess elements in scalar initializer [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: (near initialization for 'id3_functions[0]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: excess elements in scalar initializer [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: (near initialization for 'id3_functions[0]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: excess elements in scalar initializer [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: (near initialization for 'id3_functions[0]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: excess elements in scalar initializer [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:197:2:
warning: (near initialization for 'id3_functions[0]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2:
warning: braces around scalar initializer [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2:
warning: (near initialization for 'id3_functions[1]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2:
warning: initialization makes integer from pointer without a cast [enabled
by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2:
warning: (near initialization for 'id3_functions[1]') [enabled by default]
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2: error:
initializer element is not computable at load time
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2: error:
(near initialization for 'id3_functions[1]')
/home/builduser/rpmbuild/BUILD/php-pecl-id3-0.2/id3-0.2/id3.c:198:2:
warning: 

Bug #52312 [Com]: PHP safe_mode/open_basedir - lstat performance problem

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=52312&edit=1

 ID: 52312
 Comment by: spam2 at rhsoft dot net
 Reported by:v dot damore at gmail dot com
 Summary:PHP safe_mode/open_basedir - lstat performance
 problem
 Status: Analyzed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 New Comment:

why the hell is a extern extension need to disable this "security feature" 
nobody needs who dsiables symlink() at all? this is only a bad joke in my 
opinion!


Previous Comments:

[2011-08-16 18:52:34] spam2 at rhsoft dot net

> Caching open_basedir stats is insecure

not really because the permissions are not changed the whole day


[2011-07-03 21:21:21] ras...@php.net

I really don't see a middle ground here. You are either secure or you aren't. 
Caching open_basedir stats is insecure and the whole point of open_basedir in a 
shared hosting setup is to secure these file accesses. If you don't care about 
security, turn it off and live with the security issue, or better yet, change 
your shared hosting setup to use VMs or other lower-level strategies that keep 
users separated from each other.


[2011-07-03 20:24:57] css at morefoo dot com

Hello,

Not much more than a "me too", sorry.  Is there any plan in the works to make 
php 
both safe in a mass hosting setup as well as not take a big performance hit 
when 
running webapps with a large number of "require" and "include" functions?  I'm 
running php 5.3.6 and still seeing a huge amount of cpu time spent in "system" 
on 
common web apps like Joomla, Drupal and C5.  Not seeing a clear solution that 
works well on a shared hosting setup.


[2011-06-02 15:01:13] aargoth at boo dot pl

You can simply use this PHP extension to bypass default security checks 
mentioned in comments above.

http://php.webtutor.pl/en/2011/06/02/running-php-on-nfs-huge-performance-problems-and-one-simple-solution/


[2011-04-05 18:27:16] cedric at yterium dot com

As a matter of fact, same performance problem occurs with PHP Version 5.3.3 on 
Debian Squeeze.

On our test plateform (with an SSD disk) a small bench show that the penalties 
of using open_basedir is more than small on real case application.

Base configuration :
ab -n200 -c20 http://benchb.xxx.yy/
Requests per second:266.45 [#/sec] (mean)
After open_basedir activation :
Requests per second:82.95 [#/sec] (mean)

Recompiling with --disable-phar doesn't reduce the performance gap.
Recompiling after patching main/main.c with comment on both occurences of :
//CWDG(realpath_cache_size_limit) = 0;

allows to reach an acceptable performance :
Requests per second:178.27 [#/sec] (mean)

By increasing the realpath cache, we can at last reach a smaller penalty :
Requests per second:220.69 [#/sec] (mean)

Our tries tu use open_basedir on NFS leads us to more dramatic situation.

Can we expect a fix for a better situation in further PHP versions ?
Maybe this realpath cache de-activation could be a default setting in case of 
open_basedir with the ability of re-activating without need of recompiling.

I know this can be a security hole, but maybe it's better to give an 
intermediate choice between on/off. 

I'm affraid that in the current situation, activating open_basedir is not 
really an acceptable choice due to the performance struggling, and I think 
that's worse for security.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=52312


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

Bug #55804 [Opn]: tempnam(): wrong fallback to /tmp

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=55804&edit=1

 ID: 55804
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:tempnam(): wrong fallback to /tmp
 Status: Open
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

your definition of "easy solution" is a little bit strange
how can it be easy to set a ENV-Var for 500 domains where
only most of them use docroot/temp/

a smarter fallback would be the configured uploadtemp but not /tmp


Previous Comments:

[2011-09-28 09:28:44] paj...@php.net

I was wrong about the removal, that's only for tmpfile.

The rest of my comment remains (BC break and easy solution).


[2011-09-28 09:22:29] spam2 at rhsoft dot net

they are not removed or how should a stat-call in a terminal show that they are 
existing? anyways - they must not be created

Warning: fopen() [function.fopen.php]: open_basedir restriction in effect. 
File(/tmp/rhcsv5f9RIs) is not within the
allowed path(s): 
(/mnt/data/www/beta.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/var/www/uploadtemp)
 in
/mnt/data/www/beta.rhsoft.net/tempname.php on line 6
Warning: fopen(/tmp/rhcsv5f9RIs) [function.fopen.php]: failed to open stream: 
Operation not permitted in
/mnt/data/www/beta.rhsoft.net/tempname.php on line 6

[harry@srv-rhsoft:~]$ stat /tmp/rhcsv5f9RIs
  Datei: „/tmp/rhcsv5f9RIs“
  Größe: 0  Blöcke: 0  EA Block: 4096   reguläre leere 
Datei
Gerät: 809h/2057d   Inode: 48  Verknüpfungen: 1
Zugriff: (0600/-rw---)  Uid: (   48/  apache)   Gid: (   48/  apache)
Zugriff: 2011-09-28 08:58:01.046916064 +0200
Modifiziert: 2011-09-28 08:58:01.046916064 +0200
Geändert   : 2011-09-28 08:58:01.046916064 +0200


[2011-09-28 09:14:51] paj...@php.net

if the files are not removed on request or sapi shutdown, then we have a bug.


[2011-09-28 09:13:01] spam2 at rhsoft dot net

> Documented behavior, changing it will break BC

what sort of BC?
the created file is outside open_basedir, can not be used and can not be deleted
so this file is useless and simply at the wrong location
i can not imagine any code which useful relies on that "feature"


[2011-09-28 09:09:51] paj...@php.net

Documented behavior, changing it will break BC.

To correctly configure the temp directory in each host is a the way to go for 
now.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55804


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

Bug #55804 [Opn]: tempnam(): wrong fallback to /tmp

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=55804&edit=1

 ID: 55804
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:tempnam(): wrong fallback to /tmp
 Status: Open
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

they are not removed or how should a stat-call in a terminal show that they are 
existing? anyways - they must not be created

Warning: fopen() [function.fopen.php]: open_basedir restriction in effect. 
File(/tmp/rhcsv5f9RIs) is not within the
allowed path(s): 
(/mnt/data/www/beta.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/var/www/uploadtemp)
 in
/mnt/data/www/beta.rhsoft.net/tempname.php on line 6
Warning: fopen(/tmp/rhcsv5f9RIs) [function.fopen.php]: failed to open stream: 
Operation not permitted in
/mnt/data/www/beta.rhsoft.net/tempname.php on line 6

[harry@srv-rhsoft:~]$ stat /tmp/rhcsv5f9RIs
  Datei: „/tmp/rhcsv5f9RIs“
  Größe: 0  Blöcke: 0  EA Block: 4096   reguläre leere 
Datei
Gerät: 809h/2057d   Inode: 48  Verknüpfungen: 1
Zugriff: (0600/-rw---)  Uid: (   48/  apache)   Gid: (   48/  apache)
Zugriff: 2011-09-28 08:58:01.046916064 +0200
Modifiziert: 2011-09-28 08:58:01.046916064 +0200
Geändert   : 2011-09-28 08:58:01.046916064 +0200


Previous Comments:

[2011-09-28 09:14:51] paj...@php.net

if the files are not removed on request or sapi shutdown, then we have a bug.


[2011-09-28 09:13:01] spam2 at rhsoft dot net

> Documented behavior, changing it will break BC

what sort of BC?
the created file is outside open_basedir, can not be used and can not be deleted
so this file is useless and simply at the wrong location
i can not imagine any code which useful relies on that "feature"


[2011-09-28 09:09:51] paj...@php.net

Documented behavior, changing it will break BC.

To correctly configure the temp directory in each host is a the way to go for 
now.


[2011-09-28 09:05:35] spam2 at rhsoft dot net

Description:

tempnam() should NOT fall back to /tmp if the $dir-param is explicit set to a 
real-path inside the open_basedir and because of wrong permissions $dir is not 
writeable

Test script:
---


Expected result:

error message that $dir is not writeable

Actual result:
--
temporary file is created in /tmp which violates open_basedir and fopen() is 
failing with open_basedir restriction messages






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

Bug #55804 [Opn]: tempnam(): wrong fallback to /tmp

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=55804&edit=1

 ID: 55804
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:tempnam(): wrong fallback to /tmp
 Status: Open
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

> Documented behavior, changing it will break BC

what sort of BC?
the created file is outside open_basedir, can not be used and can not be deleted
so this file is useless and simply at the wrong location
i can not imagine any code which useful relies on that "feature"


Previous Comments:

[2011-09-28 09:09:51] paj...@php.net

Documented behavior, changing it will break BC.

To correctly configure the temp directory in each host is a the way to go for 
now.


[2011-09-28 09:05:35] spam2 at rhsoft dot net

Description:

tempnam() should NOT fall back to /tmp if the $dir-param is explicit set to a 
real-path inside the open_basedir and because of wrong permissions $dir is not 
writeable

Test script:
---


Expected result:

error message that $dir is not writeable

Actual result:
--
temporary file is created in /tmp which violates open_basedir and fopen() is 
failing with open_basedir restriction messages






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

[PHP-BUG] Bug #55804 [NEW]: tempnam(): wrong fallback to /tmp

[spam2 at rhsoft dot net]

From: 
Operating system: Linux
PHP version:  5.3.8
Package:  Safe Mode/open_basedir
Bug Type: Bug
Bug description:tempnam(): wrong fallback to /tmp

Description:

tempnam() should NOT fall back to /tmp if the $dir-param is explicit set to
a real-path inside the open_basedir and because of wrong permissions $dir
is not writeable

Test script:
---


Expected result:

error message that $dir is not writeable

Actual result:
--
temporary file is created in /tmp which violates open_basedir and fopen()
is failing with open_basedir restriction messages

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

Bug #55283 [Com]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=55283&edit=1

 ID: 55283
 Comment by: spam2 at rhsoft dot net
 Reported by:aleksey at wepay dot com
 Summary:SSL options set by mysqli_ssl_set ignored for MySQLi
 persistent connections
 Status: Assigned
 Type:   Bug
 Package:MySQLi related
 Operating System:   Cent OS
 PHP Version:5.3.6
 Assigned To:scottmac
 Block user comment: N
 Private report: N

 New Comment:

would it not be the better solution to think about dropping the 
libmysql-support and use only mysqlnd - we are runnning some hundret domains 
and using mysqlnd since the first 5.3 release

you will always have the problem of regressions and the result of auto-tests 
are depending how php was compiled


Previous Comments:

[2011-09-02 12:19:28] johan...@php.net

Scott, can you check how we can fix both things - SSL timeout while having 
mysqlnd SSL working? We're happy to help on the MySQL side ... Thanks!


[2011-09-02 11:22:37] u...@php.net

PHP 5.4 beta is scheduled for next week. Is anybody working on fixing the 
underlying PHP Streams issue not only with 5.3 but also 5.4?


[2011-08-22 21:31:56] johan...@php.net

Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=315310
Log: - Revert r313616 (When we have a blocking SSL socket, respect the timeout
  option, scottmac)

# This caused bug #55283, we should investigate a proper solution without
# breaking anything.


[2011-08-18 07:55:45] paj...@php.net

You can try in German then as you both speak German as well.

However it looks to me that the code speaks for itself. The connection fails 
after 
the timeout. This comment is based on this discussion on internals, 
http://news.php.net/php.internals/54667 .


[2011-08-18 07:51:51] and...@php.net

English is neither my mother tongue.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55283


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

Bug #55283 [Com]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=55283&edit=1

 ID: 55283
 Comment by: spam2 at rhsoft dot net
 Reported by:aleksey at wepay dot com
 Summary:SSL options set by mysqli_ssl_set ignored for MySQLi
 persistent connections
 Status: Verified
 Type:   Bug
 Package:MySQLi related
 Operating System:   Cent OS
 PHP Version:5.3.6
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

what try you to tell me with "I don't get your comment :("
remember that not everfybody has english as nmative language

i need a way to revert this change to get PHP 5.3.7 
working with mysqlnd/ssl the same way as it did the 
whole last year


Previous Comments:

[2011-08-18 06:08:55] and...@php.net

I don't get your comment :(

----
[2011-08-18 01:34:33] spam2 at rhsoft dot net

well i guess this change results in connections hanging around and 
after a hughe timeout filling my mailbox with cron-mails since 
upgraded to 5.3.7 using MYSQLND so "Changing mysqli to make libmysql happy will 
cause leaks with mysqlnd" seems to be true -> but why done this change if 
knowing it?

mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $
without ssl_set() all works fine but unencyrpted 

how can i revert this change for the 5.3.7-final.tar.bz2?
___

MySQL server has gone away

 $this->ssl_key = '/etc/mysql-ssl/client.pem';
 $this->ssl_crt = '/etc/mysql-ssl/client.pem';
 $this->ssl_ca  = '/etc/mysql-ssl/ca.crt';

$>conn->ssl_set($this->ssl_key, $this->ssl_crt, $this->ssl_ca, NULL, NULL);


[2011-08-05 13:39:28] and...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=314330
Log: Fix for bug #55283 SSL options set by mysqli_ssl_set ignored for MySQLi 
persistent connections


[2011-08-05 13:17:59] u...@php.net

The actual issue here is in mysqlnd (or in the mysqli user API, however you put 
it :-)): if using mysqli_init() to create a connection object we don't yet know 
if it needs to be persistent or not. mysqli was changed to meet the needs of 
mysqlnd. Unfortunately, this has an unforeseen side-effect on mysqli @ libmysql 
[@ SSL]. Changing mysqli to make libmysql happy will cause leaks with mysqlnd. 

This needs some think time.


[2011-08-05 11:53:47] u...@php.net

Reproducible with PHP 5.3.7RC4-dev (cli) (built: Jul 26 2011 17:35:20) (DEBUG) 
using *libmysql* to connect to 5.1.45-debug-log 

Configure Command =>  './configure'  '--with-mysql=mysqlnd' 
'--with-mysqli=/usr/local/mysql/bin/mysql_config' 
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--enable-debug' 
'--enable-maintainer-zts' '--enable-mysqlnd-ms' '--enable-mysqlenterprise' 
'--enable-mysqlnd-uh' '--enable-pcntl'

nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_3> sapi/cli/php bar.php
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(18) "DHE-RSA-AES256-SHA"
}
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(7) "RC4-MD5"
}




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55283


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

Bug #55283 [Com]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=55283&edit=1

 ID: 55283
 Comment by: spam2 at rhsoft dot net
 Reported by:aleksey at wepay dot com
 Summary:SSL options set by mysqli_ssl_set ignored for MySQLi
 persistent connections
 Status: Verified
 Type:   Bug
 Package:MySQLi related
 Operating System:   Cent OS
 PHP Version:5.3.6
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

well i guess this change results in connections hanging around and 
after a hughe timeout filling my mailbox with cron-mails since 
upgraded to 5.3.7 using MYSQLND so "Changing mysqli to make libmysql happy will 
cause leaks with mysqlnd" seems to be true -> but why done this change if 
knowing it?

mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $
without ssl_set() all works fine but unencyrpted 

how can i revert this change for the 5.3.7-final.tar.bz2?
___

MySQL server has gone away

 $this->ssl_key = '/etc/mysql-ssl/client.pem';
 $this->ssl_crt = '/etc/mysql-ssl/client.pem';
 $this->ssl_ca  = '/etc/mysql-ssl/ca.crt';

$>conn->ssl_set($this->ssl_key, $this->ssl_crt, $this->ssl_ca, NULL, NULL);


Previous Comments:

[2011-08-05 13:39:28] and...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=314330
Log: Fix for bug #55283 SSL options set by mysqli_ssl_set ignored for MySQLi 
persistent connections


[2011-08-05 13:17:59] u...@php.net

The actual issue here is in mysqlnd (or in the mysqli user API, however you put 
it :-)): if using mysqli_init() to create a connection object we don't yet know 
if it needs to be persistent or not. mysqli was changed to meet the needs of 
mysqlnd. Unfortunately, this has an unforeseen side-effect on mysqli @ libmysql 
[@ SSL]. Changing mysqli to make libmysql happy will cause leaks with mysqlnd. 

This needs some think time.


[2011-08-05 11:53:47] u...@php.net

Reproducible with PHP 5.3.7RC4-dev (cli) (built: Jul 26 2011 17:35:20) (DEBUG) 
using *libmysql* to connect to 5.1.45-debug-log 

Configure Command =>  './configure'  '--with-mysql=mysqlnd' 
'--with-mysqli=/usr/local/mysql/bin/mysql_config' 
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--enable-debug' 
'--enable-maintainer-zts' '--enable-mysqlnd-ms' '--enable-mysqlenterprise' 
'--enable-mysqlnd-uh' '--enable-pcntl'

nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_3> sapi/cli/php bar.php
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(18) "DHE-RSA-AES256-SHA"
}
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(7) "RC4-MD5"
}


[2011-07-26 00:25:00] aleksey at wepay dot com

Please note that while the example shows the problem with the cipher, all other 
parameters are also ignored. In particular, ssl cert info is critical.


[2011-07-26 00:20:58] aleksey at wepay dot com

Description:

The MySQLi ignores SSL options set with mysqli_ssl_set() for persistent 
connections (works fine for non-persistent connections).

To reproduce:
1) Configure MySQL server with SSL support 
(http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html)
2) Run the attached test script



Test script:
---
query("SHOW STATUS LIKE 'Ssl_cipher'");
var_dump($r->fetch_row());
}

/* non-persistent connection */
$link = mysqli_init();
mysqli_ssl_set($link, null, null, null, null, "RC4-MD5");
if (mysqli_real_connect($link, $host, $user, $pass, $db, $port, null, $flags)) {
$r = $link->query("SHOW STATUS LIKE 'Ssl_cipher'");
var_dump($r->fetch_row());
}


Expected result:

array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(18) "RC4-MD5"
}
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(7) "RC4-MD5"
}


Actual result:
--
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(18) "DHE-RSA-AES256-SHA"
}
array(2) {
  [0]=>
  string(10) "Ssl_cipher"
  [1]=>
  string(7) "RC4-MD5"
}







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

Bug #52312 [Com]: PHP safe_mode/open_basedir - lstat performance problem

[spam2 at rhsoft dot net]

Edit report at https://bugs.php.net/bug.php?id=52312&edit=1

 ID: 52312
 Comment by: spam2 at rhsoft dot net
 Reported by:v dot damore at gmail dot com
 Summary:PHP safe_mode/open_basedir - lstat performance
 problem
 Status: Analyzed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 New Comment:

> Caching open_basedir stats is insecure

not really because the permissions are not changed the whole day


Previous Comments:

[2011-07-03 21:21:21] ras...@php.net

I really don't see a middle ground here. You are either secure or you aren't. 
Caching open_basedir stats is insecure and the whole point of open_basedir in a 
shared hosting setup is to secure these file accesses. If you don't care about 
security, turn it off and live with the security issue, or better yet, change 
your shared hosting setup to use VMs or other lower-level strategies that keep 
users separated from each other.


[2011-07-03 20:24:57] css at morefoo dot com

Hello,

Not much more than a "me too", sorry.  Is there any plan in the works to make 
php 
both safe in a mass hosting setup as well as not take a big performance hit 
when 
running webapps with a large number of "require" and "include" functions?  I'm 
running php 5.3.6 and still seeing a huge amount of cpu time spent in "system" 
on 
common web apps like Joomla, Drupal and C5.  Not seeing a clear solution that 
works well on a shared hosting setup.


[2011-06-02 15:01:13] aargoth at boo dot pl

You can simply use this PHP extension to bypass default security checks 
mentioned in comments above.

http://php.webtutor.pl/en/2011/06/02/running-php-on-nfs-huge-performance-problems-and-one-simple-solution/


[2011-04-05 18:27:16] cedric at yterium dot com

As a matter of fact, same performance problem occurs with PHP Version 5.3.3 on 
Debian Squeeze.

On our test plateform (with an SSD disk) a small bench show that the penalties 
of using open_basedir is more than small on real case application.

Base configuration :
ab -n200 -c20 http://benchb.xxx.yy/
Requests per second:266.45 [#/sec] (mean)
After open_basedir activation :
Requests per second:82.95 [#/sec] (mean)

Recompiling with --disable-phar doesn't reduce the performance gap.
Recompiling after patching main/main.c with comment on both occurences of :
//CWDG(realpath_cache_size_limit) = 0;

allows to reach an acceptable performance :
Requests per second:178.27 [#/sec] (mean)

By increasing the realpath cache, we can at last reach a smaller penalty :
Requests per second:220.69 [#/sec] (mean)

Our tries tu use open_basedir on NFS leads us to more dramatic situation.

Can we expect a fix for a better situation in further PHP versions ?
Maybe this realpath cache de-activation could be a default setting in case of 
open_basedir with the ability of re-activating without need of recompiling.

I know this can be a security hole, but maybe it's better to give an 
intermediate choice between on/off. 

I'm affraid that in the current situation, activating open_basedir is not 
really an acceptable choice due to the performance struggling, and I think 
that's worse for security.


[2010-07-23 13:26:00] v dot damore at gmail dot com

Hello,

I have recompiled php commenting both in main/main.c:

/*
if (PG(safe_mode) || (PG(open_basedir) && *PG(open_basedir))) {
CWDG(realpath_cache_size_limit) = 0;
}
*/

I have defined into TSRM/tsrm_virtual_cwd.c

#define realpath(x,y) strcpy(y,x)

and I have disabled PHP function symlink.

Now I finally not have performance problems, but I suppose I still can have 
security problem.

Can you help me in order to understand if there is a better solution?




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=52312


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

#42836 [Bgs]: php6-snapshot and perhost-openbasedir

[spam2 at rhsoft dot net]

 ID:   42836
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Fedora 7
 PHP Version:  6CVS-2007-10-03 (snap)
 New Comment:

I see bogus-reports can be commented now

Have you understand what here happens?
wtf i need no support i report a bug
php6 snapshots take a random open_basedir from a random vhost
php5 with identic configuration works

this is a bug and you should not comment in such ignorant way
and no i have not tested again because i see no reason to test for you
early snaphshots if your answer to my help is "go away"


Previous Comments:


[2007-10-03 11:22:48] tony2...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.





[2007-10-03 10:59:36] spam2 at rhsoft dot net

Description:

I have running a second httpd on port 84 with php-snapshot
Each host has a open_basedir in the VHost-Config
If i try to change the hosts sometimes a open_basedir-error occurs with
the path from the last visited viurtual host

Warning: Unknown: open_basedir restriction in effect.
File(/mnt/data/www/www.rhsoft.net/index.php) is not within the allowed
path(s): (àµÜ/data/www/thelounge.rhsoft.net/hvb/www.hvb.at) in Unknown
on line 0 Warning: Unknown: failed to open stream: Operation not
permitted in Unknown on line 0 Fatal error: Unknown: Failed opening
required '/mnt/data/www/www.rhsoft.net/index.php'
(include_path='.:/mnt/data/www/phpincludes:/usr/share/pear') in Unknown
on line 0

Warning: Unknown: open_basedir restriction in effect.
File(/mnt/data/www/www.rhsoft.net/index.php) is not within the allowed
path(s): (H¶Ü/data/www/thelounge.rhsoft.net/www.alufenster.at) in
Unknown on line 0 Warning: Unknown: failed to open stream: Operation not
permitted in Unknown on line 0 Fatal error: Unknown: Failed opening
required '/mnt/data/www/www.rhsoft.net/index.php'
(include_path='.:/mnt/data/www/phpincludes:/usr/share/pear') in Unknown
on line 0 






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

#47315 [Bgs]: is_file() MUST NOT be true on remote-files

[spam2 at rhsoft dot net]

 ID:  47315
 User updated by: spam2 at rhsoft dot net
 Reported By: spam2 at rhsoft dot net
 Status:  Bogus
 Bug Type:Feature/Change Request
 PHP Version: 5.2.8
 New Comment:

What do you think to get as answer to "Wow only 6 years too late for
suggested changes"? How do you think should i smell this
idiotic-change?

I noticed this while reading a security-news about the break-in in the
phpBB server and the second comment from stefan esser pointed at this
problem.

My last test remote/local file was to a http-url did what i think
NOBODY can smell that ftp-URLs does other things and so this idiotic
change will not be noticed from > 90% of all developers but can hit a
application if a exploit knows about it and the attacker places his
files on a ftp-server instead of http


Previous Comments:


[2009-02-05 15:45:26] scott...@php.net

We're sorry that you're an asshole and feel unhappy with PHP which is
an open source project. Feel free to submit some updates to the German
manual if you have time.



[2009-02-05 15:40:36] spam2 at rhsoft dot net

Foolish idiot in the last available german doku is until today no hint
http://www.php.net/manual/de/function.is-file.php
Hinweis: Diese Funktion kann nicht mit entfernten Dateien arbeiten, da
der Zugriff auf
die Datei, die bearbeitet werden soll, über das Dateisystem des Servers
möglich sein muss.

This means it DOES NOT support remote-files, this was years along fact
is documentaded and used at many locations until today and some idiots
think it's cool to make it impossilbe to check if you work with a
local
or a remote file.

Wow, only 6 years too late to refresh the documentation and if
you i should use the english one - WHY does a german one exists?

Only idiots are making such major changes without thinking what this
can mean for existing applications and to make this joke perfect
it works with some streams (ftp) and some other not (http)
Again: How stupid must a guy be to create such a crap?

And yes i know that i'm not friendly because stupid people
are making me angry - everytime and everywehre!

Even if its documentated - how check if path is local or remote
even if you change the application?



[2009-02-05 15:10:11] scott...@php.net

Wow only 6 years too late for suggested changes. Changes were made to
use streams, the end.

--------

[2009-02-05 14:54:38] spam2 at rhsoft dot net

Description:

> As of PHP 5.0.0, this function can also be used with some URL 
> wrappers. Refer to List of Supported Protocols/Wrappers for 
> a listing of which wrappers support stat() family of functionality.

Which fool has decided to make such a MAJOR-CHANGE for functions like
"is_file()" as default instead of enable this only with a new optional
parameter?

You will break EVERY check in applications if the given path is a local
file! Revert this completly or add a parameter to enable it
Has anybody ever thougt that this can make SECURITY-PROBLEMS in some
cases? 

I hope no one wites a new function like "is_real_file" as seen at
"mysql_escape_string/mysql_real_escape_string", this is crap and
sometimes i wonder why many people are not thinking before doing!

Reproduce code:
---
$path = 'ftp://user:p...@host/file.txt';
if(is_file($path))   
{
 echo 'yes';  
}
else
{
 echo 'no';
}


Expected result:

no

Actual result:
--
yes 





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

#47315 [Bgs]: is_file() MUST NOT be true on remote-files

[spam2 at rhsoft dot net]

 ID:  47315
 User updated by: spam2 at rhsoft dot net
 Reported By: spam2 at rhsoft dot net
 Status:  Bogus
 Bug Type:Feature/Change Request
 PHP Version: 5.2.8
 New Comment:

Foolish idiot in the last available german doku is until today no hint
http://www.php.net/manual/de/function.is-file.php
Hinweis: Diese Funktion kann nicht mit entfernten Dateien arbeiten, da
der Zugriff auf
die Datei, die bearbeitet werden soll, über das Dateisystem des Servers
möglich sein muss.

This means it DOES NOT support remote-files, this was years along fact
is documentaded and used at many locations until today and some idiots
think it's cool to make it impossilbe to check if you work with a
local
or a remote file.

Wow, only 6 years too late to refresh the documentation and if
you i should use the english one - WHY does a german one exists?

Only idiots are making such major changes without thinking what this
can mean for existing applications and to make this joke perfect
it works with some streams (ftp) and some other not (http)
Again: How stupid must a guy be to create such a crap?

And yes i know that i'm not friendly because stupid people
are making me angry - everytime and everywehre!

Even if its documentated - how check if path is local or remote
even if you change the application?


Previous Comments:


[2009-02-05 15:10:11] scott...@php.net

Wow only 6 years too late for suggested changes. Changes were made to
use streams, the end.



[2009-02-05 14:54:38] spam2 at rhsoft dot net

Description:

> As of PHP 5.0.0, this function can also be used with some URL 
> wrappers. Refer to List of Supported Protocols/Wrappers for 
> a listing of which wrappers support stat() family of functionality.

Which fool has decided to make such a MAJOR-CHANGE for functions like
"is_file()" as default instead of enable this only with a new optional
parameter?

You will break EVERY check in applications if the given path is a local
file! Revert this completly or add a parameter to enable it
Has anybody ever thougt that this can make SECURITY-PROBLEMS in some
cases? 

I hope no one wites a new function like "is_real_file" as seen at
"mysql_escape_string/mysql_real_escape_string", this is crap and
sometimes i wonder why many people are not thinking before doing!

Reproduce code:
---
$path = 'ftp://user:p...@host/file.txt';
if(is_file($path))   
{
 echo 'yes';  
}
else
{
 echo 'no';
}


Expected result:

no

Actual result:
--
yes 





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

#47315 [NEW]: is_file() MUST NOT be true on remote-files

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: 
PHP version:  5.2.8
PHP Bug Type: Feature/Change Request
Bug description:  is_file() MUST NOT be true on remote-files

Description:

> As of PHP 5.0.0, this function can also be used with some URL 
> wrappers. Refer to List of Supported Protocols/Wrappers for 
> a listing of which wrappers support stat() family of functionality.

Which fool has decided to make such a MAJOR-CHANGE for functions like
"is_file()" as default instead of enable this only with a new optional
parameter?

You will break EVERY check in applications if the given path is a local
file! Revert this completly or add a parameter to enable it
Has anybody ever thougt that this can make SECURITY-PROBLEMS in some
cases? 

I hope no one wites a new function like "is_real_file" as seen at
"mysql_escape_string/mysql_real_escape_string", this is crap and sometimes
i wonder why many people are not thinking before doing!

Reproduce code:
---
$path = 'ftp://user:p...@host/file.txt';
if(is_file($path))   
{
 echo 'yes';  
}
else
{
 echo 'no';
}


Expected result:

no

Actual result:
--
yes 

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

#45087 [NEW]: Illegal or truncated character in input

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Fedora 9 x86_64
PHP version:  6CVS-2008-05-25 (CVS)
PHP Bug Type: Unknown/Other Function
Bug description:  Illegal or truncated character in input

Description:

Warning: Illegal or truncated character in input: offset 104, state=0 in
/mnt/data/www/thelounge.rhsoft.net/index.php on line 45 Parse error: syntax
error, unexpected $end in /mnt/data/www/thelounge.rhsoft.net/index.php on
line 45

_

The problem is the german "ü"

else echo " Derzeit stehen keine
Entwicklungsprojekte auf dieser Domain zur Verfügung ! ";



Reproduce code:
---
" . strtolower($dir) . "";
  }
 }
 else echo " Derzeit stehen keine
Entwicklungsprojekte auf dieser Domain zur Verfügung ! ";
?>

Expected result:

A simple html page

Actual result:
--
a strange parse error

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

#42836 [NEW]: php6-snapshot and perhost-openbasedir

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Fedora 7
PHP version:  6CVS-2007-10-03 (snap)
PHP Bug Type: *General Issues
Bug description:  php6-snapshot and perhost-openbasedir

Description:

I have running a second httpd on port 84 with php-snapshot
Each host has a open_basedir in the VHost-Config
If i try to change the hosts sometimes a open_basedir-error occurs with
the path from the last visited viurtual host

Warning: Unknown: open_basedir restriction in effect.
File(/mnt/data/www/www.rhsoft.net/index.php) is not within the allowed
path(s): (àµÜ/data/www/thelounge.rhsoft.net/hvb/www.hvb.at) in Unknown on
line 0 Warning: Unknown: failed to open stream: Operation not permitted in
Unknown on line 0 Fatal error: Unknown: Failed opening required
'/mnt/data/www/www.rhsoft.net/index.php'
(include_path='.:/mnt/data/www/phpincludes:/usr/share/pear') in Unknown on
line 0

Warning: Unknown: open_basedir restriction in effect.
File(/mnt/data/www/www.rhsoft.net/index.php) is not within the allowed
path(s): (H¶Ü/data/www/thelounge.rhsoft.net/www.alufenster.at) in Unknown
on line 0 Warning: Unknown: failed to open stream: Operation not permitted
in Unknown on line 0 Fatal error: Unknown: Failed opening required
'/mnt/data/www/www.rhsoft.net/index.php'
(include_path='.:/mnt/data/www/phpincludes:/usr/share/pear') in Unknown on
line 0 


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

#42262 [NEW]: get_magic_quotes_gpc() should be there and return false

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: All
PHP version:  6CVS-2007-08-09 (snap)
PHP Bug Type: Feature/Change Request
Bug description:  get_magic_quotes_gpc() should be there and return false

Description:

[10-Aug-2007 00:30:56] PHP Fatal error:  Call to undefined function
get_magic_quotes_gpc() in
/mnt/data/www/sql.rhsoft.net/libraries/common.lib.php on line 2606


The function "get_magic_quotes_gpc()" should available in PHP6 and return
always false, so you dont break applications that check the setting and
make a "stripslashes" if it is on.



Reproduce code:
---
if(function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc())
{
 @$akt_temp_str_name = stripslashes(@$akt_temp_str_name);
}

Expected result:

if(get_magic_quotes_gpc())
{
 @$akt_temp_str_name = stripslashes(@$akt_temp_str_name);
}

should work also

Actual result:
--
A fatal error

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

#42138 [NEW]: Build against mysql 5.1.20 beta fails

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5CVS-2007-07-29 (CVS)
PHP Bug Type: MySQL related
Bug description:  Build against mysql 5.1.20 beta fails

Description:

Build against a mysql-source-build 5.1.20 beta with prefix
/usr/local/mysql/ fails.

This is not a big problem and installing mysql-devel and building against
this with 5.0.x client-library is a workaround, but it think this should be
fixed.

In file included from /usr/local/mysql/include/mysql/mysql.h:66,
 from /data/development/src/php/ext/mysql/php_mysql.c:67:
/usr/local/mysql/include/mysql/mysql_version.h:18:1: warning:
"MYSQL_UNIX_ADDR" redefined
In file included from /data/development/src/php/TSRM/tsrm_config.h:1,
 from
/data/development/src/php/TSRM/tsrm_config_common.h:13,
 from
/data/development/src/php/TSRM/tsrm_virtual_cwd.h:26,
 from /data/development/src/php/main/php.h:409,
 from /data/development/src/php/ext/mysql/php_mysql.c:32:
/data/development/src/php/include/../main/php_config.h:1903:1: warning:
this is the location of the previous definition
/bin/sh /data/development/src/php/libtool --silent --preserve-dup-deps
--mode=compile gcc  -Iext/mysqli/ -I/data/development/src/php/ext/mysqli/
-DPHP_ATOM_INC -I/data/development/src/php/include
-I/data/development/src/php/main -I/data/development/src/php
-I/usr/include/libxml2 -I/usr/kerberos/include
-I/data/development/src/php/ext/date/lib -I/usr/include/freetype2
-I/usr/include/imap -I/data/development/src/php/ext/mbstring/oniguruma
-I/data/development/src/php/ext/mbstring/libmbfl
-I/data/development/src/php/ext/mbstring/libmbfl/mbfl
-I/usr/local/mysql/include/mysql -I/usr/include/mysql
-I/data/development/src/php/TSRM -I/data/development/src/php/Zend   
-I/usr/include -O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse2 -fopenmp
-mfpmath=sse,387 -pipe -ffast-math  -prefer-non-pic -c
/data/development/src/php/ext/mysqli/mysqli.c -o ext/mysqli/mysqli.lo
In file included from /usr/local/mysql/include/mysql/mysql.h:66,
 from
/data/development/src/php/ext/mysqli/php_mysqli.h:28,
 from /data/development/src/php/ext/mysqli/mysqli.c:31:
/usr/local/mysql/include/mysql/mysql_version.h:18:1: warning:
"MYSQL_UNIX_ADDR" redefined
In file included from /data/development/src/php/TSRM/tsrm_config.h:1,
 from
/data/development/src/php/TSRM/tsrm_config_common.h:13,
 from
/data/development/src/php/TSRM/tsrm_virtual_cwd.h:26,
 from /data/development/src/php/main/php.h:409,
 from /data/development/src/php/ext/mysqli/mysqli.c:27:
/data/development/src/php/include/../main/php_config.h:1903:1: warning:
this is the location of the previous definition
/bin/sh /data/development/src/php/libtool --silent --preserve-dup-deps
--mode=compile gcc  -Iext/mysqli/ -I/data/development/src/php/ext/mysqli/
-DPHP_ATOM_INC -I/data/development/src/php/include
-I/data/development/src/php/main -I/data/development/src/php
-I/usr/include/libxml2 -I/usr/kerberos/include
-I/data/development/src/php/ext/date/lib -I/usr/include/freetype2
-I/usr/include/imap -I/data/development/src/php/ext/mbstring/oniguruma
-I/data/development/src/php/ext/mbstring/libmbfl
-I/data/development/src/php/ext/mbstring/libmbfl/mbfl
-I/usr/local/mysql/include/mysql -I/usr/include/mysql
-I/data/development/src/php/TSRM -I/data/development/src/php/Zend   
-I/usr/include -O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse2 -fopenmp
-mfpmath=sse,387 -pipe -ffast-math  -prefer-non-pic -c
/data/development/src/php/ext/mysqli/mysqli_api.c -o
ext/mysqli/mysqli_api.lo
In file included from /usr/local/mysql/include/mysql/mysql.h:66,
 from
/data/development/src/php/ext/mysqli/php_mysqli.h:28,
 from
/data/development/src/php/ext/mysqli/mysqli_api.c:30:
/usr/local/mysql/include/mysql/mysql_version.h:18:1: warning:
"MYSQL_UNIX_ADDR" redefined
In file included from /data/development/src/php/TSRM/tsrm_config.h:1,
 from
/data/development/src/php/TSRM/tsrm_config_common.h:13,
 from
/data/development/src/php/TSRM/tsrm_virtual_cwd.h:26,
 from /data/development/src/php/main/php.h:409,
 from
/data/development/src/php/ext/mysqli/mysqli_api.c:27:
/data/development/src/php/include/../main/php_config.h:1903:1: warning:
this is the location of the previous definition
/data/development/src/php/ext/mysqli/mysqli_api.c: In function
'zif_mysqli_stmt_bind_param':
/data/development/src/php/ext/mysqli/mysqli_api.c:144: error: 'gptr'
undeclared (first use in this function)
/data/development/src/php/ext/mysqli/mysqli_api.c:144: error: (Each
undeclared identifier is reported only once
/data/development/src/php/ext/mysqli/mysqli_api.c:144: error: for each
function it appears in.)
/data/development/src/php/ext/mysqli/mysqli_a

#42077 [NEW]: Why have the session folder in open_basedir

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5CVS-2007-07-23 (snap)
PHP Bug Type: Session related
Bug description:  Why have the session folder in open_basedir

Description:

The Session-Save-Dir MUST NOT be in open_basedir because scripts must not
read session files for security!

And a failed session_start() have not to be fatal error too


Warning: session_start() [function.session-start.php]: open_basedir
restriction in effect. File(/var/www/sessiondata) is not within the
allowed path(s):
(/mnt/data/www/www.rhsoft.net:/mnt/data/www/phpincludes:/usr/share/pear:/var/www/uploadtemp)
in /mnt/data/www/www.rhsoft.net/test.php on line 2

Fatal error: session_start() [function.session-start.php]:
Failed to initialize storage module: files (path: /var/www/sessiondata)
in /mnt/data/www/www.rhsoft.net/test.php on line 2

Reproduce code:
---


Expected result:

A started session

Actual result:
--
A killed script

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

#42059 [Bgs]: Since some days php 5.2.4-dev does not work on fedora

[spam2 at rhsoft dot net]

 ID:   42059
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Fedora 7
 PHP Version:  5CVS-2007-07-21 (snap)
 New Comment:

That's not a bug but a bug that was fixed. (CVE-2007-3378)



Should this be a joke?
THIS IS a bug!
The session-save-apth HAS NOT to be in openbase-dir and a failed
session_start() has not to kill a script.

So there has to be started a session and not display warning nor error!


Previous Comments:


[2007-07-22 21:47:37] [EMAIL PROTECTED]

That's not a bug but a bug that was fixed. (CVE-2007-3378)



[2007-07-22 16:53:50] spam2 at rhsoft dot net

I found the problem!



works



brings

Warning: session_start() [function.session-start.php]: open_basedir
restriction in effect. File(/var/www/sessiondata) is not within the
allowed path(s):
(/mnt/data/www/www.rhsoft.net:/mnt/data/www/phpincludes:/usr/share/pear:/var/www/uploadtemp)
in /mnt/data/www/www.rhsoft.net/test.php on line 2

Fatal error: session_start() [function.session-start.php]:
Failed to initialize storage module: files (path: /var/www/sessiondata)
in /mnt/data/www/www.rhsoft.net/test.php on line 2


It was invisible because in my central library with autoloading and
much functions there is a @session_start(); to dont show warnings if
anyone has startet a session oder sendt headers before including

Its the same with the last snapshot
On a other machine a snapshot from 08.07.2007 i think does without
troubles



[2007-07-21 16:13:58] [EMAIL PROTECTED]

And shouldn't you stop apache before doing 'make install' ?
Anyway, then run apache like this:

# gdb --arg httpd -X 
(gdb) run

Try access a page and see if it crashes..



[2007-07-21 16:12:02] [EMAIL PROTECTED]

Try building with this configure line instead (and do not set any
cflags/etc):

# rm config.cache && ./configure --with-apxs2 --disable-all
--enable-debug

--------

[2007-07-21 13:17:05] spam2 at rhsoft dot net

Description:

Since some days the snapshot-builds from source under fedora 7 does
produce a white page with HTTP-Status 500 and without any messages in
logfiles.

I have built it every second day and now it will not run, the cli semms
to work normal

If i use the 5.2.3-sources with the same build--script all works
perfect

Reproduce code:
---
export CFLAGS="-O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse3
-fopenmp"
export CXX=gcc
export CXXFLAGS="-O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse3
-fopenmp"
export PHP_PREFIX="/usr"

# In den Source-Folder wechseln
cd /data/development/src/php/

# Config-Cache falls vorhanden entfernen und aufräumen um Probleme zu
vermeiden
rm -f ./config.cache > /dev/null
make clean > /dev/null

# Configure-Optionen setzen
./configure \
 --with-apxs2=/usr/sbin/apxs \
 --with-pear=/usr/share/pear \
 --build=i686-redhat-linux-gnu \
 --host=i686-redhat-linux-gnu \
 --target=i686-redhat-linux-gnu \
 --prefix=$PHP_PREFIX \
 --sysconfdir=/etc \
 --localstatedir=/var \
 --disable-debug \
 --disable-rpath \
 --disable-ipv6 \
 --disable-dba \
 --without-odbc \
 --without-unixODBC \
 --without-gdbm \
 --enable-inline-optimization \
 --enable-exif \
 --enable-ftp \
 --enable-sockets \
 --enable-yp \
 --enable-wddx \
 --enable-memory-limit \
 --enable-calendar \
 --enable-mbstring \
 --enable-soap \
 --enable-bcmath \
 --enable-gd-native-ttf \
 --enable-zip \
 --with-readline \
 --with-libdir=lib \
 --with-config-file-path=/etc \
 --with-exec-dir=/usr/bin \
 --with-freetype-dir=/usr \
 --with-png-dir=/usr \
 --with-jpeg-dir=/usr \
 --with-expat-dir=/usr \
 --with-pcre-regex=/usr \
 --with-libxml-dir=/usr \
 --with-mysql=/usr/local/mysql \
 --with-mysql-sock=/var/lib/mysql \
 --with-mysqli \
 --with-curl \
 --with-gettext \
 --with-iconv \
 --with-openssl \
 --with-png \
 --with-bz2 \
 --with-zlib \
 --with-layout=GNU \
 --with-xml \
 --with-xmlrpc \
 --with-mssql \
 --with-pgsql \
 --with-pdo-mysql \
 --with-pdo-pgsql \
 --with-pdo-sqlite \
 --with-tidy \
 --with-mcrypt \
 --with-mhash \
 --with-gd \
 --with-ttf \
 --with-kerberos \
 --with-ldap \
 --with-imap \
 --with-imap-ssl \
&& make \
&& strip .libs/libphp5.so \
&& strip sapi/cli/php \
&& sudo make install \
&& sudo /sbin/service httpd restart

# Aufräumen
make clean > /dev/null
rm -f ./config.cache > /dev/null


Expected result:

a running apache-module

Actual result:
--
a white page





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

#42059 [Fbk->Opn]: Since some days php 5.2.4-dev does not work on fedora

[spam2 at rhsoft dot net]

 ID:   42059
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Fedora 7
 PHP Version:  5CVS-2007-07-21 (snap)
 New Comment:

I found the problem!



works



brings

Warning: session_start() [function.session-start.php]: open_basedir
restriction in effect. File(/var/www/sessiondata) is not within the
allowed path(s):
(/mnt/data/www/www.rhsoft.net:/mnt/data/www/phpincludes:/usr/share/pear:/var/www/uploadtemp)
in /mnt/data/www/www.rhsoft.net/test.php on line 2

Fatal error: session_start() [function.session-start.php]:
Failed to initialize storage module: files (path: /var/www/sessiondata)
in /mnt/data/www/www.rhsoft.net/test.php on line 2


It was invisible because in my central library with autoloading and
much functions there is a @session_start(); to dont show warnings if
anyone has startet a session oder sendt headers before including

Its the same with the last snapshot
On a other machine a snapshot from 08.07.2007 i think does without
troubles


Previous Comments:


[2007-07-21 16:13:58] [EMAIL PROTECTED]

And shouldn't you stop apache before doing 'make install' ?
Anyway, then run apache like this:

# gdb --arg httpd -X 
(gdb) run

Try access a page and see if it crashes..



[2007-07-21 16:12:02] [EMAIL PROTECTED]

Try building with this configure line instead (and do not set any
cflags/etc):

# rm config.cache && ./configure --with-apxs2 --disable-all
--enable-debug



[2007-07-21 13:17:05] spam2 at rhsoft dot net

Description:

Since some days the snapshot-builds from source under fedora 7 does
produce a white page with HTTP-Status 500 and without any messages in
logfiles.

I have built it every second day and now it will not run, the cli semms
to work normal

If i use the 5.2.3-sources with the same build--script all works
perfect

Reproduce code:
---
export CFLAGS="-O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse3
-fopenmp"
export CXX=gcc
export CXXFLAGS="-O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse3
-fopenmp"
export PHP_PREFIX="/usr"

# In den Source-Folder wechseln
cd /data/development/src/php/

# Config-Cache falls vorhanden entfernen und aufräumen um Probleme zu
vermeiden
rm -f ./config.cache > /dev/null
make clean > /dev/null

# Configure-Optionen setzen
./configure \
 --with-apxs2=/usr/sbin/apxs \
 --with-pear=/usr/share/pear \
 --build=i686-redhat-linux-gnu \
 --host=i686-redhat-linux-gnu \
 --target=i686-redhat-linux-gnu \
 --prefix=$PHP_PREFIX \
 --sysconfdir=/etc \
 --localstatedir=/var \
 --disable-debug \
 --disable-rpath \
 --disable-ipv6 \
 --disable-dba \
 --without-odbc \
 --without-unixODBC \
 --without-gdbm \
 --enable-inline-optimization \
 --enable-exif \
 --enable-ftp \
 --enable-sockets \
 --enable-yp \
 --enable-wddx \
 --enable-memory-limit \
 --enable-calendar \
 --enable-mbstring \
 --enable-soap \
 --enable-bcmath \
 --enable-gd-native-ttf \
 --enable-zip \
 --with-readline \
 --with-libdir=lib \
 --with-config-file-path=/etc \
 --with-exec-dir=/usr/bin \
 --with-freetype-dir=/usr \
 --with-png-dir=/usr \
 --with-jpeg-dir=/usr \
 --with-expat-dir=/usr \
 --with-pcre-regex=/usr \
 --with-libxml-dir=/usr \
 --with-mysql=/usr/local/mysql \
 --with-mysql-sock=/var/lib/mysql \
 --with-mysqli \
 --with-curl \
 --with-gettext \
 --with-iconv \
 --with-openssl \
 --with-png \
 --with-bz2 \
 --with-zlib \
 --with-layout=GNU \
 --with-xml \
 --with-xmlrpc \
 --with-mssql \
 --with-pgsql \
 --with-pdo-mysql \
 --with-pdo-pgsql \
 --with-pdo-sqlite \
 --with-tidy \
 --with-mcrypt \
 --with-mhash \
 --with-gd \
 --with-ttf \
 --with-kerberos \
 --with-ldap \
 --with-imap \
 --with-imap-ssl \
&& make \
&& strip .libs/libphp5.so \
&& strip sapi/cli/php \
&& sudo make install \
&& sudo /sbin/service httpd restart

# Aufräumen
make clean > /dev/null
rm -f ./config.cache > /dev/null


Expected result:

a running apache-module

Actual result:
--
a white page





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

#42059 [NEW]: Since some days php 5.2.4-dev does not work on fedora

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Fedora 7
PHP version:  5CVS-2007-07-21 (snap)
PHP Bug Type: Apache2 related
Bug description:  Since some days php 5.2.4-dev does not work on fedora

Description:

Since some days the snapshot-builds from source under fedora 7 does
produce a white page with HTTP-Status 500 and without any messages in
logfiles.

I have built it every second day and now it will not run, the cli semms to
work normal

If i use the 5.2.3-sources with the same build--script all works perfect

Reproduce code:
---
export CFLAGS="-O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse3
-fopenmp"
export CXX=gcc
export CXXFLAGS="-O3 -march=i686 -mcpu=i686 -mtune=i686 -mmmx -msse3
-fopenmp"
export PHP_PREFIX="/usr"

# In den Source-Folder wechseln
cd /data/development/src/php/

# Config-Cache falls vorhanden entfernen und aufräumen um Probleme zu
vermeiden
rm -f ./config.cache > /dev/null
make clean > /dev/null

# Configure-Optionen setzen
./configure \
 --with-apxs2=/usr/sbin/apxs \
 --with-pear=/usr/share/pear \
 --build=i686-redhat-linux-gnu \
 --host=i686-redhat-linux-gnu \
 --target=i686-redhat-linux-gnu \
 --prefix=$PHP_PREFIX \
 --sysconfdir=/etc \
 --localstatedir=/var \
 --disable-debug \
 --disable-rpath \
 --disable-ipv6 \
 --disable-dba \
 --without-odbc \
 --without-unixODBC \
 --without-gdbm \
 --enable-inline-optimization \
 --enable-exif \
 --enable-ftp \
 --enable-sockets \
 --enable-yp \
 --enable-wddx \
 --enable-memory-limit \
 --enable-calendar \
 --enable-mbstring \
 --enable-soap \
 --enable-bcmath \
 --enable-gd-native-ttf \
 --enable-zip \
 --with-readline \
 --with-libdir=lib \
 --with-config-file-path=/etc \
 --with-exec-dir=/usr/bin \
 --with-freetype-dir=/usr \
 --with-png-dir=/usr \
 --with-jpeg-dir=/usr \
 --with-expat-dir=/usr \
 --with-pcre-regex=/usr \
 --with-libxml-dir=/usr \
 --with-mysql=/usr/local/mysql \
 --with-mysql-sock=/var/lib/mysql \
 --with-mysqli \
 --with-curl \
 --with-gettext \
 --with-iconv \
 --with-openssl \
 --with-png \
 --with-bz2 \
 --with-zlib \
 --with-layout=GNU \
 --with-xml \
 --with-xmlrpc \
 --with-mssql \
 --with-pgsql \
 --with-pdo-mysql \
 --with-pdo-pgsql \
 --with-pdo-sqlite \
 --with-tidy \
 --with-mcrypt \
 --with-mhash \
 --with-gd \
 --with-ttf \
 --with-kerberos \
 --with-ldap \
 --with-imap \
 --with-imap-ssl \
&& make \
&& strip .libs/libphp5.so \
&& strip sapi/cli/php \
&& sudo make install \
&& sudo /sbin/service httpd restart

# Aufräumen
make clean > /dev/null
rm -f ./config.cache > /dev/null


Expected result:

a running apache-module

Actual result:
--
a white page

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

#38941 [NEW]: -with-imap doesnt compile anymore after uw-imap update

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux Fedora 5
PHP version:  5.1.6
PHP Bug Type: Compile Failure
Bug description:  -with-imap doesnt compile anymore after uw-imap update

Description:

Since last update from uw-imap with yum on fedora fc5 it seems that php
does not compile any more with the extension

php-sources and make-calls are the same, but after i seen the update i
decided to compile php again the new version

package: 
uw-imap-devel-2006-2.fc5.1

below the messages from the complier

--

/data/development/src/php/ext/imap/php_imap.c:78: error: conflicting types
for 'utf8_mime2text'
/usr/include/imap/utf8.h:546: error: previous declaration of
'utf8_mime2text' was here
make: *** [ext/imap/php_imap.lo] Fehler 1



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

#36807 [Opn]: CLI crashes unter win32

[spam2 at rhsoft dot net]

 ID:   36807
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
-PHP Version:  5.1.3RC4
+PHP Version:  5.2.0-dev
 New Comment:

The problem is in 5.2.0-dev (last nightly) also 
And now im sure that is only here when php_tidy.dll is loaded

A workaround is to place a "php.ini" with all modules in the
apache/conf-Folder an a line like 
PHPIniDir "d:/server/apache/conf"
in the httpd.conf

Now under c:\windows\php.ini can removed the tidy-line and both works -
make sure there is no php.ini in the php-folder himself!

that is not nice but helps now -> Please look where the problem it self
lives, because its not a good sign when php crashs with a bundled
extension!


Previous Comments:


[2006-04-22 10:33:23] spam2 at rhsoft dot net

I have tried no many Configurations
The Problem seems only to exist if php_tidy.dll is loaded
Whe i uncomment it the following script is running, if tidy is loaded
it will crash after a few seconds





[2006-04-18 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".



[2006-04-10 12:37:26] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.



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

[2006-04-10 02:50:52] spam2 at rhsoft dot net

Is there any solution fpr this problem?
I cant use 5.1.3dev because i need cli in many cases on my development
machine :-(

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

[2006-03-22 11:04:52] spam2 at rhsoft dot net

A example on my computers is a simple "pear upgrade-all", after few
seconds php-cli crashs

The other scripts are also much bigger than 20 lines because uses a
library with 5000 lines and some wrappers

one of them is a db-class for mysql/pgsql/mssql who makes it possible
to connect to one mysqlserver, create a table dump and excute each
insert directly on a second server or buffer the dump, create single
files and generate a zip with them and save it to a backup-folder.

---

The last days the following script crashs after a longer time also





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36807

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

#36807 [NoF->Opn]: CLI crashes unter win32

[spam2 at rhsoft dot net]

 ID:   36807
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
-Status:   No Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
-PHP Version:  5.1.3RC1
+PHP Version:  5.1.3RC4
 New Comment:

I have tried no many Configurations
The Problem seems only to exist if php_tidy.dll is loaded
Whe i uncomment it the following script is running, if tidy is loaded
it will crash after a few seconds




Previous Comments:


[2006-04-18 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".



[2006-04-10 12:37:26] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2006-04-10 02:50:52] spam2 at rhsoft dot net

Is there any solution fpr this problem?
I cant use 5.1.3dev because i need cli in many cases on my development
machine :-(



[2006-03-22 11:04:52] spam2 at rhsoft dot net

A example on my computers is a simple "pear upgrade-all", after few
seconds php-cli crashs

The other scripts are also much bigger than 20 lines because uses a
library with 5000 lines and some wrappers

one of them is a db-class for mysql/pgsql/mssql who makes it possible
to connect to one mysqlserver, create a table dump and excute each
insert directly on a second server or buffer the dump, create single
files and generate a zip with them and save it to a backup-folder.

---

The last days the following script crashs after a longer time also



----

[2006-03-20 23:25:38] spam2 at rhsoft dot net

Description:

The latest snapshots for win32 crashs (only the cli)
Not only one - all my scripts who will alter or backup databases for a
batch-command on windows will crash down if running in command line
interface - same skripts over apache2handler works normal.

Some snapshots before the problem went away but it exists also in an
earlier build of 5.1.3dev

Reproduce code:
---
Sorry not possible






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

#36807 [Opn]: CLI crashs unter win32

[spam2 at rhsoft dot net]

 ID:   36807
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.1.3RC1
 New Comment:

Is there any solution fpr this problem?
I cant use 5.1.3dev because i need cli in many cases on my development
machine :-(


Previous Comments:


[2006-03-22 11:04:52] spam2 at rhsoft dot net

A example on my computers is a simple "pear upgrade-all", after few
seconds php-cli crashs

The other scripts are also much bigger than 20 lines because uses a
library with 5000 lines and some wrappers

one of them is a db-class for mysql/pgsql/mssql who makes it possible
to connect to one mysqlserver, create a table dump and excute each
insert directly on a second server or buffer the dump, create single
files and generate a zip with them and save it to a backup-folder.

---

The last days the following script crashs after a longer time also





[2006-03-22 08:35:14] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-03-21 22:16:22] kleef84 at hotmail dot com

I have the same problem since php5.1-200603202330.tar.gz was released.
I'm using custom build on Windows Server 2003.
Error appears with php.exe, php-win.exe and php-cgi.exe, the ISAPI dll
(php5isapi.dll) appears to work fine.

Error pop-up message:
Application Error
The instruction at "0x101ed783" referenced memory at "0x0bec". The
memory could not be "read".

When hitting cancel, Visual C++ debug says:
Unhandled exception in php.exe (PHP5TS.DLL): 0xC005: Access
Violation

Event log:
Event Type: Error
Event Source:   Application Error
Event Category: (100)
Event ID:   1000
Date:   3/21/2006
Time:   10:08:20 PM
User:   N/A
Computer:   xxx
Description:
Faulting application php.exe, version 5.1.3.3, faulting module
php5ts.dll, version 5.1.3.3, fault address 0x001ed783.



[2006-03-20 23:26:03] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




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

[2006-03-20 23:25:38] spam2 at rhsoft dot net

Description:

The latest snapshots for win32 crashs (only the cli)
Not only one - all my scripts who will alter or backup databases for a
batch-command on windows will crash down if running in command line
interface - same skripts over apache2handler works normal.

Some snapshots before the problem went away but it exists also in an
earlier build of 5.1.3dev

Reproduce code:
---
Sorry not possible






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

#36807 [Fbk->Opn]: CLI crashs unter win32

[spam2 at rhsoft dot net]

 ID:   36807
 User updated by:  spam2 at rhsoft dot net
 Reported By:  spam2 at rhsoft dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.1.3RC1
 New Comment:

A example on my computers is a simple "pear upgrade-all", after few
seconds php-cli crashs

The other scripts are also much bigger than 20 lines because uses a
library with 5000 lines and some wrappers

one of them is a db-class for mysql/pgsql/mssql who makes it possible
to connect to one mysqlserver, create a table dump and excute each
insert directly on a second server or buffer the dump, create single
files and generate a zip with them and save it to a backup-folder.

---

The last days the following script crashs after a longer time also




Previous Comments:


[2006-03-22 08:35:14] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-03-21 22:16:22] kleef84 at hotmail dot com

I have the same problem since php5.1-200603202330.tar.gz was released.
I'm using custom build on Windows Server 2003.
Error appears with php.exe, php-win.exe and php-cgi.exe, the ISAPI dll
(php5isapi.dll) appears to work fine.

Error pop-up message:
Application Error
The instruction at "0x101ed783" referenced memory at "0x0bec". The
memory could not be "read".

When hitting cancel, Visual C++ debug says:
Unhandled exception in php.exe (PHP5TS.DLL): 0xC005: Access
Violation

Event log:
Event Type: Error
Event Source:   Application Error
Event Category: (100)
Event ID:   1000
Date:   3/21/2006
Time:   10:08:20 PM
User:   N/A
Computer:   xxx
Description:
Faulting application php.exe, version 5.1.3.3, faulting module
php5ts.dll, version 5.1.3.3, fault address 0x001ed783.



[2006-03-20 23:26:03] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




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

[2006-03-20 23:25:38] spam2 at rhsoft dot net

Description:

The latest snapshots for win32 crashs (only the cli)
Not only one - all my scripts who will alter or backup databases for a
batch-command on windows will crash down if running in command line
interface - same skripts over apache2handler works normal.

Some snapshots before the problem went away but it exists also in an
earlier build of 5.1.3dev

Reproduce code:
---
Sorry not possible






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

#36807 [NEW]: CLI crashs unter win32

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Windows XP
PHP version:  5.1.3RC1
PHP Bug Type: Reproducible crash
Bug description:  CLI crashs unter win32

Description:

The latest snapshots for win32 crashs (only the cli)
Not only one - all my scripts who will alter or backup databases for a
batch-command on windows will crash down if running in command line
interface - same skripts over apache2handler works normal.

Some snapshots before the problem went away but it exists also in an
earlier build of 5.1.3dev

Reproduce code:
---
Sorry not possible


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

#35098 [Asn]: Problem still exists with nightly

[spam2 at rhsoft dot net]

 ID:   35098
 User updated by:  spam2 at rhsoft dot net
-Summary:  5.1RC5 has troubles with Zlib which 5.1RC4 not have
 Reported By:  spam2 at rhsoft dot net
 Status:   Assigned
 Bug Type: Zlib Related
 Operating System: Windows XP
 PHP Version:  5.1.0RC4
 Assigned To:  iliaa
 New Comment:

Check this: http://local.rhsoft.net/

Strange: 
phpinfo works on this vhost
http://local.rhsoft.net/phpinfo.php

Internet Explorer crashs if it is the startpage
Firefox Win/Linux and Konqueror shows stuff

---

Other vhost with same cms-system works
http://afi.rhsoft.net/

Same page with PHP 5.0.4 on all os and 5.1 until RC4 on the same
machine and the first RC5 works also - Its a Windows XP with Apache
2.0.55

http://www.rhsoft.net/


Previous Comments:


[2005-11-04 09:27:24] [EMAIL PROTECTED]

Ilia, there is apparently something wrong with the fix for the leak?



[2005-11-04 04:34:58] spam2 at rhsoft dot net

Description:

The last Nightlys PHP 5.1 (RC5) have on some pages troubles with
zlib_outputcompression = On which RC4 hast not.

Strange caracters will occur - looks like compressed output not
decompressed by browser (firefox)

This is not really reproduceable but in fact on my dev-machine when i
"downgrade" all pages will work, its a cms-system and some other
dev-hosts with the same scripts will running ... 






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

#35098 [NEW]: 5.1RC5 has troubles with Zlib which 5.1RC4 not have

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Windows XP
PHP version:  5.1.0RC4
PHP Bug Type: Zlib Related
Bug description:  5.1RC5 has troubles with Zlib which 5.1RC4 not have

Description:

The last Nightlys PHP 5.1 (RC5) have on some pages troubles with
zlib_outputcompression = On which RC4 hast not.

Strange caracters will occur - looks like compressed output not
decompressed by browser (firefox)

This is not really reproduceable but in fact on my dev-machine when i
"downgrade" all pages will work, its a cms-system and some other dev-hosts
with the same scripts will running ... 


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

#26315 [Com]: mssql_fectch_* functions are returning a space char on empty fields

[spam2 at rhsoft dot net]

 ID:   26315
 Comment by:   spam2 at rhsoft dot net
 Reported By:  webmaster at cbre dot fr
 Status:   Bogus
 Bug Type: MSSQL related
 Operating System: Windows 2000 Server
 PHP Version:  4.3.4
 New Comment:

hmm this is a bug
i developed a cms first for mysql and the port for postgre with select
database-type works very fine

the last two days i try to get it running with mssql/msde an nothing
works with this damned spaces

if (!empty($image)) echo ""; for example
makes a big shit :-(


Previous Comments:


[2004-05-24 21:23:07] hagen at woecht dot de

If you must make from a space to '' in your PHP script, how can you
distinguish between a "true" space or "faked" space?
All '' and space in the DB are then '' (:-((()



[2004-04-23 10:25:51] tomasz at biznespolska dot pl

In my opinion this is bug, and is still present on version 4.3.6. This
is not only problem with CHAR, and NCHAR columns but also empty VARCHAR
columns returns space.

Example:
$re = mssql_fetch_row(mssql_query("SELECT CAST('' AS VARCHAR(10))"));
print('--'.$re[0].'--');
// the result is: -- --
// and should be: 

Because of that I still use PHP4.3.3.



[2004-03-24 04:33:03] francois dot zietlow at ri-solution dot com

The Protocol have been changed.
Quote from Sybase Doco.

[quote]
The empty string ("") is treated as a single space. In *char* and
*nchar* *not null* columns, the result is a (column-length) field of
spaces.
[/quote]

Found on Bug Report:
http://bugs.php.net/bug.php?id=6527


Its not nice...
Just I write my own empty-Function.


Francois



[2004-03-24 04:18:11] francois dot zietlow at ri-solution dot com

I think that is a Bug, too.
I have the same Problem.
It's not a solution to trim any value. Or??

@iliaa:
Please write why do you think it's not a Bug.


Thanks!
Francois



[2004-03-16 13:29:50] webmaster at groupphotographers dot com

THIS most DEFINITELY is a BUG! I have built a VERY LARGE DB driven PHP
site. In many places, I check to see if the DB field was empty or not.
Before, Fetch always returned an empty string or a NULL, it doesn't
matter which because it evaluated to a FALSE, and now it returns a
space character which evaluates to TRUE! This is quite nasty. I'm going
to add this ME TOO comment because it hasn't been fixed yet, and it
really needs to be...PLEASE!



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26315

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