#36158 [Opn->Asn]: SIGTERM is not handled correctly when running as a FastCGI server

[sniper]

 ID:   36158
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chris at mysociety dot org
-Status:   Open
+Status:   Assigned
 Bug Type: CGI related
-Operating System: n/a
+Operating System: *
-PHP Version:  4.4.2
+PHP Version:  5.1.2, 4.4.2
-Assigned To:  
+Assigned To:  dmitry
 New Comment:

Dmitry, does the new code fix this problem..?


Previous Comments:


[2006-01-26 01:55:15] chris at mysociety dot org

That snapshot (a) doesn't fix the problem -- the FastCGI code is
essentially unchanged since 4.x, though with a bunch of whitespace
noise; and (b) wouldn't help us in any case since it's PHP5 and our
applications are written for PHP4.



[2006-01-25 23:51:05] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2006-01-25 21:00:06] chris at mysociety dot org

Description:

When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager
uses this signal to shut down excess dynamic servers. "Graceful" in
this context means that the server must finish handling any outstanding
request and then terminate its connection to the web server. Presently,
PHP does not handle SIGTERM at all in the FastCGI request loop, so that
on receipt of SIGTERM, php aborts, even if half-way through a request.
This typically results in the web server logging "Incomplete headers (0
bytes) received", and returning "500 Internal Server Error" to the
client.

I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.

Reproduce code:
---
Put the following in a .php file:

and set it up to run under FastCGI. Set up a script to request the page
in a loop ("while : ; do wget -O/dev/null -q http://path/to/script ;
done") Then kill the PHP process (pkill php will do this under Linux).
If you catch the script in the sleep, this will result in the client
getting a 500 and the web server logging a message about php failing,
as describe above.

Expected result:

No errors.

Actual result:
--
500 error.





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

#36158 [Fbk->Opn]: SIGTERM is not handled correctly when running as a FastCGI server

[chris at mysociety dot org]

 ID:   36158
 User updated by:  chris at mysociety dot org
 Reported By:  chris at mysociety dot org
-Status:   Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: n/a
 PHP Version:  4.4.2
 New Comment:

That snapshot (a) doesn't fix the problem -- the FastCGI code is
essentially unchanged since 4.x, though with a bunch of whitespace
noise; and (b) wouldn't help us in any case since it's PHP5 and our
applications are written for PHP4.


Previous Comments:


[2006-01-25 23:51:05] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2006-01-25 21:00:06] chris at mysociety dot org

Description:

When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager
uses this signal to shut down excess dynamic servers. "Graceful" in
this context means that the server must finish handling any outstanding
request and then terminate its connection to the web server. Presently,
PHP does not handle SIGTERM at all in the FastCGI request loop, so that
on receipt of SIGTERM, php aborts, even if half-way through a request.
This typically results in the web server logging "Incomplete headers (0
bytes) received", and returning "500 Internal Server Error" to the
client.

I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.

Reproduce code:
---
Put the following in a .php file:

and set it up to run under FastCGI. Set up a script to request the page
in a loop ("while : ; do wget -O/dev/null -q http://path/to/script ;
done") Then kill the PHP process (pkill php will do this under Linux).
If you catch the script in the sleep, this will result in the client
getting a 500 and the web server logging a message about php failing,
as describe above.

Expected result:

No errors.

Actual result:
--
500 error.





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

#36158 [Opn->Fbk]: SIGTERM is not handled correctly when running as a FastCGI server

[sniper]

 ID:   36158
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chris at mysociety dot org
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: n/a
 PHP Version:  4.4.2
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2006-01-25 21:00:06] chris at mysociety dot org

Description:

When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager
uses this signal to shut down excess dynamic servers. "Graceful" in
this context means that the server must finish handling any outstanding
request and then terminate its connection to the web server. Presently,
PHP does not handle SIGTERM at all in the FastCGI request loop, so that
on receipt of SIGTERM, php aborts, even if half-way through a request.
This typically results in the web server logging "Incomplete headers (0
bytes) received", and returning "500 Internal Server Error" to the
client.

I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.

Reproduce code:
---
Put the following in a .php file:

and set it up to run under FastCGI. Set up a script to request the page
in a loop ("while : ; do wget -O/dev/null -q http://path/to/script ;
done") Then kill the PHP process (pkill php will do this under Linux).
If you catch the script in the sleep, this will result in the client
getting a 500 and the web server logging a message about php failing,
as describe above.

Expected result:

No errors.

Actual result:
--
500 error.





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

#36160 [Fbk->Opn]: include/require ../ relative to current script

[ovdspek at liacs dot nl]

 ID:   36160
 User updated by:  ovdspek at liacs dot nl
 Reported By:  ovdspek at liacs dot nl
-Status:   Feedback
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.1.2
 New Comment:

Last sentence of your quote:
If filename begins with ./ or ../, it is looked only in
include_path relative to the current working directory.


Previous Comments:


[2006-01-25 23:30:12] [EMAIL PROTECTED]

Maybe we're looking to different docs?
-
Files for including are first looked in include_path relative to the
current working directory and then in include_path relative to the
directory of current script. E.g. if your include_path is ., current
working directory is /www/, you included include/a.php and there is
include "b.php" in that file, b.php is first looked in /www/ and then
in /www/include/. If filename begins with ./ or ../, it is looked only
in include_path relative to the current working directory.
-
(c) http://php.net/include




[2006-01-25 23:09:04] ovdspek at liacs dot nl

The fact that the documentation says it's not (it says it's only
relative to the current working directory).



[2006-01-25 23:06:38] [EMAIL PROTECTED]

What makes you think it's not relative to the current script?



[2006-01-25 22:59:22] ovdspek at liacs dot nl

It's not.
And if you're sure it is, could you update the documentation?



[2006-01-25 22:56:56] [EMAIL PROTECTED]

It is.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36160

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

#36160 [Opn->Fbk]: include/require ../ relative to current script

[tony2001]

 ID:   36160
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ovdspek at liacs dot nl
-Status:   Open
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.1.2
 New Comment:

Maybe we're looking to different docs?
-
Files for including are first looked in include_path relative to the
current working directory and then in include_path relative to the
directory of current script. E.g. if your include_path is ., current
working directory is /www/, you included include/a.php and there is
include "b.php" in that file, b.php is first looked in /www/ and then
in /www/include/. If filename begins with ./ or ../, it is looked only
in include_path relative to the current working directory.
-
(c) http://php.net/include



Previous Comments:


[2006-01-25 23:09:04] ovdspek at liacs dot nl

The fact that the documentation says it's not (it says it's only
relative to the current working directory).



[2006-01-25 23:06:38] [EMAIL PROTECTED]

What makes you think it's not relative to the current script?



[2006-01-25 22:59:22] ovdspek at liacs dot nl

It's not.
And if you're sure it is, could you update the documentation?



[2006-01-25 22:56:56] [EMAIL PROTECTED]

It is.



[2006-01-25 22:55:25] ovdspek at liacs dot nl

Description:

http://php.net/include/

> then in include_path relative to the directory of current script. 
> If filename begins with ./ or ../, it is looked only in include_path
relative to the current working directory. 

Could the 'relative to the current script' also be applied to
includes/requires that start with ../?

Reproduce code:
---
include('../common.php');

Expected result:

-

Actual result:
--
-





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

#36161 [Opn->Bgs]: go-pear.bat doesn't install pear.bat

[tony2001]

 ID:   36161
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tony at tonybibbs dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Windows XP
 PHP Version:  5.1.2
 New Comment:

Please report that problem to http://pear.php.net


Previous Comments:


[2006-01-25 23:08:23] tony at tonybibbs dot com

Description:

Installing PEAR from the bundled go-pear.bat that is packaged with the
ZIP package doens't install pear.bat

Reproduce code:
---
1) Unzip to PHP 5.1.2 zip to C:\PHP
2) open DOS command prompt and change directory to c:\PHP
3) at DOS prompt run go-pear.php
4) Choose system wide copy
5) change "Installation base" to c:\PHP\PEAR
6) If needed, change "Path to CLI php.exe" to c:\PHP
7) Hit enter (to install with those settings)
8) Once installed, change directory to C:\PHP\PEAR
9) do a directory listing...I see pear.bat old but not pear.bat
10) use XP search feature to search recursively on c:\PHP for pear.bat
to ensure pear.bat didn't get put somewhere unexpected (didn't work for
me).

Expected result:

I expect to see pear.bat somewhere.

Actual result:
--
No pear.bat produced.





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

#36160 [Fbk->Opn]: include/require ../ relative to current script

[ovdspek at liacs dot nl]

 ID:   36160
 User updated by:  ovdspek at liacs dot nl
 Reported By:  ovdspek at liacs dot nl
-Status:   Feedback
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.1.2
 New Comment:

The fact that the documentation says it's not (it says it's only
relative to the current working directory).


Previous Comments:


[2006-01-25 23:06:38] [EMAIL PROTECTED]

What makes you think it's not relative to the current script?



[2006-01-25 22:59:22] ovdspek at liacs dot nl

It's not.
And if you're sure it is, could you update the documentation?



[2006-01-25 22:56:56] [EMAIL PROTECTED]

It is.



[2006-01-25 22:55:25] ovdspek at liacs dot nl

Description:

http://php.net/include/

> then in include_path relative to the directory of current script. 
> If filename begins with ./ or ../, it is looked only in include_path
relative to the current working directory. 

Could the 'relative to the current script' also be applied to
includes/requires that start with ../?

Reproduce code:
---
include('../common.php');

Expected result:

-

Actual result:
--
-





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

#36161 [NEW]: go-pear.bat doesn't install pear.bat

[tony at tonybibbs dot com]

From: tony at tonybibbs dot com
Operating system: Windows XP
PHP version:  5.1.2
PHP Bug Type: Unknown/Other Function
Bug description:  go-pear.bat doesn't install pear.bat

Description:

Installing PEAR from the bundled go-pear.bat that is packaged with the ZIP
package doens't install pear.bat

Reproduce code:
---
1) Unzip to PHP 5.1.2 zip to C:\PHP
2) open DOS command prompt and change directory to c:\PHP
3) at DOS prompt run go-pear.php
4) Choose system wide copy
5) change "Installation base" to c:\PHP\PEAR
6) If needed, change "Path to CLI php.exe" to c:\PHP
7) Hit enter (to install with those settings)
8) Once installed, change directory to C:\PHP\PEAR
9) do a directory listing...I see pear.bat old but not pear.bat
10) use XP search feature to search recursively on c:\PHP for pear.bat to
ensure pear.bat didn't get put somewhere unexpected (didn't work for me).

Expected result:

I expect to see pear.bat somewhere.

Actual result:
--
No pear.bat produced.

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

#36160 [Opn->Fbk]: include/require ../ relative to current script

