date:20080117

#22378 [Com]: "sendmail_from" not set in php.ini or custom "From:" header missing

2008-01-17 Thread chaurasia151078 at hotmail dot com

 ID:   22378
 Comment by:   chaurasia151078 at hotmail dot com
 Reported By:  kris at aethiamud dot org
 Status:   No Feedback
 Bug Type: Mail related
 Operating System: Windows XP
 PHP Version:  4.3.0
 New Comment:

hi


Previous Comments:


[2003-03-09 19:01:20] [EMAIL PROTECTED]

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 "Open". Thank you.





[2003-02-22 23:29:10] [EMAIL PROTECTED]

Just a note: I tested this with latest STABLE snapshot on my win2k
machine and it works just fine..




[2003-02-22 20:09:26] [EMAIL PROTECTED]

Ok, then it looks like a parse problem, or you have a syntax error in
your php.ini file or the settings are not passed through to the php
core.

Try changing a setting _below_ the [mail function] section, like for
instance: mysql.default_port to 4306.

Does that value change? Then we can strike the 'passed through' error.



[2003-02-22 17:39:48] kris at aethiamud dot org

Ok I just got what you meant after I hit submit hehe.  I tried adding
that line to the phpinfo.php file, and now it lists the local value as
smtp.aethiamud.org and the master value still as localhost.



[2003-02-22 17:34:35] kris at aethiamud dot org

re:

1) Could you tell me how to do that ini_set thing?  I tried a few
variations with the php/cli/php.exe command line, but couldn't figure
out what you meant.

2) I did do the php/cli/php -i and it also displayed the same things;
i.e. 'sendmail_from => no value => no value' and 'SMTP => localhost =>
localhost'



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/22378

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

#43886 [NEW]: checkdnsrr should distinguisch between 'no records' and 'error'

2008-01-17 Thread php dot gewuerzschinken at spamgourmet dot com

From: php dot gewuerzschinken at spamgourmet dot com
Operating system: Slackware Linux 11
PHP version:  5.2.5
PHP Bug Type: *Network Functions
Bug description:  checkdnsrr should distinguisch between 'no records' and 
'error'

Description:

I'd like to see the function distinguishing between 'no records' (boolean
function result or zero) and 'error' (Exception or negative function
result).  

In the case of an error, one would log the error and continue or not.
And if there is no record, one would sort out the invalid domain.
At the moment I have to sort out the domain in every way even if the
domain is valid but the machine cannot connect to a domain name service or
what ever.


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

#43682 [Opn->Fbk]: session id kept, content lost on subdomain

2008-01-17 Thread jani

 ID:   43682
 Updated by:   [EMAIL PROTECTED]
 Reported By:  k dot andris at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Debian Sarge
 PHP Version:  5.2.5
 New Comment:

I'd check first that the cookie is actually set and with what data.
I had some problems with this when I changed the domain to be something
different what it originally was, and as there already existed a cookie
with same name, but just set with domain 'www.example.com' it wasn't
reset. (tested using Firefox)

Try change the session name (ie. cookie name) too.



Previous Comments:


[2007-12-27 00:27:18] k dot andris at gmail dot com

Works all right in 5.2



[2007-12-26 21:00:49] k dot andris at gmail dot com

Description:

The $_SESSION variable is empty when I look at it on a subdomain
(abc.mydomain.com) even though session_id() is the same as on the main
site (mydomain.com). Sessions are saved in files under /var/log/php5 -
they just not read from there. The session cookie is OK too.

Reproduce code:
---
I have this on the base domain and on subdoamins too with different
assigment lines. Still, they only seee their own assigments.

ini_set("session.cookie_domain", ".mydomain.net");
session_start();

print_r($_SESSION);

$_SESSION['main'] = 'main'; // assigment

print_r($_SESSION);



Expected result:

Since I have the same session id, I expect the $_SESSION variable to be
shared acreoss pages, and subdomains.






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

#43859 [Opn->Bgs]: Wrong comparison

2008-01-17 Thread jani

 ID:   43859
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seocar at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Fedora Core
 PHP Version:  5.2.5
 New Comment:

RTFM: http://www.php.net/manual/en/language.operators.comparison.php

And there it says under the table:

"If you compare two numerical strings, they are compared as integers."


Previous Comments:


[2008-01-15 20:27:28] seocar at gmail dot com

Description:

Wrong comparison between two strings.
(Yes, I know about strict comparison, but I want to know about this
case)

Reproduce code:
---
if ("" == "0e01")
echo "BUG";
else
echo "OK";

Expected result:

OK

Actual result:
--
BUG





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

#43882 [Opn->Asn]: Include_path escape sequences problem

2008-01-17 Thread jani

 ID:   43882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dutow at nwi dot hu
-Status:   Open
+Status:   Assigned
 Bug Type: *Configuration Issues
 Operating System: Windows XP SP2
 PHP Version:  5.3CVS-2008-01-17 (snap)
-Assigned To:  
+Assigned To:  jani
 New Comment:

Unfortunate side-effect of allowing it elsewhere.
You can always use single quotes though..iirc. :)
I'll see what I can do about it.


Previous Comments:


[2008-01-17 19:03:49] dutow at nwi dot hu

Description:

PHP escapes escape sequences in include_path.

Reproduce code:
---
include_path = ".;d:\web\php\pear;d:\web\nowww"



Expected result:

.;d:\web\php\pear;d:\web\nowww

Actual result:
--
.;d:\web\php\pear;d:\web
owww





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

#43559 [Opn]: array_merge_recursive() doesn't behave as expected with duplicate NULL values

2008-01-17 Thread felipe

 ID:   43559
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kraghuba at in dot ibm dot com
 Status:   Open
 Bug Type: Arrays related
 Operating System: Linux, windows
 PHP Version:  5.2CVS-2007-12-11 (snap)
 New Comment:

Simple fix:
http://ecl.zoone.com.br/etc/patches/bug43559.patch


Previous Comments:


[2007-12-11 05:35:05] kraghuba at in dot ibm dot com

Description:

When two arrays having common key and value are passed as argument to
array_merge_recursive(), the function behaves in an unexpected way for
NULL values. It outputs an empty array instead of an array having two
elements, both being NULL. Whereas, the function behaves in an expected
way with values other than NULL. This behavior can be observed in the
testcase array_merge_recursive_variation9.phpt.
   
This behavior is observed in PHP5.3 and PHP6 as well.

I tried creating an array with two null values and it works:
  
output:
  array(2) {
  [0]=>
  NULL
  [1]=>
  NULL
}




Reproduce code:
---
 'string' );
$a2 = array( 'b' => 'string' );
$a3 = array( 'b' => NULL );
$a4 = array( 'b' => NULL );
var_dump( array_merge_recursive($a1, $a2) );  // expected output
var_dump( array_merge_recursive($a3, $a4) );  // unexpecteed output
?>


Expected result:

array(1) {
  ["b"]=>
  array(2) {
[0]=>
string(6) "string"
[1]=>
string(6) "string"
  }
}
array(1) {
  ["b"]=>
  array(2) {
[0]=>
NULL
[1]=>
NULL
  }
}


Actual result:
--
array(1) {
  ["b"]=>
  array(2) {
[0]=>
string(6) "string"
[1]=>
string(6) "string"
  }
}
array(1) {
  ["b"]=>
  array(0) {
  }
}






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

#43885 [NEW]: Object model

2008-01-17 Thread vbaryshev at list dot ru

From: vbaryshev at list dot ru
Operating system: Windows XP
PHP version:  6CVS-2008-01-17 (snap)
PHP Bug Type: *General Issues
Bug description:  Object model

Description:

Some bugs with __get(), __set()

Reproduce code:
---
class Test1
{
public function __construct() { }
public function test()
{
$this->Prop = 'test';
echo $this->Prop;
echo isset($this->Prop);
echo !empty($this->Prop);
echo $this->Prop;
}
}
class Test2 extends Test1
{
private $prop;
public function __construct() { }
public function __get($name)
{
$name{0} = strtolower($name{0}); // Property called with first
symbol upper case
switch ($name)
{
case "prop" :
return $this->prop;
break;
}
}
public function __set($name, $value)
{
$name{0} = strtolower($name{0}); // Property called with first
symbol upper case
switch ($name)
{
case "prop" :
$this->prop = $value;
break;
}
}
}
$obj = new Test2();
$obj->test();


Expected result:

test
{false}
{false}
test

Actual result:
--
test
1
1
test

Íàëè÷èå ñâîéñòâ íå ðàñïîçíàþòñÿ ñòàíäàðòíûìè ôóíêöèÿìè, ÷òî ÿâëÿåòñÿ
íåâåðíûì ñ ëîãè÷åñêîé òî÷êè çðåíèÿ è çàòðóäíÿåò ïðîâîäèòü íåêîòîðûå
ïðîâåðêè ñ ïðàêòè÷åñêîé òî÷êè çðåíèÿ.
Sory, my english very bad :(

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

#26004 [Com]: $_POST variables not set when using enctype="multipart/form-data"

2008-01-17 Thread emmcmahon at comast dot net

 ID:   26004
 Comment by:   emmcmahon at comast dot net
 Reported By:  jacknorton101 at hotmail dot com
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: RedHat Linux 9
 PHP Version:  4.3.3
 New Comment:

I just experienced this problem NOT using enctype="multipart/form-data"
- although I have data being passsed simultaneously with Adobe Spry.  I
used the recent solution  worked for me.


Previous Comments:


[2007-12-23 04:36:50] mondo at mondomx dot com

Been a while since anyone posted. But I am still having this trouble. I
have tried all the solutions on the thread and nothing works.

PHP Version 5.2.4, Apache 2.2.6



[2007-08-08 15:03:57] marcel at cohnen dot nl

I have experienced the problem.

The solution provided on this page worked for me. I had a form with a
lot of textboxes, and also six fileboxes. Changing the enctypes resulted
in either the textboxes working and the fileboxes not working, and vice
versa, but no combination so both would work.

My max file size in php.ini was set to 64M which should be enough.




IMPORTANT:
adding the MAX_FILE_SIZE to my form was the solution to the problem.
But I discovered a new problem doing this, I had to set the
MAX_FILE_SIZE directly under the  tag, unlike some other people's
examples on this page. Doing this It worked fine for me.

for the record, i am running PHP/4.4.7 Apache/1.3.37 on Fedora 5
running kernel  2.6.20-1.2316.fc5smp



[2007-08-03 22:51:29] m_ellingham at hotmail dot com

I had this problem and had to raise realpath_cache_size from 16k to
128k. No problems so far.



[2007-07-14 16:15:56] mgo dot netmail at gmail dot com

Yup, have the same problem with PHP 5.1.6.
If someone have a fix for this issue please let me know. I recently
update my environment and this is starting to cost me too much time and
money.

Thanks in advanced.



[2007-07-03 11:34:35] info at netsilik dot nl

Althoug I cannot reproduce the error myself some of my custommers
experience the bug described above.
And they pop-up in my error-log files

When reguesting a page with the POST method and the enctype is set to
"multipart/form-data", the $_POST suberglobal is left empty.

(Post requests without enctype="multipart/form-data" work fine.)

I've recently moved to PHP 5.1.6.
The exact same code worked fine for months on the previous version.


some php.ini settings (same as previous version):
  max_execution_time = 60
  max_input_time = 120
  memory_limit = 24M
  post_max_size = 8M
  file_uploads = On
  upload_max_filesize = 3M

The html-form: (the document is valid XHTML 1.0 Transitional)


  
  
  
  
  
  
  
  


I've not yet found a solutions for this VERY SERIOUS problem
If there is anyone that has a fix, please let me know.



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/26004

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

#43884 [NEW]: Object model

2008-01-17 Thread vbaryshev at list dot ru

From: vbaryshev at list dot ru
Operating system: Windows XP
PHP version:  6CVS-2008-01-17 (snap)
PHP Bug Type: *General Issues
Bug description:  Object model

Description:

Sory. I very bad speek english. Ñòðàííîå ïðåäñòàâëåíèå êîíñòàíòû
__CLASS__.

Reproduce code:
---
class Test1 {
public function __construct() { }
public function foo()
{
echo __CLASS__ . '';
}
}
class Test2 extends Test1 {
public function __construct() { }
}
$obj1 = new Test1();
$obj2 = new Test2();
$obj1->foo();
$obj2->foo();


Expected result:

Test1
Test1

Actual result:
--
I think, that result must be:
Test1
Test2

Êëàññ Test2() íàñëåäóåò ìåòîäû êëàññà Test1() è ìåòîä foo() ïðè âûçîâå èç
îáúåêòà obj2 äîëæåí áûòü âûçâàí êàê ìåòîä êëàññà Test2() IMHO

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

#41335 [Opn->Csd]: strtotime does not parse australian style dates correctly

2008-01-17 Thread derick

 ID:   41335
 Updated by:   [EMAIL PROTECTED]
 Reported By:  daniel dot oconnor at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  5.2.2
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.

THis is now fixed (for PHP 5.3 and higher). With the
date_create_from_format() function you can now do this:

format( 'c' );
?>

// outputs:
2007-10-01T22:02:37+02:00


Previous Comments:


[2007-05-09 06:15:45] [EMAIL PROTECTED]

Using / here is problematic as it's also the separator in use by the US
folks, but then in the opposite way. Providing a configuration parameter
won't work as the parser would not be able to handle that. As it's
deliberately not working it is not a bug, but a feature request. It
would be possible to allow parsing according to a given format but that
would be totally new functionality which could make it into PHP 6.



[2007-05-09 02:37:27] daniel dot oconnor at gmail dot com

Description:

Australians tend to do dates in dd/mm/ format, rather than
mm/dd/

strtotime cannot handle this when the seperator is a '/', but can for
'-' and '.'

PHP should either:
 * Use consistent parsing all the way through. It should not matter if
I pick a '-', '/' or '.'
 * Provide me an argument or configuration setting with which I can
change the default behaviour.
   See http://en.wikipedia.org/wiki/Calendar_date#Date_format for a
list of countries which use dd/mm/ as a default, compared to a list
of those who use mm/dd/.


Reproduce code:
---
http://bugs.php.net/?id=41335&edit=1

#43883 [NEW]: Xsl gives Segmentation fault

2008-01-17 Thread jonasmunk at mac dot com

From: jonasmunk at mac dot com
Operating system: Mac OS X leopard
PHP version:  5.2.5
PHP Bug Type: XSLT related
Bug description:  Xsl gives Segmentation fault

Description:

Hello

When trying to use the xsl functions in php from macports install like 
this:

$xslData = ''.
'http://www.w3.org/1999/XSL/Transform"; version="1.0">'.
''.
'abc'.
'';
$xmlData = '';
$xslt = new xsltProcessor;
$xslt->importStyleSheet(DomDocument::loadXML($xslData));
$result = $xslt->transformToXML(DomDocument::loadXML($xmlData));

I get this error in the log file (after a few seconds):

[Thu Jan 17 20:09:19 2008] [notice] child pid 13951 exit signal 
Segmentation fault (11)

Does anyone know why this happens.

It works with the PHP standard in leopard and I have been working 
on/using this code for years (also on tiger and panther) using other 
php-dists.







Reproduce code:
---
$xslData = ''.
'http://www.w3.org/1999/XSL/Transform";
version="1.0">'.
''.
'abc'.
'';
$xmlData = '';
$xslt = new xsltProcessor;
$xslt->importStyleSheet(DomDocument::loadXML($xslData));
$result = $xslt->transformToXML(DomDocument::loadXML($xmlData));

Expected result:

No fault

Actual result:
--
Here's the crash report:

Process: httpd [14154]
Path:/opt/local/apache2/bin/httpd
Identifier:  httpd
Version: ??? (???)
Code Type:   PPC (Native)
Parent Process:  httpd [13623]

Date/Time:   2008-01-17 20:12:37.909 +0100
OS Version:  Mac OS X 10.5.1 (9B18)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00030024
Crashed Thread:  0

Application Specific Information:
*** single-threaded process forked ***

Thread 0 Crashed:
0   libxml2.2.dylib 0x019e2db4 
xmlXPathContextSetCache + 212
1   libxslt.1.dylib 0x01af560c 
xsltNewTransformContext + 540
2   libphp5.so  0x012372a8 
php_xsl_apply_stylesheet + 936
3   libphp5.so  0x01237490 
zif_xsl_xsltprocessor_transform_to_xml + 128
4   libphp5.so  0x012a8918 
zend_do_fcall_common_helper_SPEC + 2152
5   libphp5.so  0x012a5944 execute + 388
6   libphp5.so  0x012851b8 
zend_execute_scripts + 360
7   libphp5.so  0x0123cf28 php_execute_script 
+ 616
8   libphp5.so  0x0132c248 php_handler + 1272
9   httpd   0x2d10 ap_run_handler + 96
10  httpd   0x3384 ap_invoke_handler + 
244
11  httpd   0x00027de8 ap_process_request 
+ 104
12  httpd   0x00024c54 
ap_process_http_connection + 116
13  httpd   0x00010d60 
ap_run_process_connection + 96
14  httpd   0x0002c2b8 child_main + 1240
15  httpd   0x0002c47c make_child + 316
16  httpd   0x0002cdd0 ap_mpm_run + 2128
17  httpd   0x9338 main + 3384
18  httpd   0x2070 start + 64
19  ??? 0xbbc8 0 + 3221224392

Thread 0 crashed with PPC Thread State 32:
 srr0: 0x019e2db4  srr1: 0xd930   dar: 0x00030024 dsisr: 
0x4200
   r0: 0xr1: 0xbfffe730r2: 0x24004224r3: 
0x0003
   r4: 0x0001r5: 0xr6: 0xr7: 
0x332e6f72
   r8: 0x30322f30r9: 0x75657279   r10: 0xff3f   r11: 
0x01b00348
  r12: 0x019e2ce0   r13: 0x   r14: 0xbfffea90   r15: 
0x01b23028
  r16: 0x01366f10   r17: 0x01366f10   r18: 0x01b22fb0   r19: 
0x01d09230
  r20: 0x01366f10   r21: 0x01b227b8   r22: 0xbfffe828   r23: 
0x
  r24: 0x01d09ff0   r25: 0x01b1f120   r26: 0x01d09ff0   r27: 
0x
  r28: 0x0001   r29: 0x01d09eb0   r30: 0x0064   r31: 
0x019e2cf4
   cr: 0x44004228   xer: 0xlr: 0x019e2cf4   ctr: 
0x019e2ce0
vrsave: 0x8000

Binary Images:
   0x1000 -0x37ff7 +httpd ??? (???) /opt/local/apache2/bin/httpd
  0x54000 -0x75ff7 +libpcre.0.dylib ??? (???) 
/opt/local/lib/libpcre.0.dylib
  0x79000 -0x8cffd +libaprutil-1.0.dylib ??? (???) 
/opt/local/lib/libaprutil-1.0.dylib
  0x94000 -0xb2ff3 +libexpat.1.dylib ??? (???) 
/opt/local/lib/libexpat.1.dylib
  0xbc000 -0xbcff1 +mod_authn_file.so ??? (???) 
/opt/local/apache2/modules/mod_authn_file.so
  0xbf000 -0xbfffd +mod_authn_dbm.so ??? (???) 
/opt/local/apache2/modules/mod_authn_dbm.so
  0xc2000 -0xc2ff5 +mod_authn_anon.so ??? (???) 
/opt/local/apache2/modules/mod_authn_anon.so
  0xc5000 -0xc5ff5 +mod_authn_dbd.so ??? (???) 
/opt/local/apache2/modules/mod_authn_dbd.so
  0xc8000 -0xc8ff8 +mod_authn_default.so ??? (???) 
/opt/local/apache2/modules/mod_authn_default.so
  0xcb000 -

#41599 [Asn->Csd]: setTime() fails after modify() is used

2008-01-17 Thread derick

 ID:   41599
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kgrecki at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Windows/Linux
 PHP Version:  5.2.3
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2007-06-05 16:11:45] kgrecki at gmail dot com

