Bug #54189 [Opn-Bgs]: foreach changes array values after iterating by reference followed by foreach

[scottmac]

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

 ID: 54189
 Updated by: scott...@php.net
 Reported by:phazei at gmail dot com
 Summary:foreach changes array values after iterating by
 reference followed by foreach
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   RHEL 5.6
 PHP Version:5.2.17
 Block user comment: N
 Private report: N

 New Comment:

This is on the foreach manual page.



Between the two foreach loops, $value is a reference to the last entry
in the 

array.



When the second loop starts you then start assigning new values to
$value which 

reference the last element of the array.


Previous Comments:

[2011-03-08 08:11:41] phazei at gmail dot com

Description:

(I searched through the bug reports and found some foreach pointer
issues, but 

none related to this)



If I simply go through an array with a referenced value like so:

foreach ($array as $value) {  }



And then go through it again, not referenced, like so:

foreach ($array as $value) {  }



Both times using the same variable $value, then during the second
foreach, the 

second to the last value is actually copied over the last value changing
the 

array.



If I simply use $value2 there is no issue.

Test script:
---
$array = array('a','b','c','d','e');

echo '1) '.print_r($array, true).'br';

foreach ($array as $value) {  }

echo '2) '.print_r($array, true).'br 3) ';

foreach ($array as $key = $value) { echo [$key] = $value ; }

echo 'br 4) '.print_r($array, true).'br';

Expected result:

1) Array ( [0] = a [1] = b [2] = c [3] = d [4] =
e ) 

2) Array ( [0] = a [1] = b [2] = c [3] = d [4] =
e ) 

3) [0] = a [1] = b [2] = c [3] = d [4] = e 

4) Array ( [0] = a [1] = b [2] = c [3] = d [4] =
e ) 

Actual result:
--
1) Array ( [0] = a [1] = b [2] = c [3] = d [4] =
e ) 

2) Array ( [0] = a [1] = b [2] = c [3] = d [4] =
e ) 

3) [0] = a [1] = b [2] = c [3] = d [4] = d 

4) Array ( [0] = a [1] = b [2] = c [3] = d [4] =
d ) 






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

Bug #54181 [Bgs]: MySQLi doesn't always reuse persistent link inside same script

[scottmac]

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

 ID: 54181
 Updated by: scott...@php.net
 Reported by:carsten_sttgt at gmx dot de
 Summary:MySQLi doesn't always reuse persistent link inside
 same script
 Status: Bogus
 Type:   Bug
 Package:MySQLi related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

The problem with using the same connection twice is that with unbuffered
results 

you can't run more than query at once. MySQLi only puts a connection up
for availability until after its done with it.



MySQL should behave the same but is probably affected by the new_link
parameter 

which returned the same connection if all the parameters matched. It
wasn't 

persistance just an optimization that caused more confusion than
anything else.


Previous Comments:

[2011-03-07 19:53:34] carsten_sttgt at gmx dot de

 This is working as expected, persistent connections are only

 re-used if they're no longer in use by another script.



OK, with another Script you also mean the same script. Just to
recapitulate:

| ?php

| $con1 = mysqli_connect('p:localhost', 'foo', '');

| $con2 = mysqli_connect('p:localhost', 'foo', '');

| ?



$con1 is already in use, so $con2 will results in a second connection.



If this is the expected behavior, why is this script:

| ?php

| $con1 = new PDO(

| 'mysql:host=localhost',

| 'foo', '',

| array(PDO::ATTR_PERSISTENT = true)

| );

| $con2 = new PDO(

| 'mysql:host=localhost',

| 'foo', '',

| array(PDO::ATTR_PERSISTENT = true)

| );

| ?



or

| ?php

| $con1 = mysql_pconnect('localhost', 'foo', '');

| $con2 = mysql_pconnect('localhost', 'foo', '');

| ?



resulting in 1 connection? $con1 is already in use, but $con2 is using
the same connection as $1.


[2011-03-07 17:28:31] scott...@php.net

This doesn't have anything to do with persistent connections, with
mysql_connect() 

if you open a connection with the same parameters it won't return a new
link 

unless you set the 4th parameter to true.



This is working as expected, persistent connections are only re-used if
they're no 

longer in use by another script.


[2011-03-07 15:10:49] carsten_sttgt at gmx dot de

Description:

If I open an existing persistent link a second (or 3rd, ...) time inside
the same script, MySQLi is only reusing the existent link if I have
explicitly closed the link before. At the moment it's always creating a
new link.



With MySQL it's working as expected.



 

Test script:
---
?php

$con1 = mysqli_connect('p:localhost', 'foo', '');

var_dump($con1-thread_id);

$con2 = mysqli_connect('p:localhost', 'foo', '');

var_dump($con2-thread_id);

mysqli_close($con1);

mysqli_close($con2);



echo ---\n;



$con3 = mysqli_connect('p:localhost', 'bar', '');

var_dump($con3-thread_id);

mysqli_close($con3);

$con4 = mysqli_connect('p:localhost', 'bar', '');

var_dump($con4-thread_id);

mysqli_close($con4);



echo ===\n;



$con5 = mysql_pconnect('localhost', 'foo', '');

var_dump(mysql_thread_id($con5));

$con6 = mysql_pconnect('localhost', 'foo', '');

var_dump(mysql_thread_id($con6));

mysql_close($con5);

mysql_close($con6);



echo ---\n;



$con7 = mysql_pconnect('localhost', 'bar', '');

var_dump(mysql_thread_id($con7));

mysql_close($con7);

$con8 = mysql_pconnect('localhost', 'bar', '');

var_dump(mysql_thread_id($con8));

mysql_close($con8);



?



Expected result:

int(1)

int(1)

---

int(2)

int(2)

===

int(3)

int(3)

---

int(4)

int(4)

Actual result:
--
int(1)

int(2)

---

int(3)

int(3)

===

int(4)

int(4)

---

int(5)

int(5)






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

Bug #54181 [Bgs]: MySQLi doesn't always reuse persistent link inside same script

[carsten_sttgt at gmx dot de]

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

 ID: 54181
 User updated by:carsten_sttgt at gmx dot de
 Reported by:carsten_sttgt at gmx dot de
 Summary:MySQLi doesn't always reuse persistent link inside
 same script
 Status: Bogus
 Type:   Bug
 Package:MySQLi related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

 MySQL should behave the same but is probably affected

 by the new_link parameter



Ok, this one I can understand (I think...)



| $con1 = mysqli_connect('localhost', 'foo', '');

| $con2 = mysqli_connect('localhost', 'foo', '');

is resulting in 2 connections, so:

| $con1 = mysqli_connect('p:localhost', 'foo', '');

| $con2 = mysqli_connect('p:localhost', 'foo', '');

is also resulting in 2 connections.



| $con1 = mysql_connect('localhost', 'foo', '');

| $con2 = mysql_connect('localhost', 'foo', '');

is resulting in 1 connections, so:

| $con1 = mysql_pconnect('localhost', 'foo', '');

| $con2 = mysql_pconnect('localhost', 'foo', '');

is also resulting in 1 connections.

(no new_link)





But what's with PDO_MySQL?

| $con1 = new PDO('mysql:host=localhost', 'foo', '');

| $con2 = new PDO('mysql:host=localhost', 'foo', '');

is resulting in 2 connections, but:



| $con1 = new PDO('mysql:host=localhost', 'foo', '',

| array(PDO::ATTR_PERSISTENT = true));

| $con2 = new PDO('mysql:host=localhost', 'foo', '',

| array(PDO::ATTR_PERSISTENT = true));

is resulting in 1 connections.



Thus this bug should be assigned to PDO/PDO_MySQL? (Maybe as change
request).

