date:20120912

Bug #63026 [Fbk->Nab]: require_once error

2012-09-12 Thread laruence

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

 ID: 63026
 Updated by: larue...@php.net
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
-Status: Feedback
+Status: Not a bug
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

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.

å°ç°å¨, æç¡®è®¤è¿ä¸ªårequire onceæ²¡ä»ä¹å³ç³»äº, 

ä¹è®¸ä½ çå®æ¬èº«å°±æ²¡å®ä¹å¥½, 
æèå¶ä»çä»ä¹åå é æççèµ·æ¥æªå¼çç»è®º, 

å³éè¿ä¸ªæ¥å,  å»ºè®®ä½ å¤æè°è¯ä¿¡æ¯, 
å¤å³æ³¨éè¯¯è¾åºå»ææ¥.

thanks


Previous Comments:

[2012-09-13 05:46:51] ian dot xspace at yahoo dot cn

return array(
'M'=>'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
å³é®æ¯è¿ç§æåµä¸æè°ç¨å¾å¤ç±»é½æåäºï¼ä¸æ¯åºè¯¥å¤±è´¥çåï¼ä¸é¢ææ¯æ£ç¡®åæ³
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);


[2012-09-12 10:30:46] re...@php.net

â$obj = $this->loadCS('M.share_model');//è°ç¨å¶å®ç±»
   
//ä½ å¯ä»¥å¤è°ç¨å ä¸ªç±»ï¼å¨ä¸é¢éè¯¯åæ³æåµä¸ï¼æçç±»å¯ä»¥è°ç¨æåï¼æçå¤±è´¥
   //sysModule 
éçå¯¹åºå³ç³»ï¼åºè¯¥è¿ä¹å'C'=>CTRLS,åèæ éå¼å·
â
require_onceçè·¯å¾æ¯ç´æ¥æ¼çï¼èä¸ä¸æ¯autoloadï¼
ä»è¿éæ²¡æå¶ä»çä¾åï¼å¦æé¨åç±»åå¤§å°åéäºï¼å°±ä¼åºç°é¨åç±»æ¾ä¸å°çæåµã

å¨requireåå¢å ä¸ªæ£æ¥å°±è½ç¡®è®¤æèæé¤è¿ä¸ªé®é¢äº


[2012-09-12 10:25:08] larue...@php.net

ä½ ä»åªéçåºæ¥åå¤§å°åæå³ç³»ç?


[2012-09-12 10:15:04] re...@php.net

çä½ è¿æåµï¼æå¯è½æ¯ä½ çå¤§å°åé®é¢ï¼ 
ä½ æ¯ç´æ¥require_onceçï¼å¦æå¤§å°åéäºæ¯æé®é¢çã
ä¸ºäºå¥½è°è¯ï¼ä½ å¯ä»¥å¨require_once åå ä¸ä¸ªif(!file_exists($file) 
{die($file not found)}
æ£æ¥ä¸ä¸ã ä½ ç¡®è®¤ä¸ä¸æä»¶çç¡®åå¨å§ã

åæ¶ï¼æ¯å¨ä¸è¡ï¼æä½ çä»£ç å®æ´æåä¼ å°æä¸ªå°æ¹å§ãã


[2012-09-12 02:03:08] larue...@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=63026


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

Bug #63026 [Com]: require_once error

2012-09-12 Thread ian dot xspace at yahoo dot cn

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

 ID: 63026
 Comment by: ian dot xspace at yahoo dot cn
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

return array(
'M'=>'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
å³é®æ¯è¿ç§æåµä¸æè°ç¨å¾å¤ç±»é½æåäºï¼ä¸æ¯åºè¯¥å¤±è´¥çåï¼ä¸é¢ææ¯æ£ç¡®åæ³
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);


Previous Comments:

[2012-09-12 10:30:46] re...@php.net

â$obj = $this->loadCS('M.share_model');//è°ç¨å¶å®ç±»
   
//ä½ å¯ä»¥å¤è°ç¨å ä¸ªç±»ï¼å¨ä¸é¢éè¯¯åæ³æåµä¸ï¼æçç±»å¯ä»¥è°ç¨æåï¼æçå¤±è´¥
   //sysModule 
éçå¯¹åºå³ç³»ï¼åºè¯¥è¿ä¹å'C'=>CTRLS,åèæ éå¼å·
â
require_onceçè·¯å¾æ¯ç´æ¥æ¼çï¼èä¸ä¸æ¯autoloadï¼
ä»è¿éæ²¡æå¶ä»çä¾åï¼å¦æé¨åç±»åå¤§å°åéäºï¼å°±ä¼åºç°é¨åç±»æ¾ä¸å°çæåµã

å¨requireåå¢å ä¸ªæ£æ¥å°±è½ç¡®è®¤æèæé¤è¿ä¸ªé®é¢äº


[2012-09-12 10:25:08] larue...@php.net

ä½ ä»åªéçåºæ¥åå¤§å°åæå³ç³»ç?


[2012-09-12 10:15:04] re...@php.net

çä½ è¿æåµï¼æå¯è½æ¯ä½ çå¤§å°åé®é¢ï¼ 
ä½ æ¯ç´æ¥require_onceçï¼å¦æå¤§å°åéäºæ¯æé®é¢çã
ä¸ºäºå¥½è°è¯ï¼ä½ å¯ä»¥å¨require_once åå ä¸ä¸ªif(!file_exists($file) 
{die($file not found)}
æ£æ¥ä¸ä¸ã ä½ ç¡®è®¤ä¸ä¸æä»¶çç¡®åå¨å§ã

åæ¶ï¼æ¯å¨ä¸è¡ï¼æä½ çä»£ç å®æ´æåä¼ å°æä¸ªå°æ¹å§ãã


[2012-09-12 02:03:08] larue...@php.net

é£äºç±»åå¯ä»¥æ£ç¡®å è½½ ,é£äºç±»åä¸å¯ä»¥?  ä½ ä¸¾ä¸ªä¾å?


[2012-09-12 01:56:19] ian dot xspace at yahoo dot cn

//init.php å®ä¹ç½ç«ç®å½
/***ç½ç«ç®å½å®ä¹***/
define('THEME', 'default');
//define('TEMP', WEB_ROOT.DS.'temp');
//define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
define('LOGS', VIEWS.DS.'logs');
define('DYN', VIEWS.DS.'dynamic');
define('HLP', WEB_ROOT.DS.'helpers');
//define('PLNS', WEB_ROOT.DS.'plugins');
define('CONFS', WEB_ROOT.DS.'configs');
define('MODELS', WEB_ROOT.DS.'models');
define('CTRLS', WEB_ROOT.DS.'controls');
//SYS.php  
sysModuleå½æ°éçå¯¹åºå³ç³»ä¸ºéè¯¯åæ³ï¼æ£ç¡®åæ³åºè¯¥æ¯'M'=>MODELSåèæ éåå¼å·
class SYS
{
//sysModuleç³»ç»ç®å½æ å°
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
}
//getSysè·åç¸åºéç½®
public static function getSys($fun)
{
return self::$fun();
}
}
//common.php å¶ä¸ä¸ä¸ªå½æ°ï¼å è½½æéè¦çç±»
class Common
{
//loadCS
protected function loadCS($cs)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //ç´æ¥å®ä½   
require_once($moArr[$type].DS."{$csName}.php");
//  switch($type)  ä»¥ä¸å°ä¼è·åæ´å¿«æ§è¡éåº¦
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', 'è°ç¨å¤±è´¥!');
//

[PHP-BUG] Req #63078 [NEW]: Need Bug Tracker PDO Driver Specific Categories

2012-09-12 Thread ssuffic...@php.net

From: ssufficool
Operating system: Irrelevant
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Need Bug Tracker PDO Driver Specific Categories

Description:

Currently all PDO issues are lumped in the bug tracker under "PDOI
Related". Each 
PDO driver has it's own maintainer(s) and it would be helpful to narrow
which 
driver the bug is related to.

Test script:
---
Try to find a bug related to a specific PDO driver. Eyes start to bleed.

Expected result:

PDO Core
PDO_DBLIB
PDO_ODBC
PDO_MYSQL
PDO_OCI
PDO_FIREBIRD
PDO_SQLITE
PDO Other Driver

Actual result:
--
PDO Related

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

Bug #38805 [Opn->Csd]: PDO Truncates Text from SQL Server Text Data Type Field

2012-09-12 Thread ssufficool

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

 ID: 38805
 Updated by: ssuffic...@php.net
 Reported by:gkrajci at arescorporation dot com
 Summary:PDO Truncates Text from SQL Server Text Data Type
 Field
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Windows NT PBMA-WB2 5.2 build 37
 PHP Version:5.1.6
-Assigned To:
+Assigned To:ssufficool
 Block user comment: N
 Private report: N

 New Comment:

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-12-04 02:48:51] ssuffic...@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.




[2010-12-17 21:07:48] ka...@php.net

.


[2010-03-04 20:55:06] juan dot pineda at resultstel dot com

I solved this problem by adding to my php script a TEXTSIZE that is less than 
the allowed memory from the MSSQL server. 

Remember, all the number are in Bytes, so I kept playing with the numbers, 
until this worked:
// ranges from 0 - 3145728 = 3Megabytes.  Default to 4096.
$sql = "SET TEXTSIZE 3145728";
mssql_query($sql, $db) or die(mssql_get_last_message());

Remember to always know what the allowed upload size for your server is.

I hope this helps someone


[2010-02-12 16:57:02] s...@php.net

Those changes are still in SVN. That means the TEXTLIMIT var is being set to 
its highest possible value, which in turn means that truncation shouldn't be an 
issue now.

$pdo->query('SET TEXTSIZE 30');

should work from PHP 5.2.11 up, it just needs doccing.


[2010-02-12 09:05:28] philipp at servicemail24 dot de

This problem is actually fixed in cvs:

http://www.mail-archive.com/php-cvs@lists.php.net/msg40731.html
http://www.mail-archive.com/php-cvs@lists.php.net/msg40711.html

Here is the working source code:

http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_dblib/

I have no idea why these fixes aren't included in the 5.2 and 5.3 releases!

@sfox can you ensure that pdo_dblib is updated with the release of 5.2.13 and 
5.3.2?




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=38805


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

Bug #61123 [Opn->Nab]: PDO_DBLIB out of memory

2012-09-12 Thread ssufficool

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

 ID: 61123
 Updated by: ssuffic...@php.net
 Reported by:guillaume dot gruson at gmail dot com
 Summary:PDO_DBLIB out of memory
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PDO related
 Operating System:   debian squeeze 2.6.32-5
 PHP Version:5.3SVN-2012-02-17 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Sorry to close this with a canned response, but you need to update to a newer 
version of PHP to fix this bug.


Previous Comments:

[2012-02-17 14:17:44] guillaume dot gruson at gmail dot com

Description:

Hi i meet same problem as this "old" report :
https://bugs.php.net/bug.php?id=50755

When querying huge table, i get out of memory error.

Seems the patch from this report has never been commited in any branches.

I revert pdo_dblib directory to rev 297505 and gave a try to ssufficool's 
patch, and everything work like a charm with it.

So, i didn't understand why it has never been commited ?
a mistake ?

Thanks.







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

Bug #62803 [Opn->Fbk]: nextRowset not returning false

2012-09-12 Thread ssufficool

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

 ID: 62803
 Updated by: ssuffic...@php.net
 Reported by:jackspr at hotmail dot com
 Summary:nextRowset not returning false
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Windows Server 2008
 PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

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.


Which PDO driver are you using? I.e. MySQL, MSSQL, DBLIB, PGSQL


Previous Comments:

[2012-08-12 16:09:02] jackspr at hotmail dot com

update


[2012-08-12 16:06:11] jackspr at hotmail dot com

Description:

---
>From manual page: http://www.php.net/pdostatement.nextrowset#refsect1-
pdostatement.nextrowset-seealso
---
nextRowset is not returning false. The code below causes an exception in the 
fetchAll line because it is trying to access a result set does not exist.

$r=0
$qy = "CALL getAllInfo()";
$istmt = $con->prepare($qy);
if ($istmt->execute())
{
$outcome = self::SUCCESS;
do 
{   
  $result[$r] = $istmt->fetchAll(PDO::FETCH_ASSOC);
  $r++;
}
while($istmt->nextRowset());
}

Test script:
---
$r=0
$qy = "CALL getAllInfo()";
$istmt = $con->prepare($qy);
if ($istmt->execute())
{
$outcome = self::SUCCESS;
do 
{   
  $result[$r] = $istmt->fetchAll(PDO::FETCH_ASSOC);
  $r++;
}
while($istmt->nextRowset());
}

Expected result:

Clean exit with all possible resultsets in the result array.

Actual result:
--
exception 'PDOException' with message 'SQLSTATE[HY000]: General error'






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

Bug #62901 [Com]: foreach unexpectedly advances the internal array pointer

2012-09-12 Thread larue...@php.net

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

 ID: 62901
 Comment by: larue...@php.net
 Reported by:david at grudl dot com
 Summary:foreach unexpectedly advances the internal array
 pointer
 Status: Not a bug
 Type:   Bug
 Package:Variables related
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

s ,write on copy, copy on write,  ;<


Previous Comments:

[2012-09-13 02:44:38] larue...@php.net

the same, although it is *copy* of a array, but still the same zval, PHP using 
"write on copy".  but the internalPointer's change is not considered as "write" 
here.


[2012-09-13 01:51:19] david at grudl dot com

The point is: the iteration is not started on $this->arr, but it is started on 
array returned from method getArr(). 

Foreach resets internal array pointer of completely different array.


[2012-08-24 02:51:39] larue...@php.net

"When foreach first starts executing, the internal array pointer is 
automatically 
reset to the first element of the array. "  that means foreach change the 
internal 
potinter of an array.

http://us3.php.net/manual/en/control-structures.foreach.php


[2012-08-24 01:27:07] david at grudl dot com

Maybe this is not a bug, but i have read documentations carefully and there is 
nothing about this. Could you send a link?

And one question: why function reset() uses reference, if there is no need to 
use reference to advance internal array pointer?


[2012-08-23 15:37:32] larue...@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

please see the note at : http://us3.php.net/manual/en/control-
structures.foreach.php




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=62901


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

Bug #62901 [Nab]: foreach unexpectedly advances the internal array pointer

2012-09-12 Thread laruence

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

 ID: 62901
 Updated by: larue...@php.net
 Reported by:david at grudl dot com
 Summary:foreach unexpectedly advances the internal array
 pointer
 Status: Not a bug
 Type:   Bug
 Package:Variables related
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

the same, although it is *copy* of a array, but still the same zval, PHP using 
"write on copy".  but the internalPointer's change is not considered as "write" 
here.


Previous Comments:

[2012-09-13 01:51:19] david at grudl dot com

The point is: the iteration is not started on $this->arr, but it is started on 
array returned from method getArr(). 

Foreach resets internal array pointer of completely different array.


[2012-08-24 02:51:39] larue...@php.net

"When foreach first starts executing, the internal array pointer is 
automatically 
reset to the first element of the array. "  that means foreach change the 
internal 
potinter of an array.

http://us3.php.net/manual/en/control-structures.foreach.php


[2012-08-24 01:27:07] david at grudl dot com

Maybe this is not a bug, but i have read documentations carefully and there is 
nothing about this. Could you send a link?

And one question: why function reset() uses reference, if there is no need to 
use reference to advance internal array pointer?


[2012-08-23 15:37:32] larue...@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

please see the note at : http://us3.php.net/manual/en/control-
structures.foreach.php


[2012-08-23 02:08:58] david at grudl dot com

Description:

Foreach unexpectedly advances the internal array pointer, although array is 
returned by function without reference.

Test script:
---
arr = array('item');
var_dump(key($this->arr)); // dumps 0

// this unexpectedly advances the internal array pointer
foreach ($this->getArr() as $v) {}

var_dump(key($this->arr)); // dumps NULL
}