[tony2001]

 ID:   36160
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ovdspek at liacs dot nl
-Status:   Open
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.1.2
 New Comment:

What makes you think it's not relative to the current script?


Previous Comments:


[2006-01-25 22:59:22] ovdspek at liacs dot nl

It's not.
And if you're sure it is, could you update the documentation?



[2006-01-25 22:56:56] [EMAIL PROTECTED]

It is.



[2006-01-25 22:55:25] ovdspek at liacs dot nl

Description:

http://php.net/include/

> then in include_path relative to the directory of current script. 
> If filename begins with ./ or ../, it is looked only in include_path
relative to the current working directory. 

Could the 'relative to the current script' also be applied to
includes/requires that start with ../?

Reproduce code:
---
include('../common.php');

Expected result:

-

Actual result:
--
-





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

#36160 [Bgs->Opn]: include/require ../ relative to current script

[ovdspek at liacs dot nl]

 ID:   36160
 User updated by:  ovdspek at liacs dot nl
 Reported By:  ovdspek at liacs dot nl
-Status:   Bogus
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.1.2
 New Comment:

It's not.
And if you're sure it is, could you update the documentation?


Previous Comments:


[2006-01-25 22:56:56] [EMAIL PROTECTED]

It is.



[2006-01-25 22:55:25] ovdspek at liacs dot nl

Description:

http://php.net/include/

> then in include_path relative to the directory of current script. 
> If filename begins with ./ or ../, it is looked only in include_path
relative to the current working directory. 

Could the 'relative to the current script' also be applied to
includes/requires that start with ../?

Reproduce code:
---
include('../common.php');

Expected result:

-

Actual result:
--
-





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

#36160 [Opn->Bgs]: include/require ../ relative to current script

[tony2001]

 ID:   36160
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ovdspek at liacs dot nl
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.1.2
 New Comment:

It is.


Previous Comments:


[2006-01-25 22:55:25] ovdspek at liacs dot nl

Description:

http://php.net/include/

> then in include_path relative to the directory of current script. 
> If filename begins with ./ or ../, it is looked only in include_path
relative to the current working directory. 

Could the 'relative to the current script' also be applied to
includes/requires that start with ../?

Reproduce code:
---
include('../common.php');

Expected result:

-

Actual result:
--
-





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

#36160 [NEW]: include/require ../ relative to current script

[ovdspek at liacs dot nl]

From: ovdspek at liacs dot nl
Operating system: *
PHP version:  5.1.2
PHP Bug Type: Feature/Change Request
Bug description:  include/require ../ relative to current script

Description:

http://php.net/include/

> then in include_path relative to the directory of current script. 
> If filename begins with ./ or ../, it is looked only in include_path
relative to the current working directory. 

Could the 'relative to the current script' also be applied to
includes/requires that start with ../?

Reproduce code:
---
include('../common.php');

Expected result:

-

Actual result:
--
-

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

#36159 [NEW]: Running simple prepared statement SELECT fails (postgres)

[edrozenberg at pobox dot com]

From: edrozenberg at pobox dot com
Operating system: Windows XP SP2
PHP version:  5.1.2
PHP Bug Type: PDO related
Bug description:  Running simple prepared statement SELECT fails (postgres)

Description:

Since upgrading PHP from 5.1.1 to 5.1.2, running a simple prepared
statement SELECT fails.  Error info from print_r($stmt->errorInfo()):
Array ( [0] => 0 )

I have experienced no such problems on Linux 2.4 with PHP 5.1.2 compiled
from source.



Reproduce code:
---
private function dbSel($query, $values)
{   
$stmt = $this->dbh->prepare($query);
if ( ! $stmt->execute($values) )
{   
print_r($stmt->errorInfo());
$this->dbErrorGet($stmt);
return(0);
}
$this->rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
return(1);  
}

--
$query:  "SELECT * \n FROM t_workfile"
$values: array of 

Expected result:

$stmt->execute($values) should return TRUE and
there should be rows that can be fetched

Actual result:
--
$stmt->execute($values) returns false and the print_r($stmt->errorInfo())
statement prints "Array ( [0] => 0 )"

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

#36158 [NEW]: SIGTERM is not handled correctly when running as a FastCGI server

[chris at mysociety dot org]

From: chris at mysociety dot org
Operating system: n/a
PHP version:  4.4.2
PHP Bug Type: *Web Server problem
Bug description:  SIGTERM is not handled correctly when running as a FastCGI 
server

Description:

When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager uses
this signal to shut down excess dynamic servers. "Graceful" in this
context means that the server must finish handling any outstanding request
and then terminate its connection to the web server. Presently, PHP does
not handle SIGTERM at all in the FastCGI request loop, so that on receipt
of SIGTERM, php aborts, even if half-way through a request. This typically
results in the web server logging "Incomplete headers (0 bytes) received",
and returning "500 Internal Server Error" to the client.

I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.

Reproduce code:
---
Put the following in a .php file:

and set it up to run under FastCGI. Set up a script to request the page in
a loop ("while : ; do wget -O/dev/null -q http://path/to/script ; done")
Then kill the PHP process (pkill php will do this under Linux). If you
catch the script in the sleep, this will result in the client getting a
500 and the web server logging a message about php failing, as describe
above.

Expected result:

No errors.

Actual result:
--
500 error.

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

#36148 [Opn->Asn]: unpack("H*hex", $data) is adding an extra character to the end of the string.

[sniper]

 ID:   36148
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andy at advancethermal dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Strings related
-Operating System: WinXP, Win2k3
+Operating System: *
 PHP Version:  5CVS-2006-01-25 (snap)
-Assigned To:  
+Assigned To:  iliaa
 New Comment:

Ilia, verified on Linux too.


Previous Comments:


[2006-01-25 18:53:49] andy at advancethermal dot com

The latest CVS (5.1.3-dev built Jan 25 2006 16:19:11) does not correct
the problem.



[2006-01-25 18:22:14] andy at advancethermal dot com

Upon further testing, I found the following:

CODE:
 $values = array("a", "aa", "aaa", "");
 foreach ($values as $value) {
   $a = pack("H*", $value);
   $b = unpack("H*", $a);
   echo "".$value.": ";
   var_dump($b);
 }

ACTUAL RESULT:
a: array(1) { [1]=> string(3) "a00" }
aa: array(1) { [1]=> string(3) "aa0" }
aaa: array(1) { [1]=> string(5) "aaa00" }
: array(1) { [1]=> string(5) "0" }

EXPECTED RESULT: (produced from PHP 5.0.5)
a: array(1) { [1]=> string(2) "a0" }
aa: array(1) { [1]=> string(2) "aa" }
aaa: array(1) { [1]=> string(4) "aaa0" }
: array(1) { [1]=> string(4) "" }

The release notes for 5.1.2 indicate that the problem was fixed,
however this does not appear to be the case -- or is a new problem. 
All scripts that handle binary data using unpack() had to be modified
with substr($unpackeddata[1], 0, -1) so it would be properly handled.



[2006-01-25 00:32:56] [EMAIL PROTECTED]

See bug #35817.



[2006-01-25 00:10:45] andy at advancethermal dot com

Sorry, reverse the Expected and Actual Results...



[2006-01-25 00:09:59] andy at advancethermal dot com

Description:

unpack("H*hex", $data) is adding an unexpected extra character to the
end of the string. Upgraded to PHP 5.1.2 using Windows Zip package.

Reproduce code:
---
echo "".unpack("H*hex", file_get_contents("c:/php/php.exe"));

Try in 5.0.5 and 5.1.2 -- there is a difference.

Expected result:

...fff90

Actual result:
--
...fff9





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

#36148 [Fbk->Opn]: unpack("H*hex", $data) is adding an extra character to the end of the string.

[andy at advancethermal dot com]

 ID:   36148
 User updated by:  andy at advancethermal dot com
 Reported By:  andy at advancethermal dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Strings related
 Operating System: WinXP, Win2k3
 PHP Version:  5.1.2
 New Comment:

The latest CVS (5.1.3-dev built Jan 25 2006 16:19:11) does not correct
the problem.


Previous Comments:


[2006-01-25 18:44:30] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2006-01-25 18:22:14] andy at advancethermal dot com

Upon further testing, I found the following:

CODE:
 $values = array("a", "aa", "aaa", "");
 foreach ($values as $value) {
   $a = pack("H*", $value);
   $b = unpack("H*", $a);
   echo "".$value.": ";
   var_dump($b);
 }

ACTUAL RESULT:
a: array(1) { [1]=> string(3) "a00" }
aa: array(1) { [1]=> string(3) "aa0" }
aaa: array(1) { [1]=> string(5) "aaa00" }
: array(1) { [1]=> string(5) "0" }

EXPECTED RESULT: (produced from PHP 5.0.5)
a: array(1) { [1]=> string(2) "a0" }
aa: array(1) { [1]=> string(2) "aa" }
aaa: array(1) { [1]=> string(4) "aaa0" }
: array(1) { [1]=> string(4) "" }

The release notes for 5.1.2 indicate that the problem was fixed,
however this does not appear to be the case -- or is a new problem. 
All scripts that handle binary data using unpack() had to be modified
with substr($unpackeddata[1], 0, -1) so it would be properly handled.



[2006-01-25 00:32:56] [EMAIL PROTECTED]

See bug #35817.



[2006-01-25 00:10:45] andy at advancethermal dot com

Sorry, reverse the Expected and Actual Results...



[2006-01-25 00:09:59] andy at advancethermal dot com

Description:

unpack("H*hex", $data) is adding an unexpected extra character to the
end of the string. Upgraded to PHP 5.1.2 using Windows Zip package.

Reproduce code:
---
echo "".unpack("H*hex", file_get_contents("c:/php/php.exe"));

Try in 5.0.5 and 5.1.2 -- there is a difference.

Expected result:

...fff90

Actual result:
--
...fff9





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

#36148 [Opn->Fbk]: unpack("H*hex", $data) is adding an extra character to the end of the string.

[sniper]

 ID:   36148
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andy at advancethermal dot com
-Status:   Open
+Status:   Feedback
-Bug Type: Unknown/Other Function
+Bug Type: Strings related
 Operating System: WinXP, Win2k3
 PHP Version:  5.1.2
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2006-01-25 18:22:14] andy at advancethermal dot com

Upon further testing, I found the following:

CODE:
 $values = array("a", "aa", "aaa", "");
 foreach ($values as $value) {
   $a = pack("H*", $value);
   $b = unpack("H*", $a);
   echo "".$value.": ";
   var_dump($b);
 }

ACTUAL RESULT:
a: array(1) { [1]=> string(3) "a00" }
aa: array(1) { [1]=> string(3) "aa0" }
aaa: array(1) { [1]=> string(5) "aaa00" }
: array(1) { [1]=> string(5) "0" }