Description:

setTime() causes time to move to next Sunday if modify() was called
before it. See example. Looks related to Bug #39782
Tested on 5.2.2 Windows & 5.2.3 Linux

Reproduce code:
---
date_default_timezone_set('Europe/London');

$start = new DateTime('last Monday');
echo $start->format('Y-m-d H:i:s'),PHP_EOL;
//good

$start->modify('Tuesday');
echo $start->format('Y-m-d H:i:s'),PHP_EOL;
//good

$start->setTime(0, 0, 0);
echo $start->format('Y-m-d H:i:s'),PHP_EOL;
//jumped to next Sunday

$start->setTime(0, 0, 0);
echo $start->format('Y-m-d H:i:s'),PHP_EOL;
//jumped to next Sunday again

Expected result:

2007-06-04 00:00:00
2007-06-05 00:00:00
2007-06-05 00:00:00
2007-06-05 00:00:00

Actual result:
--
2007-06-04 00:00:00
2007-06-05 00:00:00
2007-06-10 00:00:00
2007-06-17 00:00:00





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

#43075 [Asn->Csd]: Support 2007-11-01T24:00:00+00:00

2008-01-17 Thread derick

 ID:   43075
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.3CVS-2007-10-23 (CVS)
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2007-10-23 07:17:31] [EMAIL PROTECTED]

Description:

Support 2007-11-01T24:00:00+00:00 in strtotime()






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

#43808 [Asn->Csd]: date_create never fails (even when it should)

2008-01-17 Thread derick

 ID:   43808
 Updated by:   [EMAIL PROTECTED]
 Reported By:  martin dot contento at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: linux
 PHP Version:  5.2.5
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2008-01-10 18:30:37] martin dot contento at gmail dot com

Description:

As "karsten" already mentioned
(http://de.php.net/manual/en/function.date-create.php#77871)
date_create() never returns FALSE like it is supposed to, even when it
is handed complete garbage. It seems to be something like "if the string
starts with a letter, treat it as a timezone -> this is not a timezone
*dies*)

edit:
also, this bug might be related: http://bugs.php.net/bug.php?id=40340

Reproduce code:
---


Expected result:

nothing (i would expect date_create() to handle the error in the
timezone function and return FALSE)

Actual result:
--
Warning: date_create(): Failed to parse time string (asdfasdf) at
position 0 (a): The timezone could not be found in the database in
/home/mcontento/datetimebug.php on line 3





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

#43003 [Asn->Csd]: Invalid timezone reported for DateTime objects constructed using a timestamp

2008-01-17 Thread derick

 ID:   43003
 Updated by:   [EMAIL PROTECTED]
 Reported By:  post at jefago dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Debian GNU/Linux
 PHP Version:  5.2.4
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2007-10-17 12:30:34] post at jefago dot de

Description:

A DateTime object that is created using a timestamp (with the
"@$iTimestamp" notation) but without a explicitly given time zone (in
the constructor) invalidly reports its time zone as the default time
zone, although its time zone really is UTC. Converting it to the default
time zone corrects this behaviour.

I know that this bug is somewhat similiar to
http://bugs.php.net/bug.php?id=41912, that was marked as "bogus", but I
think the demonstration code makes it clearer that in this case it is
really buggy behaviour.

In fact, the UNIX timestamp is quite clearly defined as "the number of
seconds since 1970-01-01 00:00:00 UTC" and thus it should be time zone
independant.

Reproduce code:
---
$oDateTest = new DateTime("@0", new
DateTimeZone(date_default_timezone_get()));
echo "timestamp 0, constructed with default time zone
(".$oDateTest->getTimezone()->getName()."): " .
$oDateTest->format("Y-m-d H:i:s")."";
$oDateTest->setTimezone(new DateTimeZone("UTC"));
echo "timestamp 0, constructed with default time zone, set to
".$oDateTest->getTimezone()->getName()." afterwards: " .
$oDateTest->format("Y-m-d H:i:s")."";
$oDateTest->setTimezone(new
DateTimeZone(date_default_timezone_get()));
echo "timestamp 0, constructed with default time zone, then set to UTC
and then to default time zone (".$oDateTest->getTimezone()->getName().")
again: " . $oDateTest->format("Y-m-d H:i:s")."";

$oDateTest = new DateTime("@0");
echo "timestamp 0, constructed with default time zone
(".$oDateTest->getTimezone()->getName()."): " .
$oDateTest->format("Y-m-d H:i:s")."";
$oDateTest->setTimezone( new
DateTimeZone(date_default_timezone_get()));
echo "timestamp 0, constructed with default time zone, explicitly set
to default time zone (".$oDateTest->getTimezone()->getName().")
afterwards: " . $oDateTest->format("Y-m-d H:i:s")."";


Expected result:

timestamp 0, constructed with default time zone (Europe/Berlin):
1970-01-01 01:00:00
timestamp 0, constructed with default time zone, set to UTC afterwards:
1970-01-01 00:00:00
timestamp 0, constructed with default time zone, then set to UTC and
then to default time zone (Europe/Berlin) again: 1970-01-01 01:00:00
timestamp 0, constructed with default time zone (Europe/Berlin):
1970-01-01 01:00:00
timestamp 0, constructed with default time zone, explicitly set to
default time zone (Europe/Berlin) afterwards: 1970-01-01 01:00:00

Actual result:
--
timestamp 0, constructed with default time zone (Europe/Berlin):
1970-01-01 00:00:00 (Either the time zone or the reported time is
WRONG)
timestamp 0, constructed with default time zone, set to UTC afterwards:
1970-01-01 00:00:00
timestamp 0, constructed with default time zone, then set to UTC and
then to default time zone (Europe/Berlin) again: 1970-01-01 01:00:00
timestamp 0, constructed with default time zone (Europe/Berlin):
1970-01-01 00:00:00 (Either the time zone or the reported time is
WRONG)
timestamp 0, constructed with default time zone, explicitly set to
default time zone (Europe/Berlin) afterwards: 1970-01-01 01:00:00





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

#43872 [Opn->Csd]: preg_replace() returns blank string

2008-01-17 Thread floyd dot mcmichael at alaska dot gov

 ID:   43872
 User updated by:  floyd dot mcmichael at alaska dot gov
 Reported By:  floyd dot mcmichael at alaska dot gov
-Status:   Open
+Status:   Closed
 Bug Type: *Regular Expressions
 Operating System: windows
 PHP Version:  5.2.5
 New Comment:

reviewed preg_replace string again and realized two non-alphanumeric
characters were not escaped. (specifically two "(" ) re-ran and now the
preg_replace string works. this must have been a change in 5.2.5 but now
that the ('s are escaped the function works properly.


Previous Comments:


[2008-01-16 23:52:00] floyd dot mcmichael at alaska dot gov

EDIT:
""

should be ""

preg_last_error(); returns 0 NO_ERROR.
why is this function not working as expected?



[2008-01-16 23:45:51] floyd dot mcmichael at alaska dot gov

Description:

preg_replace blanks a string that it didn't use to in previous versions
of PHP 5.x. other preg_replace strings not affected


Reproduce code:
---
function doSmiles($string, $skinname)
{
$patterns = array(
"/\[alien\]/i",
... snipped due to length ...
"/\[crazy\]/i"
);
$replacements = array(
"",
... snip due to length ...
""
);

$string = preg_replace($patterns, $replacements, $string);
return $string;
}


Expected result:

print substrings like [alien] to html-valid strings like . prior to upgrading to 5.2.5 this
particular function DID work. it no longer works.

Actual result:
--
returns a blank string ""





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

#31954 [Com]: Interbase returning bool - PHP crash

2008-01-17 Thread virtue at rocketmonkeys dot com

 ID:   31954
 Comment by:   virtue at rocketmonkeys dot com
 Reported By:  okke at formsma dot nl
 Status:   No Feedback
 Bug Type: InterBase related
 Operating System: Windows XP SP1
 PHP Version:  5.0.3
 New Comment:

I'm experiencing this bug, and I think it might be the same issue.
I make a page with just this:

The connect and "CREATE TABLE" run fine, but the "SELECT" statement
crashes Apache.  If I do the same thing without the boolean field, this
doesn't happen.  The same statements work fine in IBConsole, so it
doesn't seem to be any problem with Interbase or the SQL code itself.  I
think this bug needs to be reopened, unless I missed something simple.

php 5.2.5
apache 2.2.6
interbase 2007 on PC, version WI-V8.1.0.257


Previous Comments:


[2005-03-20 18:09:20] [EMAIL PROTECTED]

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 "Open". Thank you.





[2005-02-24 07:32:42] [EMAIL PROTECTED]

Please try if the error can be reproduced with a php_interbase.dll
built from source using the ibase.h header file that comes with
Interbase 7.1




[2005-02-23 22:44:05] okke at formsma dot nl

I used the pre-built one from PHP.net



[2005-02-23 20:51:04] [EMAIL PROTECTED]

Did you build php_interbase.dll from source, or did you use the
pre-built one from php.net?




[2005-02-13 12:23:16] okke at formsma dot nl

Description:

I'm using interbase 7. 

I made a table using a BOOLEAN field. Everything worked fine, until I
tried to extract data from the table. Then I found out that the BOOLEAN
field was crashing PHP (and, in succession, apache). 

The error I got with PHP was (command line client): 
"Warning: ibase_fetch_assoc(): Dynamic SQL Error SQL error code = -804
Incorrect values within SQLDA structure  in [...]"

(for search-sake: the Apache error was "Parent: child process exited
with status 3221225477 -- Restarting.")

The problem is not a database failure; IBconsole and Database Workbench
both handle the test-SQL perfectly.

Reproduce code:
---
I left the PHP code out, for readability. I'm using ibase_connect(),
ibase_query() and ibase_fetch_assoc().
Run the following SQL first:
CREATE TABLE TEST
(
  ID INTEGER NOT NULL,
  PUBLISHED  BOOLEAN DEFAULT 0,
 CONSTRAINT PK_CMS PRIMARY KEY (ID)
)
;

Fill the database with some lines, it doesn't matter what exactly:
INSERT INTO TEST(ID, PUBLISHED) VALUES(1,false);
INSERT INTO TEST(ID, PUBLISHED) VALUES(2,true);
INSERT INTO TEST(ID, PUBLISHED) VALUES(3,false);
INSERT INTO TEST(ID, PUBLISHED) VALUES(4,true);

Then try to extract data from the database:
SELECT * FROM TEST;

Expected result:

(after ibase_query()): 

an array with the values from the database.


Actual result:
--
A big fat error, where after PHP and Apache will crash. The problem
occurs on the line with ibase_query().





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

#43882 [NEW]: Include_path escape sequences problem

2008-01-17 Thread dutow at nwi dot hu

From: dutow at nwi dot hu
Operating system: Windows XP SP2
PHP version:  5.3CVS-2008-01-17 (snap)
PHP Bug Type: *Configuration Issues
Bug description:  Include_path escape sequences problem

Description:

PHP escapes escape sequences in include_path.

Reproduce code:
---
include_path = ".;d:\web\php\pear;d:\web\nowww"



Expected result:

.;d:\web\php\pear;d:\web\nowww

Actual result:
--
.;d:\web\php\pear;d:\web
owww

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

#43527 [Asn->Csd]: DateTime created from a timestamp reports environment timezone

2008-01-17 Thread derick

 ID:   43527
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mattis at xait dot no
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Windows XP SP2
 PHP Version:  5.2.5
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.

The script now returns:
+10:00
(And you really should not be using the "Etc/*" style timezone
identifiers.


Previous Comments:


[2007-12-07 09:59:22] [EMAIL PROTECTED]

There is a bug here, but the expected result is not necessarily what
you say it should be. Because there is no real timezone , it probably
should return false.



[2007-12-07 09:55:51] mattis at xait dot no

Description:

When creating a DateTime from a timestamp (i.e. date('r)) it will
report the TimeZone of the environment it was created in and not the
timezone in the timestamp.

Reproduce code:
---
getTimezone()->getName(), "\n";

Expected result:

Etc/GMT-10

Actual result:
--
Etc/GMT+1





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

#42910 [Asn->Csd]: Constructing DateTime with TimeZone Indicator invalidates DateTimeZone

2008-01-17 Thread derick

 ID:   42910
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at michaelho dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Mac OS X 10.4.10
 PHP Version:  5.2.4
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2007-11-04 21:56:58] alex at kiesel dot name

I also believe that there should be a possibility to distinguish
between a timezone "constructed" by an GMT offset and one constructed by
an timezone identifier.

Here is a shorter reproducting script which shows the inconsistency:


This prints:
$ php date.php 
string(22) "+0200 Australia/Sydney"



[2007-10-09 23:42:18] [EMAIL PROTECTED]

This is expected behavior, but I'll check your claim about getName().



[2007-10-09 23:35:16] php at michaelho dot com

Typo... the first sentence in the third paragraph should read:

"My guess is that **IF** a timezone indicator is passed into the
__construct() method..."



[2007-10-09 23:33:36] php at michaelho dot com

Description:

When creating a new DateTime with an timezone indicator (e.g. "-0800"),
it seems to ignore any DateTimeZone rules as specified either by the
default_timezone setting OR by an explicit DateTimeZone parameter.

Notice that in the example below, the engine no longer applies
DateTimeZone rules for $bar, even though the engine still lists
"America/Los_Angeles" as $bar's DateTimeZone value.

My guess is that a timezone indicator is passed into the __construct()
method, it will be very difficult for the engine to deduce the correct
DateTimeZone rules to use for that DateTime object, and thus, no rules
should be applied after this point.

If this is the case, then at the very least
$bar->getTimezone()->getName() should return something like 'Undefined'
or 'Custom/-0800' or something like that, to correctly indicate it is no
longer using 'America/Los_Angeles' timezone rules.

Reproduce code:
---
date_default_timezone_set('America/Los_Angeles');
$foo = new DateTime('2007-03-11');
$bar = new DateTime('2007-03-11T00:00:00-0800');

print $foo->format(DateTime::ISO8601) . ' - ' .
$foo->getTimezone()->getName() . ' - ' . $foo->format('U') . "\r\n";
print $bar->format(DateTime::ISO8601) . ' - ' .
$foo->getTimezone()->getName() . ' - ' . $bar->format('U') . "\r\n";

$foo->setDate(2007, 03, 12);
$bar->setDate(2007, 03, 12);

print $foo->format(DateTime::ISO8601) . ' - ' .
$foo->getTimezone()->getName() . ' - ' . $foo->format('U') . "\r\n";
print $bar->format(DateTime::ISO8601) . ' - ' .
$foo->getTimezone()->getName() . ' - ' . $bar->format('U') . "\r\n";


Expected result:

2007-03-11T00:00:00-0800 - America/Los_Angeles - 117360
2007-03-11T00:00:00-0800 - America/Los_Angeles - 117360
2007-03-12T00:00:00-0700 - America/Los_Angeles - 1173682800
2007-03-12T00:00:00-0700 - America/Los_Angeles - 1173682800

Actual result:
--
2007-03-11T00:00:00-0800 - America/Los_Angeles - 117360
2007-03-11T00:00:00-0800 - America/Los_Angeles - 117360
2007-03-12T00:00:00-0700 - America/Los_Angeles - 1173682800
2007-03-12T00:00:00-0800 - America/Los_Angeles - 1173686400





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

#40743 [Asn->Csd]: DateTime ignores the TimeZone object passed to the constructor

2008-01-17 Thread derick

 ID:   40743
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ddb at bitxtender dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Win XP
 PHP Version:  5.2.1
 Assigned To:  derick
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2007-04-19 20:53:33] artur at jedlinski dot pl

It is ignoring the #2 parameter when you put the timezone info inside
the #1. It's *absolutely* unacceptable.

// Europe/Warsaw = GMT +0200
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc, new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."";
// RESULT: 12:50:00 (expected: 14:50:00)

$dateTime->setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."";
// RESULT: 14:50:00 (correct)

IMHO the most intuitive way is to create the date based on the #1, but
displays it using #2.

It's not only strange it ignores #2, but in fact it's strange that the
internal DateTime pointer is set to timezone provided in #1 at all. If
the date_default_timezone_set() was set to some TZ, it should create
dates within this timezone if one doesn't state otherwise (using #2). Of
course the timezone info from #1 should be used, but only to calculate
the actual timestamp.

date_default_timezone_set('Europe/Warsaw');
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc);
echo $dateTime->format('H:i:s')."";
// RESULT: 12:50:00 (expected: 14:50:00)

Currently, it's pretty complicated to translate dates from one timezone
to another - you have to use DateTime::setTimeZone(), when one line
should do the thing:

$dateTime = new DateTime($dateWithSrcTimeZone, $timeZoneToDisplay);
(or even without $timeZoneToDisplay if you want to use your current
TZ).



[2007-04-11 14:45:46] [EMAIL PROTECTED]

It's not totally ignored, but something fishy is going on. See the
following script + output:

format(DATE_RFC822 . " e T O"), "\n";

$dt = new DateTime('@' . time());
echo $dt->format(DATE_RFC822 . " e T O"), "\n";

$dt = new DateTime('@' . time(), new DateTimeZone('Europe/Berlin'));
echo $dt->format(DATE_RFC822 . " e T O"), "\n";
?>

Wed, 11 Apr 07 16:42:40 +0200 Europe/Oslo CEST +0200
Wed, 11 Apr 07 14:42:40 +0100 Europe/Oslo GMT+0100 +0100
Wed, 11 Apr 07 14:42:40 +0100 Europe/Berlin GMT+0100 +0100




[2007-03-06 23:27:24] ddb at bitxtender dot de

Description:

when you create a new DateTime object the timezone object you pass
along in the constructor is ignored.
setting the timezone using setTimeZone works as expected.
also tested with 5.2-dev and 6.0-dev

Reproduce code:
---
$dt = new DateTime('@' . time(), new DateTimeZone('Europe/Berlin'));
echo $dt->format(DATE_RFC822);

Expected result:

Tue, 07 Mar 07 01:22:55 +0100

Actual result:
--
Tue, 07 Mar 07 00:22:55 +





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

#43866 [Opn->Bgs]: Can't define the connect timeout on mysqli extension class

2008-01-17 Thread uw

 ID:   43866
 Updated by:   [EMAIL PROTECTED]
 Reported By:  basilio dot vera at softonic dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Linux RHEL4
 PHP Version:  5.2.5
 New Comment:

Not a bug, solution is given, documentation "flaw" discussed.


Previous Comments:


[2008-01-17 17:54:44] basilio dot vera at softonic dot com

For example with an example inside the mysqli_init() or
mysqli_options() function docs:

class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::init();
parent::options( MYSQLI_OPT_CONNECT_TIMEOUT, 5 );
parent::real_connect( $host, $user, $pass, $db );
}
}