function getArr()
{
// is NOT returned by reference
return $this->arr;
}

}


$test = new Test;
$test->run();


Expected result:

It dumps "0" in second time too.







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

Bug #62901 [Nab]: foreach unexpectedly advances the internal array pointer

2012-09-12 Thread david at grudl dot com

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

 ID: 62901
 User updated by:david at grudl dot com
 Reported by:david at grudl dot com
 Summary:foreach unexpectedly advances the internal array
 pointer
 Status: Not a bug
 Type:   Bug
 Package:Variables related
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

The point is: the iteration is not started on $this->arr, but it is started on 
array returned from method getArr(). 

Foreach resets internal array pointer of completely different array.


Previous Comments:

[2012-08-24 02:51:39] larue...@php.net

"When foreach first starts executing, the internal array pointer is 
automatically 
reset to the first element of the array. "  that means foreach change the 
internal 
potinter of an array.

http://us3.php.net/manual/en/control-structures.foreach.php


[2012-08-24 01:27:07] david at grudl dot com

Maybe this is not a bug, but i have read documentations carefully and there is 
nothing about this. Could you send a link?

And one question: why function reset() uses reference, if there is no need to 
use reference to advance internal array pointer?


[2012-08-23 15:37:32] larue...@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

please see the note at : http://us3.php.net/manual/en/control-
structures.foreach.php


[2012-08-23 02:08:58] david at grudl dot com

Description:

Foreach unexpectedly advances the internal array pointer, although array is 
returned by function without reference.

Test script:
---
arr = array('item');
var_dump(key($this->arr)); // dumps 0

// this unexpectedly advances the internal array pointer
foreach ($this->getArr() as $v) {}

var_dump(key($this->arr)); // dumps NULL
}

function getArr()
{
// is NOT returned by reference
return $this->arr;
}

}


$test = new Test;
$test->run();


Expected result:

It dumps "0" in second time too.







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

Req #63076 [Opn->Fbk]: Force source IP on network operations

2012-09-12 Thread aharvey

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

 ID: 63076
 Updated by: ahar...@php.net
 Reported by:tonix at interazioni dot it
 Summary:Force source IP on network operations
-Status: Open
+Status: Feedback
 Type:   Feature/Change Request
-Package:Safe Mode/open_basedir
+Package:Network related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

You can already do this for any function that accepts a stream context via the 
bindto context option. Is there a specific case that isn't covered?


Previous Comments:

[2012-09-12 20:08:00] tonix at interazioni dot it

Description:

It would nbe nice to have a new security feature in PHP.

Actually, a web server receives connections from a specific IP/port, but any 
PHP script can use any available address on outgoing connections.
This can be a security problem.

It should be possible to 'force' PHP to open connections only with a spcific IP 
or with the listening IP.This helps to prevent such problems:

 * if you have internal interfaces in the same machine where you have
   public IPs, a web PHP application could try to use the internal
   address of the interface, exploring internal network (actually we avoid that
   thanks to FreeBSD jails).
 * if apache listens on a specific  IP for a single domain, and listens
   on other IPs for others domains, it would be safe if each domain can
   use as source IP only the listening IP associated. 








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

Bug #63077 [Com]: AppendIterator sometimes iterates 2 times over first iterator

2012-09-12 Thread david at grudl dot com

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

 ID: 63077
 Comment by: david at grudl dot com
 Reported by:david at grudl dot com
 Summary:AppendIterator sometimes iterates 2 times over first
 iterator
 Status: Open
 Type:   Bug
 Package:SPL related
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

It is caused by append() method, because this code:

$iterator = new RecursiveDirectoryIterator('one', 
RecursiveDirectoryIterator::SKIP_DOTS);
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new Filter($iterator);

foreach($iterator as $file){
echo $file, "\n";
}

returns correctly two items, but this code:

$iterator = new RecursiveDirectoryIterator('one', 
RecursiveDirectoryIterator::SKIP_DOTS);
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new Filter($iterator);

$append = new AppendIterator();
$append->append($iterator);

foreach($iterator as $file){ // still using $iterator, not $append
echo $file, "\n";
}

returns 4 items.


Previous Comments:

[2012-09-13 00:32:41] david at grudl dot com

Description:

Due to this bug I cannot use PHP AppendIterator because it gives wrong 
(doubled) results. It is very hard to explain it, so there is isolated use case 
http://davidgrudl.com/tmp/appenditerator.zip

It affects all PHP versions.

Test script:
---
/*
Directory structure:

/one
a
/b
c
d

/two
*/


class Filter extends FilterIterator
{
public function accept()
{
$this->x++;
return $this->x > 1;
}
}


$append = new AppendIterator();
$iterator = new RecursiveDirectoryIterator('one', 
RecursiveDirectoryIterator::SKIP_DOTS);
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new Filter($iterator);
$append->append($iterator);

$iterator = new RecursiveDirectoryIterator('two');
$iterator = new RecursiveIteratorIterator($iterator);
$append->append($iterator);

foreach($append as $file){
echo $file, "\n";
}


Expected result:

Should print:
  one/b/c
  one/b/d


Actual result:
--
Prints:
  one/b/c
  one/b/d
  one/b/c
  one/b/d







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

[PHP-BUG] Bug #63077 [NEW]: AppendIterator sometimes iterates 2 times over first iterator

2012-09-12 Thread david at grudl dot com

From: david at grudl dot com
Operating system: 
PHP version:  5.4.6
Package:  SPL related
Bug Type: Bug
Bug description:AppendIterator sometimes iterates 2 times over first iterator

Description:

Due to this bug I cannot use PHP AppendIterator because it gives wrong
(doubled) results. It is very hard to explain it, so there is isolated use
case http://davidgrudl.com/tmp/appenditerator.zip

It affects all PHP versions.

Test script:
---
/*
Directory structure:

/one
a
/b
c
d

/two
*/


class Filter extends FilterIterator
{
public function accept()
{
$this->x++;
return $this->x > 1;
}
}


$append = new AppendIterator();
$iterator = new RecursiveDirectoryIterator('one',
RecursiveDirectoryIterator::SKIP_DOTS);
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new Filter($iterator);
$append->append($iterator);

$iterator = new RecursiveDirectoryIterator('two');
$iterator = new RecursiveIteratorIterator($iterator);
$append->append($iterator);

foreach($append as $file){
echo $file, "\n";
}


Expected result:

Should print:
  one/b/c
  one/b/d


Actual result:
--
Prints:
  one/b/c
  one/b/d
  one/b/c
  one/b/d


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

Bug #61387 [Com]: NULL valued anonymous column causes segfault in odbc_fetch_array

2012-09-12 Thread brandonkirsch at gmail dot com

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

 ID: 61387
 Comment by: brandonkirsch at gmail dot com
 Reported by:marec at stringdata dot cz
 Summary:NULL valued anonymous column causes segfault in
 odbc_fetch_array
 Status: Open
 Type:   Bug
 Package:ODBC related
 Operating System:   windows server 2003 R2
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

This problem is isolated to the SQL Server Native Client ODBC Driver. Most 
other 
ODBC drivers will automatically provide some type of aliased column name for 
arbitrary values that you select.

When using a SELECT 'VALUE' statement with SQL Server ODBC, the 
php_odbc_fetch_hash() function returns the column as 'VALUE' => 'VALUE' -- that 
is, the value you select is also the key in the array.

The problem occurs at the end of the php_odbc_fetch_hash() function in 
php_odbc.c (for me, on 5.2.17 it begins on line 1510) and it looks like this:

if (!*(result->values[i].name)) { // GDB says this evaluates to 1
  zend_hash_update(Z_ARRVAL_P(return_value), Z_STRVAL_P(tmp),
Z_STRLEN_P(tmp)+1, &tmp, sizeof(zval *), NULL); // SEGFAULT

This usage of zend_hash_update() causes a segfault in PHP 5.2.17 and PHP 
5.3.16.  
I guess that result->values[i].name looks legit and/or usable when it is not.

I updated the if statement to read:

if (!*(result->values[i].name) && Z_TYPE_P(tmp) != IS_NULL) { // Evaluates 
false 
for SQL NULLs that sets ZVAL_NULL(tmp)

This skips the incorrect usage of zend_hash_update with Z_STR* functions and 
proceeds to the "else" condition that handles it correctly.

For us, this solution works perfectly and the end-result is array("" => NULL) 
instead of a segfault.  Other unaliased NULL values from other databases 
continue to work the same way as before (iSeries ODBC drivers return 
array("0001" => NULL))

Here's the rub:  I have no idea how to generate or submit a patch.  But this 
fix 
works.  If someone can turn this into a real fix and run with it, great.  If 
someone would contact me and help me turn it into a real patch, I would be 
happy 
to help.


Previous Comments:

[2012-09-12 21:56:17] brandonkirsch at gmail dot com

I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 
for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x0057528f in php_odbc_fetch_hash (ht=, 
return_value=0xfccfe8, result_type=2, return_value_ptr=, 
this_ptr=, 
return_value_used=) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend_hash_update improperly but I 
can't tell for sure.

And finally, here is a workaround script that DOES NOT segfault:


;Database=;Trusted_Connection=yes"
, ''
, ''
);

$res = odbc_exec(
  $conn
, 'SELECT SUM(1)
  FROM information_schema.tables
  WHERE 3 = 2'
);

$row = odbc_fetch_array($res);
odbc_free_result($res);
odbc_close($conn);
var_dump($row);

Expected result:

array(1) {[0]=> NULL}

or E_WARNING

Actual result:
--
segfault, apache log says:

[warn] [client x.x.x.x] (OS 109)The pipe has been ended.  : mod_fcgid: get 
overlap result error
[error] [client x.x.x.x] Premature end of script headers: foo.php
[info] mod_fcgid: process C:/Webserver/Apache2.2/php-5.3.10/php-cgi.exe(4420) 
exit(communication error), return code -1073741819

eventlog says:
Faulting application php-cgi.exe, version 5.3.10.0, faulting module php5.dll, 
version 5.3.10.0, fault address 0x000858df.

PHP itself does not produce any sort of output






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=613

Bug #44754 [Com]: Calling a bad eval() and then include(), resets $_REQUEST

2012-09-12 Thread rpavlicek at intacct dot com

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

 ID: 44754
 Comment by: rpavlicek at intacct dot com
 Reported by:famzah at icdsoft dot com
 Summary:Calling a bad eval() and then include(), resets
 $_REQUEST
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.2.5
 Block user comment: N
 Private report: N

 New Comment:

We're not "supposed" to do alot of things in programming (php or otherwise), 
but 
people do. We depend on consistent behavior. 

If setting super globals works in general, then suddenly breaks when a bad 
eval() 
takes place...how is that helpful? 

If its really not supposed to be done, shouldn't PHP throw a fatal error as 
soon 
as you try? Or are we supposed to accept "undefined behavior" when we assign 
superglobals?


Previous Comments:

[2008-07-21 20:39:40] j...@php.net

You're not supposed to modify any super-globals.


[2008-04-17 10:49:36] famzah at icdsoft dot com

Description:

If you modify an element of $_REQUEST, then call eval() with some syntax error, 
and then include() or require() another file, the changes in $_REQUEST are 
reset to the original values of $_REQUEST at script's startup time. The changes 
in $_REQUEST are permanently lost and the include()'d file as well as the main 
PHP file then operate with the reset $_REQUEST values.

Reproduce code:
---
* Proof of concept:

PHP 5.2.5 (bug):
http://famzah.net/evalbug/index.php?test=abcdef

PHP 4.4.8 (no bug):
http://famzah.net/evalbug/index.php4?test=abcdef

* Source code:

PHP 5.2.5 (bug):
http://famzah.net/evalbug/index.txt

PHP 4.4.8 (no bug):
http://famzah.net/evalbug/index4.txt


Expected result:

The expected behavior is that after the modification of an element in 
$_REQUEST, all included files as well as the main PHP file must operate with 
the modified values of $_REQUEST, because this is a super-global variable.

The above is currently true for all cases except when an eval() call is made 
which contains a syntax error. For example:
eval('this is a syntax error');

I reproduced the bug using the following PHP versions:
PHP 5.2.5 (cli), Zend Engine v2.2.0
PHP 5.2.5-3 with Suhosin-Patch 0.9.6.2 (cli), Zend Engine v2.2.0

The following PHP4 version does NOT have the bug:
PHP 4.4.8 (cli), Zend Engine v1.3.0

Actual result:
--
The bug situation is as follows:
- We call "index.php" with a GET parameter ?test=abcdef
- The script does and outputs the following:
index.php: $_REQUEST value is: abcdef
index.php: Modifying $_REQUEST by setting key 'test' to 'zzz'
index.php: $_REQUEST value is: zzz
index.php: Calling eval() with no syntax error.
index.php: Including the 'dump.php' file...
dump.php: $_REQUEST value is: zzz
index.php: $_REQUEST value is: zzz
index.php: Calling eval() with a syntax error.
index.php: $_REQUEST value is: zzz
index.php: Including the 'dump.php' file...
dump.php: $_REQUEST value is: abcdef
index.php: $_REQUEST value is: abcdef

The last two lines must contain the value 'zzz', not 'abcdef'.






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

Bug #61387 [Com]: NULL valued anonymous column causes segfault in odbc_fetch_array

2012-09-12 Thread brandonkirsch at gmail dot com

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

 ID: 61387
 Comment by: brandonkirsch at gmail dot com
 Reported by:marec at stringdata dot cz
 Summary:NULL valued anonymous column causes segfault in
 odbc_fetch_array
 Status: Open
 Type:   Bug
 Package:ODBC related
 Operating System:   windows server 2003 R2
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 
for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x0057528f in php_odbc_fetch_hash (ht=, 
return_value=0xfccfe8, result_type=2, return_value_ptr=, 
this_ptr=, 
return_value_used=) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend_hash_update improperly but I 
can't tell for sure.

And finally, here is a workaround script that DOES NOT segfault:


;Database=;Trusted_Connection=yes"
, ''
, ''
);

$res = odbc_exec(
  $conn
, 'SELECT SUM(1)
  FROM information_schema.tables
  WHERE 3 = 2'
);

$row = odbc_fetch_array($res);
odbc_free_result($res);
odbc_close($conn);
var_dump($row);

Expected result:

array(1) {[0]=> NULL}

or E_WARNING

Actual result:
--
segfault, apache log says:

[warn] [client x.x.x.x] (OS 109)The pipe has been ended.  : mod_fcgid: get 
overlap result error
[error] [client x.x.x.x] Premature end of script headers: foo.php
[info] mod_fcgid: process C:/Webserver/Apache2.2/php-5.3.10/php-cgi.exe(4420) 
exit(communication error), return code -1073741819

eventlog says:
Faulting application php-cgi.exe, version 5.3.10.0, faulting module php5.dll, 
version 5.3.10.0, fault address 0x000858df.

PHP itself does not produce any sort of output






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

Bug #61588 [Com]: PDOStatement::getColumnMeta returns original table name from view

2012-09-12 Thread jprodonovich at ttttire dot com

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

 ID: 61588
 Comment by: jprodonovich at ire dot com
 Reported by:cdburgess at gmail dot com
 Summary:PDOStatement::getColumnMeta returns original table
 name from view
 Status: Not a bug
 Type:   Bug
 Package:PDO related
 Operating System:   Mac OSX
 PHP Version:5.3.10
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

I have the exact same problem described here on a slightly older version of 
MySQL. 
Has there been any kind of resolution from MySQL on this issue or any type of 
workaround that can be used?

I also followed the same steps and verified that the mysqli command-line client 
produced the incorrect name for the Table when selecting from a view.


Previous Comments:

[2012-04-30 15:02:00] u...@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.

Thank you for your report. You have hit an issue but this is not a PHP bug. 
Please, note the fine line between a PHP related bug and an issue with the 
MySQL database. 

Please, log in to MySQL using the MySQL command line client. Set the option 
--column-type-info for the command line client. This will make the MySQL prompt 
print the metadata reported by MySQL. 

Upon execution of:

mysql> SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, `MyInstall`.`script_id`, 
`MyInstall`.`path`, `MyInstall`.`url`, `MyInstall`.`created`, 
`MyInstall`.`version`, `MyInstall`.`admin_url`, `MyInstall`.`name`, 
`MyInstall`.`icon` FROM `my_installs` AS `MyInstall` where user_id = 
"dc038c9e-7b4b-11e1-8397-60195b7d6275"  ORDER BY `url` ASC;


I see MySQL report the following meta data for the 3rd column (offset 2 in PDO):

Field   3:  `script_id`
Catalog:`def`
Database:   `testpdo`
Table:  `MyInstall`
Org_table:  `scripts`
Type:   STRING
Collation:  utf8_general_ci (33)
Length: 108
Max_length: 36
Decimals:   0
Flags:  NO_DEFAULT_VALUE 


Adding a second condition to the WHERE clause does in fact change meta data as 
you report it.

mysql> SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, `MyInstall`.`script_id`, 
`MyInstall`.`path`, `MyInstall`.`url`, `MyInstall`.`created`, 
`MyInstall`.`version`, `MyInstall`.`admin_url`, `MyInstall`.`name`, 
`MyInstall`.`icon` FROM `my_installs` AS `MyInstall` where user_id = 
"dc038c9e-7b4b-11e1-8397-60195b7d6275" and script_id = 
"057de1e0-7b48-11e1-8397-60195b7d6275" ORDER BY `url` ASC;


Note the difference:

Field   3:  `script_id`
Catalog:`def`
Database:   `testpdo`
Table:  `Script`
Org_table:  `scripts`
Type:   STRING
Collation:  utf8_general_ci (33)
Length: 108
Max_length: 36
Decimals:   0
Flags:  NOT_NULL PRI_KEY NO_DEFAULT_VALUE PART_KEY 


However, as this issue can be reproduced on the MySQL prompt one can be sure 
that there is no bug inside PHP. PHP does give you what MySQL reports.

The correctness of the MySQL value itself should be checked by MySQL, not PHP. 
Please report a bug at mysql.com.


[2012-04-03 05:57:11] cdburgess at gmail dot com

PHP v5.3.10
MySQL v5.5.22
Apache v2.2.21

Here is a script that contains all of the information you need to reproduce. 
The 
commented parts at the bottom contain all of the schema / data information. 
Just 
create your database, setup the PDO access, and run the script. It will provide 
the queries, descriptions, and getColumnMeta results to show you what I am 
seeing.

Thanks!

-- SCRIPT BELOW HERE --

' . "\n";
echo 'In this query, you will see the table is reported as expected. 
(my_installs)';
$result = $connection->query($query);
var_dump($result->getColumnMeta(2));

$query = "SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, 
`MyInstall`.`script_id`, `MyInstall`.`path`, `MyInstall`.`url`, 
`MyInstall`.`created`, `MyInstall`.`version`, `MyInstall`.`admin_url`, 
`MyInstall`.`name`, `MyInstall`.`icon` FROM `my_installs` AS `MyInstall` WHERE 
`user_id` = 'dcc87a2c-7b4b-11e1-8397-60195b7d6275' ORDER BY `url` ASC";
echo $query . '' . "\n";
echo 'With the Alias format of the query and using only the user_id in the 
where 
clause, the table Alias is reported.';
$result = $connection->query($query);
var_dump($result->getColumnMeta(2));