EXPECTED RESULT: (produced from PHP 5.0.5)
a: array(1) { [1]=> string(2) "a0" }
aa: array(1) { [1]=> string(2) "aa" }
aaa: array(1) { [1]=> string(4) "aaa0" }
: array(1) { [1]=> string(4) "" }

The release notes for 5.1.2 indicate that the problem was fixed,
however this does not appear to be the case -- or is a new problem. 
All scripts that handle binary data using unpack() had to be modified
with substr($unpackeddata[1], 0, -1) so it would be properly handled.



[2006-01-25 00:32:56] [EMAIL PROTECTED]

See bug #35817.



[2006-01-25 00:10:45] andy at advancethermal dot com

Sorry, reverse the Expected and Actual Results...



[2006-01-25 00:09:59] andy at advancethermal dot com

Description:

unpack("H*hex", $data) is adding an unexpected extra character to the
end of the string. Upgraded to PHP 5.1.2 using Windows Zip package.

Reproduce code:
---
echo "".unpack("H*hex", file_get_contents("c:/php/php.exe"));

Try in 5.0.5 and 5.1.2 -- there is a difference.

Expected result:

...fff90

Actual result:
--
...fff9





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

#36148 [Bgs->Opn]: unpack("H*hex", $data) is adding an extra character to the end of the string.

[andy at advancethermal dot com]

 ID:   36148
 User updated by:  andy at advancethermal dot com
 Reported By:  andy at advancethermal dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: WinXP, Win2k3
 PHP Version:  5.1.2
 New Comment:

Upon further testing, I found the following:

CODE:
 $values = array("a", "aa", "aaa", "");
 foreach ($values as $value) {
   $a = pack("H*", $value);
   $b = unpack("H*", $a);
   echo "".$value.": ";
   var_dump($b);
 }

ACTUAL RESULT:
a: array(1) { [1]=> string(3) "a00" }
aa: array(1) { [1]=> string(3) "aa0" }
aaa: array(1) { [1]=> string(5) "aaa00" }
: array(1) { [1]=> string(5) "0" }

EXPECTED RESULT: (produced from PHP 5.0.5)
a: array(1) { [1]=> string(2) "a0" }
aa: array(1) { [1]=> string(2) "aa" }
aaa: array(1) { [1]=> string(4) "aaa0" }
: array(1) { [1]=> string(4) "" }

The release notes for 5.1.2 indicate that the problem was fixed,
however this does not appear to be the case -- or is a new problem. 
All scripts that handle binary data using unpack() had to be modified
with substr($unpackeddata[1], 0, -1) so it would be properly handled.


Previous Comments:


[2006-01-25 00:32:56] [EMAIL PROTECTED]

See bug #35817.



[2006-01-25 00:10:45] andy at advancethermal dot com

Sorry, reverse the Expected and Actual Results...



[2006-01-25 00:09:59] andy at advancethermal dot com

Description:

unpack("H*hex", $data) is adding an unexpected extra character to the
end of the string. Upgraded to PHP 5.1.2 using Windows Zip package.

Reproduce code:
---
echo "".unpack("H*hex", file_get_contents("c:/php/php.exe"));

Try in 5.0.5 and 5.1.2 -- there is a difference.

Expected result:

...fff90

Actual result:
--
...fff9





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

#36157 [NEW]: Introduce new PDO attribute to automatically close old statement.

[fh at ez dot no]

From: fh at ez dot no
Operating system: Gentoo Linux
PHP version:  5.1.2
PHP Bug Type: Feature/Change Request
Bug description:  Introduce new PDO attribute to automatically close old 
statement.

Description:

Currently when using the MySQL PDO driver, trying to 
execute a second statement while the first one is still 
active yields: 
SQLSTATE[HY000]: General error: 2014 Cannot execute 
queries while other unbuffered queries are active.Consider 
using PDOStatement::fetchAll().  Alternatively, if your 
code is only ever going to run against mysql, you may 
enable query buffering by setting the 
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. 
 
This is all well and good, but quite unhandy since it is 
inconsistent with e.g the postgres driver that does not 
suffer from this problem. It also makes it very hard e.g 
wrap the result of an SQL statement in an iterator since 
the user might break out of it. 
 
I propose to introduce a new attribute to PDO that force 
the drivers to automatically "flush" any open statements 
when a new one is executed. 


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

#36128 [Asn]: Interbase PDO

[michael at bluemoon dot com]

 ID:   36128
 User updated by:  michael at bluemoon dot com
 Reported By:  michael at bluemoon dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Linux/Windows
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

To amend my earlier problem description, it appears that I CAN issue
the SELECT query shown in my previous example successfully.  However,
it appears that I cannot retrieve values from TIMESTAMP-type columns.

If I substitute "SELECT MY_TIMESTAMP_FIELD FROM MY_TABLE" for the query
in my original code, it will execute without throwing an exception, but
the value returned is empty (null).  The result I am expecting is an
integer (Unix timestamp) value.

I don't know if this constitutes a 'bug' or if I am simply not going
about this the right way.  I have tried many of the various
permutations for fetching results as shown in the PDO documentation,
but nothing seems to work.

Is there a way to fetch TIMESTAMP values using the Firebird/Interbase
PDO driver?


Previous Comments:


[2006-01-23 10:51:33] [EMAIL PROTECTED]

Assigned to the maintainer.



[2006-01-23 02:21:25] michael at bluemoon dot com

Description:

Exception thrown when issuing SELECT query using PDO driver 
for Firebird/Interbase. Database Server runs Interbase 7.5.x 
(Linux).

Problem occurs with PHP 5.1.2 running in both Linux/Apache 2 
and Windows 2000/IIS environments.

Tried running PHP alternately with Interbase 6 and 7.5 Run-
time Client Libraries on each platform; same problem.

Native PHP Firebird/Interbase functions (e.g., ibase_connect
(), etc.) functions work fine in same environments used to 
test PDO functions.

Confirmed DSN string used in my PDO connection function is 
correct by testing PDO::ATTR_CONNECTION_STATUS attribute; 
value returned is 1.

Reproduce code:
---
try {
  $dbh = new PDO($dsn, $user, $password, array(
PDO::ATTR_PERSISTENT => true
  ));

  $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

  $stmt = $dbh->prepare("SELECT Count(*) FROM MY_TABLE");
  $stmt->execute();

  $row = $stmt->fetch(PDO::FETCH_NUM);

  $stmt = null;

  echo $row[0];
}
catch (PDOException $e) {
  die $e->getMessage();
}

Expected result:

Should output integer value result from SELECT query to screen

Actual result:
--
Outputs the following error:

SQLSTATE[HY000]: General error: -804 Dynamic SQL Error SQL 
error code = -804 Incorrect values within SQLDA structure





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

#36156 [Opn]: API to Saxon for XSLT 2.0 support

[wouter_hartog at hotmail dot com]

 ID:   36156
 User updated by:  wouter_hartog at hotmail dot com
-Summary:  API to Saxon for XSTL 2.0 support
 Reported By:  wouter_hartog at hotmail dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  5.1.2
 New Comment:

not paying attention; misspelled xslt..


Previous Comments:


[2006-01-25 16:11:51] wouter_hartog at hotmail dot com

Removed 'DOM 3' from Summary in feature description; for me anyway,
it's about XSLT 2.0 support.



[2006-01-25 12:35:12] wouter_hartog at hotmail dot com

Description:

I need to use PHP to process a DOMDocument using an XSLT stylesheet. I
need to use XSLT features from XSLT 2.0 to do this (ex. grouping,
create multiple result documents from one stylesheet).
I believe Saxon is the only open source parser that's out there that
supports XSLT 2.0
Currently, there is no way to call the Saxon functions within PHP 5.1.

Can we somehow create an API/ interface to Saxon?
I know Saxon is Java, but there should be some way to interface with
this?

Thank you!






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

#36156 [Opn]: API to Saxon for XSTL 2.0 support

[wouter_hartog at hotmail dot com]

 ID:   36156
 User updated by:  wouter_hartog at hotmail dot com
-Summary:  API to Saxon for XSTL 2.0 and DOM 3 support
 Reported By:  wouter_hartog at hotmail dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  5.1.2
 New Comment:

Removed 'DOM 3' from Summary in feature description; for me anyway,
it's about XSLT 2.0 support.


Previous Comments:


[2006-01-25 12:35:12] wouter_hartog at hotmail dot com

Description:

I need to use PHP to process a DOMDocument using an XSLT stylesheet. I
need to use XSLT features from XSLT 2.0 to do this (ex. grouping,
create multiple result documents from one stylesheet).
I believe Saxon is the only open source parser that's out there that
supports XSLT 2.0
Currently, there is no way to call the Saxon functions within PHP 5.1.

Can we somehow create an API/ interface to Saxon?
I know Saxon is Java, but there should be some way to interface with
this?

Thank you!






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

#36143 [Opn->Asn]: bindParam on UPDATE error

[tony2001]

 ID:   36143
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lvm99 at mail dot ru
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

>It very actual to fix this error quick because 
Get the sources and fix it yourself if you want it quick.
Otherwise you have to wait for the maintainer to take a look at it and
(maybe) fix it.

Please don't change status of the report, it's assigned to the
maintainer.


Previous Comments:


[2006-01-25 13:26:03] lvm99 at mail dot ru

It very actual to fix this error quick because in ODBC function quote()
is not implemented so We cant use simple sql without parameters :-(

I cant use MSSQL under PDO because it works with OEM charset and dont
implement CHARSET opt handling under Windows :-(
So some Russian characters in CP1251 encoding (which actually used in
Windows filenames, texts, etc.) are absent in cp866 (russian OEM
encoding).
Should I report about MSSQL BUG separately (In manual they recomend
dont use it on windows as useing absolete DBLIB direct access to MSSQL
Server)?



[2006-01-25 13:18:42] [EMAIL PROTECTED]

Assigned to the maintainer.



[2006-01-25 13:04:10] lvm99 at mail dot ru

Here You can fild "working" test base and script
http://converters.ru/PHP_TEST_PDO.ZIP

On my PC script inserts all fields to :id 

and updates all fields to :id



[2006-01-24 14:53:04] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-01-24 14:41:20] lvm99 at mail dot ru

Description:

ODBC connection to MSSQL

$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";
$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

all param's fields (title, name) filling with ':id' value i.e.
'9586850'

If I bind just 'id' as param UPDATE works right
or 
If I bind 'title' and 'name' but not id  UPDATE works right
or
If I connect throut MSSQL interface everything is OK

Reproduce code:
---
//MSSQL Server 2000
$dsn ='server';
$database = 'testbase';
$login ='us';
$password = 'us';
//...
$db = new PDO("odbc:Driver={SQL Server}; Server=".$dsn.";
Database=".$database, $login, $password,  array(PDO::ERRMODE_EXCEPTION
=> true));
//...
$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";