Regards.



[2008-01-17 17:29:50] [EMAIL PROTECTED]

Give me a hint, what's up with the documentation?

http://us2.php.net/mysqli_connect shows that calling constructor of the
mysqli class is equal to calling mysqli_connect(). As you know, you need
to call mysqli_options() before a connection has been established. In
your reproduceable code you suggest a derived class which explicitly
calls the parent constructor to create a connection. Once the parent
constructor has been called you try to call mysqli_options()
(mysqli::options()). That's too late.

Your second example gets it right. How could we improve the
documentation? Thanks!

Ulf



[2008-01-17 00:19:51] basilio dot vera at softonic dot com

Hi, I've found a solution for this problem. It can be solved with:

class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
$this->init();
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$this->real_connect( $host, $user, $pass, $db );
}
}

But you may consider review your docs, because it's and undocumented
feature!



[2008-01-16 14:34:39] basilio dot vera at softonic dot com

Sorry, the error message was:

'Couldn't fetch mysqli2'



[2008-01-16 14:23:49] basilio dot vera at softonic dot com

Description:

I can't change the "MYSQLI_OPT_CONNECT_TIMEOUT" flag inside an extended
class of mysqli.

This is not really a bug, but a missed feature!


Reproduce code:
---
// I want some similar to this:
$mysqli = mysqli_init();
$mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$mysqli->real_connect('localhost', 'my_user', 'my_password', 'world');

// My class that does many magic things.
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::__construct( $host, $user, $pass, $db );
// Too late, the connection has been done before!
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
}
}
// If I put the options call before the parent::__construct() call I
get 'Couldn't fetch DbLink' error.

// And, obviously, this does not work.
class mysqli3 extends mysqli_init {}

Expected result:

The connect timeout has been changed to 5 seconds.

Actual result:
--
The connect timeout has not been changed.





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

#43866 [Opn]: Can't define the connect timeout on mysqli extension class

2008-01-17 Thread basilio dot vera at softonic dot com

 ID:   43866
 User updated by:  basilio dot vera at softonic dot com
 Reported By:  basilio dot vera at softonic dot com
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux RHEL4
 PHP Version:  5.2.5
 New Comment:

For example with an example inside the mysqli_init() or
mysqli_options() function docs:

class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::init();
parent::options( MYSQLI_OPT_CONNECT_TIMEOUT, 5 );
parent::real_connect( $host, $user, $pass, $db );
}
}

Regards.


Previous Comments:


[2008-01-17 17:29:50] [EMAIL PROTECTED]

Give me a hint, what's up with the documentation?