$query = "SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, 
`MyInstall`.`script_id`, `MyInstall`.`path`, `MyInstall`.`url`, 
`MyInstall`.`created`, `MyIn

Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE

2012-09-12 Thread dernelson at corelogic dot com

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

 ID: 49510
 Comment by: dernelson at corelogic dot com
 Reported by:m dot kurzyna at crystalpoint dot pl
 Summary:boolean validation fails with FILTER_NULL_ON_FAILURE
 Status: Assigned
 Type:   Feature/Change Request
 Package:Filter related
 Operating System:   Linux
 PHP Version:5.3.0
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

The question the developer is asking filter_var() is: "is boolean FALSE a valid 
boolean", and the answer filter_var() is giving back is "nope."  Regardless of 
the technical details underlying the implementation, there is an obvious 
problem here.

Short of changing PHP so that (string)FALSE === '0' (hah), I would suggest an 
explicit test case for boolean FALSE values, so that the function can return 
boolean FALSE in those cases, instead of NULL.


Previous Comments:

[2012-07-15 04:57:34] s...@php.net

Filters operate on strings. So any value that is passed to the filter_var() 
will 
be coerced into string. This means (boolean)false and '' is exactly the same 
for 
the filter. And that means the callbacks will be receiving strings too. 

Now, the docs specifically say '' is a valid value for "boolean" filter and is 
converted to false, so '' should not return NULL with FILTER_NULL_ON_FAILURE I 
guess since it's documented not to be failure value.


[2012-06-24 00:34:38] 2072 at teaser dot fr

Knowing this issue I wanted to make a boolean validation filter of my own using 
FILTER_CALLBACK but it suffers from the same problem, these filters are not
"boolean safe".

It appears that what is to be validated is first converted to a string.

So when given (bool)true my callback actually receives (string)'1' and 
(string)'' when given (bool)false.

There is definitely something wrong.

(I'm using PHP 5.3.8)


[2010-09-01 13:55:06] schkovich at gmail dot com

filter_var(false,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE)
 // got NULL, expected false

That does not make sense at all! Further on, I have to agree with m.kurzyna 
that since false === (bool)"" 
filter_var("",FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) should 
return FALSE and not NULL.

Basically, as implemented, getting FALSE from 
filter_var(false,FILTER_VALIDATE_BOOLEAN) means that validation failed. It 
appears to be a design problem since filter_var() as 
specified will return FALSE if the filter fails making it impossible to 
distinguish if filter failed  or valid FALSE value is returned. Therefore, 
instead returning FALSE if 
filter fails perhaps warning could be issued or even better exception thrown.

On addition when voting I've wrongly selected that I am not using the same 
version and the same operating system. Correct ones are:
PHP Version => 5.3.2-1ubuntu4.2
System => Linux schkovich 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 
UTC 2010 x86_64


[2009-09-10 11:24:37] m dot kurzyna at crystalpoint dot pl

As much as i'd like to have empty string be invalid false cast i have to 
disagree with you for consistency reasons.

If (boolean)'' == false then filter_var('','boolean') should also return false. 
Both in general and in case of FILTER_NULL_ON_FAILURE (just like the 
documentation states).

Also, because i can't stress it enough, this is a VALIDATOR not a SANITIZER so 
using it as a strict caster is secondary to it's validation purpose and as such 
it currently fails both on implied and explicit behavior.

The ideal solution would be to have FILTER_VALIDATE_BOOLEAN roughly equal to 
current behavior with FILTER_NULL_ON_FAILURE and a *seperate* 
FILTER_SANITIZE_BOOLEAN similar to current behavior w/o the null failure flag. 
This however probably is impossible due to BC.


[2009-09-10 11:09:43] sjo...@php.net

I agree that filter_var() should return null for the empty string. I think that 
this usage of filter_var() is meant to convert string representations of 
booleans to boolean values. That is, "true", "on", "1", "false", "off" and "0" 
should be converted, other strings should return null.




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=49510


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

[PHP-BUG] Req #63076 [NEW]: Force source IP on network operations

2012-09-12 Thread tonix at interazioni dot it

From: tonix at interazioni dot it
Operating system: 
PHP version:  Irrelevant
Package:  Safe Mode/open_basedir
Bug Type: Feature/Change Request
Bug description:Force source IP on network operations

Description:

It would nbe nice to have a new security feature in PHP.

Actually, a web server receives connections from a specific IP/port, but
any PHP script can use any available address on outgoing connections.
This can be a security problem.

It should be possible to 'force' PHP to open connections only with a
spcific IP or with the listening IP.This helps to prevent such problems:

 * if you have internal interfaces in the same machine where you have
   public IPs, a web PHP application could try to use the internal
   address of the interface, exploring internal network (actually we avoid
that
   thanks to FreeBSD jails).
 * if apache listens on a specific  IP for a single domain, and listens
   on other IPs for others domains, it would be safe if each domain can
   use as source IP only the listening IP associated. 



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

Bug #63075 [Opn]: PHP Segfault in PDO ODBC Execute

2012-09-12 Thread Ew6jQ8tSJhf3 at dyweni dot com

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

 ID: 63075
 User updated by:Ew6jQ8tSJhf3 at dyweni dot com
 Reported by:Ew6jQ8tSJhf3 at dyweni dot com
 Summary:PHP Segfault in PDO ODBC Execute
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Linux x86_64 (CentOS 5.8 final)
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

The 5.2.17-6.ius.el5 version of PHP from the IUS repositories works OK too.

FYI IUS is http://iuscommunity.org/


Previous Comments:

[2012-09-12 19:44:03] Ew6jQ8tSJhf3 at dyweni dot com

I tested the 5.3.16-1.ius.el5 version of PHP from the IUS repository... These 
have the same issue.

I tested the 5.3.3-13.el5_8 version of PHP from the CentOS5 Updates 
repository... These work OK.


[2012-09-12 19:22:30] Ew6jQ8tSJhf3 at dyweni dot com

Breaking GDB at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:514:


(gdb) p stmt
$6 = (pdo_stmt_t *) 0x2b283960
(gdb) p *stmt
$7 = {std = {ce = 0xbbd490, properties = 0x0, properties_table = 
0x2b284440, guards = 0x0}, methods = 0x2aaab09b9640, driver_data = 
0x2b283ad8, executed = 0, 
supports_placeholders = 2, _reserved = 0, column_count = 0,
  columns = 0x0, database_object_handle = {value = {lval = 46909632806913, dval 
= 2.3176438028923198e-310, str = {val = 0x2aaa0001 , len = -1336223392}, ht = 0x2aaa0001, obj = {handle = 1,
handlers = 0x2aaab05ad960}}, refcount__gc = 2, type = 5 '\005', 
is_ref__gc = 0 '\000'}, dbh = 0x2b2842b0, bound_params = 0x0, 
bound_param_map = 0x0, 
bound_columns = 0x0, row_count = 0,
  query_string = 0x2b284c20 "SELECT fid, original_filename, dateUploaded, 
filesize, client FROM upload ORDER BY dateUploaded DESC", query_stringlen = 
100, 
active_query_string = 0x0, active_query_stringlen = 0, error_code = "0",
  lazy_object_ref = {value = {lval = 0, dval = 0, str = {val = 0x0, len = 0}, 
ht = 0x0, obj = {handle = 0, handlers = 0x0}}, refcount__gc = 0, type = 0 
'\000', is_ref__gc 
= 0 '\000'}, refcount = 1, default_fetch_type = PDO_FETCH_BOTH,
  fetch = {column = 0, cls = {ce = 0x0, ctor_args = 0x0, retval_ptr = 0x0, fci 
= {size = 0, function_table = 0x0, function_name = 0x0, symbol_table = 0x0, 
retval_ptr_ptr = 
0x0, param_count = 0, params = 0x0, object_ptr = 0x0,
no_separation = 0 '\000'}, fcc = {initialized = 0 '\000', 
function_handler = 0x0, calling_scope = 0x0, called_scope = 0x0, object_ptr = 
0x0}}, func = {function = 
0x0, fetch_args = 0x0, object = 0x0, fci = {size = 0,
function_table = 0x0, function_name = 0x0, symbol_table = 0x0, 
retval_ptr_ptr = 0x0, param_count = 0, params = 0x0, object_ptr = 0x0, 
no_separation = 0 '\000'}, 
fcc = {initialized = 0 '\000', function_handler = 0x0,
calling_scope = 0x0, called_scope = 0x0, object_ptr = 0x0}, values = 
0x0}, into = 0x0}, named_rewrite_template = 0x0}


(gdb) n
515 if (stmt->active_query_string && 
stmt->active_query_string != stmt->query_string) {


(gdb) p stmt
$12 = (pdo_stmt_t *) 0x2aaa
(gdb) p *stmt
Cannot access memory at address 0x2aaa


[2012-09-12 19:17:09] Ew6jQ8tSJhf3 at dyweni dot com

Description:

PHP 5.4.6
Microsoft SQL Server ODBC Driver V1.0 for Linux

PHP Segfaults while executing the call '$sth->execute()'

GDB Backtrace is:


Program received signal SIGSEGV, Segmentation fault.
zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, 
return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
515 if (stmt->active_query_string && stmt-
>active_query_string != stmt->query_string) {
(gdb) bt
#0  zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
#1  0x006005e5 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x2b250060) at /usr/src/debug/php-
5.4.6/Zend/zend_vm_execute.h:642
#2  0x0060643e in execute (op_array=0x2b282fc8) at 
/usr/src/debug/php-5.4.6/Zend/zend_vm_execute.h:410
#3  0x005d1a8e in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/debug/php-5.4.6/Zend/zend.c:1289
#4  0x00576c38 in php_execute_script (primary_file=0x7fffc190) at 
/usr/src/debug/php-5.4.6/main/main.c:2473
#5  0x006785ed in do_cli (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:988
#6  0x00678f6d in main (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:1364


Valgrind Output is:

==9423== Memcheck, a memory error detector
==9423== Copyright (C) 2002-2009, and GNU GPL'd, by Julian

Bug #63075 [Opn]: PHP Segfault in PDO ODBC Execute

2012-09-12 Thread Ew6jQ8tSJhf3 at dyweni dot com

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

 ID: 63075
 User updated by:Ew6jQ8tSJhf3 at dyweni dot com
 Reported by:Ew6jQ8tSJhf3 at dyweni dot com
 Summary:PHP Segfault in PDO ODBC Execute
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Linux x86_64 (CentOS 5.8 final)
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

I tested the 5.3.16-1.ius.el5 version of PHP from the IUS repository... These 
have the same issue.

I tested the 5.3.3-13.el5_8 version of PHP from the CentOS5 Updates 
repository... These work OK.


Previous Comments:

[2012-09-12 19:22:30] Ew6jQ8tSJhf3 at dyweni dot com

Breaking GDB at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:514:


(gdb) p stmt
$6 = (pdo_stmt_t *) 0x2b283960
(gdb) p *stmt
$7 = {std = {ce = 0xbbd490, properties = 0x0, properties_table = 
0x2b284440, guards = 0x0}, methods = 0x2aaab09b9640, driver_data = 
0x2b283ad8, executed = 0, 
supports_placeholders = 2, _reserved = 0, column_count = 0,
  columns = 0x0, database_object_handle = {value = {lval = 46909632806913, dval 
= 2.3176438028923198e-310, str = {val = 0x2aaa0001 , len = -1336223392}, ht = 0x2aaa0001, obj = {handle = 1,
handlers = 0x2aaab05ad960}}, refcount__gc = 2, type = 5 '\005', 
is_ref__gc = 0 '\000'}, dbh = 0x2b2842b0, bound_params = 0x0, 
bound_param_map = 0x0, 
bound_columns = 0x0, row_count = 0,
  query_string = 0x2b284c20 "SELECT fid, original_filename, dateUploaded, 
filesize, client FROM upload ORDER BY dateUploaded DESC", query_stringlen = 
100, 
active_query_string = 0x0, active_query_stringlen = 0, error_code = "0",
  lazy_object_ref = {value = {lval = 0, dval = 0, str = {val = 0x0, len = 0}, 
ht = 0x0, obj = {handle = 0, handlers = 0x0}}, refcount__gc = 0, type = 0 
'\000', is_ref__gc 
= 0 '\000'}, refcount = 1, default_fetch_type = PDO_FETCH_BOTH,
  fetch = {column = 0, cls = {ce = 0x0, ctor_args = 0x0, retval_ptr = 0x0, fci 
= {size = 0, function_table = 0x0, function_name = 0x0, symbol_table = 0x0, 
retval_ptr_ptr = 
0x0, param_count = 0, params = 0x0, object_ptr = 0x0,
no_separation = 0 '\000'}, fcc = {initialized = 0 '\000', 
function_handler = 0x0, calling_scope = 0x0, called_scope = 0x0, object_ptr = 
0x0}}, func = {function = 
0x0, fetch_args = 0x0, object = 0x0, fci = {size = 0,
function_table = 0x0, function_name = 0x0, symbol_table = 0x0, 
retval_ptr_ptr = 0x0, param_count = 0, params = 0x0, object_ptr = 0x0, 
no_separation = 0 '\000'}, 
fcc = {initialized = 0 '\000', function_handler = 0x0,
calling_scope = 0x0, called_scope = 0x0, object_ptr = 0x0}, values = 
0x0}, into = 0x0}, named_rewrite_template = 0x0}


(gdb) n
515 if (stmt->active_query_string && 
stmt->active_query_string != stmt->query_string) {


(gdb) p stmt
$12 = (pdo_stmt_t *) 0x2aaa
(gdb) p *stmt
Cannot access memory at address 0x2aaa


[2012-09-12 19:17:09] Ew6jQ8tSJhf3 at dyweni dot com

Description:

PHP 5.4.6
Microsoft SQL Server ODBC Driver V1.0 for Linux

PHP Segfaults while executing the call '$sth->execute()'

GDB Backtrace is:


Program received signal SIGSEGV, Segmentation fault.
zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, 
return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
515 if (stmt->active_query_string && stmt-
>active_query_string != stmt->query_string) {
(gdb) bt
#0  zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
#1  0x006005e5 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x2b250060) at /usr/src/debug/php-
5.4.6/Zend/zend_vm_execute.h:642
#2  0x0060643e in execute (op_array=0x2b282fc8) at 
/usr/src/debug/php-5.4.6/Zend/zend_vm_execute.h:410
#3  0x005d1a8e in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/debug/php-5.4.6/Zend/zend.c:1289
#4  0x00576c38 in php_execute_script (primary_file=0x7fffc190) at 
/usr/src/debug/php-5.4.6/main/main.c:2473
#5  0x006785ed in do_cli (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:988
#6  0x00678f6d in main (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:1364


Valgrind Output is:

==9423== Memcheck, a memory error detector
==9423== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9423== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9423== Command: php test.php
==9423==
==9423== Invalid read of size 8
==9423==at 0xA7588B4: zim_PDOStatement_execute (pdo_stmt.c:515)
==9423==

Bug #63075 [Opn]: PHP Segfault in PDO ODBC Execute

2012-09-12 Thread Ew6jQ8tSJhf3 at dyweni dot com

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

 ID: 63075
 User updated by:Ew6jQ8tSJhf3 at dyweni dot com
 Reported by:Ew6jQ8tSJhf3 at dyweni dot com
 Summary:PHP Segfault in PDO ODBC Execute
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Linux x86_64 (CentOS 5.8 final)
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Breaking GDB at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:514:


(gdb) p stmt
$6 = (pdo_stmt_t *) 0x2b283960
(gdb) p *stmt
$7 = {std = {ce = 0xbbd490, properties = 0x0, properties_table = 
0x2b284440, guards = 0x0}, methods = 0x2aaab09b9640, driver_data = 
0x2b283ad8, executed = 0, 
supports_placeholders = 2, _reserved = 0, column_count = 0,
  columns = 0x0, database_object_handle = {value = {lval = 46909632806913, dval 
= 2.3176438028923198e-310, str = {val = 0x2aaa0001 , len = -1336223392}, ht = 0x2aaa0001, obj = {handle = 1,
handlers = 0x2aaab05ad960}}, refcount__gc = 2, type = 5 '\005', 
is_ref__gc = 0 '\000'}, dbh = 0x2b2842b0, bound_params = 0x0, 
bound_param_map = 0x0, 
bound_columns = 0x0, row_count = 0,
  query_string = 0x2b284c20 "SELECT fid, original_filename, dateUploaded, 
filesize, client FROM upload ORDER BY dateUploaded DESC", query_stringlen = 
100, 
active_query_string = 0x0, active_query_stringlen = 0, error_code = "0",
  lazy_object_ref = {value = {lval = 0, dval = 0, str = {val = 0x0, len = 0}, 
ht = 0x0, obj = {handle = 0, handlers = 0x0}}, refcount__gc = 0, type = 0 
'\000', is_ref__gc 
= 0 '\000'}, refcount = 1, default_fetch_type = PDO_FETCH_BOTH,
  fetch = {column = 0, cls = {ce = 0x0, ctor_args = 0x0, retval_ptr = 0x0, fci 
= {size = 0, function_table = 0x0, function_name = 0x0, symbol_table = 0x0, 
retval_ptr_ptr = 
0x0, param_count = 0, params = 0x0, object_ptr = 0x0,
no_separation = 0 '\000'}, fcc = {initialized = 0 '\000', 
function_handler = 0x0, calling_scope = 0x0, called_scope = 0x0, object_ptr = 
0x0}}, func = {function = 
0x0, fetch_args = 0x0, object = 0x0, fci = {size = 0,
function_table = 0x0, function_name = 0x0, symbol_table = 0x0, 
retval_ptr_ptr = 0x0, param_count = 0, params = 0x0, object_ptr = 0x0, 
no_separation = 0 '\000'}, 
fcc = {initialized = 0 '\000', function_handler = 0x0,
calling_scope = 0x0, called_scope = 0x0, object_ptr = 0x0}, values = 
0x0}, into = 0x0}, named_rewrite_template = 0x0}


(gdb) n
515 if (stmt->active_query_string && 
stmt->active_query_string != stmt->query_string) {


(gdb) p stmt
$12 = (pdo_stmt_t *) 0x2aaa
(gdb) p *stmt
Cannot access memory at address 0x2aaa


Previous Comments:

[2012-09-12 19:17:09] Ew6jQ8tSJhf3 at dyweni dot com

Description:

PHP 5.4.6
Microsoft SQL Server ODBC Driver V1.0 for Linux

PHP Segfaults while executing the call '$sth->execute()'

GDB Backtrace is:


Program received signal SIGSEGV, Segmentation fault.
zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, 
return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
515 if (stmt->active_query_string && stmt-
>active_query_string != stmt->query_string) {
(gdb) bt
#0  zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
#1  0x006005e5 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x2b250060) at /usr/src/debug/php-
5.4.6/Zend/zend_vm_execute.h:642
#2  0x0060643e in execute (op_array=0x2b282fc8) at 
/usr/src/debug/php-5.4.6/Zend/zend_vm_execute.h:410
#3  0x005d1a8e in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/debug/php-5.4.6/Zend/zend.c:1289
#4  0x00576c38 in php_execute_script (primary_file=0x7fffc190) at 
/usr/src/debug/php-5.4.6/main/main.c:2473
#5  0x006785ed in do_cli (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:988
#6  0x00678f6d in main (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:1364


Valgrind Output is:

==9423== Memcheck, a memory error detector
==9423== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9423== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9423== Command: php test.php
==9423==
==9423== Invalid read of size 8
==9423==at 0xA7588B4: zim_PDOStatement_execute (pdo_stmt.c:515)
==9423==by 0x6005E4: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==9423==by 0x60643D: execute (zend_vm_execute.h:410)
==9423==by 0x5D1A8D: zend_execute_scripts (zend.c:1289)
==9423==by 0x576C37: php_execute_script (main.c:2473)
==9423==by 0x6785EC: do_cli (php_cli.c:988)
==9423==by 0x678F6C: main (p

[PHP-BUG] Bug #63075 [NEW]: PHP Segfault in PDO ODBC Execute

2012-09-12 Thread Ew6jQ8tSJhf3 at dyweni dot com

From: Ew6jQ8tSJhf3 at dyweni dot com
Operating system: Linux x86_64 (CentOS 5.8 final)
PHP version:  5.4.6
Package:  PDO related
Bug Type: Bug
Bug description:PHP Segfault in PDO ODBC Execute

Description:

PHP 5.4.6
Microsoft SQL Server ODBC Driver V1.0 for Linux

PHP Segfaults while executing the call '$sth->execute()'

GDB Backtrace is:


Program received signal SIGSEGV, Segmentation fault.
zim_PDOStatement_execute (ht=,
return_value=0x2b284210, 
return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
515 if (stmt->active_query_string && stmt-
>active_query_string != stmt->query_string) {
(gdb) bt
#0  zim_PDOStatement_execute (ht=, 
return_value=0x2b284210, return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
#1  0x006005e5 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x2b250060) at /usr/src/debug/php-
5.4.6/Zend/zend_vm_execute.h:642
#2  0x0060643e in execute (op_array=0x2b282fc8) at 
/usr/src/debug/php-5.4.6/Zend/zend_vm_execute.h:410
#3  0x005d1a8e in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/debug/php-5.4.6/Zend/zend.c:1289
#4  0x00576c38 in php_execute_script (primary_file=0x7fffc190)
at 
/usr/src/debug/php-5.4.6/main/main.c:2473
#5  0x006785ed in do_cli (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:988
#6  0x00678f6d in main (argc=2, argv=0x7fffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:1364


Valgrind Output is:

==9423== Memcheck, a memory error detector
==9423== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9423== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9423== Command: php test.php
==9423==
==9423== Invalid read of size 8
==9423==at 0xA7588B4: zim_PDOStatement_execute (pdo_stmt.c:515)
==9423==by 0x6005E4: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==9423==by 0x60643D: execute (zend_vm_execute.h:410)
==9423==by 0x5D1A8D: zend_execute_scripts (zend.c:1289)
==9423==by 0x576C37: php_execute_script (main.c:2473)
==9423==by 0x6785EC: do_cli (php_cli.c:988)
==9423==by 0x678F6C: main (php_cli.c:1364)
==9423==  Address 0x1008f is not stack'd, malloc'd or (recently)
free'd
==9423==
==9423==
==9423== Process terminating with default action of signal 11 (SIGSEGV)
==9423==  Access not within mapped region at address 0x1008F
==9423==at 0xA7588B4: zim_PDOStatement_execute (pdo_stmt.c:515)
==9423==by 0x6005E4: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==9423==by 0x60643D: execute (zend_vm_execute.h:410)
==9423==by 0x5D1A8D: zend_execute_scripts (zend.c:1289)
==9423==by 0x576C37: php_execute_script (main.c:2473)
==9423==by 0x6785EC: do_cli (php_cli.c:988)
==9423==by 0x678F6C: main (php_cli.c:1364)
==9423==  If you believe this happened as a result of a stack
==9423==  overflow in your program's main thread (unlikely but
==9423==  possible), you can try to increase the size of the
==9423==  main thread stack using the --main-stacksize= flag.
==9423==  The main thread stack size used in this run was 10485760.
==9423==
==9423== HEAP SUMMARY:
==9423== in use at exit: 4,021,443 bytes in 19,132 blocks
==9423==   total heap usage: 22,569 allocs, 3,437 frees, 5,755,940 bytes 
allocated




Test script:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = 'SELECT fid, original_filename, dateUploaded, filesize, client FROM
upload ORDER BY dateUploaded DESC';
$sth = $pdo->prepare($stmt);
$sth->execute();
var_dump($sth->fetchAll());





Expected result:

The script should output the results from $sth->fetchAll.

Actual result:
--
The script crashes with a Segmentation Fault.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63075&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63075&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63075&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=63075&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63075&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=63075&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63075&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=63075&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=63075&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=63075&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=63075&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=63075&r=notwrong
Not

Bug #47640 [Com]: Session does not unlock file in /tmp/

2012-09-12 Thread connie at jaygoss dot com

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

 ID: 47640
 Comment by: connie at jaygoss dot com
 Reported by:manuel dot schmitt at manitu dot de
 Summary:Session does not unlock file in /tmp/
 Status: Open
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

I just encountered this bug on version 5.3.13. The script worked fine for about 
a year, then stopped working for no known reason (no code changes, version 
upgrades, etc.)

This script works:

echo "Flock Test Without Session"; 
$fp = fopen("_order_id.txt", "r+");
if (flock($fp, LOCK_EX)) { 
/* do an exclusive lock to get an order number */
$id = fread($fp,filesize("_order_id.txt"));
$id++;
echo "Got the lock, id is now $id";
ftruncate($fp, 0); /* truncate file */
rewind($fp); /* reset pointer */
fwrite($fp, $id); /* write new order id */
flock($fp, LOCK_UN); /* release the lock */
} else {
echo "Couldn't get the lock"; 
}

However, if I put the same code inside a session, it fails on my live site, but 
still works fine in my localhost (version 5.3.8):

session_start();
echo "Flock Test With Session"; 
$fp = fopen("_order_id.txt", "r+");
if (flock($fp, LOCK_EX)) { 
/* do an exclusive lock to get an order number */
$id = fread($fp,filesize("_order_id.txt"));
$id++;
echo "Got the lock, id is now $id";
ftruncate($fp, 0); /* truncate file */
rewind($fp); /* reset pointer */
fwrite($fp, $id); /* write new order id */
flock($fp, LOCK_UN); /* release the lock */
} else {
echo "Couldn't get the lock"; 
}
session_destroy();


Previous Comments:

[2012-09-12 03:14:57] ahar...@php.net

Explanation provided separately, since it's not relevant to this bug. Bug 
reopened.


[2012-09-12 03:10:26] larue...@php.net

...maybe it's chagned by the reporter self, no action history log in the 
changes 
tab


[2012-09-11 20:39:24] kriscr...@php.net

Could somebody explain why the status was changed to "Not a bug?"  I'm not 
seeing 
anything in the comments to indicate why that edit was made.  Looks like a real 
bug to me and everything else seems to check-out, so I'm assuming that was an 
error given the lack of an explanation.

I'm re-opening this with "Feedback" status.  If you're the one who closed this 
(the edit history is empty), please post a comment explaining your reasoning.  
Thanks!


[2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net

I worked around this problem by simply moving sessions from file storage to 
memcache.

session.save_handler = memcache
session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211"

An application pool that had been creeping up to MaxCli (900 children apiece, 
in 
this case) within a couple hours of a restart due to this FLOCK issue settled 
down and has now been running happily for several days on fewer than 150 
children per server.  I highly recommend just NOT USING php's file based 
session 
storage in the first place, because of exactly this issue.


[2012-02-01 19:50:15] pio at rdl dot pl

Hello !

Is there any news with this issue ?

Piotr




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=47640


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

Bug #63074 [Opn->Nab]: Intval doesn't return exact value

2012-09-12 Thread rasmus

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

 ID: 63074
 Updated by: ras...@php.net
 Reported by:berthonneau dot olivier at gmail dot com
 Summary:Intval doesn't return exact value
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Math related
 Operating System:   Windows Server 2008 and Ubuntu
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://www.floating-point-gui.de/

Thank you for your interest in PHP.




Previous Comments:

[2012-09-12 16:10:45] berthonneau dot olivier at gmail dot com

Description:

Hi!

I found a strange bug today.
I have a float variable which contains 3876., I want to pass it through the 
intval() function.
I know it's already an integer because there is no decimals, but the strange 
thing 
is that intval() don't return 3876 but 3875.

I experience the same thing with explicite cast.

Test script:
---
$tmp = 1370 * 1.15;
echo $tmp . ""; // echo 3875.5
$tmp += 0.5;
echo $tmp . ""; // echo 3876
$tmp = intval($tmp);
echo "tmp= ". $tmp . ""; // echo 3875



Same thing with an explicite cast: $tmp = (int)$tmp;

Expected result:

I expect that the last echo output 3876

Actual result:
--
The last echo output 3875 instead of 3876.






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

Bug #62886 [Com]: PHP-FPM may segfault/hang on startup

2012-09-12 Thread jeffrey dot ness at rackspace dot com

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

 ID: 62886
 Comment by: jeffrey dot ness at rackspace dot com
 Reported by:pierre at archlinux dot de
 Summary:PHP-FPM may segfault/hang on startup
 Status: Assigned
 Type:   Bug
 Package:FPM related
 Operating System:   Arch Linux
 PHP Version:5.4.6
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

I am also noticing this issue with our 5.3.16 packages:

# php-fpm -v
PHP 5.3.16 (fpm-fcgi) (built: Aug 20 2012 10:39:20)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

# for i in {1..100}; do php-fpm ; killall php-fpm; done
Segmentation fault
Segmentation fault
Segmentation fault

# dmesg | grep php-fpm
php-fpm[30800]: segfault at 7f7d199f4cd0 ip 7f7d24a43b83 sp 
7fffdd48fb20 error 4 in ld-
2.12.so[7f7d24a35000+2]
php-fpm[31599]: segfault at 7f50f17c3cd0 ip 7f50fc812b83 sp 
7fff09f13120 error 4 in ld-
2.12.so[7f50fc804000+2]
php-fpm[32009]: segfault at 7f3005f59cc0 ip 7f3010938b83 sp 
7fffb291c3a0 error 4 in ld-
2.12.so[7f301092a000+2]
php-fpm[32313]: segfault at 7f17094a4cc0 ip 7f1713e83b83 sp 
7fffaab94e20 error 4 in ld-
2.12.so[7f1713e75000+2]
php-fpm[32585]: segfault at 7f60ad427cc0 ip 7f60b7e06b83 sp 
744e06a0 error 4 in ld-
2.12.so[7f60b7df8000+2]


Previous Comments:

[2012-08-24 09:06:27] pierre at archlinux dot de

I have attached php.ini and php-fpm.conf as patches (sorry, didn't fint another 
way to attach those)

Here is what is different from the configuration shipped with PHP 5.4.6:

The php-fpm.conf is the plain upstream one with this patch applied: 
https://projects.archlinux.de/svntogit/packages.git/tree/trunk/php-fpm.conf.in.patch?h=packages/php

php.ini is a copy of php.ini-production with this patch applied: 
https://projects.archlinux.de/svntogit/packages.git/tree/trunk/php.ini.patch?h=packages/php

On top of that I applied the following changes locally: 
http://paste.xinu.at/Hp6/


[2012-08-24 08:46:19] f...@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.


I also need your FPM configuration and your php.ini please

thanks


[2012-08-24 08:37:27] pierre at archlinux dot de

I rebuild with debug symbols and got the following trace:

Core was generated by `php-fpm'.
Program terminated with signal 11, Segmentation fault.
#0  0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2
(gdb) bt
#0  0x7fc96b2c6ed6 in _dl_fini () from /lib/ld-linux-x86-64.so.2
#1  0x7fc96970cb31 in __run_exit_handlers () from /lib/libc.so.6
#2  0x7fc96970cbb5 in exit () from /lib/libc.so.6
#3  0x008cb754 in fpm_signals_sighandler_exit_ok (pid=10) at 
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_signals.c:254
#4  
#5  0x7fc96b2cf3c7 in munmap () from /lib/ld-linux-x86-64.so.2
#6  0x7fc96b2ceb4d in _dl_unmap () from /lib/ld-linux-x86-64.so.2
#7  0x7fc96b2cba1f in _dl_close_worker () from /lib/ld-linux-x86-64.so.2
#8  0x7fc96b2cc18c in _dl_close () from /lib/ld-linux-x86-64.so.2
#9  0x7fc96b2c6736 in _dl_catch_error () from /lib/ld-linux-x86-64.so.2
#10 0x7fc969fee5fc in ?? () from /lib/libdl.so.2
#11 0x7fc969fee10f in dlclose () from /lib/libdl.so.2
#12 0x00773e2c in module_destructor (module=0x1ba6050) at 
/build/src/php-5.4.6/Zend/zend_API.c:2284
#13 0x0077c30f in zend_hash_apply_deleter (ht=0xfb5240 
, p=0x1ba5ff0) at /build/src/php-5.4.6/Zend/zend_hash.c:650
#14 0x0077c4aa in zend_hash_graceful_reverse_destroy (ht=0xfb5240 
) at /build/src/php-5.4.6/Zend/zend_hash.c:687
#15 0x00771f97 in zend_destroy_modules () at 
/build/src/php-5.4.6/Zend/zend_API.c:1797
#16 0x00768e9e in zend_shutdown () at 
/build/src/php-5.4.6/Zend/zend.c:823
#17 0x006d5151 in php_module_shutdown () at 
/build/src/php-5.4.6/main/main.c:2346
#18 0x008c7e23 in fpm_php_cleanup (which=2, arg=0x0) at 
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_php.c:199
#19 0x008bc629 in fpm_cleanups_run (type=2) at 
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_cleanup.c:45
#20 0x008cf1df in fpm_unix_init_main () at 
/build/src/php-5.4.6/sapi/fpm/fpm/fpm_unix.c:312
#21 0x008bb2df in fpm_init (argc=1, argv=0x7fff252a4a98, config=0x0, 
prefix=0x0, pid=0x0, test_conf=0, run_as_root=0) at 
/build/src/php-5.4.6/sapi/fpm/fpm/fpm.c:59
#22 0x008c7221 in main (argc=1, argv=0x7fff252a4a98) at