Or as Doc for MySQLi/PDO how this is working in detail.





BTW:

I think there should be consequent behavior how thinks are working. Or a
better description how a extension is working.  For mysql_pconnect there
is an exact description:

| First, when connecting, the function would first try to find a
(persistent)

| link that's already open with the same host, username and password. If
one

| is found, an identifier for it will be returned instead of opening a
new

| connection.


Previous Comments:

[2011-03-08 09:34:39] scott...@php.net

The problem with using the same connection twice is that with unbuffered
results 

you can't run more than query at once. MySQLi only puts a connection up
for availability until after its done with it.



MySQL should behave the same but is probably affected by the new_link
parameter 

which returned the same connection if all the parameters matched. It
wasn't 

persistance just an optimization that caused more confusion than
anything else.


[2011-03-07 19:53:34] carsten_sttgt at gmx dot de

 This is working as expected, persistent connections are only

 re-used if they're no longer in use by another script.



OK, with another Script you also mean the same script. Just to
recapitulate:

| ?php

| $con1 = mysqli_connect('p:localhost', 'foo', '');

| $con2 = mysqli_connect('p:localhost', 'foo', '');

| ?



$con1 is already in use, so $con2 will results in a second connection.



If this is the expected behavior, why is this script:

| ?php

| $con1 = new PDO(

| 'mysql:host=localhost',

| 'foo', '',

| array(PDO::ATTR_PERSISTENT = true)

| );

| $con2 = new PDO(

| 'mysql:host=localhost',

| 'foo', '',

| array(PDO::ATTR_PERSISTENT = true)

| );

| ?



or

| ?php

| $con1 = mysql_pconnect('localhost', 'foo', '');

| $con2 = mysql_pconnect('localhost', 'foo', '');

| ?



resulting in 1 connection? $con1 is already in use, but $con2 is using
the same connection as $1.


[2011-03-07 17:28:31] scott...@php.net

This doesn't have anything to do with persistent connections, with
mysql_connect() 

if you open a connection with the same parameters it won't return a new
link 

unless you set the 4th parameter to true.



This is working as expected, persistent connections are only re-used if
they're no 

longer in use by another script.


[2011-03-07 15:10:49] carsten_sttgt at gmx dot de

Description:

If I open an existing persistent link a second (or 3rd, ...) time inside
the same script, MySQLi is only reusing the existent link if I have
explicitly closed the link before. At the moment it's always creating a
new link.



With MySQL it's working as expected.



 

Test script:
---
?php

$con1 = mysqli_connect('p:localhost', 'foo', '');

var_dump($con1-thread_id);

$con2 = mysqli_connect('p:localhost', 'foo', '');

var_dump($con2-thread_id);

mysqli_close($con1);

mysqli_close($con2);



echo ---\n;



$con3 = mysqli_connect('p:localhost', 'bar', '');

var_dump($con3-thread_id);

[PHP-BUG] Bug #54190 [NEW]: mysqli-insert_id will return zero after mysqli-get_warnings()

[srwang at pixnet dot tw]

From: 
Operating system: FreeBSD 7.3
PHP version:  5.3.5
Package:  MySQLi related
Bug Type: Bug
Bug description:mysqli-insert_id will return zero after mysqli-get_warnings()

Description:

mysqli-insert_id will return zero after mysqli-get_warnings()

(In PHP 5.3.3, it is ok)

Test script:
---
$link = new mysqli('localhost', '', '', 'test');



$link-query(DROP TABLE `abcde`);

$link-query(CREATE TABLE abcde (`id` int(11) NOT NULL AUTO_INCREMENT,
`value` VARCHAR(255) NOT NULL, PRIMARY KEY (`id`)););

$link-query(INSERT INTO abcde SET `id` = 0);



print_r($link-get_warnings());

echo $link-insert_id . \n;

echo $link-query(SELECT LAST_INSERT_ID() AS `id`)-fetch_object()-id .
\n;

Expected result:

mysqli_warning Object

(

[message] = Field 'value' doesn't have a default value

[sqlstate] = HY000

[errno] = 1364

)

1

1

Actual result:
--
mysqli_warning Object

(

[message] = Field 'value' doesn't have a default value

[sqlstate] = HY000

[errno] = 1364

)

0

1



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

Bug #49625 [Com]: spl_autoload and case sensitivity

[simon at systemparadox dot co dot uk]

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

 ID: 49625
 Comment by: simon at systemparadox dot co dot uk
 Reported by:jo at feuersee dot de
 Summary:spl_autoload and case sensitivity
 Status: Bogus
 Type:   Bug
 Package:SPL related
 Operating System:   Linux
 PHP Version:5.3.0
 Block user comment: N
 Private report: N

 New Comment:

Why is this bug marked as bogus?

Even if spl_autoload itself isn't fixed, at the very least a version
that does it correctly could be added (although in this case it
seriously could just be fixed by trying the correct case first).



Implementing one in PHP is all very well, but that means that it's
non-standard and likely incompatible with what each programmer might
expect. It's also slower.


Previous Comments:

[2009-09-23 07:11:47] sjo...@php.net

Trying both lowercased and original case could solve this without
breaking backwards compatibility. However, you could as well supply your
own autoload function defined in PHP to solve this.


[2009-09-22 19:37:20] jo at feuersee dot de

The reason here is that is spl_autoload becomes case

sensitive, it will break scripts which depend on spl_autoload being

case insensitive.



spl_autoload() was introduced in PHP 5.1.2 which is case sensitive
concerning class names. This implies that if an operation on an unknown
class is done, spl_autoload() is triggered and executed with the case
sensitive name of the class.

Thus we have 4 different possibilities:



1) The class name all lower case, the file containing the class
definition is all lower case (eg. $foo = system::bar(); system.php)



This will work independent wether spl_autoload() is lowercasing or not,
since all is lowercased. 

Note that if the class defined in the file system.php is actually named
System it wouldn't have ever worked because the class system is still
not defined, which would trigger an error.



2) The class name all lower case, the file containing the class
definition is uppercased (eg. $foo = system::bar(); System.php)



This wouldn't work anymore on file systems which are case sensitive if
spl_autoload() would skip lowercasing.



Note that this would only have worked if the file system is case
insensitive and the class definition in System.php would define a class
system. 



3) The class name contains upper case letters, the file containing the
class definition is lowercased (eg. $foo = System::bar(); system.php)



This is what currently isn't working at all but would work at least for
case insensitive file systems if lowercasing would be dropped.



Note that if the class defined in the file system.php is actually named
system it wouldn't have ever worked because the class System is still
not defined.



4) The class name contains upper case letters, the file containing the
class definition is uppercased (eg. $foo = System::bar(); System.php)



This is what should (and would) work, but currently doesn't.





Conclusion:



The only problem might be (2):



Class name: sample

Filename: Sample.php

Class definition in Sample.php: class sample { ... }

Note: this does work on case insensitive file systems only.



I really can't see any reason for maintaining the Worse is better
principle here, I really doubt that there is much code around relying on
the tolowercase feature/bug of spl_autoload().



As a compromise I propose the following:

1) spl_autoload() additionally tries to find a file _not_ lowercased. 2)
Throw a E_DEPRECATED in case the filename had to be lowercased to
match.



Until then:

I really don't know why this lowercasing thing was introduced into
slp_autoload() to begin with, all it ever did was preventing classes to
be named with upper case letters on file systems which are case
sensitive. In other words: the only compatibility issue is that code
which currently works on platforms like Windows only would suddenly work
on UN*X like platforms too.



Pls confirm if this is the compatibility issue you are talking about.


[2009-09-22 16:22:22] sjo...@php.net

Thank you for your bug report.