http://us2.php.net/mysqli_connect shows that calling constructor of the
mysqli class is equal to calling mysqli_connect(). As you know, you need
to call mysqli_options() before a connection has been established. In
your reproduceable code you suggest a derived class which explicitly
calls the parent constructor to create a connection. Once the parent
constructor has been called you try to call mysqli_options()
(mysqli::options()). That's too late.

Your second example gets it right. How could we improve the
documentation? Thanks!

Ulf



[2008-01-17 00:19:51] basilio dot vera at softonic dot com

Hi, I've found a solution for this problem. It can be solved with:

class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
$this->init();
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$this->real_connect( $host, $user, $pass, $db );
}
}

But you may consider review your docs, because it's and undocumented
feature!



[2008-01-16 14:34:39] basilio dot vera at softonic dot com

Sorry, the error message was:

'Couldn't fetch mysqli2'



[2008-01-16 14:23:49] basilio dot vera at softonic dot com

Description:

I can't change the "MYSQLI_OPT_CONNECT_TIMEOUT" flag inside an extended
class of mysqli.

This is not really a bug, but a missed feature!


Reproduce code:
---
// I want some similar to this:
$mysqli = mysqli_init();
$mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$mysqli->real_connect('localhost', 'my_user', 'my_password', 'world');

// My class that does many magic things.
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::__construct( $host, $user, $pass, $db );
// Too late, the connection has been done before!
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
}
}
// If I put the options call before the parent::__construct() call I
get 'Couldn't fetch DbLink' error.

// And, obviously, this does not work.
class mysqli3 extends mysqli_init {}

Expected result:

The connect timeout has been changed to 5 seconds.

Actual result:
--
The connect timeout has not been changed.





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

#43866 [Opn]: Can't define the connect timeout on mysqli extension class

2008-01-17 Thread uw

 ID:   43866
 Updated by:   [EMAIL PROTECTED]
 Reported By:  basilio dot vera at softonic dot com
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux RHEL4
 PHP Version:  5.2.5
 New Comment:

Give me a hint, what's up with the documentation?

http://us2.php.net/mysqli_connect shows that calling constructor of the
mysqli class is equal to calling mysqli_connect(). As you know, you need
to call mysqli_options() before a connection has been established. In
your reproduceable code you suggest a derived class which explicitly
calls the parent constructor to create a connection. Once the parent
constructor has been called you try to call mysqli_options()
(mysqli::options()). That's too late.

Your second example gets it right. How could we improve the
documentation? Thanks!

Ulf


Previous Comments:


[2008-01-17 00:19:51] basilio dot vera at softonic dot com

Hi, I've found a solution for this problem. It can be solved with:

class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
$this->init();
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$this->real_connect( $host, $user, $pass, $db );
}
}

But you may consider review your docs, because it's and undocumented
feature!



[2008-01-16 14:34:39] basilio dot vera at softonic dot com

Sorry, the error message was:

'Couldn't fetch mysqli2'



[2008-01-16 14:23:49] basilio dot vera at softonic dot com

Description:

I can't change the "MYSQLI_OPT_CONNECT_TIMEOUT" flag inside an extended
class of mysqli.

This is not really a bug, but a missed feature!


Reproduce code:
---
// I want some similar to this:
$mysqli = mysqli_init();
$mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$mysqli->real_connect('localhost', 'my_user', 'my_password', 'world');

// My class that does many magic things.
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::__construct( $host, $user, $pass, $db );
// Too late, the connection has been done before!
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
}
}
// If I put the options call before the parent::__construct() call I
get 'Couldn't fetch DbLink' error.

// And, obviously, this does not work.
class mysqli3 extends mysqli_init {}

Expected result:

The connect timeout has been changed to 5 seconds.

Actual result:
--
The connect timeout has not been changed.





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

#43677 [Com]: Inconsistent behaviour of include_path set with php_value

2008-01-17 Thread d at tpyo dot net

 ID:   43677
 Comment by:   d at tpyo dot net
 Reported By:  root at net1 dot cc
 Status:   Open
 Bug Type: Safe Mode/open_basedir
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 New Comment:

Thanks Manuel.  Patch works perfectly.  But I agree, it is a fairly 
serious issue that undoubtedly affects a lot of users.


Previous Comments:


[2008-01-17 13:40:04] manuel at mausz dot at

Err... php as apache module... :)



[2008-01-17 13:35:48] manuel at mausz dot at

Can some dev please take a look at this (or the patch)?
This is a serious issue for all users running apache as module and
mixing php_admin_value and php_value.

It also looks like this is the same as:
http://bugs.php.net/bug.php?id=43842
http://bugs.php.net/bug.php?id=43755
http://bugs.php.net/bug.php?id=43207



[2008-01-13 03:14:53] root at net1 dot cc

I've been using the patched PHP for several hours now, and - confirmed
- it's working flawless! This patch really fixes the issue! Thanks once
again, Manuel!

For FreeBSD users, I've uploaded a modified patch file for deployment
with the ports system, for ease of use, and instructions here:
http://mirror.net1.cc/projects/php-bug43677-patch/



[2008-01-12 21:19:29] root at net1 dot cc

I'm gonna test Manuel's patch (thanks!) and report back later if it
does fix the problems observed.



[2008-01-12 18:08:43] manuel at mausz dot at

I tracked the problem down. Every altered ini setting gets added to the
 modified_ini_directives-hashtable in order to restore the original
value after the request has been processed. Zend simply forgets to
restore the modifiable-level.

A patch can be found at 
http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch
Please note that this patch will break the ini setting ABI. Thus all
extensions registering ini settings will have to be recompiled.



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/43677

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

#43879 [NEW]: PHP_INI_PERDIR support in registry

2008-01-17 Thread phprequests at iis-aid dot com

From: phprequests at iis-aid dot com
Operating system: Windows 2003 Server
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  PHP_INI_PERDIR support in registry

Description:

Would it be possible to add support for setting PHP_INI_PERDIR values in
the Windows registry the same as PHP_INI_USER values as per documented in
the link below?

http://us2.php.net/configuration.changes

This has been brought up way back in 2005 in this report;

http://bugs.php.net/bug.php?id=32337&edit=2

Problem is when using PHP on IIS the registry method is the only way I am
aware of for setting per directory/localised PHP environment values without
using the ini_set() function which is not usally a viable option.


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

#43877 [NEW]: Tempnam: absolute/relative path

2008-01-17 Thread stefano dot sanguineti at selesta dot it

From: stefano dot sanguineti at selesta dot it
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: Filesystem function related
Bug description:  Tempnam: absolute/relative path

Description:

Until 5.2.3 a file created with tempnam had relative path.
After this version the file have absolute path.

Reproduce code:
---
PHP 5.2.3:
$report=tempnam('temp', 'report.rpt');
echo $report;
temp/report.rpt


PHP 5.2.4 and 5.2.5:
$report=tempnam('temp', 'report.rpt');
echo $report;
/usr/local/apache/htdocs/temp/report.rpt




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

#43871 [Opn->Csd]: Segmentation fault in dns_get_record

2008-01-17 Thread iliaa

 ID:   43871
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Linux 2.6.23-gentoo-r5
 PHP Version:  5.3CVS-2008-01-16 (CVS)
 New Comment:

This bug has been fixed in CVS.

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.




Previous Comments:


[2008-01-16 23:19:31] [EMAIL PROTECTED]

Description:

Segmentation fault for:

$ php -r 'var_dump( dns_get_record( "localhost", DNS_A ) );'
Segmentation fault

Reproduce code:
---
php -r 'var_dump( dns_get_record( "localhost", DNS_A ) );'

Expected result:

Not a segfault.