[PHP-BUG] Bug #63074 [NEW]: Intval doesn't return exact value

2012-09-12 Thread berthonneau dot olivier at gmail dot com

From: berthonneau dot olivier at gmail dot com
Operating system: Windows Server 2008 and Ubuntu
PHP version:  5.3.16
Package:  Math related
Bug Type: Bug
Bug description:Intval doesn't return exact value

Description:

Hi!

I found a strange bug today.
I have a float variable which contains 3876., I want to pass it through
the 
intval() function.
I know it's already an integer because there is no decimals, but the
strange thing 
is that intval() don't return 3876 but 3875.

I experience the same thing with explicite cast.

Test script:
---
$tmp = 1370 * 1.15;
echo $tmp . ""; // echo 3875.5
$tmp += 0.5;
echo $tmp . ""; // echo 3876
$tmp = intval($tmp);
echo "tmp= ". $tmp . ""; // echo 3875



Same thing with an explicite cast: $tmp = (int)$tmp;

Expected result:

I expect that the last echo output 3876

Actual result:
--
The last echo output 3875 instead of 3876.

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

[PHP-BUG] Bug #63073 [NEW]: master "make install" fails to install PEAR

2012-09-12 Thread php at bof dot de

From: php at bof dot de
Operating system: openSUSE 11.4 64bit
PHP version:  master-Git-2012-09-12 (Git)
Package:  Compile Failure
Bug Type: Bug
Bug description:master "make install" fails to install PEAR