$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

Expected result:

Fields have to be set to 
name = 'new name'
title='updated with params'

Actual result:
--
name = '9586850'
title= '9586850'





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

#36143 [Asn->Opn]: bindParam on UPDATE error

[lvm99 at mail dot ru]

 ID:   36143
 User updated by:  lvm99 at mail dot ru
 Reported By:  lvm99 at mail dot ru
-Status:   Assigned
+Status:   Open
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

It very actual to fix this error quick because in ODBC function quote()
is not implemented so We cant use simple sql without parameters :-(

I cant use MSSQL under PDO because it works with OEM charset and dont
implement CHARSET opt handling under Windows :-(
So some Russian characters in CP1251 encoding (which actually used in
Windows filenames, texts, etc.) are absent in cp866 (russian OEM
encoding).
Should I report about MSSQL BUG separately (In manual they recomend
dont use it on windows as useing absolete DBLIB direct access to MSSQL
Server)?


Previous Comments:


[2006-01-25 13:18:42] [EMAIL PROTECTED]

Assigned to the maintainer.



[2006-01-25 13:04:10] lvm99 at mail dot ru

Here You can fild "working" test base and script
http://converters.ru/PHP_TEST_PDO.ZIP

On my PC script inserts all fields to :id 

and updates all fields to :id



[2006-01-24 14:53:04] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-01-24 14:41:20] lvm99 at mail dot ru

Description:

ODBC connection to MSSQL

$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";
$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

all param's fields (title, name) filling with ':id' value i.e.
'9586850'

If I bind just 'id' as param UPDATE works right
or 
If I bind 'title' and 'name' but not id  UPDATE works right
or
If I connect throut MSSQL interface everything is OK

Reproduce code:
---
//MSSQL Server 2000
$dsn ='server';
$database = 'testbase';
$login ='us';
$password = 'us';
//...
$db = new PDO("odbc:Driver={SQL Server}; Server=".$dsn.";
Database=".$database, $login, $password,  array(PDO::ERRMODE_EXCEPTION
=> true));
//...
$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";

$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

Expected result:

Fields have to be set to 
name = 'new name'
title='updated with params'

Actual result:
--
name = '9586850'
title= '9586850'





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

#36143 [Opn->Asn]: bindParam on UPDATE error

[tony2001]

 ID:   36143
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lvm99 at mail dot ru
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.1.2
-Assigned To:  
+Assigned To:  wez
 New Comment:

Assigned to the maintainer.


Previous Comments:


[2006-01-25 13:04:10] lvm99 at mail dot ru

Here You can fild "working" test base and script
http://converters.ru/PHP_TEST_PDO.ZIP

On my PC script inserts all fields to :id 

and updates all fields to :id



[2006-01-24 14:53:04] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-01-24 14:41:20] lvm99 at mail dot ru

Description:

ODBC connection to MSSQL

$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";
$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

all param's fields (title, name) filling with ':id' value i.e.
'9586850'

If I bind just 'id' as param UPDATE works right
or 
If I bind 'title' and 'name' but not id  UPDATE works right
or
If I connect throut MSSQL interface everything is OK

Reproduce code:
---
//MSSQL Server 2000
$dsn ='server';
$database = 'testbase';
$login ='us';
$password = 'us';
//...
$db = new PDO("odbc:Driver={SQL Server}; Server=".$dsn.";
Database=".$database, $login, $password,  array(PDO::ERRMODE_EXCEPTION
=> true));
//...
$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";

$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

Expected result:

Fields have to be set to 
name = 'new name'
title='updated with params'

Actual result:
--
name = '9586850'
title= '9586850'





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

#36143 [Fbk->Opn]: bindParam on UPDATE error

[lvm99 at mail dot ru]

 ID:   36143
 User updated by:  lvm99 at mail dot ru
 Reported By:  lvm99 at mail dot ru
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.1.2
 New Comment:

Here You can fild "working" test base and script
http://converters.ru/PHP_TEST_PDO.ZIP

On my PC script inserts all fields to :id 

and updates all fields to :id


Previous Comments:


[2006-01-24 14:53:04] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-01-24 14:41:20] lvm99 at mail dot ru

Description:

ODBC connection to MSSQL

$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";
$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

all param's fields (title, name) filling with ':id' value i.e.
'9586850'

If I bind just 'id' as param UPDATE works right
or 
If I bind 'title' and 'name' but not id  UPDATE works right
or
If I connect throut MSSQL interface everything is OK

Reproduce code:
---
//MSSQL Server 2000
$dsn ='server';
$database = 'testbase';
$login ='us';
$password = 'us';
//...
$db = new PDO("odbc:Driver={SQL Server}; Server=".$dsn.";
Database=".$database, $login, $password,  array(PDO::ERRMODE_EXCEPTION
=> true));
//...
$sql = "UPDATE sources_test SET title=:title, name=:name WHERE
id=:id";

$sth = $db->prepare($sql);

$params = array(':title'=>'updated with params', 
':name'=>'new name', ':id'=>'9586850')

$isOk = $sth->execute($params); 

Expected result:

Fields have to be set to 
name = 'new name'
title='updated with params'

Actual result:
--
name = '9586850'
title= '9586850'





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

#36156 [NEW]: API to Saxon for XSTL 2.0 and DOM 3 support

[wouter_hartog at hotmail dot com]

From: wouter_hartog at hotmail dot com
Operating system: All
PHP version:  5.1.2
PHP Bug Type: Feature/Change Request
Bug description:  API to Saxon for XSTL 2.0 and DOM 3 support

Description:

I need to use PHP to process a DOMDocument using an XSLT stylesheet. I
need to use XSLT features from XSLT 2.0 to do this (ex. grouping, create
multiple result documents from one stylesheet).
I believe Saxon is the only open source parser that's out there that
supports XSLT 2.0
Currently, there is no way to call the Saxon functions within PHP 5.1.

Can we somehow create an API/ interface to Saxon?
I know Saxon is Java, but there should be some way to interface with
this?

Thank you!


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

#34552 [Com]: Problems with __FILE__ and realpath()

[gdelafond at aquaray dot com]

 ID:   34552
 Comment by:   gdelafond at aquaray dot com
 Reported By:  mmayer at blastwave dot org
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Solaris 9, MacOSX, netBSD
 PHP Version:  5CVS, 4CVS (2005-09-20)
 New Comment:

I have the same bug on Mac OS X Server 10.4.3 with PHP 4.4.2 
when it is load as apache's module... but not when using the 
cli version.


Previous Comments:


[2005-12-20 15:11:38] a dot l dot w dot kuijper at rug dot nl

I CAN reproduce this bug in __FILE__ and realpath with the CLI version
of PHP 4.4.0 installed on a netBSD 2.0.2 box with  apache 2.0.55.

I did exactly same as mmayer's example above (same files, same chmods)
and got the same issue. 

This bug occurred when installing for Calendar 2. I hope you guys
finally can resolve this mysterious bug.



[2005-09-20 18:43:34] mmayer at blastwave dot org

No, I cannot reproduce this problem with CLI. Even 4.4.0 works in that
case. 

I downloaded php5-latest.tar.gz.

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 20 Sep 2005 16:31:46 GMT
Server: Apache/2.0.54 (Unix) DAV/2 PHP/5.1.0RC2-dev
[...]

Still getting the same results with the apache module that I saw for
4.4.0, so the problem is still there. CLI of 5.1.0RC2 works, however,
just like CLI for 4.4.0.



[2005-09-20 11:02:12] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

See also bug #34514, can you reproduce this with CLI?




[2005-09-19 18:21:07] mmayer at blastwave dot org

Description:

This issue seems to be related to bug #27823, but broader in scope.

Using __FILE__ or realpath() on Solaris 9 SPARC (don't know about x86)
doesn't work as expected if the scripts are located in a user's
home-directory (~username/public_html) and the URL looks like
http://my.example.com/~user/testscript.php. (Don't know if the '~' is
actually causing the problem or if it's something else in this
scenario).

Note that I *do* get the expected results from these scripts if I copy
them to /opt/csw/apache2/share/htdocs/file_bug (i.e. underneath my
web-server's doc-root) and access them through a URL like
http://my.example.com/file_bug/.

In the failure case, __FILE__ returns './' instead of the
full path if it is used in an included file.

realpath() returns an empty string instead of the actual path even
though the file in question exists and the permissions are correct.
(Regardless of whether realpath is used in an included file or
directly.)



Reproduce code:
---
=== file.php: ===
";
require("file2.php");
?>

=== file2.php: ===


=== realpath.php: ===



Expected result:

file.php should print:
/home/markus/public_html/file_bug/file.php
/home/markus/public_html/file_bug/file2.php

realpath.php should print:
realpath: '/home/markus/public_html/file_bug/realpath/test.txt'

Actual result:
--
file.php prints:
/home/markus/public_html/file_bug/file.php
./file2.php

realpath.php prints:
realpath: ''

This is the directory layout (just to show that it's not a permission
problem):
total 14
drwxr-xr-x   3 markus   staff  512 Sep 19 09:10 .
drwxr-xr-x  11 markus   staff 1536 Sep 15 11:07 ..
-rw-r--r--   1 markus   staff   60 Sep 14 13:41 file.php
-rw-r--r--   1 markus   staff   25 Sep 14 13:41 file2.php
drwxr-xr-x   2 markus   staff  512 Sep 19 09:07 realpath
-rw-r--r--   1 markus   staff   67 Sep 19 09:08 realpath.php

./realpath:
total 6
drwxr-xr-x   2 markus   staff  512 Sep 19 09:07 .
drwxr-xr-x   3 markus   staff  512 Sep 19 09:10 ..
-rw-r--r--   1 markus   staff5 Sep 19 09:07 test.txt






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

#36152 [Asn]: problems with curl+ssl and pgsql+ssl in same PHP

[mike]

 ID:   36152
 Updated by:   [EMAIL PROTECTED]
 Reported By:  misiek at dione dot ids dot pl
 Status:   Assigned
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2006-01-25) (snap)
 Assigned To:  mike
 New Comment:

A temporary fix could be to reset

CRYPTO_set_id_callback(php_curl_ssl_id);
CRYPTO_set_locking_callback(php_curl_ssl_lock);

prior calling curl_global_cleanup().


Previous Comments:


[2006-01-25 11:21:41] [EMAIL PROTECTED]

Well, the problem apparently is, that PHP links with lots of libraries
using openssl and even openssl itself.

Some libs like libcurl leave it up to you to define crypto locking
callbacks while obviously libraries like libpq define their own if we
don't.

We'd need openssl crypto locking callbacks for all PHP once and adjust
extensions, which link libraries that would define their own callbacks,
accordingly.

This is just my best bet.





[2006-01-25 11:21:39] misiek at dione dot ids dot pl