Wontfix means: we agree that there is a bug, but there are reasons not
to fix it. The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being case
insensitive.


[2009-09-22 16:01:15] jo at feuersee dot de

Description:

This is basically the same as PHP bug #48129.



Yes, I have read it won't fix



My opinion on this is won't fix is not an option because it _is_ a bug
and not fixing bugs does not work:



1) It is common practice in OO languages (including PHP) to give classes

Bug #53795 [Com]: Connect Error from MySqli (mysqlnd) when using SSL

[carsten_sttgt at gmx dot de]

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

 ID: 53795
 Comment by: carsten_sttgt at gmx dot de
 Reported by:dave dot kelly at dawkco dot com
 Summary:Connect Error from MySqli (mysqlnd) when using SSL
 Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Windows
 PHP Version:5.3.5
 Assigned To:kalle
 Block user comment: N
 Private report: N

 New Comment:

@ kalle

 as MYSQLND_SSL_SUPPORTED is not defined on Windows,

 its a simple one line fix that I will commit shortly



How is MySQLnd SSL support related to ZLIB? I think you should move the
AC_DEFINE below the if PHP_ZLIB block, like this is done in the *nix
configure (means always enabled).



Of course, in my opinion both (windows/*nix) is wrong. At the moment
phpinfo is always showing you SSL = supported, even PHP is build
without OpenSSL and SSL connection (through the streams) can't work.



So, what is SSL = supported telling me?

a) mysqlnd is build with SSL support.

-- In this case there should be a configure switch like
--enable-mysqlnd-ssl (or only define this, if PHP is also build with
OpenSSL)



b) MySQLnd SSL connections are currently working in this installation.

-- in this case this should be a runtime setting and not a compiler
define. (because a shared OpenSSL extension maybe loaded or not)


Previous Comments:

[2011-02-05 10:54:52] dave dot kelly at dawkco dot com

OK, the patch works.  Mysqli (mysqlnd build) on Windows can now use
SSL/TLS connections.  Thank you!


[2011-01-31 13:51:40] ka...@php.net

This bug has been fixed in SVN.

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




[2011-01-31 13:47:31] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307880
Log: Fixed bug #53795 (Connect Error from MySqli (mysqlnd) when using
SSL)


[2011-01-30 11:35:52] ka...@php.net

I got an idea why this fails, as MYSQLND_SSL_SUPPORTED is not defined on
Windows, its a simple one line fix that I will commit shortly


[2011-01-29 09:36:07] dave dot kelly at dawkco dot com

FYI (you probably already know):  there are currently no SSL/TLS options
available to be set with the mysqli::options method.



I tried using the mysqli::ssl_set method as follows, but it didn't work
either (same connect error):



$mysqli-ssl_set(NULL, // key file path or NULL

 NULL, // cert file path or NULL

 'C:/ssl/ca-cert.pem', // ca cert file path or NULL

 NULL, // capath directory or NULL

 'DHE-RSA-AES256-SHA'); // cipher or NULL



Also, tried the following (no luck):



$mysqli-ssl_set('C:/ssl/key.pem', // key file path or NULL

 'C:/ssl/cert.pem', // cert file path or NULL

 'C:/ssl/ca-cert.pem', // ca cert file path or NULL

 NULL, // capath directory or NULL

 NULL); // cipher or NULL



As noted before, these all work with PHP 5.2.17, but not with PHP
5.3.5.



A fix for mysqlnd would be great because trying to do a custom build on
Windows with mysqlnd disabled has become a real ordeal.




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/bug.php?id=53795


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

[PHP-BUG] Bug #54191 [NEW]: Give me solution for a bug......

[tejasmaster11 at gmail dot com]

From: 
Operating system: XP
PHP version:  5.3.6RC2
Package:  *Configuration Issues
Bug Type: Bug
Bug description:Give me solution for a bug..

Description:

---

From manual page: http://www.php.net/function.ini-set#Examples

---



Test script:
---
?php



if (!ini_get('display_errors')) {

ini_set('display_errors', 1);

}



echo ini_get('display_errors');

?

Expected result:

1

Actual result:
--
11

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

[PHP-BUG] Bug #54194 [NEW]: wrong behavior with non existent certificate

[carsten_sttgt at gmx dot de]

From: 
Operating system: 
PHP version:  Irrelevant
Package:  MySQLi related
Bug Type: Bug
Bug description:wrong behavior with non existent certificate

Description:

Maybe this is a bug in MySQLnd and not MySQLi, so feel free to change the
affected package. With libmysql this is working as expected.







Test script:
---
?php

error_reporting(E_ALL);



$con1 = mysqli_init();



mysqli_ssl_set($con1,

nonexistent,

nonexistent,

nonexistent,

null, null

);





if (!mysqli_real_connect($con1, 'localhost', 'foo', '')){

printf(Connect Error: %s\n, mysqli_connect_error());

exit;

}

printf(Connected.\n);



$res = mysqli_query($con1, SHOW STATUS LIKE 'Ssl_cipher');

printf(SSL-Connection: %d\n, (bool) end(mysqli_fetch_row($res)));

?



Expected result:

SSL error: Unable to get certificate from 'nonexistent'



Warning: mysqli_real_connect(): (HY000/2026): SSL connection error in

C:\Users\Public\Documents\htdocs\test.php on line 21

Connect Error: SSL connection error



Actual result:
--
Connected.

SSL-Connection: 1



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

[PHP-BUG] Bug #54195 [NEW]: The notorious Call to a member function .. on a non-object fatal error

[landeholm at gmail dot com]

From: 
Operating system: Irrelevant
PHP version:  5.3.5
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:The notorious Call to a member function .. on a non-object 
fatal error

Description:

I had this problem a million times. It's very easy to accidentally invoke
Fatal Error: Call to a member function .. on a non-object. The problem is
that this triggers an error so fatal that it can't even be caught by the
shutdown function. This recently gave me a huge headache in a production
system where an obscure bug where a variable contain null which was called
on invoked a silent crash. It's a headache because I run everything in a
framework with great wrappers for error handling/detection that are suppose
to send me an email when obscure bugs get tripped. This obviously doesn't
work when the PHP commits seppuku and explodes.



I don't see any reason for this error to be that fatal. Sure, keep the
error fatal but at least allow the shutdown function to catch it.

Test script:
---
\register_shutdown_function(function(){

$e = \error_get_last();

if (!\is_null($e))

die('Houston we have a problem: ' . \print_r($e, true));

});



$hello = null;

$hello-bar();

Expected result:

Houston we have a problem: Array

(

...

Actual result:
--
Fatal error: Call to a member function bar() on a non-object in ...

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

Bug #53967 [Opn-Ana]: ReflectionClass::isCloneable reports false positives

[felipe]

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

 ID: 53967
 Updated by: fel...@php.net
 Reported by:whatthejeff at gmail dot com
 Summary:ReflectionClass::isCloneable reports false positives
-Status: Open
+Status: Analyzed
 Type:   Bug
 Package:Reflection related
 PHP Version:trunk-SVN-2011-02-09 (snap)
 Block user comment: N
 Private report: N



Previous Comments:

[2011-02-11 22:48:53] whatthejeff at gmail dot com

Yeah, I actually realized ReflectionClass::isCloneable wouldn't work for
SplFileObject and SplTempFileObject when I was looking at the
implementation for 

SplFileObject.


[2011-02-11 22:43:57] fel...@php.net

SplFileObject and SplTempFileObject are exception because the way as it
was coded, there is a logic behinds it to decide if it is clonable or
not...


[2011-02-09 07:47:43] sebast...@php.net

I do not think that this is limited to SplFileObject. Have a look at



sb@thinkpad ~ % php
-r'print_r(array_filter(get_declared_classes(),function($n){$c=new
ReflectionClass($n);return $c-isCloneable();}));'

Array

(

[0] = stdClass

[3] = Closure

[4] = DateTime

[5] = DateTimeZone

[6] = DateInterval

[7] = DatePeriod

[8] = LibXMLError

[13] = DOMStringList

[14] = DOMNameList

[15] = DOMImplementationList

[16] = DOMImplementationSource

[17] = DOMImplementation

[18] = DOMNode

[19] = DOMNameSpaceNode

[20] = DOMDocumentFragment

[21] = DOMDocument

[22] = DOMNodeList

[23] = DOMNamedNodeMap

[24] = DOMCharacterData

[25] = DOMAttr

[26] = DOMElement

[27] = DOMText

[28] = DOMComment

[29] = DOMTypeinfo

[30] = DOMUserDataHandler

[31] = DOMDomError

[32] = DOMErrorHandler

[33] = DOMLocator

[34] = DOMConfiguration

[35] = DOMCdataSection

[36] = DOMDocumentType

[37] = DOMNotation

[38] = DOMEntity

[39] = DOMEntityReference

[40] = DOMProcessingInstruction

[41] = DOMStringExtend

[42] = DOMXPath

[43] = finfo

[70] = EmptyIterator

[72] = ArrayObject

[73] = ArrayIterator

[74] = RecursiveArrayIterator

[75] = SplFileInfo

[76] = DirectoryIterator

[77] = FilesystemIterator

[78] = RecursiveDirectoryIterator

[79] = GlobIterator

[80] = SplFileObject

[81] = SplTempFileObject

[82] = SplDoublyLinkedList

[83] = SplQueue

[84] = SplStack

[86] = SplMinHeap

[87] = SplMaxHeap

[88] = SplPriorityQueue

[89] = SplFixedArray

[90] = SplObjectStorage

[91] = MultipleIterator

[93] = PDO

[94] = PDOStatement

[97] = Reflection

[107] = __PHP_Incomplete_Class

[108] = php_user_filter

[109] = Directory

[110] = SimpleXMLElement

[111] = SimpleXMLIterator

[112] = SoapClient

[113] = SoapVar

[114] = SoapServer

[116] = SoapParam

[117] = SoapHeader

[119] = Phar

[120] = PharData

[121] = PharFileInfo

[124] = XMLReader

)



I am sure that there are more false positives in there.


[2011-02-09 04:30:41] whatthejeff at gmail dot com

Description:

ReflectionClass::isCloneable returns true on some classes which are not
actually 

cloneable.

Test script:
---
?php



$reflection = new ReflectionClass('SplFileObject');

var_dump($reflection-isCloneable());



$reflection = new ReflectionClass('SplTempFileObject');

var_dump($reflection-isCloneable());



?

Expected result:

bool(false)

bool(false)

Actual result:
--
bool(true)

bool(true)






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

Bug #53626 [Opn-Fbk]: Segmentation Fault

[felipe]

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

 ID: 53626
 Updated by: fel...@php.net
 Reported by:bionoren at letu dot edu
 Summary:Segmentation Fault
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Mac OS X 10.6.5
 PHP Version:5.3.4
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

  http://windows.php.net/snapshots/




Previous Comments:

[2010-12-29 01:07:56] bionoren at letu dot edu

?php

class test {

public function __construct(array $values) {

print_r($values);

}



public static function getInstance($db) {

$result = $db-query(SELECT * from test);

return new test($result-fetchArray(SQLITE3_ASSOC));

}

}



$db = new SQLite3(test.sqlite, SQLITE3_OPEN_READWRITE |
SQLITE3_OPEN_CREATE);

$db-query(CREATE TABLE test (foo, bar));



test::getInstance($db);

print done;

?


[2010-12-29 00:02:51] fel...@php.net

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

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

Please avoid embedding huge scripts into the report.




[2010-12-28 23:57:04] bionoren at letu dot edu

Description:

./configure '--prefix=/usr' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--sysconfdir=/private/etc'
'--with-apxs2=/usr/sbin/apxs' '--enable-cli'
'--with-config-file-path=/etc' '--with-libxml-dir=/usr'
'--with-openssl=/usr' '--with-kerberos=/usr' '--with-zlib=/usr'
'--enable-bcmath' '--with-bz2=/usr' '--enable-calendar'
'--with-curl=/usr' '--enable-exif' '--enable-ftp' '--with-gd'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--enable-gd-native-ttf' '--with-ldap=/usr' '--with-ldap-sasl=/usr'
'--enable-mbstring' '--enable-mbregex' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd'
'--with-mysql-sock=/var/mysql/mysql.sock' '--with-iodbc=/usr'
'--enable-shmop' '--with-snmp=/usr' '--enable-soap' '--enable-sockets'
'--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-xmlrpc'
'--with-iconv-dir=/usr' '--with-xsl=/usr' '--enable-zend-multibyte'
'--enable-zip' '--with-pcre-regex' --disable-cgi --enable-debug
--with-freetype-dir=/usr/local --with-mcrypt

Expected result:

An error message describing whatever bad situation I created for PHP

Actual result:
--
Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: 13 at address: 0x

0x0001015bed85 in zend_llist_del_element (l=0x1022aade8,
element=0x102099818, compare=0x101095ad6
php_sqlite3_compare_stmt_free) at
/downloads/php/php-5.3.4/Zend/zend_llist.c:97

97  next = current-next;

(gdb) bt

#0  0x0001015bed85 in zend_llist_del_element (l=0x1022aade8,
element=0x102099818, compare=0x101095ad6
php_sqlite3_compare_stmt_free) at
/downloads/php/php-5.3.4/Zend/zend_llist.c:97

#1  0x000101095d6d in php_sqlite3_stmt_object_free_storage
(object=0x1023132b0) at
/downloads/php/php-5.3.4/ext/sqlite3/sqlite3.c:1936

#2  0x0001015fe9fd in zend_objects_store_free_object_storage
(objects=0x101c95e38) at
/downloads/php/php-5.3.4/Zend/zend_objects_API.c:92

#3  0x0001015b8ff1 in shutdown_executor () at
/downloads/php/php-5.3.4/Zend/zend_execute_API.c:302

#4  0x0001015cc9f3 in zend_deactivate () at
/downloads/php/php-5.3.4/Zend/zend.c:890

#5  0x0001015493d4 in php_request_shutdown (dummy=0x0) at
/downloads/php/php-5.3.4/main/main.c:1633

#6  0x0001016b948b in php_apache_request_dtor (r=0x1009b1ea8) at
/downloads/php/php-5.3.4/sapi/apache2handler/sapi_apache2.c:509

#7  0x0001016b9c63 in php_handler (r=0x1009b1ea8) at
/downloads/php/php-5.3.4/sapi/apache2handler/sapi_apache2.c:681

#8  0x000121db in ap_run_handler ()

#9  0x00012aba in ap_invoke_handler ()

#10 0x00010002f738 in ap_process_request ()

#11 0x00010002bfa9 in ap_process_http_connection ()

#12 0x000100013737 in ap_run_process_connection ()

#13 0x000100013bd1 in ap_process_connection ()

#14 0x0001000363f2 in child_main ()

#15 0x0001000364dc in make_child ()

#16 0x000100036aaf in ap_mpm_run ()

#17 0x0001a821 in main ()

(gdb)

Bug #54191 [Opn]: Give me solution for a bug......

[dtajchreber]

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

 ID: 54191
 Updated by: dtajchre...@php.net
 Reported by:tejasmaster11 at gmail dot com
 Summary:Give me solution for a bug..
 Status: Open
 Type:   Bug
 Package:*Configuration Issues
 Operating System:   XP
 PHP Version:5.3.6RC2
 Block user comment: N
 Private report: N

 New Comment:

This looks like the example off the ini_set page... you sure the page
you're 

running is exactly what's below? 



http://codepad.viper-7.com/z63S3W


Previous Comments:

[2011-03-08 13:23:21] tejasmaster11 at gmail dot com

Description:

---

From manual page: http://www.php.net/function.ini-set#Examples

---



Test script:
---
?php



if (!ini_get('display_errors')) {

ini_set('display_errors', 1);

}



echo ini_get('display_errors');

?

Expected result:

1

Actual result:
--
11






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

Bug #50189 [Opn-Bgs]: [PATCH] - unicode byte order difference between SPARC and x86

[felipe]

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

 ID: 50189
 Updated by: fel...@php.net
 Reported by:yoarvi at gmail dot com
 Summary:[PATCH] - unicode byte order difference between
 SPARC and x86
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Unicode Engine related
 Operating System:   Solaris 10 (SPARC)
 PHP Version:6SVN-2009-11-16 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

php6 code is dead.


Previous Comments:

[2009-11-17 10:51:24] yoarvi at gmail dot com

Updated patch using WORDS_BIGENDIAN (suggested by christopher dot jones
at oracle dot com)



Index: ext/standard/php_smart_str.h

===

--- ext/standard/php_smart_str.h(revision 290471)

+++ ext/standard/php_smart_str.h(working copy)

@@ -86,10 +86,17 @@

smart_str_appendc_ex((dest), (c), 0)



 /* appending of a single UTF-16 code unit (2 byte)*/

+#ifndef WORDS_BIGENDIAN

 #define smart_str_append2c(dest, c) do {   \

smart_str_appendc_ex((dest), (c0xFF), 0);  \

smart_str_appendc_ex((dest), (c0xFF00 ? c8 : '\0'), 0); 
\

 } while (0)