Description:

I'm building PHP master from current git (at 
5246d6f02e52798e343bd5208692f1a5ed89b9d9)

Compile works fine, but on "make install", PEAR does not install. See
"Actual 
result" regarding the error output I get.

I can successfully compile AND install, with identical configure, the
PHP-5.4.6 
release, so I don't think that there is anything wrong with my build
environment.

I tried to copy over pecl, pear, and the pear environment, from the 5.4 
build/install. pecl and pear search works. download or install fetches the
file, 
but then fails with a similar "could not extract" error.

Test script:
---
make install

Expected result:

Installing PEAR environment:  /opt/php/php/
[PEAR] Archive_Tar- already installed: 1.3.7
[PEAR] Console_Getopt - already installed: 1.3.0
[PEAR] Structures_Graph- already installed: 1.0.4
[PEAR] XML_Util   - already installed: 1.2.1
[PEAR] PEAR   - already installed: 1.9.4


Actual result:
--
Installing PEAR environment:  /opt/php/php/
[PEAR] Archive_Tar: could not extract the package.xml file from
"phar://install-
pear-nozlib.phar/Archive_Tar-1.3.7.tar"
[PEAR] Console_Getopt: could not extract the package.xml file from 
"phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar"
[PEAR] Structures_Graph: could not extract the package.xml file from 
"phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar"
[PEAR] XML_Util: could not extract the package.xml file from
"phar://install-
pear-nozlib.phar/XML_Util-1.2.1.tar"
[PEAR] PEAR: could not extract the package.xml file from
"phar://install-pear-
nozlib.phar/PEAR-1.9.4.tar"


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

Bug #63071 [Com]: func_get_args loses byref information

2012-09-12 Thread maarten at ba dot be

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

 ID: 63071
 Comment by: maarten at ba dot be
 Reported by:maarten at ba dot be
 Summary:func_get_args loses byref information
 Status: Not a bug
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   all
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

"This function returns a copy of the passed arguments only, ..."

from the same page.

thus an array. it's just that this copied array loses it's byref value for one 
of the elements in the array...

this makes it impossible to have a hook system where you can also modify a 
parameter because it's byref


Previous Comments:

[2012-09-12 11:15:12] larue...@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

"Returns an array in which each element is a copy of the corresponding member 
of 
the current user-defined function's argument list."

http://us2.php.net/manual/en/function.func-get-args.php


[2012-09-12 11:00:08] maarten at ba dot be

Description:

i'm writing code that invokes "hooks" with byref parameters.