Actual result:
--
[EMAIL PROTECTED] trunk $ php -v
PHP 5.3.0-dev (cli) (built: Jan 17 2008 00:10:25) (DEBUG)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.2, Copyright (c) 2002-2007, by Derick Rethans
[EMAIL PROTECTED] trunk $ gdb php
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -r 'var_dump( dns_get_record( "localhost", DNS_A ) );'
Starting program: /usr/bin/php -r 'var_dump( dns_get_record(
"localhost", DNS_A ) );'
[Thread debugging using libthread_db enabled]
[New Thread 0xb62af6d0 (LWP 13199)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb62af6d0 (LWP 13199)]
0x0839ec12 in _zval_dtor (zvalue=0xeb0, __zend_filename=0x8774038
"/home/kore/bin/php/php-5.3-cvs/php-src/ext/standard/dns.c",
__zend_lineno=672) at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_variables.h:32
32  if (zvalue->type <= IS_BOOL) {
(gdb) bt
#0  0x0839ec12 in _zval_dtor (zvalue=0xeb0, __zend_filename=0x8774038
"/home/kore/bin/php/php-5.3-cvs/php-src/ext/standard/dns.c",
__zend_lineno=672) at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_variables.h:32
#1  0x0839e32f in zif_dns_get_record (ht=2, return_value=0x8936aec,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/home/kore/bin/php/php-5.3-cvs/php-src/ext/standard/dns.c:672
#2  0x084a7b82 in execute_internal (execute_data_ptr=0xbf8cabac,
return_value_used=1) at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_execute.c:1436
#3  0xb61feb24 in xdebug_execute_internal
(current_execute_data=0xbf8cabac, return_value_used=1) at
/tmp/pear/cache/xdebug-2.0.2/xdebug.c:1573
#4  0x084a8346 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf8cabac) at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_vm_execute.h:193
#5  0x084ad545 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbf8cabac) at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_vm_execute.h:1393
#6  0x084a7e29 in execute (op_array=0x89364f0) at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_vm_execute.h:87
#7  0xb61fe7b3 in xdebug_execute (op_array=0x89364f0) at
/tmp/pear/cache/xdebug-2.0.2/xdebug.c:1509
#8  0x0847315e in zend_eval_string (str=0xbf8cc12e "var_dump(
dns_get_record( \"localhost\", DNS_A ) );", retval_ptr=0x0,
string_name=0x87b3644 "Command line code")
at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_execute_API.c:1262
#9  0x084732fe in zend_eval_string_ex (str=0xbf8cc12e "var_dump(
dns_get_record( \"localhost\", DNS_A ) );", retval_ptr=0x0,
string_name=0x87b3644 "Command line code", handle_exceptions=1)
at
/home/kore/bin/php/php-5.3-cvs/php-src/Zend/zend_execute_API.c:1295
#10 0x085146c7 in main (argc=3, argv=0xbf8cb034) at
/home/kore/bin/php/php-5.3-cvs/php-src/sapi/cli/php_cli.c:1179
(gdb) quit






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

#43677 [Com]: Inconsistent behaviour of include_path set with php_value

2008-01-17 Thread manuel at mausz dot at

 ID:   43677
 Comment by:   manuel at mausz dot at
 Reported By:  root at net1 dot cc
 Status:   Open
 Bug Type: Safe Mode/open_basedir
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 New Comment:

Err... php as apache module... :)


Previous Comments:


[2008-01-17 13:35:48] manuel at mausz dot at

Can some dev please take a look at this (or the patch)?
This is a serious issue for all users running apache as module and
mixing php_admin_value and php_value.

It also looks like this is the same as:
http://bugs.php.net/bug.php?id=43842
http://bugs.php.net/bug.php?id=43755
http://bugs.php.net/bug.php?id=43207



[2008-01-13 03:14:53] root at net1 dot cc

I've been using the patched PHP for several hours now, and - confirmed
- it's working flawless! This patch really fixes the issue! Thanks once
again, Manuel!

For FreeBSD users, I've uploaded a modified patch file for deployment
with the ports system, for ease of use, and instructions here:
http://mirror.net1.cc/projects/php-bug43677-patch/



[2008-01-12 21:19:29] root at net1 dot cc

I'm gonna test Manuel's patch (thanks!) and report back later if it
does fix the problems observed.



[2008-01-12 18:08:43] manuel at mausz dot at

I tracked the problem down. Every altered ini setting gets added to the
 modified_ini_directives-hashtable in order to restore the original
value after the request has been processed. Zend simply forgets to
restore the modifiable-level.

A patch can be found at 
http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch
Please note that this patch will break the ini setting ABI. Thus all
extensions registering ini settings will have to be recompiled.



[2008-01-07 22:57:03] root at net1 dot cc

Digging some more into that, I've found the problem to be in the
Apache/PHP interpretation of the configured VirtualHost.

First, the problem only exists if we do have *both* VirtualHost(s) with
'php_admin_value include_path' *and* another VirtualHost(s)with
'php_value include_path'. If all our VirtualHosts use 'php_value' only,
it's behaving as usual.

Experimenting with this shows that, after an Apache startup/reload,
things work OK. Then, they start to randomly fail until some time later
100% of the requests fail to work OK.

Looking at the Apache logs, the problem (according to me) is that the
PHP module behaves strange when it sees the php_admin_value variable.
Let's say we have this config (not a working one, just to give you the
idea):

  ServerName test1.dot.com
  php_value include_path .:/test1


  ServerName test2.dot.com
  php_admin_value include_path .:/test2

We fire up Apache, and start accessing test1.dot.com pages *only*.
Everything works fine. *But* when we start to simultaneously access
test2.dot.com, the test1.dot.com pages start to fail more and more (due
to the incorrect include_path). Monitoring which Apache process servers
each page reveals that *when* a process serves a page for test2.dot.com,
it reads the 'php_admin_value' for it, sets it up, and refuses to change
the include_path from further config lines, *even* if they are from the
config of the virtual host of a *new* request. That is - once an Apache
process servers a page for a VirtualHost with php_admin_value, all
consequent requests served by the same process are processed with that
php_admin_value, regardless of their config.

The *solution* , though insecure, is to change *all* your
'php_admin_value include_path' lines to 'php_value include_path'.

I would very much like to see this fixed (though I'm completely unaware
of the way Apache/PHP configuration is parsed), and will provide more
feedback if needed.



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/43677

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

#43677 [Com]: Inconsistent behaviour of include_path set with php_value

2008-01-17 Thread manuel at mausz dot at

 ID:   43677
 Comment by:   manuel at mausz dot at
 Reported By:  root at net1 dot cc
 Status:   Open
 Bug Type: Safe Mode/open_basedir
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 New Comment:

Can some dev please take a look at this (or the patch)?
This is a serious issue for all users running apache as module and
mixing php_admin_value and php_value.

It also looks like this is the same as:
http://bugs.php.net/bug.php?id=43842
http://bugs.php.net/bug.php?id=43755
http://bugs.php.net/bug.php?id=43207


Previous Comments:


[2008-01-13 03:14:53] root at net1 dot cc

I've been using the patched PHP for several hours now, and - confirmed
- it's working flawless! This patch really fixes the issue! Thanks once
again, Manuel!

For FreeBSD users, I've uploaded a modified patch file for deployment
with the ports system, for ease of use, and instructions here:
http://mirror.net1.cc/projects/php-bug43677-patch/



[2008-01-12 21:19:29] root at net1 dot cc

I'm gonna test Manuel's patch (thanks!) and report back later if it
does fix the problems observed.



[2008-01-12 18:08:43] manuel at mausz dot at

I tracked the problem down. Every altered ini setting gets added to the
 modified_ini_directives-hashtable in order to restore the original
value after the request has been processed. Zend simply forgets to
restore the modifiable-level.

A patch can be found at 
http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch
Please note that this patch will break the ini setting ABI. Thus all
extensions registering ini settings will have to be recompiled.



[2008-01-07 22:57:03] root at net1 dot cc

Digging some more into that, I've found the problem to be in the
Apache/PHP interpretation of the configured VirtualHost.

First, the problem only exists if we do have *both* VirtualHost(s) with
'php_admin_value include_path' *and* another VirtualHost(s)with
'php_value include_path'. If all our VirtualHosts use 'php_value' only,
it's behaving as usual.

Experimenting with this shows that, after an Apache startup/reload,
things work OK. Then, they start to randomly fail until some time later
100% of the requests fail to work OK.

Looking at the Apache logs, the problem (according to me) is that the
PHP module behaves strange when it sees the php_admin_value variable.
Let's say we have this config (not a working one, just to give you the
idea):

  ServerName test1.dot.com
  php_value include_path .:/test1


  ServerName test2.dot.com
  php_admin_value include_path .:/test2

We fire up Apache, and start accessing test1.dot.com pages *only*.
Everything works fine. *But* when we start to simultaneously access
test2.dot.com, the test1.dot.com pages start to fail more and more (due
to the incorrect include_path). Monitoring which Apache process servers
each page reveals that *when* a process serves a page for test2.dot.com,
it reads the 'php_admin_value' for it, sets it up, and refuses to change
the include_path from further config lines, *even* if they are from the
config of the virtual host of a *new* request. That is - once an Apache
process servers a page for a VirtualHost with php_admin_value, all
consequent requests served by the same process are processed with that
php_admin_value, regardless of their config.