+#else

+#define smart_str_append2c(dest, c) do {   \

+   smart_str_appendc_ex((dest), (c0xFF00 ? c8 : '\0'), 0); 
\

+   smart_str_appendc_ex((dest), (c0xFF), 0);  \

+} while (0)

+#endif



 #define smart_str_free(s) \

smart_str_free_ex((s), 0)


[2009-11-16 16:35:08] yoarvi at gmail dot com

ext/sqlite3/libsqlite/sqlite3.c uses

#if defined(i386) || defined(__i386__) || defined(_M_IX86)\

 || defined(__x86_64) ||
defined(__x86_64__)





Is that better?


[2009-11-16 13:07:50] tokul at users dot sourceforge dot net

If is not #if (defined(i386) || defined(__i386__) || defined(_X86_))

 vs others.



It is little endian vs big endian. I suspect that code should not assume
that all other archs are big endian.


[2009-11-16 12:20:44] yoarvi at gmail dot com

Description:

zspprintf() incorrectly represents strings/chars as unicode characters
on Solaris (SPARC).



There are byte ordering differences for unicode representations between
x86 and SPARC:



For example, the unicode representation (i've grouped them in sets of
2chars) of '/tmp' on x86 is

'/''\0' 't''\0' 'm''\0' 'p''\0'