but the generalized hook functions lose the byref information due to 
func_get_args being a copy (but not exact), thus call_user_func_array() (which 
needs to have references in it's array) can't work.

see shortened example below:

Test script:
---
$foo = "foo";
$bar = "bar";
function func_a(&$a, $b) {
  $a = $b;
};
function c() {
  $args = func_get_args();
  call_user_func_array("func_a", $args);
};
c(&$foo, $bar);
var_dump($foo);

Expected result:

i expected for $foo to have 'bar'

Actual result:
--
$foo is still 'foo', and a warning is generated






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

Req #63072 [Opn]: Request: function as register_shutdown_function, but as it was before PHP 4.1.0

2012-09-12 Thread zdexter_cds at hotmail dot com

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

 ID: 63072
 User updated by:zdexter_cds at hotmail dot com
 Reported by:zdexter_cds at hotmail dot com
 Summary:Request: function as register_shutdown_function, but
 as it was before PHP 4.1.0
 Status: Open
 Type:   Feature/Change Request
-Package:Output Control
+Package:Unknown/Other Function
 Operating System:   Anyone
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Edit: bug type changed.


Previous Comments:

[2012-09-12 15:04:40] zdexter_cds at hotmail dot com

Description:

I'm asking for a function as register_shutdown_function used to be, when it 
executed after client disconnects.

Reason: Get faster responses to the user when some considerably 'slow' process 
might be executed in background, after processes.

I know it could be done by some custom function, as well as it's possible 
through Output Control Buffers Functions, but it's more code to write, more 
commands to be processed by server and it'd 'conflict' with output_buffering 
setting from php.ini so you'd also need to manage it.

Also, the current function could be simulated easier than the old one, but it's 
the one chosen.

It can easily be done by you, as it's just copy & paste, so I hope it's 
implemented.

Thanks in advance.







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

[PHP-BUG] Req #63072 [NEW]: Request: function as register_shutdown_function, but as it was before PHP 4.1.0

2012-09-12 Thread zdexter_cds at hotmail dot com

From: zdexter_cds at hotmail dot com
Operating system: Anyone
PHP version:  5.4.6
Package:  Output Control
Bug Type: Feature/Change Request
Bug description:Request: function as register_shutdown_function, but as it was 
before PHP 4.1.0

Description:

I'm asking for a function as register_shutdown_function used to be, when it

executed after client disconnects.

Reason: Get faster responses to the user when some considerably 'slow'
process 
might be executed in background, after processes.

I know it could be done by some custom function, as well as it's possible 
through Output Control Buffers Functions, but it's more code to write, more

commands to be processed by server and it'd 'conflict' with
output_buffering 
setting from php.ini so you'd also need to manage it.

Also, the current function could be simulated easier than the old one, but
it's 
the one chosen.

It can easily be done by you, as it's just copy & paste, so I hope it's 
implemented.

Thanks in advance.


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

Req #62113 [Opn]: ReflectionMethod::invoke && invokeArgs support static binding...

2012-09-12 Thread nath...@php.net

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

 ID: 62113
 User updated by:nath...@php.net
 Reported by:nath...@php.net
 Summary:ReflectionMethod::invoke && invokeArgs support
 static binding...
 Status: Open
 Type:   Feature/Change Request
 Package:Reflection related
 Operating System:   N/A
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

* Updated email address for profiling and spam reasons


Previous Comments:

[2012-05-22 21:38:01] nath...@php.net

Description:

I think it'd be useful to be able to set the static binding of a class method 
if 
it's a static method. Currently you can only set the binding if it's not a 
static 
method, but my patch (see below) now will allow you to pass a string or an 
object 
to the ReflectionMethod::invoke and invokeArgs methods allowing you to set the 
static binding of static functions.

The script below will work with the patch in place, but not work with current 
version of PHP because you *must* pass a valid object or null as the first 
argument, but if you are wanting it to call a static method my patch will allow 
you to set the Class the static method will run under.

Test script:
---
 ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invoke($this);
$returns[] = 'B => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invoke('B');
$returns[] = 'C => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invoke('C');
$returns[] = 'A => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invoke(null);
$returns[] = 'stdClass => ' .   current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invoke(new 
stdClass);

$returns[] = 'C => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invokeArgs($this,
 array());
$returns[] = 'B => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invokeArgs('B',
 array());
$returns[] = 'C => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invokeArgs('C',
 array());
$returns[] = 'A => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('static_method')->invokeArgs(null,
 array());

$returns[] = 'C => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invoke($this);
$returns[] = 'stdClass => ' .   current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invoke(new 
stdClass);
$returns[] = 'B => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invoke(new 
B());

$returns[] = 'C => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invoke($this);
$returns[] = 'stdClass => ' .   current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invoke(new
 stdClass());
$returns[] = 'B => ' .  current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invoke(new
 B());

// Normal methods need an object
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invokeArgs($this,
 array());
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invoke('B', 
array()); // Error
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invoke('B', 
array()); // Error
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method')->invoke(null, 
array()); // Error
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invokeArgs($this,
 array());
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invoke('B',
 array()); // Error
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invoke('B',
 array()); // Error
//$returns[] = current((new 
ReflectionClass('C'))->getTraits())->getMethod('normal_method_this')->invoke(null,
 array()); // Error
return $returns;
}
}

$a = new C;
print_r($a->test());
echo  "\n";

Expec

Bug #63071 [Opn->Nab]: func_get_args loses byref information

2012-09-12 Thread laruence

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

 ID: 63071
 Updated by: larue...@php.net
 Reported by:maarten at ba dot be
 Summary:func_get_args loses byref information
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   all
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

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

"Returns an array in which each element is a copy of the corresponding member 
of 
the current user-defined function's argument list."

http://us2.php.net/manual/en/function.func-get-args.php


Previous Comments:

[2012-09-12 11:00:08] maarten at ba dot be

Description:

i'm writing code that invokes "hooks" with byref parameters.

but the generalized hook functions lose the byref information due to 
func_get_args being a copy (but not exact), thus call_user_func_array() (which 
needs to have references in it's array) can't work.

see shortened example below:

Test script:
---
$foo = "foo";
$bar = "bar";
function func_a(&$a, $b) {
  $a = $b;
};
function c() {
  $args = func_get_args();
  call_user_func_array("func_a", $args);
};
c(&$foo, $bar);
var_dump($foo);

Expected result:

i expected for $foo to have 'bar'

Actual result:
--
$foo is still 'foo', and a warning is generated






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

[PHP-BUG] Bug #63071 [NEW]: func_get_args loses byref information

2012-09-12 Thread maarten at ba dot be

From: maarten at ba dot be
Operating system: all
PHP version:  5.3.16
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:func_get_args loses byref information

Description:

i'm writing code that invokes "hooks" with byref parameters.

but the generalized hook functions lose the byref information due to
func_get_args being a copy (but not exact), thus call_user_func_array()
(which needs to have references in it's array) can't work.

see shortened example below:

Test script:
---
$foo = "foo";
$bar = "bar";
function func_a(&$a, $b) {
  $a = $b;
};
function c() {
  $args = func_get_args();
  call_user_func_array("func_a", $args);
};
c(&$foo, $bar);
var_dump($foo);

Expected result:

i expected for $foo to have 'bar'

Actual result:
--
$foo is still 'foo', and a warning is generated

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

Bug #63026 [Fbk]: require_once error

2012-09-12 Thread reeze

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

 ID: 63026
 Updated by: re...@php.net
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

â$obj = $this->loadCS('M.share_model');//è°ç¨å¶å®ç±»
   
//ä½ å¯ä»¥å¤è°ç¨å ä¸ªç±»ï¼å¨ä¸é¢éè¯¯åæ³æåµä¸ï¼æçç±»å¯ä»¥è°ç¨æåï¼æçå¤±è´¥
   //sysModule 
éçå¯¹åºå³ç³»ï¼åºè¯¥è¿ä¹å'C'=>CTRLS,åèæ éå¼å·
â
require_onceçè·¯å¾æ¯ç´æ¥æ¼çï¼èä¸ä¸æ¯autoloadï¼
ä»è¿éæ²¡æå¶ä»çä¾åï¼å¦æé¨åç±»åå¤§å°åéäºï¼å°±ä¼åºç°é¨åç±»æ¾ä¸å°çæåµã

å¨requireåå¢å ä¸ªæ£æ¥å°±è½ç¡®è®¤æèæé¤è¿ä¸ªé®é¢äº


Previous Comments:

[2012-09-12 10:25:08] larue...@php.net

ä½ ä»åªéçåºæ¥åå¤§å°åæå³ç³»ç?


[2012-09-12 10:15:04] re...@php.net

çä½ è¿æåµï¼æå¯è½æ¯ä½ çå¤§å°åé®é¢ï¼ 
ä½ æ¯ç´æ¥require_onceçï¼å¦æå¤§å°åéäºæ¯æé®é¢çã
ä¸ºäºå¥½è°è¯ï¼ä½ å¯ä»¥å¨require_once åå ä¸ä¸ªif(!file_exists($file) 
{die($file not found)}
æ£æ¥ä¸ä¸ã ä½ ç¡®è®¤ä¸ä¸æä»¶çç¡®åå¨å§ã

åæ¶ï¼æ¯å¨ä¸è¡ï¼æä½ çä»£ç å®æ´æåä¼ å°æä¸ªå°æ¹å§ãã


[2012-09-12 02:03:08] larue...@php.net

é£äºç±»åå¯ä»¥æ£ç¡®å è½½ ,é£äºç±»åä¸å¯ä»¥?  ä½ ä¸¾ä¸ªä¾å?


[2012-09-12 01:56:19] ian dot xspace at yahoo dot cn

//init.php å®ä¹ç½ç«ç®å½
/***ç½ç«ç®å½å®ä¹***/
define('THEME', 'default');
//define('TEMP', WEB_ROOT.DS.'temp');
//define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
define('LOGS', VIEWS.DS.'logs');
define('DYN', VIEWS.DS.'dynamic');
define('HLP', WEB_ROOT.DS.'helpers');
//define('PLNS', WEB_ROOT.DS.'plugins');
define('CONFS', WEB_ROOT.DS.'configs');
define('MODELS', WEB_ROOT.DS.'models');
define('CTRLS', WEB_ROOT.DS.'controls');
//SYS.php  
sysModuleå½æ°éçå¯¹åºå³ç³»ä¸ºéè¯¯åæ³ï¼æ£ç¡®åæ³åºè¯¥æ¯'M'=>MODELSåèæ éåå¼å·
class SYS
{
//sysModuleç³»ç»ç®å½æ å°
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
}
//getSysè·åç¸åºéç½®
public static function getSys($fun)
{
return self::$fun();
}
}
//common.php å¶ä¸ä¸ä¸ªå½æ°ï¼å è½½æéè¦çç±»
class Common
{
//loadCS
protected function loadCS($cs)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //ç´æ¥å®ä½   
require_once($moArr[$type].DS."{$csName}.php");
//  switch($type)  ä»¥ä¸å°ä¼è·åæ´å¿«æ§è¡éåº¦
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', 'è°ç¨å¤±è´¥!');
//  }
$CS = ucfirst($csName);
return new $CS();
}
}

//index.php é¦é¡µè°ç¨å¶å®ç±»
//Index
class Index extends IAN_C
{
//__construct
public function __construct()
{
   $obj = $this->loadCS('M.share_model');//è°ç¨å¶å®ç±»
   
//ä½ å¯ä»¥å¤è°ç¨å ä¸ªç±»ï¼å¨ä¸é¢éè¯¯åæ³æåµä¸ï¼æçç±»å¯ä»¥è°ç¨æåï¼æçå¤±è´¥
   //sysModule 
éçå¯¹åºå³ç³»ï¼åºè¯¥è¿ä¹å'C'=>CTRLS,åèæ éå¼å·
}

}
new Index

//å¤§å¥ä½ è¦æ¯åçä¸æç½ï¼æä¹æ²¡è¾äº

--

Bug #63026 [Fbk]: require_once error

2012-09-12 Thread laruence

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

 ID: 63026
 Updated by: larue...@php.net
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

ä½ ä»åªéçåºæ¥åå¤§å°åæå³ç³»ç?


Previous Comments:

[2012-09-12 10:15:04] re...@php.net

çä½ è¿æåµï¼æå¯è½æ¯ä½ çå¤§å°åé®é¢ï¼ 
ä½ æ¯ç´æ¥require_onceçï¼å¦æå¤§å°åéäºæ¯æé®é¢çã
ä¸ºäºå¥½è°è¯ï¼ä½ å¯ä»¥å¨require_once åå ä¸ä¸ªif(!file_exists($file) 
{die($file not found)}
æ£æ¥ä¸ä¸ã ä½ ç¡®è®¤ä¸ä¸æä»¶çç¡®åå¨å§ã

åæ¶ï¼æ¯å¨ä¸è¡ï¼æä½ çä»£ç å®æ´æåä¼ å°æä¸ªå°æ¹å§ãã


[2012-09-12 02:03:08] larue...@php.net

é£äºç±»åå¯ä»¥æ£ç¡®å è½½ ,é£äºç±»åä¸å¯ä»¥?  ä½ ä¸¾ä¸ªä¾å?


[2012-09-12 01:56:19] ian dot xspace at yahoo dot cn

//init.php å®ä¹ç½ç«ç®å½
/***ç½ç«ç®å½å®ä¹***/
define('THEME', 'default');
//define('TEMP', WEB_ROOT.DS.'temp');
//define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
define('LOGS', VIEWS.DS.'logs');
define('DYN', VIEWS.DS.'dynamic');
define('HLP', WEB_ROOT.DS.'helpers');
//define('PLNS', WEB_ROOT.DS.'plugins');
define('CONFS', WEB_ROOT.DS.'configs');
define('MODELS', WEB_ROOT.DS.'models');
define('CTRLS', WEB_ROOT.DS.'controls');
//SYS.php  
sysModuleå½æ°éçå¯¹åºå³ç³»ä¸ºéè¯¯åæ³ï¼æ£ç¡®åæ³åºè¯¥æ¯'M'=>MODELSåèæ éåå¼å·
class SYS
{
//sysModuleç³»ç»ç®å½æ å°
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
}
//getSysè·åç¸åºéç½®
public static function getSys($fun)
{
return self::$fun();
}
}
//common.php å¶ä¸ä¸ä¸ªå½æ°ï¼å è½½æéè¦çç±»
class Common
{
//loadCS
protected function loadCS($cs)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //ç´æ¥å®ä½   
require_once($moArr[$type].DS."{$csName}.php");
//  switch($type)  ä»¥ä¸å°ä¼è·åæ´å¿«æ§è¡éåº¦
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', 'è°ç¨å¤±è´¥!');
//  }
$CS = ucfirst($csName);
return new $CS();
}
}