The *solution* , though insecure, is to change *all* your
'php_admin_value include_path' lines to 'php_value include_path'.

I would very much like to see this fixed (though I'm completely unaware
of the way Apache/PHP configuration is parsed), and will provide more
feedback if needed.



[2008-01-07 20:57:58] tborgans at gmx dot de

same problem here on linux with 5.2.5, apache 1.3.39



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/43677

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

#27421 [Com]: mbstring.func_overload set in .htaccess becomes global

2008-01-17 Thread mihau at great dot net dot pl

 ID:   27421
 Comment by:   mihau at great dot net dot pl
 Reported By:  php at strategma dot bg
 Status:   No Feedback
 Bug Type: mbstring related
 Operating System: Slackware 9.1 kernel: 2.4.22
 PHP Version:  4.3.4
 New Comment:

I'm still experiencing this bug.
On apache 2.0.59 with php 5.2.4, as well as php 4.4.x.

It looks like mbstring.func_overload setting in .htaccess affects other
virtualhosts and directories.

I've tried with these in httpd.conf:


MaxRequestsPerChild 10


It works as expected for site A until I enter site B with
mbstring.func_overload in .htaccess. Site B works as expected.
Then i come back to site A and see unexpected results. I hit refresh
few times and results back to normal.

It looks like one request affects all other requests for specified
child.
When apache kill it after "MaxRequestPerChild" and spawn new child
everything is working fine, until site B is requested.

Is this bug somehow related to #43677?

With one exception: ini_get("mbstring.func_overload") returns correct
values - I mean values from config files.


Previous Comments:


[2007-01-18 09:29:39] info at bert-jan dot com

I've tried it on another server running Debian unstable with PHP
5.2.0-8 on Apache 2.2.3 both installed with apt-get and the same issue
is reproducible here too.



[2007-01-17 21:57:23] info at bert-jan dot com

FYI: I'm running Slamd64 (Slackware x86-64) with Apache and PHP
installed from source.

Apache:

./configure \
--enable-ssl \
--with-ssl \
--enable-proxy \
--enable-proxy-connect \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-rewrite \
--enable-deflate \
--enable-so \

PHP:

./configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql=/usr/local/mysql/ \
--with-zlib \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--with-freetype-dir \
--enable-ftp \
--with-bz2 \
--with-gzip \
--with-openssl \
--enable-shmop \
--enable-posix \
--enable-pcntl \
--enable-sysvsem \
--enable-sysvshm \
--enable-iconv \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--enable-mbstring \
--enable-shmop \
--enable-soap \
--enable-memory-limit



[2007-01-17 21:41:53] info at bert-jan dot com

I'm having this exact same issue on PHP 5.1.6 on Apache 2.0.59. Putting
the mbstring.* settings in the VirtualHost-directive or in .htaccess
doesn't seem to make a difference. The settings are 'leaked' to other
vhosts who start to randomly malfunction and report errors like

Warning: mb_strrpos() [function.mb-strrpos]: Unknown encoding "6" in
/home/bertjan/public_html/functions.php on line 307

As stated in the other comments, the erroneous behaviour isn't
consistent. Sometimes it works but more often it doesn't. The trouble is
quite evident in e.g. Squirrelmail or phpMyAdmin.



[2006-11-17 15:02:35] christophe at saout dot de

I'm still seing a similar problem in PHP 4.4.4.

The site has globally turned on mbstring.func_overload in php.ini.

When turning it off in a .htaccess for a specific directory, the
behaviour experienced by the scripts in that directory becomes random.
Sometimes it works as expected (especially after a fresh start of
apache), but most of the time the script is using the overloaded
mbstring functions e.g. for substr, even though
ini_get("mbstring.func_overload") returns 0.

It looks like the save/restore in the mbstring module somehow gets
confused and leaks overloaded functions between apache requests.

Assuming this is a variant of the bug experienced by the original bug
author, I'm posting this here and requesting a re-opening.



[2004-03-13 05:01:58] [EMAIL PROTECTED]

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 "Open". Thank you.





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/27421

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

#43875 [NEW]: Two error messages returned for $new and $flag argument in mysql_connect()

2008-01-17 Thread josmessa at uk dot ibm dot com

From: josmessa at uk dot ibm dot com
Operating system: Windows XP
PHP version:  5.2CVS-2008-01-17 (snap)
PHP Bug Type: MySQL related
Bug description:  Two error messages returned for $new and $flag argument in 
mysql_connect()

Description:

In the latest snapshot of PHP (this behaviour is *not* in PHP 5.2.5) there
appears to be a stricter check on what can be passed as the $new and $flag
argument in mysql_connect. If the wrong type of argument is passed then two
error messages are returned. The first says that the parameter should be
long, the second is a warning that the there is the wrong parameter count
in mysql_connect(). I believe that this second error message is a bug as a)
it contradicts the previous error message and b) it does not say what the
correct parameter count is as it usually does with this type of error
message.

Reproduce code:
---


Expected result:

Warning: mysql_connect() expects parameter 4 to be long, string given in
...\mysql_connect.php on line 4
NULL

Warning: mysql_connect() expects parameter 5 to be long, string given in
...\mysql_connect.php on line 5
NULL


Actual result:
--
Warning: mysql_connect() expects parameter 4 to be long, string given in
C:\Josie\Workspace\Bugs\mysql\mysql_connect.php on line 4

Warning: Wrong parameter count for mysql_connect() in
C:\Josie\Workspace\Bugs\mysql\mysql_connect.php on line 4
NULL

Warning: mysql_connect() expects parameter 5 to be long, string given in
C:\Josie\Workspace\Bugs\mysql\mysql_connect.php on line 5

Warning: Wrong parameter count for mysql_connect() in
C:\Josie\Workspace\Bugs\mysql\mysql_connect.php on line 5
NULL


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

#22378 [Com]: "sendmail_from" not set in php.ini or custom "From:" header missing

#43886 [NEW]: checkdnsrr should distinguisch between 'no records' and 'error'

#43682 [Opn->Fbk]: session id kept, content lost on subdomain

#43859 [Opn->Bgs]: Wrong comparison

#43882 [Opn->Asn]: Include_path escape sequences problem

#43559 [Opn]: array_merge_recursive() doesn't behave as expected with duplicate NULL values

#43885 [NEW]: Object model

#26004 [Com]: $_POST variables not set when using enctype="multipart/form-data"

#43884 [NEW]: Object model

#41335 [Opn->Csd]: strtotime does not parse australian style dates correctly

#43883 [NEW]: Xsl gives Segmentation fault

#41599 [Asn->Csd]: setTime() fails after modify() is used

#43075 [Asn->Csd]: Support 2007-11-01T24:00:00+00:00

#43808 [Asn->Csd]: date_create never fails (even when it should)

#43003 [Asn->Csd]: Invalid timezone reported for DateTime objects constructed using a timestamp

#43872 [Opn->Csd]: preg_replace() returns blank string

#31954 [Com]: Interbase returning bool - PHP crash

#43882 [NEW]: Include_path escape sequences problem

#43527 [Asn->Csd]: DateTime created from a timestamp reports environment timezone

#42910 [Asn->Csd]: Constructing DateTime with TimeZone Indicator invalidates DateTimeZone

#40743 [Asn->Csd]: DateTime ignores the TimeZone object passed to the constructor

#43866 [Opn->Bgs]: Can't define the connect timeout on mysqli extension class

#43866 [Opn]: Can't define the connect timeout on mysqli extension class

#43866 [Opn]: Can't define the connect timeout on mysqli extension class

#43677 [Com]: Inconsistent behaviour of include_path set with php_value

#43879 [NEW]: PHP_INI_PERDIR support in registry

#43877 [NEW]: Tempnam: absolute/relative path

#43871 [Opn->Csd]: Segmentation fault in dns_get_record

#43677 [Com]: Inconsistent behaviour of include_path set with php_value

#43677 [Com]: Inconsistent behaviour of include_path set with php_value

#27421 [Com]: mbstring.func_overload set in .htaccess becomes global

#43875 [NEW]: Two error messages returned for $new and $flag argument in mysql_connect()

32 matches

Site Navigation

Mail list logo

Footer information