and on SPARC it is

'\0''/' '\0''t' '\0''m' '\0''p'



http://marc.info/?l=php-internalsm=125811990106419w=2 has some more
details.



the problem seems to be in the smart_str_append2c macro that
zspprintf()/xbuf_format_converter end up using.



The following patch fixes the problem:

Index: ext/standard/php_smart_str.h

===

--- ext/standard/php_smart_str.h(revision 290471)

+++ ext/standard/php_smart_str.h(working copy)

@@ -86,10 +86,17 @@

smart_str_appendc_ex((dest), (c), 0)



 /* appending of a single UTF-16 code unit (2 byte)*/

+#if (defined(i386) || defined(__i386__) || defined(_X86_))

 #define smart_str_append2c(dest, c) do {   \

smart_str_appendc_ex((dest), (c0xFF), 0);  \

smart_str_appendc_ex((dest), (c0xFF00 ? c8 : '\0'), 0); 
\

 } while (0)

+#else

+#define smart_str_append2c(dest, c) do {   \

+   smart_str_appendc_ex((dest), (c0xFF00 ? c8 : '\0'), 0); 
\

+   smart_str_appendc_ex((dest), (c0xFF), 0);  \

+} while (0)

+#endif



 #define smart_str_free(s) \

smart_str_free_ex((s), 0)





Reproduce code:
---
% sapi/cli/php
ext/spl/tests/DirectoryIterator_getBasename_basic_test.php

Expected result:

getBasename_test

Actual result:
--
php goes into an infinite loop






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

[PHP-BUG] Bug #54197 [NEW]: [PATH=] sections incompatibility with user_ini.filename set to null

[julientld at free dot fr]

From: 
Operating system: Windows Server 2003 SP2
PHP version:  5.3.5
Package:  PHP options/info functions
Bug Type: Bug
Bug description:[PATH=] sections incompatibility with user_ini.filename set to 
null

Description:

Hello,



My configuration :



Windows Server 2003 SP2

IIS 6.0

PHP 5.3.5 VC9 x86 NTS

FastCGI 1.5

WinCache 1.1



Same problem seen with IIS 5.1 under Windows XP SP3.

Test script:
---
In the php.ini file (production based) :





[PHP]



;I do not want users to set their own configuration file so I disable the
below option (set to null)

user_ini.filename =



;I want to set my own simple PATH sections like that

[PATH=D:/www/]

upload_max_filesize = 5M

Expected result:

I expect to get no error

Actual result:
--
But all the php script I open return the following :





FastCGI Error

The FastCGI Handler was unable to process the request. 





Error Details:



•The FastCGI process exited unexpectedly

•Error Number: -1073741819 (0xc005).

•Error Description: Unknown Error

HTTP Error 500 - Server Error.

Internet Information Services (IIS)



I obtain no error if I remove the [PATH=] section or set a filename to
user_ini.filename

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

Bug #54197 [Opn-Fbk]: [PATH=] sections incompatibility with user_ini.filename set to null

[pajoye]

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

 ID: 54197
 Updated by: paj...@php.net
 Reported by:julientld at free dot fr
 Summary:[PATH=] sections incompatibility with
 user_ini.filename set to null
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Windows Server 2003 SP2
 PHP Version:5.3.5
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

What says the error log? Or is it actually a crash?


Previous Comments:

[2011-03-08 19:25:07] julientld at free dot fr

Description:

Hello,



My configuration :



Windows Server 2003 SP2

IIS 6.0

PHP 5.3.5 VC9 x86 NTS

FastCGI 1.5

WinCache 1.1



Same problem seen with IIS 5.1 under Windows XP SP3.

Test script:
---
In the php.ini file (production based) :





[PHP]



;I do not want users to set their own configuration file so I disable
the below option (set to null)

user_ini.filename =



;I want to set my own simple PATH sections like that

[PATH=D:/www/]

upload_max_filesize = 5M

Expected result:

I expect to get no error

Actual result:
--
But all the php script I open return the following :





FastCGI Error

The FastCGI Handler was unable to process the request. 





Error Details:



•The FastCGI process exited unexpectedly

•Error Number: -1073741819 (0xc005).

•Error Description: Unknown Error

HTTP Error 500 - Server Error.

Internet Information Services (IIS)



I obtain no error if I remove the [PATH=] section or set a filename to
user_ini.filename






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

Bug #54197 [Com]: [PATH=] sections incompatibility with user_ini.filename set to null

[julientld at free dot fr]

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

 ID: 54197
 Comment by: julientld at free dot fr
 Reported by:julientld at free dot fr
 Summary:[PATH=] sections incompatibility with
 user_ini.filename set to null
 Status: Feedback
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Windows Server 2003 SP2
 PHP Version:5.3.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