There are PQregisterThreadLock() and PQinitSSL() in libpq which allow
to move initialization from libpq to application.



[2006-01-25 11:16:28] [EMAIL PROTECTED]

>curl tries to initialize openssl and then to setup own callbacks.
>pgsql via libpq does the same thing.
"curl" here means ext/curl, while ext/pgsql doesn't set its handlers,
libpq does that.
So personally I don't see a way to handle it, if an *external* library
changes callbacks that were set in PHP extension.
I guess the library should be fixed first.



[2006-01-25 11:11:01] misiek at dione dot ids dot pl

This is how I see it. It's not problem in curl module. It's problem
with callback handling in entire php. openssl allows only single
callback function for entire application. curl and pgsql are just two
things that happen to trigger the problem.

Now curl tries to initialize openssl and then to setup own callbacks.
pgsql via libpq does the same thing. It again initializes already
initialized openssl and setupts own callbacks again.

Every next module which uses openssl callbacks will be problematic
unless initialization and callback handling will be done in upper layer
(php itself) once for all modules. Maybe other solution (like
initializing only once in first module) would also work...



[2006-01-25 10:55:59] [EMAIL PROTECTED]

Mike. this is related to your patch for #33760.
Please take a look.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36152

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

#36152 [Asn]: problems with curl+ssl and pgsql+ssl in same PHP

[mike]

 ID:   36152
 Updated by:   [EMAIL PROTECTED]
-Summary:  threaded version of php has problems with curl+ssl &&
   pgsql+ss at the same time
 Reported By:  misiek at dione dot ids dot pl
 Status:   Assigned
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2006-01-25) (snap)
 Assigned To:  mike
 New Comment:

Well, the problem apparently is, that PHP links with lots of libraries
using openssl and even openssl itself.

Some libs like libcurl leave it up to you to define crypto locking
callbacks while obviously libraries like libpq define their own if we
don't.

We'd need openssl crypto locking callbacks for all PHP once and adjust
extensions, which link libraries that would define their own callbacks,
accordingly.

This is just my best bet.




Previous Comments:


[2006-01-25 11:21:39] misiek at dione dot ids dot pl

There are PQregisterThreadLock() and PQinitSSL() in libpq which allow
to move initialization from libpq to application.



[2006-01-25 11:16:28] [EMAIL PROTECTED]

>curl tries to initialize openssl and then to setup own callbacks.
>pgsql via libpq does the same thing.
"curl" here means ext/curl, while ext/pgsql doesn't set its handlers,
libpq does that.
So personally I don't see a way to handle it, if an *external* library
changes callbacks that were set in PHP extension.
I guess the library should be fixed first.



[2006-01-25 11:11:01] misiek at dione dot ids dot pl

This is how I see it. It's not problem in curl module. It's problem
with callback handling in entire php. openssl allows only single
callback function for entire application. curl and pgsql are just two
things that happen to trigger the problem.

Now curl tries to initialize openssl and then to setup own callbacks.
pgsql via libpq does the same thing. It again initializes already
initialized openssl and setupts own callbacks again.

Every next module which uses openssl callbacks will be problematic
unless initialization and callback handling will be done in upper layer
(php itself) once for all modules. Maybe other solution (like
initializing only once in first module) would also work...



[2006-01-25 10:55:59] [EMAIL PROTECTED]

Mike. this is related to your patch for #33760.
Please take a look.



[2006-01-25 10:55:49] [EMAIL PROTECTED]

See also bug #33760




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36152

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

#36152 [Asn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[misiek at dione dot ids dot pl]

 ID:   36152
 User updated by:  misiek at dione dot ids dot pl
 Reported By:  misiek at dione dot ids dot pl
 Status:   Assigned
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2006-01-25) (snap)
 Assigned To:  mike
 New Comment:

There are PQregisterThreadLock() and PQinitSSL() in libpq which allow
to move initialization from libpq to application.


Previous Comments:


[2006-01-25 11:16:28] [EMAIL PROTECTED]

>curl tries to initialize openssl and then to setup own callbacks.
>pgsql via libpq does the same thing.
"curl" here means ext/curl, while ext/pgsql doesn't set its handlers,
libpq does that.
So personally I don't see a way to handle it, if an *external* library
changes callbacks that were set in PHP extension.
I guess the library should be fixed first.



[2006-01-25 11:11:01] misiek at dione dot ids dot pl

This is how I see it. It's not problem in curl module. It's problem
with callback handling in entire php. openssl allows only single
callback function for entire application. curl and pgsql are just two
things that happen to trigger the problem.

Now curl tries to initialize openssl and then to setup own callbacks.
pgsql via libpq does the same thing. It again initializes already
initialized openssl and setupts own callbacks again.

Every next module which uses openssl callbacks will be problematic
unless initialization and callback handling will be done in upper layer
(php itself) once for all modules. Maybe other solution (like
initializing only once in first module) would also work...



[2006-01-25 10:55:59] [EMAIL PROTECTED]

Mike. this is related to your patch for #33760.
Please take a look.



[2006-01-25 10:55:49] [EMAIL PROTECTED]

See also bug #33760




[2006-01-25 10:42:49] misiek at dione dot ids dot pl

This also happens in php4.4.2.

openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36152

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

#36152 [Asn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[tony2001]

 ID:   36152
 Updated by:   [EMAIL PROTECTED]
 Reported By:  misiek at dione dot ids dot pl
 Status:   Assigned
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2006-01-25) (snap)
 Assigned To:  mike
 New Comment:

>curl tries to initialize openssl and then to setup own callbacks.
>pgsql via libpq does the same thing.
"curl" here means ext/curl, while ext/pgsql doesn't set its handlers,
libpq does that.
So personally I don't see a way to handle it, if an *external* library
changes callbacks that were set in PHP extension.
I guess the library should be fixed first.


Previous Comments:


[2006-01-25 11:11:01] misiek at dione dot ids dot pl

This is how I see it. It's not problem in curl module. It's problem
with callback handling in entire php. openssl allows only single
callback function for entire application. curl and pgsql are just two
things that happen to trigger the problem.

Now curl tries to initialize openssl and then to setup own callbacks.
pgsql via libpq does the same thing. It again initializes already
initialized openssl and setupts own callbacks again.

Every next module which uses openssl callbacks will be problematic
unless initialization and callback handling will be done in upper layer
(php itself) once for all modules. Maybe other solution (like
initializing only once in first module) would also work...



[2006-01-25 10:55:59] [EMAIL PROTECTED]

Mike. this is related to your patch for #33760.
Please take a look.



[2006-01-25 10:55:49] [EMAIL PROTECTED]

See also bug #33760




[2006-01-25 10:42:49] misiek at dione dot ids dot pl

This also happens in php4.4.2.

openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.



[2006-01-25 10:28:17] misiek at dione dot ids dot pl

[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved

Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428

(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)  

this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).

Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36152

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

#36152 [Asn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[misiek at dione dot ids dot pl]

 ID:   36152
 User updated by:  misiek at dione dot ids dot pl
-Summary:  problems with curl+ssl and pgsql+ssl in same PHP
 Reported By:  misiek at dione dot ids dot pl
 Status:   Assigned
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2006-01-25) (snap)
 Assigned To:  mike
 New Comment:

This is how I see it. It's not problem in curl module. It's problem
with callback handling in entire php. openssl allows only single
callback function for entire application. curl and pgsql are just two
things that happen to trigger the problem.

Now curl tries to initialize openssl and then to setup own callbacks.
pgsql via libpq does the same thing. It again initializes already
initialized openssl and setupts own callbacks again.

Every next module which uses openssl callbacks will be problematic
unless initialization and callback handling will be done in upper layer
(php itself) once for all modules. Maybe other solution (like
initializing only once in first module) would also work...


Previous Comments:


[2006-01-25 10:55:59] [EMAIL PROTECTED]

Mike. this is related to your patch for #33760.
Please take a look.



[2006-01-25 10:55:49] [EMAIL PROTECTED]

See also bug #33760




[2006-01-25 10:42:49] misiek at dione dot ids dot pl

This also happens in php4.4.2.

openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.



[2006-01-25 10:28:17] misiek at dione dot ids dot pl

[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved

Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428

(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)  

this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).

Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?



[2006-01-25 10:21:24] misiek at dione dot ids dot pl

Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.