//index.php é¦é¡µè°ç¨å¶å®ç±»
//Index
class Index extends IAN_C
{
//__construct
public function __construct()
{
   $obj = $this->loadCS('M.share_model');//è°ç¨å¶å®ç±»
   
//ä½ å¯ä»¥å¤è°ç¨å ä¸ªç±»ï¼å¨ä¸é¢éè¯¯åæ³æåµä¸ï¼æçç±»å¯ä»¥è°ç¨æåï¼æçå¤±è´¥
   //sysModule 
éçå¯¹åºå³ç³»ï¼åºè¯¥è¿ä¹å'C'=>CTRLS,åèæ éå¼å·
}

}
new Index

//å¤§å¥ä½ è¦æ¯åçä¸æç½ï¼æä¹æ²¡è¾äº


[2012-09-12 01:48:03] ian dot xspace at yahoo dot cn

æ©è¯´åï¼æè¿ä»¥ä¸ºé½æ¯å¤å½äººå¢ã
//å®ä¹ç½ç«è·ç®å½ init.php
define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/'));
//å®ä¹ç½ç«çå¶å®ç®å½
define('TEMP', WEB_ROOT.DS.'temp');
define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
//ä¸é¢æ¯æåçä¸ä¸ªç±» sys.php
class SYS
{

//è¿ä¸ªæ¯æ¯ä¸ªç®å½å¯¹åºçç®åï¼ä½æ¯è¿æ¯éè¯¯åæ³ï¼å¯å¨åæçç¨åºè°ç¨ä¸å±ç¶æç
//å¯ä»¥æåæçå¤±è´¥äº  $moArr = SYS::getSys('sysModule');
//require_once($moArr[$type].DS."{$csNa

Bug #51521 [Com]: XMLReader doesn't open files via stream_wrapper

2012-09-12 Thread ibra_3 at yahoo dot com

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

 ID: 51521
 Comment by: ibra_3 at yahoo dot com
 Reported by:andrey at niakhaichyk dot org
 Summary:XMLReader doesn't open files via stream_wrapper
 Status: Not a bug
 Type:   Bug
 Package:XML Reader
 Operating System:   Linux i686
 PHP Version:5.3.0
 Block user comment: N
 Private report: N

 New Comment:

I faced same problem while using this code

$objReader = XMLReader::open('reader.xml')

but it was solved here

$objReader = XMLReader;
$objReader->open('reader.xml')

best regards


Previous Comments:

[2010-04-09 19:59:13] andrey at niakhaichyk dot org

Cannot reproduce in 5.3.2


[2010-04-09 19:58:26] andrey at niakhaichyk dot org

Cannot reproduce for PHP 5.3.2 Win x32. Seems to was fixed.


[2010-04-09 19:56:54] andrey at niakhaichyk dot org

Tested on old PHP version


[2010-04-09 16:58:19] andrey at niakhaichyk dot org

Description:

XMLReader generates the error when tries to open files via stream_wrapper. 
Works for 5.2.12

Test script:
---
http://niakhaichyk.org/xmlreader.bug.txt

Expected result:

PHP_VERSION: 5.3.0
XML: Thank you
root=
#text=Thank you
root=


Actual result:
--
PHP_VERSION: 5.3.0
XML: Thank you


Warning:  XMLReader::open() [xmlreader.open]: Unable to open source data in 
/var/www/vidunia/public/xmlreader.bug.php on line 12



Warning:  XMLReader::read() [xmlreader.read]: Load Data before trying to read 
in /var/www/vidunia/public/xmlreader.bug.php on line 13








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

Bug #63026 [Fbk]: require_once error

2012-09-12 Thread reeze

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

 ID: 63026
 Updated by: re...@php.net
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

çä½ è¿æåµï¼æå¯è½æ¯ä½ çå¤§å°åé®é¢ï¼ 
ä½ æ¯ç´æ¥require_onceçï¼å¦æå¤§å°åéäºæ¯æé®é¢çã
ä¸ºäºå¥½è°è¯ï¼ä½ å¯ä»¥å¨require_once åå ä¸ä¸ªif(!file_exists($file) 
{die($file not found)}
æ£æ¥ä¸ä¸ã ä½ ç¡®è®¤ä¸ä¸æä»¶çç¡®åå¨å§ã

åæ¶ï¼æ¯å¨ä¸è¡ï¼æä½ çä»£ç å®æ´æåä¼ å°æä¸ªå°æ¹å§ãã


Previous Comments:

[2012-09-12 02:03:08] larue...@php.net

é£äºç±»åå¯ä»¥æ£ç¡®å è½½ ,é£äºç±»åä¸å¯ä»¥?  ä½ ä¸¾ä¸ªä¾å?


[2012-09-12 01:56:19] ian dot xspace at yahoo dot cn

//init.php å®ä¹ç½ç«ç®å½
/***ç½ç«ç®å½å®ä¹***/
define('THEME', 'default');
//define('TEMP', WEB_ROOT.DS.'temp');
//define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
define('LOGS', VIEWS.DS.'logs');
define('DYN', VIEWS.DS.'dynamic');
define('HLP', WEB_ROOT.DS.'helpers');
//define('PLNS', WEB_ROOT.DS.'plugins');
define('CONFS', WEB_ROOT.DS.'configs');
define('MODELS', WEB_ROOT.DS.'models');
define('CTRLS', WEB_ROOT.DS.'controls');
//SYS.php  
sysModuleå½æ°éçå¯¹åºå³ç³»ä¸ºéè¯¯åæ³ï¼æ£ç¡®åæ³åºè¯¥æ¯'M'=>MODELSåèæ éåå¼å·
class SYS
{
//sysModuleç³»ç»ç®å½æ å°
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
}
//getSysè·åç¸åºéç½®
public static function getSys($fun)
{
return self::$fun();
}
}
//common.php å¶ä¸ä¸ä¸ªå½æ°ï¼å è½½æéè¦çç±»
class Common
{
//loadCS
protected function loadCS($cs)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //ç´æ¥å®ä½   
require_once($moArr[$type].DS."{$csName}.php");
//  switch($type)  ä»¥ä¸å°ä¼è·åæ´å¿«æ§è¡éåº¦
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', 'è°ç¨å¤±è´¥!');
//  }
$CS = ucfirst($csName);
return new $CS();
}
}

//index.php é¦é¡µè°ç¨å¶å®ç±»
//Index
class Index extends IAN_C
{
//__construct
public function __construct()
{
   $obj = $this->loadCS('M.share_model');//è°ç¨å¶å®ç±»
   
//ä½ å¯ä»¥å¤è°ç¨å ä¸ªç±»ï¼å¨ä¸é¢éè¯¯åæ³æåµä¸ï¼æçç±»å¯ä»¥è°ç¨æåï¼æçå¤±è´¥
   //sysModule 
éçå¯¹åºå³ç³»ï¼åºè¯¥è¿ä¹å'C'=>CTRLS,åèæ éå¼å·
}

}
new Index

//å¤§å¥ä½ è¦æ¯åçä¸æç½ï¼æä¹æ²¡è¾äº


[2012-09-12 01:48:03] ian dot xspace at yahoo dot cn

æ©è¯´åï¼æè¿ä»¥ä¸ºé½æ¯å¤å½äººå¢ã
//å®ä¹ç½ç«è·ç®å½ init.php
define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/'));
//å®ä¹ç½ç«çå¶å®ç®å½
define('TEMP', WEB_ROOT.DS.'temp');
define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
//ä¸é¢æ¯æåçä¸ä¸ªç±» sys.php
class SYS
{

//è¿ä¸ªæ¯æ¯ä¸ªç®å½å¯¹åºçç®åï¼ä½æ¯è¿æ¯éè¯¯åæ³ï¼å¯å¨åæçç¨åºè°ç¨ä¸å±ç¶æç
//å¯ä»¥æåæçå¤±è´¥äº  $moArr = SYS::getSys('sysModule');
//require_once($moArr[$type].DS."{$csName}.php"); è¿æ ·å¯ä»¥ç´æ¥
//å¼å¥æéè¦çæä»¶ï¼é¿åä½¿ç¨switchæµªè´¹æ¶é´
/*
//  switch($type)  ä»¥ä¸å°ä¼è·åæ´

Bug #62954 [Fbk]: startup problems fpm / php-fpm

2012-09-12 Thread tony2001

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

 ID: 62954
 Updated by: tony2...@php.net
 Reported by:jonas at brachium-system dot net
 Summary:startup problems fpm / php-fpm
 Status: Feedback
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3Git-2012-08-27 (Git)
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

>Program received signal SIGUSR1, User defined signal 1

This only shows us that FPM has successfully forked to detach from the console.
It didn't hang, crash or exit, it's still running and you can see it yourself: 
`ps afx | grep php`


Previous Comments:

[2012-09-10 19:32:56] jonas at brachium-system dot net

I have pulled the current PHP-5.3 branch and compile it with:

 ./configure --prefix=/usr --enable-fpm --enable-bcmath --with-bz2 
--enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp 
--enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib 
--with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash 
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd 
--enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop 
--enable-soap --enable-sockets --enable-sysvmsg --enable-wddx  --with-xsl 
--enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd 
--enable-debug

I have started PHP with gdb:
-
root@testm64:/home/jonas/php-src# gdb sapi/fpm/php-fpm
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jonas/php-src/sapi/fpm/php-fpm...done.
warning: not using untrusted file "/home/jonas/php-src/.gdbinit"
(gdb) run
Starting program: /home/jonas/php-src/sapi/fpm/php-fpm 
[Thread debugging using libthread_db enabled]

Program received signal SIGUSR1, User defined signal 1.
0x749c8380 in ?? () from /lib/libc.so.6
(gdb) bt
#0  0x749c8380 in ?? () from /lib/libc.so.6
#1  0x749cb94c in free () from /lib/libc.so.6
#2  0x009d416e in zend_hash_destroy (ht=0x132c170) at 
/home/jonas/php-src/Zend/zend_hash.c:532
#3  0x009c2cd3 in zend_shutdown () at 
/home/jonas/php-src/Zend/zend.c:773
#4  0x0094b6a3 in php_module_shutdown () at 
/home/jonas/php-src/main/main.c:2186
#5  0x00abb116 in fpm_php_cleanup (which=2, arg=0x0) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_php.c:199
#6  0x00ab009d in fpm_cleanups_run (type=2) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_cleanup.c:45
#7  0x00ac2109 in fpm_unix_init_main () at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_unix.c:312
#8  0x00aaed7b in fpm_init (argc=1, argv=0x7fffe788, config=0x0, 
prefix=0x0, pid=0x0, test_conf=0, run_as_root=0) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm.c:59
#9  0x00aba69c in main (argc=1, argv=0x7fffe788) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_main.c:1805


[2012-09-10 13:18:31] tony2...@php.net

#4  0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5  0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0

This looks like a problem of your system's PCRE library.
No idea why would you use it instead of the bundled, but can you just try a 
plain PHP version provided from php.net and see if you still can reproduce the 
problem? Preferably a recent snapshot, preferable without any external libs and 
opcode caches.
This'll help us to understand if this is a genuine FPM problem or something 
different.


[2012-09-05 17:06:39] rainer-phpbugs at 7val dot com

I can reproduce this problem with php 5.3.16 on SLES 11.2 x86_64 (after about 
20 attempts on average), but not on Ubuntu 12.04.1 x86_64 or Centos (RHEL) 6.3 
(no problem after more than 2000 restarts each).

remove_usr1_usr2_fpm_unix.patch reliably fixes this problem for me.

gdb backtraces of the hanging process always look like this (taken on opensuse 
11 i386):

#0  0xe424 in __kernel_vsyscall ()
#1  0xb4fe3e53 in __lll_lock_wait_private () from /lib/libc.so.6
#2  0xb4f762fb in _L_lock_10372 () from /lib/libc.so.6
#3  0xb4f74a66 in free () from /lib/libc.so.6
#4  0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5  0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0
#6  0xb4f3089f in __run_exit_handlers () from /l

38 matches

Mail list logo