IIS does not crash. It continues to serve static files. But all php
scripts return the HTTP 500 error.



There is nothing in the php log file.


Previous Comments:

[2011-03-08 19:31:13] paj...@php.net

What says the error log? Or is it actually a crash?


[2011-03-08 19:25:07] julientld at free dot fr

Description:

Hello,



My configuration :



Windows Server 2003 SP2

IIS 6.0

PHP 5.3.5 VC9 x86 NTS

FastCGI 1.5

WinCache 1.1



Same problem seen with IIS 5.1 under Windows XP SP3.

Test script:
---
In the php.ini file (production based) :





[PHP]



;I do not want users to set their own configuration file so I disable
the below option (set to null)

user_ini.filename =



;I want to set my own simple PATH sections like that

[PATH=D:/www/]

upload_max_filesize = 5M

Expected result:

I expect to get no error

Actual result:
--
But all the php script I open return the following :





FastCGI Error

The FastCGI Handler was unable to process the request. 





Error Details:



•The FastCGI process exited unexpectedly

•Error Number: -1073741819 (0xc005).

•Error Description: Unknown Error

HTTP Error 500 - Server Error.

Internet Information Services (IIS)



I obtain no error if I remove the [PATH=] section or set a filename to
user_ini.filename






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

Bug #53626 [Fbk-Opn]: Segmentation Fault

[bionoren at letu dot edu]

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

 ID: 53626
 User updated by:bionoren at letu dot edu
 Reported by:bionoren at letu dot edu
 Summary:Segmentation Fault
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Reproducible crash
-Operating System:   Mac OS X 10.6.5
+Operating System:   Mac OS X 10.6.6
-PHP Version:5.3.4
+PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

It's more helpful. I get the following messages in the Apache error
log:

test/index.php(14) : Warning - SQLite3::query() [a
href='sqlite3.query'sqlite3.query/a]: table test already exists

test/index.php(3) : Catchable fatal error - Argument 1 passed to
test::__construct() must be an array, boolean given, called in
test/index.php on line 9 and defined

[Tue Mar 08 13:11:41 2011] [notice] child pid 26396 exit signal
Segmentation fault (11)



Here's the stack trace:

Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: 13 at address: 0x

0x0001015d0831 in zend_llist_del_element (l=0x10071c0f0,
element=0x10208c258, compare=0x10109f549
php_sqlite3_compare_stmt_free) at
/Users/bion/Downloads/php5.3-201103081730/Zend/zend_llist.c:97

97  next = current-next;


Previous Comments:

[2011-03-08 18:00:04] fel...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/




[2010-12-29 01:07:56] bionoren at letu dot edu

?php

class test {

public function __construct(array $values) {

print_r($values);

}



public static function getInstance($db) {

$result = $db-query(SELECT * from test);

return new test($result-fetchArray(SQLITE3_ASSOC));

}

}



$db = new SQLite3(test.sqlite, SQLITE3_OPEN_READWRITE |
SQLITE3_OPEN_CREATE);

$db-query(CREATE TABLE test (foo, bar));



test::getInstance($db);

print done;

?


[2010-12-29 00:02:51] fel...@php.net

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

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

Please avoid embedding huge scripts into the report.




[2010-12-28 23:57:04] bionoren at letu dot edu

Description:

./configure '--prefix=/usr' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--sysconfdir=/private/etc'
'--with-apxs2=/usr/sbin/apxs' '--enable-cli'
'--with-config-file-path=/etc' '--with-libxml-dir=/usr'
'--with-openssl=/usr' '--with-kerberos=/usr' '--with-zlib=/usr'
'--enable-bcmath' '--with-bz2=/usr' '--enable-calendar'
'--with-curl=/usr' '--enable-exif' '--enable-ftp' '--with-gd'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--enable-gd-native-ttf' '--with-ldap=/usr' '--with-ldap-sasl=/usr'
'--enable-mbstring' '--enable-mbregex' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd'
'--with-mysql-sock=/var/mysql/mysql.sock' '--with-iodbc=/usr'
'--enable-shmop' '--with-snmp=/usr' '--enable-soap' '--enable-sockets'
'--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-xmlrpc'
'--with-iconv-dir=/usr' '--with-xsl=/usr' '--enable-zend-multibyte'
'--enable-zip' '--with-pcre-regex' --disable-cgi --enable-debug
--with-freetype-dir=/usr/local --with-mcrypt

Expected result:

An error message describing whatever bad situation I created for PHP

Actual result:
--
Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: 13 at address: 0x

0x0001015bed85 in zend_llist_del_element (l=0x1022aade8,
element=0x102099818, compare=0x101095ad6
php_sqlite3_compare_stmt_free) at
/downloads/php/php-5.3.4/Zend/zend_llist.c:97

97  next = current-next;

(gdb) bt

#0  0x0001015bed85 in zend_llist_del_element (l=0x1022aade8,
element=0x102099818, compare=0x101095ad6
php_sqlite3_compare_stmt_free) at
/downloads/php/php-5.3.4/Zend/zend_llist.c:97

#1  0x000101095d6d in php_sqlite3_stmt_object_free_storage
(object=0x1023132b0) at
/downloads/php/php-5.3.4/ext/sqlite3/sqlite3.c:1936

#2  0x0001015fe9fd in zend_objects_store_free_object_storage
(objects=0x101c95e38) at
/downloads/php/php-5.3.4/Zend/zend_objects_API.c:92

#3  0x0001015b8ff1 in 

Bug #49608 [Asn-Csd]: Using CachingIterator on DirectoryIterator instance segfaults

[felipe]

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

 ID: 49608
 Updated by: fel...@php.net
 Reported by:david at grudl dot com
 Summary:Using CachingIterator on DirectoryIterator instance
 segfaults
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:SPL related
 Operating System:   *
 PHP Version:5.3SVN-2009-09-20 (snap)
 Assigned To:colder
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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




Previous Comments:

[2011-03-08 20:56:31] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=309035
Log: - Fixed bug #49608 (Using CachingIterator on DirectoryIterator
instance segfaults)


[2010-08-09 03:39:33] fel...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/




[2010-05-18 14:15:19] m...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/

Works here on Linux (tm).


[2009-09-20 14:59:56] paj...@php.net

Pretty sure it is not a windows only bug either.


[2009-09-20 14:59:09] paj...@php.net

Backtrace:



   php5_debug.dll!zval_delref_p(_zval_struct * pz=0x)  Line 385 +
0x3 bytes   C

php5_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x00c1ebe4,
char * __zend_filename=0x10563320, unsigned int __zend_lineno=1407) 
Line 429 + 0xb bytesC

php5_debug.dll!spl_filesystem_dir_it_dtor(_zend_object_iterator *
iter=0x02784d10)  Line 1407 + 0x17 bytesC

php5_debug.dll!spl_dual_it_free_storage(void * _object=0x02785080) 
Line 1920 + 0x16 bytes  C

php5_debug.dll!zend_objects_store_del_ref_by_handle_ex(unsigned int
handle=2, const _zend_object_handlers * handlers=0x105a6e00)  Line 220 +
0x10 bytes  C

php5_debug.dll!zend_objects_store_del_ref(_zval_struct *
zobject=0x02783ad8)  Line 172 + 0x10 bytes  C

php5_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x02783ad8, char
* __zend_filename=0x104dea40, unsigned int __zend_lineno=435)  Line 52 +
0x11 bytes  C

php5_debug.dll!_zval_dtor(_zval_struct * zvalue=0x02783ad8, char *
__zend_filename=0x104dea40, unsigned int __zend_lineno=435)  Line 35 +
0x11 bytes  C