(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0  0xb766b428 in ?? ()
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2  0xb7896440 in int_err_del () at err.c:354
#3  0xb7896deb in ERR_free_strings () at err.c:651
#4  0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5  0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6  0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7  0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-20060

#36140 [Opn->Asn]: mb_encode_mimeheader not working properly

[sniper]

 ID:   36140
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sugan_b at yahoo dot co dot in
-Status:   Open
+Status:   Assigned
 Bug Type: mbstring related
 Operating System: FC3
 PHP Version:  5.1.2
-Assigned To:  
+Assigned To:  hirokawa
 New Comment:

Rui, can you check this out please?


Previous Comments:


[2006-01-24 12:18:54] sugan_b at yahoo dot co dot in

The actual result obtained is:
【問合】
メールのSubjectが8;z2=$1$7$F$7$^$$$^$9



[2006-01-24 12:15:12] sugan_b at yahoo dot co dot in

Description:

 A small part of my application(using only PHP 5.1.2 and Apache 2.2.0)
incorporates mailing functionality which uses
"mb_encode_mimeheader()".I am using ISO-2202-JP charset but Multibyte
characters written in ISO-2202-JP charset code are not sent to the 
receiver correctly.



Reproduce code:
---
index.php





test   
To¡§
Subject¡§ 
   



send.php:









Mail Sending has Completed.




Actual result:
--
Actual Result:
The value of Subject field :
 問合】
メールのSubjectが8;z2=$1$7$F$7$^$$$^$9


I have configured php using --enable-mbstring=all option.





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

#36144 [Opn->Asn]: only one row when using persistent connections and unbuffered queries

[sniper]

 ID:   36144
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at kanariepiet dot com
-Status:   Open
+Status:   Assigned
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  5.1.2
-Assigned To:  
+Assigned To:  andrey
 New Comment:

Assigned to the MySQL support.


Previous Comments:


[2006-01-24 15:30:13] php at kanariepiet dot com

Description:

Assume you have a webserver serving two PHP scripts. Both PHP 
scripts use persistent MySQL database connections. Script one 
uses normal mysql_query calls, script two uses 
mysql_unbuffered_query calls.
Also, script one is doing additional mysql_query calls while 
retrieving the records of the first mysql_query (yes, an sql 
join would be better).

When script two (the one with mysql_unbuffered_query) 
finishes, and script one reuses the persistent database 
connection of script two, the resource identifier in script 
one gets lost after the first loop, resulting in only one 
returned row.
get_resource_type($res) should return 'mysql result', but will 
return 'Unknown'


Reproduce code:
---
Script1.html:
$db = mysql_pconnect ('host', 'user', 'pass');
print ('We are using MySQL thread: '. mysql_thread_id() .'');

$res = mysql_query ("SELECT * FROM temp.documents");  // table with
1200 records

print ('mysql_num_rows() returned '. mysql_num_rows($res) .'');

while ($row = mysql_fetch_assoc ($res)) {
  $res2 = mysql_query ("SELECT * FROM temp.attachments WHERE document =
". $row['id']);
  while ($row2 = mysql_fetch_assoc ($res2))
$row['attachments'][] = $row2;

  $documents[] = $row;
}

print ('number of documents: '. count ($documents));


Script2.html:
$db = mysql_pconnect ('host', 'user', 'pass');
print ('We are using MySQL thread: '. mysql_thread_id() .'');
$res = mysql_unbuffered_query ("SELECT * FROM temp.documents");
while ($row = mysql_fetch_assoc ($res)) {
}

Expected result:

Open script2.html and note the thread id.
Keep opening script1.html until the thread id is the same as 
the one script2 used.
You should see this:
(script2.html)
We are using MySQL thread: 1439

(script1.html)
We are using MySQL thread: 1439
mysql_num_rows() returned 1200
number of documents: 1200

Actual result:
--
However, the output will be:
(script2.html)
We are using MySQL thread: 1439

(script1.html)
We are using MySQL thread: 1439
mysql_num_rows() returned 1200
number of documents: 1





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

#36152 [Opn->Asn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[tony2001]

 ID:   36152
 Updated by:   [EMAIL PROTECTED]
-Summary:  problems with curl+ssl and pgsql+ssl at the same time
 Reported By:  misiek at dione dot ids dot pl
-Status:   Open
+Status:   Assigned
-Bug Type: PostgreSQL related
+Bug Type: cURL related
 Operating System: Linux 2.6/glibc 2.3
 PHP Version:  5CVS-2006-01-25 (snap)
-Assigned To:  
+Assigned To:  mike
 New Comment:

Mike. this is related to your patch for #33760.
Please take a look.


Previous Comments:


[2006-01-25 10:55:49] [EMAIL PROTECTED]

See also bug #33760




[2006-01-25 10:42:49] misiek at dione dot ids dot pl

This also happens in php4.4.2.

openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.



[2006-01-25 10:28:17] misiek at dione dot ids dot pl

[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved

Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428

(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)  

this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).

Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?



[2006-01-25 10:21:24] misiek at dione dot ids dot pl

Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.

(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0  0xb766b428 in ?? ()
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2  0xb7896440 in int_err_del () at err.c:354
#3  0xb7896deb in ERR_free_strings () at err.c:651
#4  0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5  0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6  0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7  0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-200601242130/ext/curl/interface.c:491
#8  0x0822f160 in module_destructor (module=0x8396d40) at
/home/users/arekm/php5.1-200601242130/Zend/zend_API.c:1757
#9  0x08232b98 in zend_hash_apply_deleter (ht=0x8363c20, p=0x8396d10)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:574
#10 0x08232c3c in zend_hash_graceful_reverse_destroy (ht=0x8363c20)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:640
#11 0x0822a61e in zend_shutdown () at
/home/users/arekm/php5.1-200601242130/Zend/zend.c:720
#12 0x081f26cf in php_module_shutdown () at
/home/users/arekm/php5.1-200601242130/main/main.c:1604
#13 0x0828f732 in main (argc=2, argv=0xbfc153a4) at
/home/users/arekm/php5.1-200601242130/sapi/cgi/cgi_main.c:1661
(gd

#36152 [Opn]: problems with curl+ssl and pgsql+ssl at the same time

[sniper]

 ID:   36152
 Updated by:   [EMAIL PROTECTED]
-Summary:  threaded version of php has problems with curl+ssl &&
   pgsql+ss at the same time
 Reported By:  misiek at dione dot ids dot pl
 Status:   Open
 Bug Type: PostgreSQL related
 Operating System: Linux 2.6/glibc 2.3
 PHP Version:  5CVS-2006-01-25 (snap)
 New Comment:

See also bug #33760



Previous Comments:


[2006-01-25 10:42:49] misiek at dione dot ids dot pl

This also happens in php4.4.2.

openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.



[2006-01-25 10:28:17] misiek at dione dot ids dot pl

[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved

Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428

(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)  

this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).

Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?



[2006-01-25 10:21:24] misiek at dione dot ids dot pl

Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.

(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0  0xb766b428 in ?? ()
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2  0xb7896440 in int_err_del () at err.c:354
#3  0xb7896deb in ERR_free_strings () at err.c:651
#4  0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5  0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6  0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7  0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-200601242130/ext/curl/interface.c:491
#8  0x0822f160 in module_destructor (module=0x8396d40) at
/home/users/arekm/php5.1-200601242130/Zend/zend_API.c:1757
#9  0x08232b98 in zend_hash_apply_deleter (ht=0x8363c20, p=0x8396d10)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:574
#10 0x08232c3c in zend_hash_graceful_reverse_destroy (ht=0x8363c20)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:640
#11 0x0822a61e in zend_shutdown () at
/home/users/arekm/php5.1-200601242130/Zend/zend.c:720
#12 0x081f26cf in php_module_shutdown () at
/home/users/arekm/php5.1-200601242130/main/main.c:1604
#13 0x0828f732 in main (argc=2, argv=0xbfc153a4) at
/home/users/arekm/php5.1-200601242130/sapi/cgi/cgi_main.c:1661
(gdb) frame 1
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
430 locking_callback(mode,type,file,line);
(gdb) print locking_callback
$1 = (void (*)(int, int, const c

#35955 [Opn->Bgs]: curl curl_multi_info_read not implemented/working

[sniper]

 ID:   35955
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kevin at tackledesign dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: linux
 PHP Version:  5.1.1
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #27618 


Previous Comments:


[2006-01-10 06:58:01] kevin at tackledesign dot com

Description:

hi,

i would like to formally submit a report regarding the non-implemented
status of the curl_multi_info_read function. the fact that this
function is non implemented is only referenced in a comment in the
documentation. 

given the design of curl_multi_info_read i can see how it might be
complicated to implement (requires the development of an underlying
message queue for the multi interface).
howver, it is important to correct this as the absence of the call
prevents the proper utilization of the curl multi interface. for
example there's no other proper way to tell if a multi request has
completed successfully without this function.

is this something that's scheduled to be corrected?

thanks!
kevin 








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

#36154 [Opn->Bgs]: strange array cursor behavior during array assignment

[sniper]

 ID:   36154
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dmitriy dot buldakov at etadirect dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD 5.3
 PHP Version:  4.4.2
 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




Previous Comments:


[2006-01-25 10:18:14] dmitriy dot buldakov at etadirect dot com

Description:

In case of assignment to a variable another variable that contains an
array with positioned cursor the old array loses cursor position but
array in new variable cathes it.

I think - the initial array ($a) cursor should be untouched.
The copied array ($c) cursor can be copied or reset, but its behavior
should be documented.

Reproduce code:
---


Expected result:

bash-3.00# php test.php
next($a); ...
 current($a) = 2
 current($b) = 1
$c = $a; ...
 current($a) = 2
 current($b) = 1
 current($c) = 1
bash-3.00#

or

bash-3.00# php test.php
next($a); ...
 current($a) = 2
 current($b) = 1
$c = $a; ...
 current($a) = 2
 current($b) = 1
 current($c) = 2
bash-3.00#



Actual result:
--
bash-3.00# php test.php
next($a); ...
 current($a) = 2
 current($b) = 1
$c = $a; ...
 current($a) = 1
 current($b) = 1
 current($c) = 2
bash-3.00#






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

#36152 [Opn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[misiek at dione dot ids dot pl]

 ID:   36152
 User updated by:  misiek at dione dot ids dot pl
 Reported By:  misiek at dione dot ids dot pl
 Status:   Open
 Bug Type: PostgreSQL related
 Operating System: Linux 2.6/glibc 2.3
 PHP Version:  5CVS-2006-01-25 (snap)
 New Comment:

This also happens in php4.4.2.

openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.


Previous Comments:


[2006-01-25 10:28:17] misiek at dione dot ids dot pl

[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved

Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428

(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)  

this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).

Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?



[2006-01-25 10:21:24] misiek at dione dot ids dot pl

Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.

(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0  0xb766b428 in ?? ()
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2  0xb7896440 in int_err_del () at err.c:354
#3  0xb7896deb in ERR_free_strings () at err.c:651
#4  0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5  0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6  0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7  0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-200601242130/ext/curl/interface.c:491
#8  0x0822f160 in module_destructor (module=0x8396d40) at
/home/users/arekm/php5.1-200601242130/Zend/zend_API.c:1757
#9  0x08232b98 in zend_hash_apply_deleter (ht=0x8363c20, p=0x8396d10)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:574
#10 0x08232c3c in zend_hash_graceful_reverse_destroy (ht=0x8363c20)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:640
#11 0x0822a61e in zend_shutdown () at
/home/users/arekm/php5.1-200601242130/Zend/zend.c:720
#12 0x081f26cf in php_module_shutdown () at
/home/users/arekm/php5.1-200601242130/main/main.c:1604
#13 0x0828f732 in main (argc=2, argv=0xbfc153a4) at
/home/users/arekm/php5.1-200601242130/sapi/cgi/cgi_main.c:1661
(gdb) frame 1
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
430 locking_callback(mode,type,file,line);
(gdb) print locking_callback
$1 = (void (*)(int, int, const char *, int)) 0xb766b428
(gdb) print *locking_callback
Cannot access memory at address 0xb766b428
(gdb)

something bad happens with callback function pointer (I guess it's
callback set by libpg.so library)

-

#36155 [NEW]: SoapServer: Possibility to have ONE function that handles all Soap requests

[tschlottke at virtualminds dot de]

From: tschlottke at virtualminds dot de
Operating system: irrelevant
PHP version:  5.1.2
PHP Bug Type: Feature/Change Request
Bug description:  SoapServer: Possibility to have ONE function that handles all 
Soap requests

Description:

It would be neat to implmentent a method to register ONE function that
handles everything, no matter which function the client called.
This function could then do (for example) Session/Authentification-related
stuff.
The soapserver should forward all parameters(as array) aswell as the
function name called by the client(and maybe the namespace) and return all
values returned by this function. So this function could handle it all.
Would be a neat thing...


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

#36152 [Opn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[misiek at dione dot ids dot pl]

 ID:   36152
 User updated by:  misiek at dione dot ids dot pl
 Reported By:  misiek at dione dot ids dot pl
 Status:   Open
 Bug Type: PostgreSQL related
 Operating System: Linux 2.6/glibc 2.3
 PHP Version:  5CVS-2006-01-25 (snap)
 New Comment:

[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved

Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428

(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)  

this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).

Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?


Previous Comments:


[2006-01-25 10:21:24] misiek at dione dot ids dot pl

Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.

(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0  0xb766b428 in ?? ()
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2  0xb7896440 in int_err_del () at err.c:354
#3  0xb7896deb in ERR_free_strings () at err.c:651
#4  0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5  0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6  0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7  0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-200601242130/ext/curl/interface.c:491
#8  0x0822f160 in module_destructor (module=0x8396d40) at
/home/users/arekm/php5.1-200601242130/Zend/zend_API.c:1757
#9  0x08232b98 in zend_hash_apply_deleter (ht=0x8363c20, p=0x8396d10)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:574
#10 0x08232c3c in zend_hash_graceful_reverse_destroy (ht=0x8363c20)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:640
#11 0x0822a61e in zend_shutdown () at
/home/users/arekm/php5.1-200601242130/Zend/zend.c:720
#12 0x081f26cf in php_module_shutdown () at
/home/users/arekm/php5.1-200601242130/main/main.c:1604
#13 0x0828f732 in main (argc=2, argv=0xbfc153a4) at
/home/users/arekm/php5.1-200601242130/sapi/cgi/cgi_main.c:1661
(gdb) frame 1
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
430 locking_callback(mode,type,file,line);
(gdb) print locking_callback
$1 = (void (*)(int, int, const char *, int)) 0xb766b428
(gdb) print *locking_callback
Cannot access memory at address 0xb766b428
(gdb)

something bad happens with callback function pointer (I guess it's
callback set by libpg.so library)



[2006-01-25 10:07:54] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this 

#36145 [Bgs]: ldap_bind() timeouts

[brage at zoo dot uib dot no]

 ID:   36145
 User updated by:  brage at zoo dot uib dot no
 Reported By:  brage at zoo dot uib dot no
 Status:   Bogus
 Bug Type: LDAP related
 Operating System: FreeBSD 5.4-STABLE AMD64
 PHP Version:  4.4.2
 New Comment:

Definitely not file descriptors (which has a limit > 1). 

And it is not reproducible on all systems. The other bug report
(#34892) is from a similar system to mine, suggesting that the bug
might be a 64bit-related issue.


Previous Comments:


[2006-01-25 10:16:06] [EMAIL PROTECTED]

It's either openldap bug or you're just running out of file-descriptors
on your server. Definately not PHP bug. (I can't even reproduce it
myself)




[2006-01-25 10:09:24] brage at zoo dot uib dot no

Sorry, the bug-reproducing code should have $i <= 30, not 20.



[2006-01-25 10:07:25] brage at zoo dot uib dot no

The problem seems to be related to the number of open files. 
The following script will use all available cpu and never finish if run
with the cli version. If I reduce the number of open files to 20 it will
bind sucessfully immediately.



It is likely that the bug is in openldap and not in PHP. AFAICS it is
the call to ldap_bind_s() in php-4.4.2/ext/ldap/ldap.c which never
finishes.



[2006-01-24 17:32:05] brage at zoo dot uib dot no

That does not seem likely.

It is reproducible with an apache process serving no other request than
a single request to the test page. Also the number of virtualhosts
needed to reproduce the problem is fairly low ( < 15, but with own log
files). 

A ktrace of the request gives a 1.3GB kdump file with 8 million 
select()-calls before the request dies from a timeout after 60 seconds.



[2006-01-24 16:20:53] [EMAIL PROTECTED]

It's just your server hitting it's limit..



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36145

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

#36152 [Fbk->Opn]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[misiek at dione dot ids dot pl]

 ID:   36152
 User updated by:  misiek at dione dot ids dot pl
 Reported By:  misiek at dione dot ids dot pl
-Status:   Feedback
+Status:   Open
 Bug Type: PostgreSQL related
 Operating System: Linux 2.6/glibc 2.3
 PHP Version:  5CVS-2006-01-25 (snap)
 New Comment:

Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.

(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html


Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0  0xb766b428 in ?? ()
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2  0xb7896440 in int_err_del () at err.c:354
#3  0xb7896deb in ERR_free_strings () at err.c:651
#4  0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5  0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6  0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7  0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-200601242130/ext/curl/interface.c:491
#8  0x0822f160 in module_destructor (module=0x8396d40) at
/home/users/arekm/php5.1-200601242130/Zend/zend_API.c:1757
#9  0x08232b98 in zend_hash_apply_deleter (ht=0x8363c20, p=0x8396d10)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:574
#10 0x08232c3c in zend_hash_graceful_reverse_destroy (ht=0x8363c20)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:640
#11 0x0822a61e in zend_shutdown () at
/home/users/arekm/php5.1-200601242130/Zend/zend.c:720
#12 0x081f26cf in php_module_shutdown () at
/home/users/arekm/php5.1-200601242130/main/main.c:1604
#13 0x0828f732 in main (argc=2, argv=0xbfc153a4) at
/home/users/arekm/php5.1-200601242130/sapi/cgi/cgi_main.c:1661
(gdb) frame 1
#1  0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
430 locking_callback(mode,type,file,line);
(gdb) print locking_callback
$1 = (void (*)(int, int, const char *, int)) 0xb766b428
(gdb) print *locking_callback
Cannot access memory at address 0xb766b428
(gdb)

something bad happens with callback function pointer (I guess it's
callback set by libpg.so library)


Previous Comments:


[2006-01-25 10:07:54] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2006-01-25 09:12:59] misiek at dione dot ids dot pl

Description:

php5.1-200601242130
./configure --prefix=/tmp/qq --enable-maintainer-zts
--with-pgsql=shared,/usr --with-curl=shared,/usr

postgresql client libs 8.1.2 (compiled with --enable-thread-safety and
--with-openssl)

curl 7.15.1 also compiled with openssl

[EMAIL PROTECTED] 16112]# cat /tmp/qq/lib/php.ini
extension=curl.so
extension=pgsql.so

(note that extensions loading order matters)

The problems seems to be in thread safety locking code somewhere in
openssl and this combination triggers it (now the bug could be in php
curl module, pgsql client library, openssl... don't know yet).

Reproduce code:
---
[EMAIL PROTECTED] 16112]# cat config.php

[EMAIL PROTECTED] 16112]# /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html

Memory fault


The host is important - there needs to be postgresql server  which
accepts SSL connections (this one accepts only ssl connections).
user/password/dbname doesn't matter.

Expected result:

No segfault.

Actual result:
--
Memory fault





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

#36154 [NEW]: strange array cursor behavior during array assignment

[dmitriy dot buldakov at etadirect dot com]

From: dmitriy dot buldakov at etadirect dot com
Operating system: FreeBSD 5.3
PHP version:  4.4.2
PHP Bug Type: Scripting Engine problem
Bug description:  strange array cursor behavior during array assignment

Description:

In case of assignment to a variable another variable that contains an
array with positioned cursor the old array loses cursor position but array
in new variable cathes it.

I think - the initial array ($a) cursor should be untouched.
The copied array ($c) cursor can be copied or reset, but its behavior
should be documented.

Reproduce code:
---


Expected result:

bash-3.00# php test.php
next($a); ...
 current($a) = 2
 current($b) = 1
$c = $a; ...
 current($a) = 2
 current($b) = 1
 current($c) = 1
bash-3.00#

or

bash-3.00# php test.php
next($a); ...
 current($a) = 2
 current($b) = 1
$c = $a; ...
 current($a) = 2
 current($b) = 1
 current($c) = 2
bash-3.00#



Actual result:
--
bash-3.00# php test.php
next($a); ...
 current($a) = 2
 current($b) = 1
$c = $a; ...
 current($a) = 1
 current($b) = 1
 current($c) = 2
bash-3.00#


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

#36145 [Opn->Bgs]: ldap_bind() timeouts

[sniper]

 ID:   36145
 Updated by:   [EMAIL PROTECTED]
 Reported By:  brage at zoo dot uib dot no
-Status:   Open
+Status:   Bogus
 Bug Type: LDAP related
 Operating System: FreeBSD 5.4-STABLE AMD64
 PHP Version:  4.4.2
 New Comment:

It's either openldap bug or you're just running out of file-descriptors
on your server. Definately not PHP bug. (I can't even reproduce it
myself)



Previous Comments:


[2006-01-25 10:09:24] brage at zoo dot uib dot no

Sorry, the bug-reproducing code should have $i <= 30, not 20.



[2006-01-25 10:07:25] brage at zoo dot uib dot no

The problem seems to be related to the number of open files. 
The following script will use all available cpu and never finish if run
with the cli version. If I reduce the number of open files to 20 it will
bind sucessfully immediately.



It is likely that the bug is in openldap and not in PHP. AFAICS it is
the call to ldap_bind_s() in php-4.4.2/ext/ldap/ldap.c which never
finishes.



[2006-01-24 17:32:05] brage at zoo dot uib dot no

That does not seem likely.

It is reproducible with an apache process serving no other request than
a single request to the test page. Also the number of virtualhosts
needed to reproduce the problem is fairly low ( < 15, but with own log
files). 

A ktrace of the request gives a 1.3GB kdump file with 8 million 
select()-calls before the request dies from a timeout after 60 seconds.



[2006-01-24 16:20:53] [EMAIL PROTECTED]

It's just your server hitting it's limit..



[2006-01-24 16:18:49] brage at zoo dot uib dot no

Description:

I am experiencing exactly the same problem as described in 
Bug #34892 (Process hang on LDAP operations).

The system is
 - FreeBSD 5.4-STABLE AMD64 (SMP)
 - OpenLDAP Client libraries 2.2.30
 - PHP 4.4.2 

On ldap_bind() the system goes into a select-loop and uses all
available cpu until timeout.

The problem is only present when I have many open virtual servers, if I
reduce the number of active virtualhosts the problem disappears.  The
CLI version also works fine.


Reproduce code:
---
See bug #34892.







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

#36153 [Opn->Bgs]: preg_match parse errors with correct expressions

[sniper]

 ID:   36153
 Updated by:   [EMAIL PROTECTED]
 Reported By:  a dot steponavicius at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Regular Expressions
 Operating System: Windows XP
 PHP Version:  4.4.2
 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.




Previous Comments:


[2006-01-25 10:04:06] a dot steponavicius at gmail dot com

Description:

preg_match returns errors while parsing some correct expressions, o
dies with apache if there is more such "errors"...

The same behaviour is both in 4.4.2 and 5.1.2

Reproduce code:
---
$expressions = array(
1 => '/^ (?: . ){0,6} $/ix',
2 => '/^ (?: . ){0, 6} $/ix',
3 => '/^ (?: . ) {0, 6} $/ix',
4 => '/^ (?: . ) {0,6} $/ix',
);

foreach ($expressions as $key => $exp) {
echo $key, ": ";
var_dump(preg_match($exp, '2', $pat));
var_dump($pat);
echo "\n";
}


Expected result:

1: int(1)
array(1) {
  [0]=>
  string(1) "2"
}

2: int(1)
array(1) {
  [0]=>
  string(1) "2"
}

3: int(1)
array(1) {
  [0]=>
  string(1) "2"
}

4: int(1)
array(1) {
  [0]=>
  string(1) "2"
}


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

2: int(0)
array(0) {
}

3: int(0)
array(0) {
}

4: Warning: preg_match(): Compilation failed: internal error: code
overflow at offs
et 17 in D:\Inetpub\Projects\.php5\testrx.php on line 12
bool(false)
array(0) {
}
... or sometimes there is no 4: ... and apache dies...





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

#36145 [Opn]: ldap_bind() timeouts

[brage at zoo dot uib dot no]

 ID:   36145
 User updated by:  brage at zoo dot uib dot no
 Reported By:  brage at zoo dot uib dot no
 Status:   Open
 Bug Type: LDAP related
 Operating System: FreeBSD 5.4-STABLE AMD64
 PHP Version:  4.4.2
 New Comment:

Sorry, the bug-reproducing code should have $i <= 30, not 20.


Previous Comments:


[2006-01-25 10:07:25] brage at zoo dot uib dot no

The problem seems to be related to the number of open files. 
The following script will use all available cpu and never finish if run
with the cli version. If I reduce the number of open files to 20 it will
bind sucessfully immediately.



It is likely that the bug is in openldap and not in PHP. AFAICS it is
the call to ldap_bind_s() in php-4.4.2/ext/ldap/ldap.c which never
finishes.



[2006-01-24 19:28:06] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-01-24 17:32:05] brage at zoo dot uib dot no

That does not seem likely.

It is reproducible with an apache process serving no other request than
a single request to the test page. Also the number of virtualhosts
needed to reproduce the problem is fairly low ( < 15, but with own log
files). 

A ktrace of the request gives a 1.3GB kdump file with 8 million 
select()-calls before the request dies from a timeout after 60 seconds.



[2006-01-24 16:20:53] [EMAIL PROTECTED]

It's just your server hitting it's limit..



[2006-01-24 16:18:49] brage at zoo dot uib dot no

Description:

I am experiencing exactly the same problem as described in 
Bug #34892 (Process hang on LDAP operations).

The system is
 - FreeBSD 5.4-STABLE AMD64 (SMP)
 - OpenLDAP Client libraries 2.2.30
 - PHP 4.4.2 

On ldap_bind() the system goes into a select-loop and uses all
available cpu until timeout.

The problem is only present when I have many open virtual servers, if I
reduce the number of active virtualhosts the problem disappears.  The
CLI version also works fine.


Reproduce code:
---
See bug #34892.







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

#36152 [Opn->Fbk]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[tony2001]

 ID:   36152
 Updated by:   [EMAIL PROTECTED]
 Reported By:  misiek at dione dot ids dot pl
-Status:   Open
+Status:   Feedback
 Bug Type: PostgreSQL related
 Operating System: Linux 2.6/glibc 2.3
 PHP Version:  5CVS-2006-01-25 (snap)
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:


[2006-01-25 09:12:59] misiek at dione dot ids dot pl

Description:

php5.1-200601242130
./configure --prefix=/tmp/qq --enable-maintainer-zts
--with-pgsql=shared,/usr --with-curl=shared,/usr

postgresql client libs 8.1.2 (compiled with --enable-thread-safety and
--with-openssl)

curl 7.15.1 also compiled with openssl

[EMAIL PROTECTED] 16112]# cat /tmp/qq/lib/php.ini
extension=curl.so
extension=pgsql.so

(note that extensions loading order matters)

The problems seems to be in thread safety locking code somewhere in
openssl and this combination triggers it (now the bug could be in php
curl module, pgsql client library, openssl... don't know yet).

Reproduce code:
---
[EMAIL PROTECTED] 16112]# cat config.php

[EMAIL PROTECTED] 16112]# /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html

Memory fault


The host is important - there needs to be postgresql server  which
accepts SSL connections (this one accepts only ssl connections).
user/password/dbname doesn't matter.

Expected result:

No segfault.

Actual result:
--
Memory fault





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

#36145 [Fbk->Opn]: ldap_bind() timeouts

[brage at zoo dot uib dot no]

 ID:   36145
 User updated by:  brage at zoo dot uib dot no
 Reported By:  brage at zoo dot uib dot no
-Status:   Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: FreeBSD 5.4-STABLE AMD64
 PHP Version:  4.4.2
 New Comment:

The problem seems to be related to the number of open files. 
The following script will use all available cpu and never finish if run
with the cli version. If I reduce the number of open files to 20 it will
bind sucessfully immediately.



It is likely that the bug is in openldap and not in PHP. AFAICS it is
the call to ldap_bind_s() in php-4.4.2/ext/ldap/ldap.c which never
finishes.


Previous Comments:


[2006-01-24 19:28:06] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2006-01-24 17:32:05] brage at zoo dot uib dot no

That does not seem likely.

It is reproducible with an apache process serving no other request than
a single request to the test page. Also the number of virtualhosts
needed to reproduce the problem is fairly low ( < 15, but with own log
files). 

A ktrace of the request gives a 1.3GB kdump file with 8 million 
select()-calls before the request dies from a timeout after 60 seconds.



[2006-01-24 16:20:53] [EMAIL PROTECTED]

It's just your server hitting it's limit..



[2006-01-24 16:18:49] brage at zoo dot uib dot no

Description:

I am experiencing exactly the same problem as described in 
Bug #34892 (Process hang on LDAP operations).

The system is
 - FreeBSD 5.4-STABLE AMD64 (SMP)
 - OpenLDAP Client libraries 2.2.30
 - PHP 4.4.2 

On ldap_bind() the system goes into a select-loop and uses all
available cpu until timeout.

The problem is only present when I have many open virtual servers, if I
reduce the number of active virtualhosts the problem disappears.  The
CLI version also works fine.


Reproduce code:
---
See bug #34892.







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

#36139 [Opn->Fbk]: Problem with oci_parse()

[tony2001]

 ID:   36139
 Updated by:   [EMAIL PROTECTED]
 Reported By:  max__payne at list dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Win 2003 Server Standard R2
 PHP Version:  5.1.2


Previous Comments:


[2006-01-25 08:25:22] max__payne at list dot ru

I use client Oracle 9i client libraries. They are not compatible with
PHP 5.1.2?



[2006-01-24 20:15:39] [EMAIL PROTECTED]

>Oracle Call Interface
I'm sure it's OCI, but I was asking about its version.
I mean are you using Oracle Instant Client _10_ or old libraries from
Oracle _8i_ or _9i_ ?

Short version: install Instant Client and see if it works.



[2006-01-24 19:26:58] max__payne at list dot ru

Oracle Call Interface

Revision: 1.257.2.8



[2006-01-24 12:28:45] [EMAIL PROTECTED]

What version of client libraries are you using?



[2006-01-24 12:13:13] max__payne at list dot ru

Description:

Calls to oci_parse() sometimes hangs up server. Oracle server is Oracle
8.1.7.0.0 with update to 8.1.7.2.1 running under Windows 2000 Server SP
4 (P IV CPU).

With older versions of PHP (5.0.5) this code works fine.

Reproduce code:
---
$connection = oci_connect($username, $password, $tns_name);

$st = oci_parse($connection, "SELECT * FROM nextmonthbirthdays");

oci_execute($st, OCI_DEFAULT);

$res = oci_fetch_assoc($st);

while($res)
{
echo $res{"FIO"} . "";
$res = oci_fetch_assoc($st);
}

oci_free_statement($st);
oci_close($connection);

Expected result:

List of names one per line expected, instead see nothing while script
is running.

Actual result:
--
Script above has no output, it hangs up server.





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

#36153 [NEW]: preg_match parse errors with correct expressions

[a dot steponavicius at gmail dot com]

From: a dot steponavicius at gmail dot com
Operating system: Windows XP
PHP version:  4.4.2
PHP Bug Type: *Regular Expressions
Bug description:  preg_match parse errors with correct expressions

Description:

preg_match returns errors while parsing some correct expressions, o dies
with apache if there is more such "errors"...

The same behaviour is both in 4.4.2 and 5.1.2

Reproduce code:
---
$expressions = array(
1 => '/^ (?: . ){0,6} $/ix',
2 => '/^ (?: . ){0, 6} $/ix',
3 => '/^ (?: . ) {0, 6} $/ix',
4 => '/^ (?: . ) {0,6} $/ix',
);

foreach ($expressions as $key => $exp) {
echo $key, ": ";
var_dump(preg_match($exp, '2', $pat));
var_dump($pat);
echo "\n";
}


Expected result:

1: int(1)
array(1) {
  [0]=>
  string(1) "2"
}

2: int(1)
array(1) {
  [0]=>
  string(1) "2"
}

3: int(1)
array(1) {
  [0]=>
  string(1) "2"
}

4: int(1)
array(1) {
  [0]=>
  string(1) "2"
}


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

2: int(0)
array(0) {
}

3: int(0)
array(0) {
}

4: Warning: preg_match(): Compilation failed: internal error: code
overflow at offs
et 17 in D:\Inetpub\Projects\.php5\testrx.php on line 12
bool(false)
array(0) {
}
... or sometimes there is no 4: ... and apache dies...

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

#36152 [NEW]: threaded version of php has problems with curl+ssl && pgsql+ss at the same time

[misiek at dione dot ids dot pl]

From: misiek at dione dot ids dot pl
Operating system: Linux 2.6/glibc 2.3
PHP version:  5CVS-2006-01-25 (snap)
PHP Bug Type: PostgreSQL related
Bug description:  threaded version of php has problems with curl+ssl && 
pgsql+ss at the same time

Description:

php5.1-200601242130
./configure --prefix=/tmp/qq --enable-maintainer-zts
--with-pgsql=shared,/usr --with-curl=shared,/usr

postgresql client libs 8.1.2 (compiled with --enable-thread-safety and
--with-openssl)

curl 7.15.1 also compiled with openssl

[EMAIL PROTECTED] 16112]# cat /tmp/qq/lib/php.ini
extension=curl.so
extension=pgsql.so

(note that extensions loading order matters)

The problems seems to be in thread safety locking code somewhere in
openssl and this combination triggers it (now the bug could be in php curl
module, pgsql client library, openssl... don't know yet).

Reproduce code:
---
[EMAIL PROTECTED] 16112]# cat config.php

[EMAIL PROTECTED] 16112]# /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html

Memory fault


The host is important - there needs to be postgresql server  which accepts
SSL connections (this one accepts only ssl connections).
user/password/dbname doesn't matter.

Expected result:

No segfault.

Actual result:
--
Memory fault

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