php5_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x027852a4,
char * __zend_filename=0x104e3584, unsigned int __zend_lineno=175)  Line
435 + 0x19 bytesC

php5_debug.dll!_zval_ptr_dtor_wrapper(_zval_struct * *
zval_ptr=0x027852a4)  Line 175 + 0x17 bytes C

php5_debug.dll!zend_hash_apply_deleter(_hashtable * ht=0x105c0b78,
bucket * p=0x02785298)  Line 611 + 0x11 bytes   C

php5_debug.dll!zend_hash_reverse_apply(_hashtable * ht=0x105c0b78, int
(void *)* apply_func=0x10283570)  Line 760 + 0xd bytes  C

php5_debug.dll!shutdown_destructors()  Line 222 + 0xf bytes C

php5_debug.dll!zend_call_destructors()  Line 875C

php5_debug.dll!php_request_shutdown(void * dummy=0x)  Line
1547C

php.exe!main(int argc=3, char * * argv=0x00ce1bf0)  Line 1371 + 0xa
bytes   C

php.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C

php.exe!mainCRTStartup()  Line 403  C






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/bug.php?id=49608


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

Bug #53850 [Com]: openssl_pkey_export() with password not protecting private key

[jason dot gerfen at gmail dot com]

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

 ID: 53850
 Comment by: jason dot gerfen at gmail dot com
 Reported by:jason dot gerfen at gmail dot com
 Summary:openssl_pkey_export() with password not protecting
 private key
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   arch linux x86_64
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

On another note. Using strictly SSL commands to generate a new private
key using both openssl-0.9.8x  openssl-1.0.0x (installed from source)
produce a valid password protected private key.


Previous Comments:

[2011-02-16 17:19:54] jason dot gerfen at gmail dot com

Can I get an update on this status?


[2011-01-31 15:18:56] jason dot gerfen at gmail dot com

Since I have not heard anything else about this I did some digging to
try and identify the problem.



I have been adding some warning output in the
'openssl-1.0.0c/crypto/pem/pem_pkey.c' file after reviewing the the
'php-5.3.5/ext/openssl/openssl.c' file and noticing and focusing on the
calls to the OpenSSL shared objects for 'PEM_write_bio_PrivateKey()'.



When adding the warning output flags in the
'OpenSSL-1.0.0c/crypt/pem/pem_pkey.c' the password argument would always
display as '(null)'.



Correct me if I am looking the wrong spot in helping identify the
problem.


[2011-01-28 19:42:32] jason dot gerfen at gmail dot com

I have verified this under the following conditions.



Arch Linux x86_64 installation



This configuration returns a password protected private key

Apache 2.2 [./configure]

OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-0.9.8q
--shared]

PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-0.9.8q]



This configuration however does not return a password protected key

Apache 2.2 [./configure]

OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-1.0.0c
--shared]

PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-1.0.0c]



Anything else you might find pertinent?


[2011-01-26 20:12:04] paj...@php.net

There is no different code in php to deal with this function.



If two versions of openssl give you two different results then it is a
openssl 

problem, not php.



Also I would like you to test using the same PHP versions vs two
openssl, then we 

can begin to discuss a possible issue. Be sure to use the latest
versions 

available at php.net, not the centos (or any other distro) you use.


[2011-01-26 20:04:50] jason dot gerfen at gmail dot com

Description:

I have tested this against php5.3.5 with OpenSSL 1.0.0c (arch linux) vs
an older server running php5.2.14 with OpenSSL 0.9.8e (centos linux).



Test script:
---
$opts = array('config'='openssl.cnf',

  'encrypt_key'=true,

  'private_key_type'=OPENSSL_KEYTYPE_RSA,

  'digest_alg'='sha256',

  'private_key_bits'=2048,

  'x509_extensions'='usr_cert');



$handle = openssl_pkey_new($opts);

openssl_pkey_export($handle, $privatekey, sha1($_SERVER['REMOTE_ADDR']),
$opts);

echo $privatekey;



Expected result:

CentOS example output

-BEGIN RSA PRIVATE KEY-

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,C93B386451093918



buV1Kuaiu8QXhSeBdAF9Le2u+SSzaEtrHw6rLq19xL+9lWuwf4dFtrMPRI/PPvA5

HwBB7ZzT1AAzOAK2AnDiND3+n6IyqrkQjD7R0bGY6VLXdMr3qgGiJOkmsroF5t/H

LQEFGn9F8eOfEQTjkz4h9KYF/traXZSayBjNQ37fL42HO4M5WY0Ehms6bfeU5BN5

1d+NdENKLK0KVIJDNM3clQoHCc2KJwq70CeZmKq+tIG7UdigxmW0f9B/BMSM8PFx

3cFzt1eZVj23jPO65icEfqLWvdYUpOqFfZc17Si87LW8ExvO8yu4UPrk8iRR8eFH

LeOCPobR446Ehq8XBgFiFp8kzus5vDbqRLbMaBqul/mVWDmkpcyrnWJVAfginUar

FDTji8Ge8Zv5GgpuS2tjYkQpykthA17SKxDGe8s26feaHkErEanTWg5o50RP1oUo

1e2rrX+PVFoukN9f+j5OiScC8QDVfBcSZZYvfRmkE1SnF3S3CAVdtDIcqmy33WY+

Icx/n2uh3Y4tYafzSu/5O8ZeBzGUz3eKWMIAL66mxOclPAceWsQ6Ry22IBdjr+7p

Af3IKo4sWVtj3mOlrwNdNX9JtdHYiskNTVJ7+7DBlmbM+lfQlvb7wBsVek9ex6k2

qxWv250S+rdWuXBx3WuleQsQ14gBtX7Rf0Sk3DvOTinaU9C5n8xwaO9GWS0CJtjA

AkDTLZ0rylVjfdd3W7fjxfYtQEwnbKeIC1SEKuNR8tv6GXGuubU5Nt8Q5TIhZIYL

p2H027lafTE1Ky+KIRD0qZWfSEAujrxJVnH1n62edYxzWXfr+onS0g==

-END RSA PRIVATE KEY-

Actual result:
--
Arch linux sample output

-BEGIN ENCRYPTED PRIVATE KEY-

MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIkd4I9LadOsYCAggA

MBQGCCqGSIb3DQMHBAhqJEWqm0xA9ASCAoDgWeRhfyKrCqfW7aSW1rYs8LVjN3ug

Bug #49532 [Com]: php5ts.dll access violation exception php5ts!_zend_mm_free_int

[mdurovic at gmail dot com]

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

 ID: 49532
 Comment by: mdurovic at gmail dot com
 Reported by:matroy at investpsp dot ca
 Summary:php5ts.dll access violation exception 
 php5ts!_zend_mm_free_int
 Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   win32 only - Windows 2003 SP2
 PHP Version:5.2.11
 Block user comment: N
 Private report: N

 New Comment:

Same issue it happens around 3-5 times a day apache crashes and
recycles. I have around 30K page views per day and I can't pin down what
causes the error. Any help would be greatly appreciated.  



PHP: 5.2.17

Appache: 5.2.17

OS: Windows 2003 SP2



PHP.ini:



extension=php_curl.dll

extension=php_gd2.dll

extension=php_mbstring.dll

extension=php_mcrypt.dll

extension=php_mysql.dll





--



PHP5TS!_ZEND_MM_FREE_INT+66In
httpd__PID__1848__Date__03_08_2011__Time_03_20_11PM__687__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!_zend_mm_free_int+66 in
C:\php\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x on thread 148


Previous Comments:

[2011-01-11 14:05:49] eb at upcl dot univ-lyon1 dot fr

I modify my php.ini file for it expresses error messages. PHP, on
loading, claimed beeing unable to load a few modules though available in
the appropriate directory; commenting out the loading of these modules
in the php file fixed the problem.

These modules were 

; extension=php_oci8.dll

; extension=php_oci8_11g.dll

; extension=php_pdo_oci.dll

; extension=php_sybase_ct.dll


[2011-01-11 10:52:44] eb at upcl dot univ-lyon1 dot fr

Well, actually, adding a line such as LoadModule php5_module
C:/HD3/apache_php_mysql/software/php/php5apache2_2.dll in the
configuration file of the apache server is enough to lead it failing to
start and issuing a Application défaillante httpd.exe, version
2.2.17.0, module défaillant php5ts.dll, version 5.3.5.0, adresse de
défaillance 0x000e890c. in the windows log file. As I told you, this
occurs ONLY after the system has rebooted. Right after the installation,
all works well.


[2011-01-11 09:55:39] paj...@php.net

@eb at upcl dot univ-lyon1 dot fr



Many things can cause this error message.



We still need a way to reproduce it, a small script.


[2011-01-11 09:29:09] eb at upcl dot univ-lyon1 dot fr

Hello,

I am experiencing quite the same situation though i'm running Apache 2.2
under windows xp sp3. PHP version is 5.3.5.

The weird part of all this is that, right after the installation of PHP,
it works fine (no bug), the PHP module interpreting quite well php code.
But after rebooting, the apache server fails starting when loading the
php module (php5apache2_2.dll) claiming an application error due to
php5ts.dll module. I installed and uninstalled it twice and each time
the same prolem occurred the same way. 

HTTP: Apache 2.2.17.0

PHP : 5.3.5.0

Windows : XP SP3


[2009-09-20 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.




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/bug.php?id=49532


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

[PHP-BUG] Bug #54198 [NEW]: apache2 reproducible crash datefmt_create( en_US@calendar=BUDDHIST...

[giorgio dot liscio at email dot it]

From: 
Operating system: windows 7 x64
PHP version:  5.3.5
Package:  I18N and L10N related
Bug Type: Bug
Bug description:apache2 reproducible crash datefmt_create( 
en_US@calendar=BUDDHIST...

Description:

$fmt = datefmt_create( en_US@calendar=BUDDHIST ,\IntlDateFormatter::FULL,
\IntlDateFormatter::FULL, 'America/Los_Angeles',
\IntlDateFormatter::TRADITIONAL  ,MM/dd/);

echo datefmt_format( $fmt , 0);



crashes on two computers (both win7 x64), so it does not depend by my sys



if a gdb trace is needed i will try to dump it!



thank you


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

Bug #47757 [Com]: JPG vs JPEG

[test at test dot com]

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

 ID: 47757
 Comment by: test at test dot com
 Reported by:frank at scriptzone dot nl
 Summary:JPG vs JPEG
 Status: Closed
 Type:   Bug
 Package:GD related
 Operating System:   Any
 PHP Version:5.2.9
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

So unfortunately this fix had a side effect of breaking various scripts
that checked for JPEG image format support in GD by calling gd_info()
and looking for the key 'JPG Support' .



I'm surprised that the source of this breakage was just this complaint
about compiler flag labeling.



Support for existing runtime behavior and avoiding breaking currently
working scripts should easily trump worries about compiler flag
consistency, it would be cool to take that more into account in the
future.


Previous Comments:

[2009-03-24 09:46:02] paj...@php.net

This bug has been fixed in CVS.

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




[2009-03-24 09:35:19] frank at scriptzone dot nl

Description:

I think inconsistent naming is quite annoying.



To compile GD with JPEG support you have to do something like
./configure --with-gd --with-jpeg-dir. However in phpinfo pages JPEG
support is displayed as JPG Support enabled.



So basicly, when I actually successfully compiled GD with JPEG-support:
I thought it failed because I was looking for JPEG in phpinfo, and not
JPG.



Not quite an essential bug, but perhaps worth fixing in the future.

Reproduce code:
---
'./configure' '--prefix=/usr' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs'
'--with-ldap=/usr' '--with-kerberos=/usr' '--enable-cli'
'--with-zlib-dir=/usr' '--enable-exif' '--enable-ftp'
'--enable-mbstring' '--enable-mbregex' '--enable-sockets'
'--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc'
'--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql'
'--with-mysqli=/usr/local/mysql/bin/mysql_config'
'--with-mysql=/usr/local/mysql' '--with-openssl' '--with-xmlrpc'
'--with-xsl=/usr' '--without-pear' --with-jpeg-dir=/usr/local/lib/
--with-gd

Expected result:

JPEG support

Actual result:
--
JPG support






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

Bug #49532 [Fbk]: php5ts.dll access violation exception php5ts!_zend_mm_free_int

[pajoye]

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

 ID: 49532
 Updated by: paj...@php.net
 Reported by:matroy at investpsp dot ca
 Summary:php5ts.dll access violation exception 
 php5ts!_zend_mm_free_int
 Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   win32 only - Windows 2003 SP2
 PHP Version:5.2.11
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

  http://windows.php.net/snapshots/

5.3.6RC2 works too.


Previous Comments:

[2011-03-08 21:49:49] mdurovic at gmail dot com

Same issue it happens around 3-5 times a day apache crashes and
recycles. I have around 30K page views per day and I can't pin down what
causes the error. Any help would be greatly appreciated.  



PHP: 5.2.17

Appache: 5.2.17

OS: Windows 2003 SP2



PHP.ini:



extension=php_curl.dll

extension=php_gd2.dll

extension=php_mbstring.dll

extension=php_mcrypt.dll

extension=php_mysql.dll





--



PHP5TS!_ZEND_MM_FREE_INT+66In
httpd__PID__1848__Date__03_08_2011__Time_03_20_11PM__687__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!_zend_mm_free_int+66 in
C:\php\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x on thread 148


[2011-01-11 14:05:49] eb at upcl dot univ-lyon1 dot fr

I modify my php.ini file for it expresses error messages. PHP, on
loading, claimed beeing unable to load a few modules though available in
the appropriate directory; commenting out the loading of these modules
in the php file fixed the problem.

These modules were 

; extension=php_oci8.dll

; extension=php_oci8_11g.dll

; extension=php_pdo_oci.dll

; extension=php_sybase_ct.dll


[2011-01-11 10:52:44] eb at upcl dot univ-lyon1 dot fr

Well, actually, adding a line such as LoadModule php5_module
C:/HD3/apache_php_mysql/software/php/php5apache2_2.dll in the
configuration file of the apache server is enough to lead it failing to
start and issuing a Application défaillante httpd.exe, version
2.2.17.0, module défaillant php5ts.dll, version 5.3.5.0, adresse de
défaillance 0x000e890c. in the windows log file. As I told you, this
occurs ONLY after the system has rebooted. Right after the installation,
all works well.


[2011-01-11 09:55:39] paj...@php.net

@eb at upcl dot univ-lyon1 dot fr



Many things can cause this error message.



We still need a way to reproduce it, a small script.


[2011-01-11 09:29:09] eb at upcl dot univ-lyon1 dot fr

Hello,

I am experiencing quite the same situation though i'm running Apache 2.2
under windows xp sp3. PHP version is 5.3.5.

The weird part of all this is that, right after the installation of PHP,
it works fine (no bug), the PHP module interpreting quite well php code.
But after rebooting, the apache server fails starting when loading the
php module (php5apache2_2.dll) claiming an application error due to
php5ts.dll module. I installed and uninstalled it twice and each time
the same prolem occurred the same way. 

HTTP: Apache 2.2.17.0

PHP : 5.3.5.0

Windows : XP SP3




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/bug.php?id=49532


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