#37375 [NEW]: foreach memory leaks when work with try-catch

[chen dot daqi at gmail dot com]

From: chen dot daqi at gmail dot com
Operating system: linux
PHP version:  6CVS-2006-05-09 (CVS)
PHP Bug Type: Unknown/Other Function
Bug description:  foreach memory leaks when work with try-catch

Description:

When a exception is throwed from a foreach, memory leak will happen

Reproduce code:
---
getMessage()."\n";
}
?>


Expected result:

new exception


Actual result:
--
new exception
[Tue May  9 13:40:13 2006]  Script:  'test.php'
/home/xlchen/php-5.1.2/Zend/zend_execute.c(843) :  Freeing 0x0847FD5C (16
bytes)
, script=test.php
[Tue May  9 13:40:13 2006]  Script:  'test.php'
/home/xlchen/php-5.1.2/Zend/zend_vm_execute.h(3370) :  Freeing 0x0847FCAC
(35 by
tes), script=test.php
/home/xlchen/php-5.1.2/Zend/zend_hash.c(383) : Actual location (location
was rel   
 ayed)
Last leak repeated 2 times
[Tue May  9 13:40:13 2006]  Script:  'test.php'
/home/xlchen/php-5.1.2/Zend/zend_vm_execute.h(3339) :  Freeing 0x0846D054
(16 by
tes), script=test.php
Last leak repeated 2 times
[Tue May  9 13:40:13 2006]  Script:  'test.php'
/home/xlchen/php-5.1.2/Zend/zend_vm_execute.h(3320) :  Freeing 0x084809AC
(32 by
tes), script=test.php
/home/xlchen/php-5.1.2/Zend/zend_hash.c(169) : Actual location (location
was rel   
 ayed)
Last leak repeated 1 time
=== Total 9 memory leaks detected ===


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

#37367 [NEW]: WNOHANG option causes no PID to be returned.

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: Fedora 4
PHP version:  5.1.4
PHP Bug Type: PCNTL related
Bug description:  WNOHANG option causes no PID to be returned.

Description:

Thanks in advance for helping me to resolve this issue-- It will be a
great help!!


Passing the WNOHANG option will cause pcntl_wait() and pcntl_waitpid() to
never return a PID, but only 0 or -1 (0 before a child returns, and -1
after). I have tested this under version 5.0.4-10, 5.1.2-5, and 5.1.4,
both with and without the --enable-sigchild build option.


Reproduce code:
---
ftp://www.redplanet5.net, user= [EMAIL PROTECTED], pass= temp.



Expected result:

It will fork a child from the parent, and then a second child from the
first. If you send a TERM from the shell to the first child, it will
attempt to end the second child, and report whether or not it received an
acceptable wait() response. Just remove the WNOHANG flag and it works
flawlessly.

As written, the WNOHANG option was passed to the pcntl_wait() function,
and the program will report that "there may have been a problem with the
termination of the child."

Actual result:
--
If the WNOHANG option is removed, the program says that the child exited
nicely. This should be the case regardless of whether or not the WNOHANG
option was passed.

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

#37367 [Opn]: WNOHANG option causes no PID to be returned.

[doprea at chimesnet dot com]

 ID:   37367
 User updated by:  doprea at chimesnet dot com
-Reported By:  [EMAIL PROTECTED]
+Reported By:  doprea at chimesnet dot com
 Status:   Open
 Bug Type: PCNTL related
 Operating System: Fedora 4
 PHP Version:  5.1.4
 New Comment:

Please use email address doprea at chimesnet dot com.


Previous Comments:


[2006-05-08 16:56:44] [EMAIL PROTECTED]

(email change.)



[2006-05-08 16:55:22] doprea at chimesnet dot com

Description:

Thanks in advance for helping me to resolve this issue-- It will be a
great help!!


Passing the WNOHANG option will cause pcntl_wait() and pcntl_waitpid()
to never return a PID, but only 0 or -1 (0 before a child returns, and
-1 after). I have tested this under version 5.0.4-10, 5.1.2-5, and
5.1.4, both with and without the --enable-sigchild build option.


Reproduce code:
---
ftp://www.redplanet5.net, user= [EMAIL PROTECTED], pass= temp.



Expected result:

It will fork a child from the parent, and then a second child from the
first. If you send a TERM from the shell to the first child, it will
attempt to end the second child, and report whether or not it received
an acceptable wait() response. Just remove the WNOHANG flag and it
works flawlessly.

As written, the WNOHANG option was passed to the pcntl_wait() function,
and the program will report that "there may have been a problem with the
termination of the child."

Actual result:
--
If the WNOHANG option is removed, the program says that the child
exited nicely. This should be the case regardless of whether or not the
WNOHANG option was passed.





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

#37367 [Opn]: WNOHANG option causes no PID to be returned.

[[EMAIL PROTECTED]]

 ID:   37367
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PCNTL related
 Operating System: Fedora 4
 PHP Version:  5.1.4
 New Comment:

(email change.)


Previous Comments:


[2006-05-08 16:55:22] [EMAIL PROTECTED]

Description:

Thanks in advance for helping me to resolve this issue-- It will be a
great help!!


Passing the WNOHANG option will cause pcntl_wait() and pcntl_waitpid()
to never return a PID, but only 0 or -1 (0 before a child returns, and
-1 after). I have tested this under version 5.0.4-10, 5.1.2-5, and
5.1.4, both with and without the --enable-sigchild build option.


Reproduce code:
---
ftp://www.redplanet5.net, user= [EMAIL PROTECTED], pass= temp.



Expected result:

It will fork a child from the parent, and then a second child from the
first. If you send a TERM from the shell to the first child, it will
attempt to end the second child, and report whether or not it received
an acceptable wait() response. Just remove the WNOHANG flag and it
works flawlessly.

As written, the WNOHANG option was passed to the pcntl_wait() function,
and the program will report that "there may have been a problem with the
termination of the child."

Actual result:
--
If the WNOHANG option is removed, the program says that the child
exited nicely. This should be the case regardless of whether or not the
WNOHANG option was passed.





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

#37294 [Asn->Csd]: PHP crashes Apache on PDO::query instead of throwing an exception

[tgross at m-s dot de]

 ID:   37294
 User updated by:  tgross at m-s dot de
 Reported By:  tgross at m-s dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: PDO related
 Operating System: Windows 2000
 PHP Version:  5.1.3
 Assigned To:  wez
 New Comment:

This is fixed in 5.1.4


Previous Comments:


[2006-05-04 02:12:49] thad at bronto dot com

I see this exact behavior using apache 2.0.55 on Centos 
4.2 with php 5.1.3.



[2006-05-03 14:58:41] tgross at m-s dot de

Description:

When calling PDO::query(), PHP crashes Apache on certain queries if the
SQL-query contains errors.

In the example, Query 1 is correct.
Query 2 is wrong, and the exception is thrown (which is expected).
Query 3 causes Apache to crash.

Reproduce code:
---
$dbh = new PDO ('odbc:DRIVER={Microsoft Access Driver
(*.mdb)};DBQ=c:/path/to/database/db.mdb', '', '');
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

try
{
//$result = $dbh->query('select * from aktuelles');   //  Query 1:
Correct
//$result = $dbh->query('select * from aktuellesX');  //  Query 2:
Wrong (Table aktuellesX does not exist)
  $result = $dbh->query('selectX * from aktuelles');  //  Query 3:
Wrong (Command selectX does not exist)
  $ret = $result->fetchAll(PDO::FETCH_ASSOC);
}
catch (Exception $e)
{
  echo "Failed: " , $e->getMessage();
}


Expected result:

PHP throws an exception and displays the error message.

Actual result:
--
Apache crashes.





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

#31892 [Com]: PHP_SELF incorrect without cgi.fix_pathinfo, but turning on screws up PATH_INFO

[lwalker at magi dot net dot au]

 ID:   31892
 Comment by:   lwalker at magi dot net dot au
 Reported By:  ceefour at gauldong dot net
 Status:   Verified
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2005-02-11)
 New Comment:

I'm expreiencing the same issue on PHP 4.3 + 4.4 under Apache 1.3.33
and have had to switch back to mod_php for our hosting server.

Tried to access the patch to have a look at it, however it's not
loading.

Do you still have a copy of the patch, or are you able to post a
backported PHP 4.x version?

I do believe that SCRIPT_NAME + PHP_INFO is the expected behaviour.


Previous Comments:


[2006-02-06 21:52:39] php-bugs at dave dot staff dot spoonguard dot org

The following patch causes $_SERVER['PHP_SELF'] to include the
PATH_INFO component when running under CGI:

http://spoonguard.org/dave/classes/cs345/bugfix/php-5.1.2-31892.diff

Previously, PHP_SELF was being set to SCRIPT_NAME when cgi.fix_pathinfo
was set. This changes the behavior, by setting PHP_SELF to SCRIPT_NAME +
PATH_INFO.

Is this similar to what you're looking for?

Thanks,

- Dave



[2005-02-13 23:19:43] ceefour at gauldong dot net

I have verified this problem with PHP 5.0.3 on Linux 2.4 and it also
exists in PHP 5.0.3.

I'm using PHP 5.0.3 as CGI under Apache 1.3.33.

Check out this link:
http://php5.gauldong.net/phpinfo.php/test/me?query=string

It gives out the following results:
_SERVER["PATH_INFO"]/test/me
_SERVER["PATH_TRANSLATED"]  /home/u1294/domain/php5.gauldong.net/web/test/me
_SERVER["ORIG_PATH_TRANSLATED"] 
/home/u1294/domain/php5.gauldong.net/web/phpinfo.php/test/me
_SERVER["ORIG_PATH_INFO"]   /phpinfo.php/test/me
_SERVER["ORIG_SCRIPT_NAME"] /cgi-bin/php
_SERVER["ORIG_SCRIPT_FILENAME"] 
/home/u1294/domain/php5.gauldong.net/web/cgi-bin/php
_SERVER["PHP_SELF"] /phpinfo.php

-
Note that it's using a default php.ini for PHP 5 meaning
cgi.fix_pathinfo is turned ON.

In the above results PHP_SELF is incorrect. It should be
/phpinfo.php/test/me (it's missing the pathinfo part). Other variables
are correct I suppose. I hope this is fixed soon. And also in PHP 4.

The fact that this bug exists in the latest versions of both PHP 4 and
PHP 5 is truly beyond me. :-(



[2005-02-09 09:34:50] ceefour at gauldong dot net

Description:

Following up bug #31843, I tried to set cgi.fix_pathinfo On, which is
"weird" considering that this option says ANYthing about PHP_SELF. But
a good friend of mine pointed out it works on fixing PHP_SELF, so I
did, and to my surprise, it works!

So, my problem was solved, PHP_SELF was returning the correct value...
though not in a very elegant way, in my opinion, since who has access
to some hosting server's php.ini? Everyone but the most elite premium
services, I guess. Nonetheless it worked, so I enjoyed cherish,
fortune, and glory... for several seconds.

It turned that turning on cgi.fix_pathinfo actually screws up
PATH_INFO, at least in my configuration, which is VERY strange
considering the name of the option (shouldn't it be
cgi.fix_phpself_and_screw_up_pathinfo???) ;-)

Let me apologize for a bit of sinism but really it was just for making
fun out of it. So, phpinfo() says PATH_INFO and PATH_TRANSLATED is now
"no value". Something's good though, ORIG_PATH_* returns the correct
value (weird). It's possible to use ORIG_PATH_* but I guess I should
stick to the standards. Since that server was in heavy use, I quickly
realized that by just turning that option on, I could have caused many
pages to fail (since they rely on PATH_INFO) so I quickly turn this
option off again (I already had a workaround for PHP_SELF bug, it's not
a problem anymore but I'm still seeking for an elegant resolution on
this, in the part of PHP developers not in my part).

Reproduce code:
---
phpinfo()

Expected result:

PHP_SELF: phpinfo.php/test/me
PATH_INFO: /test/me

Actual result:
--
cgi.fix_path_info=Off:

PHP_SELF: /test/me
PATH_INFO: /test/me

cgi.fix_path_info=On:

PHP_SELF: phpinfo.php/test/me
PATH_INFO: (no value)






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

#37374 [NEW]: openssl_csr_sign()

[bassijunior at gmail dot com]

From: bassijunior at gmail dot com
Operating system: Windows XP
PHP version:  5.1.4
PHP Bug Type: OpenSSL related
Bug description:  openssl_csr_sign()

Description:

 I'm using a PHP 5.1.1, but I have a folowing problem:

I made a code that was to sign a request. I used almost all the code from
PHP page. I made some modifications.
The openssl_csr_sign function doesn´t work. Please, help me!!!

Reproduce code:
---
// You will usually want to create a self-signed certificate at this
// point until your CA fulfills your request.
// This creates a self-signed cert that is valid for 365 days

$cacert = "C:\demoCA\cacert.pem";
$privkey_ca = array("C:\demoCA\private\cakey.pem", "junior");
$req_cert = "C:\demoCA\csr_2.pem";

var_dump($req_cert);

$usercert = openssl_csr_sign($req_cert, $cacert, $privkey_ca, 365);

if($usercert) 
{ 
echo " A requisicao foi assinada"; 
} 
else 
{ 
echo "Erro : A requisicao nao foi assinada"; 
} 

var_dump($usercert);


openssl_x509_export_to_file($usercert, "C:\demoCA\user_cert_signed.pem");



/*
// Show any errors that occurred here
while (($e = openssl_error_string()) !== false) {
   echo $e . "\n";
}

*/
?>

Expected result:

I expect that my request is signed by CA that I created.
I made previously the request using the openssl_csr_new() function.

Actual result:
--
The result was: 

string(19) "C:\demoCA\csr_2.pem" 
Warning: openssl_csr_sign() [function.openssl-csr-sign]: cannot get CSR
from parameter 1 in
C:\xampp\xampp\htdocs\teste_php\criando_certificado_auto_assinado_teste.php
on line 24
Erro : A requisicao nao foi assinada
bool(false) 
Warning: openssl_x509_export_to_file() expects parameter 1 to be resource,
boolean given in
C:\xampp\xampp\htdocs\teste_php\criando_certificado_auto_assinado_teste.php
on line 38



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

#37352 [Opn]: cli do not parse any arguments the first line

[eddi at ai000 dot de]

 ID:   37352
 User updated by:  eddi at ai000 dot de
 Reported By:  eddi at ai000 dot de
 Status:   Open
 Bug Type: CGI related
 Operating System: *
 PHP Version:  *
 New Comment:

I have a patch for you: 

diff:  http://www.ai000.de/PHP/37352.txt
new php_cli.c: http://www.ai000.de/PHP/php_cli.c.txt

I do it as good as I can. Sorry C is not my favorite language :)


Previous Comments:


[2006-05-08 00:13:35] eddi at ai000 dot de

May be it is difficult to understand me without well formed english.
But Firstly nobody scould you "it is a bug". Edink, you are scound one
telling me that. Please read this lines and do not forget, here is a
human being too, who said "is a feature request".

Secondly it is an undiscussed fact, perl or python use the arguments
from the first line reading itself.

Thirdly perl and python do so on linux and other systems like Mac OS
too. So what is the problem? All I solicit you is to dealing with
arguments from the first line.

Sixthly there are a serious problem with security for written daemons
based on PHP. Interpreter starts and include  the master-ini and each
php[-cli].ini in PWD. May be the last make the daemon unsecure. If I
could define a config file fixed in the daemon script, security is in
my hand exclusivly.

Seventhly there are no way defining discriminative config files for all
problems, that I would like to handle with PHP when I try to start
processes by script file directly. Or I have to change the directory
each time and need a script starting all written daemons too. Exactly
that (and changing my OS) suggest your answers (partially indirect).

Eighthly it is an undiscussed fact, at start up PHP reads the first
line yet. But the function cli_seek_file_begin() (from php_cli.c)
handle the first line peculiarly. Example: "#!php\rthis text is in the
first line but still displayed\n"

You may right at the point. Yes it is a handicap of the operating
system. Nonetheless we still need it. Please modifie
cli_seek_file_begin() it will parse arguments.



[2006-05-07 21:08:40] [EMAIL PROTECTED]

Parsing of the shebang line is a kernel task. Linux supports one
argument, FreeBSD parses them the way you would like. This is not a bug
in PHP.



[2006-05-07 19:17:59] eddi at ai000 dot de

Please have look in the php_cli.c. The function cli_seek_file_begin
reads already the first line. Why it seems to you PHP could not support
arguments form the first line like Perl?



[2006-05-07 19:07:36] [EMAIL PROTECTED]

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

RTFM of your shell systemonly one argument is supported in hash
bang lines



[2006-05-07 19:00:56] eddi at ai000 dot de

Description:

1.) It is not really a bug because it is not provided in php_cli.c. It
is a feature request. PHP should suppord arguments in the first line of
a script.

#!/opt/php/php -c /other/config.ini -z /zend/modul.so

Thanks.







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

#37366 [Com]: IIS 6.0 w3wp process crash with PHP 5.1.4

[paul at routingcore dot com]

 ID:   37366
 Comment by:   paul at routingcore dot com
 Reported By:  chris dot schreiber at fast4gl dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows 2003 Server
 PHP Version:  5.1.4
 New Comment:

I get the same thing. I hadn't updated since 5.0.4, which works fine
for me. As soon as I drop 5.1.4 in I get the application errors for
w3wp.exe. I set IIS to recycle the worker threads every couple of
minutes to see if the frequency of the errors would increase, and they
did.


Previous Comments:


[2006-05-08 15:48:22] gravityworksllc at hotmail dot com

I can validate this error.  I get this along with the pool process
crashing.  This was fine in version 5.12.  If you need more information
on the errors please let me know.

Kind regards,
Mynd

www.myndpollution.com



[2006-05-08 14:07:47] chris dot schreiber at fast4gl dot com

Description:

This problem occurs using the newest builds of PHP, both 5.1.3 and
5.1.4.  This did not happen with 5.1.2 or earlier versions.

Running IIS 6.0 on Windows 2003 Server Enterprise.  Running PHP in
ISAPI mode.

w3wp.exe processes crash throughout the day, about 20-30 times. 
Several process instances will usually crash together at the same time,
and then be ok for a couple of hours until happening again.

Error is:
w3wp.exe - Application Error : The instruction at "0x01b55c80"
referenced memory at "0x01b55c80". The memory could not be "read".

The memory address is always either "0x01b55c80" or "0x01b55c90".

Here is a link to my PHPinfo():
http://mail.fast4gl.net/phpinfo.php

Reproduce code:
---
Running vBulletin (3.5.4).  Can't track down any code which produces
the crash.






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

#37359 [Opn->Bgs]: with-freetype-dir not used for libt1 test

[pajoye]

 ID:   37359
 Updated by:   [EMAIL PROTECTED]
 Reported By:  john at jcoppens dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Configuration Issues
 Operating System: Linux
 PHP Version:  5.1.4
 Assigned To:  pajoye
 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.

"configure: error: Problem with libt1.(a|so). Please check config.log
for more information."

Did you install the t1lib develpement package?

"checking for iconv in -liconv... no
configure: error: Please reinstall the iconv library.
which, again, is not the fault of not finding iconv, but
not finding freetype (according to the config.log):"

No, you are missing iconv or the development packages (-devel or
whatever it is on your platform).

I do not see something about freetype not found, only that it will use
freetype2.

What you pasted here from your config.log is sadly useless. However, it
is clear that you did not install everything required to compile PHP. It
is not a bug.


Previous Comments:


[2006-05-08 16:24:33] john at jcoppens dot com

adding:
--with-t1lib=/usr/local

same error:
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

The --with-t1lib-dir directive you asked for does not appear in
./configure --help, so I suspect it has to be the above directive
(--with-t1lib=...)

Then, disabling --without-t1lib, I get the error:

checking for iconv in -liconv... no
configure: error: Please reinstall the iconv library.

which, again, is not the fault of not finding iconv, but
not finding freetype (according to the config.log):

configure:45338: gcc -o conftest -g -O2   -Wl,-rpath,/opt/gnome/lib
-L/opt/gnome
/lib conftest.c -liconv  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm
-ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm 1>&5  
  
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype



[2006-05-08 16:05:00] [EMAIL PROTECTED]

Please use the t1lib directive and run the configure without LD_FLAGS.

"If I disablet1lib in the config, the same problem appears with another
library (also because of not finding freetype)"

Can you be more clear? Please paste the exact errors here, and which
libraries do not work, for which extensions.



[2006-05-08 16:00:03] john at jcoppens dot com

Below is the config command. I did not use --with-t1lib-dir for two
reasons: 
1) I thought that was for only for t1lib, which is found
2) It's not only a problem compiling t1lib. If I disable
   t1lib in the config, the same problem appears with
   another library (also because of not finding freetype)

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/mysql --with-apxs
--with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp --with-gd
--enable-gd-native-ttf --with-ttf=/usr/X11 --with-freetype-dir=/usr/X11
--enable-sockets --with-t1lib --with-truetype --prefix=/usr
--enable-mbstring --with-libxml-dir=/opt/gnome



[2006-05-08 14:46:51] [EMAIL PROTECTED]

What's your configure line?

Did you use --with-t1lib-dir?



[2006-05-08 14:42:16] john at jcoppens dot com

I've solved the problem for the moment adding LDFLAGS:

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/ ...

but I doubt that is the elegant 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/37359

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

#37370 [Opn->Fbk]: can't load module php5apache2.dll on Apache 2.2

[bjori]

 ID:   37370
 Updated by:   [EMAIL PROTECTED]
 Reported By:  softwebmaster at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: windows XP professional
 PHP Version:  5.1.4
 New Comment:

Please try using this CVS snapshot:

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


Previous Comments:


[2006-05-08 19:05:51] softwebmaster at gmail dot com

i received an error message "can't load module php5apache2.dll" when i
re-start apache 2.2 server. I didn't have this problem if i run apache
2.058

hopefully, a new version of php5apache2.dll will solve this problem.
thank you.



[2006-05-08 19:03:48] softwebmaster at gmail dot com

Description:

I installed apache 2.2 and php 5.14. I received error message "can't
load module php5apache2.dll". I didn't have this kind of problem in
apache 2.058.

hopefully, a new php5apache2.dll will solve this problem. thanks






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

#37370 [Opn]: can't load module php5apache2.dll on Apache 2.2

[softwebmaster at gmail dot com]

 ID:   37370
 User updated by:  softwebmaster at gmail dot com
-Summary:  can't load module php5apache2.dll
 Reported By:  softwebmaster at gmail dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: windows XP professional
 PHP Version:  5.1.4
 New Comment:

i received an error message "can't load module php5apache2.dll" when i
re-start apache 2.2 server. I didn't have this problem if i run apache
2.058

hopefully, a new version of php5apache2.dll will solve this problem.
thank you.


Previous Comments:


[2006-05-08 19:03:48] softwebmaster at gmail dot com

Description:

I installed apache 2.2 and php 5.14. I received error message "can't
load module php5apache2.dll". I didn't have this kind of problem in
apache 2.058.

hopefully, a new php5apache2.dll will solve this problem. thanks






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

#37370 [NEW]: can't load module php5apache2.dll

[softwebmaster at gmail dot com]

From: softwebmaster at gmail dot com
Operating system: windows XP professional
PHP version:  5.1.4
PHP Bug Type: Apache2 related
Bug description:  can't load module php5apache2.dll

Description:

I installed apache 2.2 and php 5.14. I received error message "can't load
module php5apache2.dll". I didn't have this kind of problem in apache
2.058.

hopefully, a new php5apache2.dll will solve this problem. thanks


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

#37369 [NEW]: HTML Form Submit Problem

[alexm at emarket2 dot com]

From: alexm at emarket2 dot com
Operating system: Win 2003
PHP version:  5.1.4
PHP Bug Type: Scripting Engine problem
Bug description:  HTML Form Submit Problem

Description:

We are submitting form from HTML email message to PHP page
and printing $_POST array.

We are getting blank $_POST array in 50% of cases on PHP 5.0.5
installation and about 10-15% ratio for PHP 5.1.4.
The problem is happening randomly, sometimes on first submit. 

The problem only happening on WIN 2003 Server(SP1)and IIS6 platform. We
have tried the same PHP installation on WIN XP Pro (IIS5) and it works
reliably. We are running PHP as ISAPI module.

Also, if form is submitted from Web Browser, the problem 
is not happening. We can see form data in HTTP Request submitted from
email message, but it is not appear on PHP page.




Reproduce code:
---
HTML Form:
===
http://www.w3.org/TR/html4/loose.dtd";>



Untitled Document




https://g2invitrogen.emarket2.com/reg/landpage.php";
method="post" name="form11" id="form11">
  

  Who are You?
  



   First Name:
  


   Last Name:
  


   Email:
  


   Job Function:
  
  
  Core Facility Manager/Director
  Core Facility Technician
  Department Head/Director/VP
  Environ.Health/Safety Officer
  Graduate/Post-Graduate Student
  Lab Director/Manager
  Principal Investigator
  Professor/Teacher/Instructor
  Purchaser/Buyer/Procurement
  Research Scient./Post-Doctoral
  Research/Technical Assistant
  Sales & Marketing
  Supply Ctr.Host/Stores Manager
  Other
  


  https://static.emarket2.com/invitrogen/iprofile/images/smallthinredbar.jpg";
width="360" height="9" border="0">


  What are You
researching?


  Everything


  https://static.emarket2.com/invitrogen/iprofile/images/smallthinredbar.jpg";
width="360" height="9" border="0">


   


   


  

  



===
PHP Page:
===

===

Expected result:

Array ( [submitaction] => Insert [IDALIAS] => TEST [FIRSTNAME] => Alex
[LASTNAME] => Melnychuck [EMAIL] => [EMAIL PROTECTED] [JOBCODE] => Other
[RESEARCHING] => Everything [Submit] => Submit ) 

Actual result:
--
Array()

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

#37368 [NEW]: Incorrect timestamp returned for strtotime()

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: Debian sarge
PHP version:  5.1.4
PHP Bug Type: Date/time related
Bug description:  Incorrect timestamp returned for strtotime()

Description:

When using strtotime() in PHP 5.1.4, it returns an inaccurate timestamp,
but PHP 5.0.4 and 4.4.2 return the correct timestamp.

Reproduce code:
---
php -r 'echo date("r", strtotime("Mon, 08 May 2006 13:06:44 -0400 +30
days"));'

Expected result:

Wed, 07 Jun 2006 13:06:44 -0400

Actual result:
--
Mon, 12 Jun 2006 13:06:44 -0400

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

#37367 [Opn]: WNOHANG option causes no PID to be returned.

[doprea at chimesnet dot com]

 ID:   37367
 User updated by:  doprea at chimesnet dot com
 Reported By:  doprea at chimesnet dot com
 Status:   Open
 Bug Type: PCNTL related
 Operating System: Fedora 4
 PHP Version:  5.1.4
 New Comment:

Sorry for the multiple posts: There is only one file at that location,
called 'multitiered.php'.


Clearly, I'm losing my mind.


Previous Comments:


[2006-05-08 16:58:07] doprea at chimesnet dot com

Please use email address doprea at chimesnet dot com.



[2006-05-08 16:56:44] [EMAIL PROTECTED]

(email change.)



[2006-05-08 16:55:22] doprea at chimesnet dot com

Description:

Thanks in advance for helping me to resolve this issue-- It will be a
great help!!


Passing the WNOHANG option will cause pcntl_wait() and pcntl_waitpid()
to never return a PID, but only 0 or -1 (0 before a child returns, and
-1 after). I have tested this under version 5.0.4-10, 5.1.2-5, and
5.1.4, both with and without the --enable-sigchild build option.


Reproduce code:
---
ftp://www.redplanet5.net, user= [EMAIL PROTECTED], pass= temp.



Expected result:

It will fork a child from the parent, and then a second child from the
first. If you send a TERM from the shell to the first child, it will
attempt to end the second child, and report whether or not it received
an acceptable wait() response. Just remove the WNOHANG flag and it
works flawlessly.

As written, the WNOHANG option was passed to the pcntl_wait() function,
and the program will report that "there may have been a problem with the
termination of the child."

Actual result:
--
If the WNOHANG option is removed, the program says that the child
exited nicely. This should be the case regardless of whether or not the
WNOHANG option was passed.





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

#37359 [Fbk->Opn]: with-freetype-dir not used for libt1 test

[john at jcoppens dot com]

 ID:   37359
 User updated by:  john at jcoppens dot com
 Reported By:  john at jcoppens dot com
-Status:   Feedback
+Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Linux
 PHP Version:  5.1.4
 Assigned To:  pajoye
 New Comment:

adding:
--with-t1lib=/usr/local

same error:
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

The --with-t1lib-dir directive you asked for does not appear in
./configure --help, so I suspect it has to be the above directive
(--with-t1lib=...)

Then, disabling --without-t1lib, I get the error:

checking for iconv in -liconv... no
configure: error: Please reinstall the iconv library.

which, again, is not the fault of not finding iconv, but
not finding freetype (according to the config.log):

configure:45338: gcc -o conftest -g -O2   -Wl,-rpath,/opt/gnome/lib
-L/opt/gnome
/lib conftest.c -liconv  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm
-ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm 1>&5  
  
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype


Previous Comments:


[2006-05-08 16:05:00] [EMAIL PROTECTED]

Please use the t1lib directive and run the configure without LD_FLAGS.

"If I disablet1lib in the config, the same problem appears with another
library (also because of not finding freetype)"

Can you be more clear? Please paste the exact errors here, and which
libraries do not work, for which extensions.



[2006-05-08 16:00:03] john at jcoppens dot com

Below is the config command. I did not use --with-t1lib-dir for two
reasons: 
1) I thought that was for only for t1lib, which is found
2) It's not only a problem compiling t1lib. If I disable
   t1lib in the config, the same problem appears with
   another library (also because of not finding freetype)

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/mysql --with-apxs
--with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp --with-gd
--enable-gd-native-ttf --with-ttf=/usr/X11 --with-freetype-dir=/usr/X11
--enable-sockets --with-t1lib --with-truetype --prefix=/usr
--enable-mbstring --with-libxml-dir=/opt/gnome



[2006-05-08 14:46:51] [EMAIL PROTECTED]

What's your configure line?

Did you use --with-t1lib-dir?



[2006-05-08 14:42:16] john at jcoppens dot com

I've solved the problem for the moment adding LDFLAGS:

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/ ...

but I doubt that is the elegant solution.



[2006-05-08 05:08:51] john at jcoppens dot com

Description:

I (tried) to run configure with

--with-freetype-dir=/usr/X11

(among other options, of course). This works fine for libfreetype
itself, but the config process stops
on (failing) to detect libt1:
If configure fails try --with-xpm-dir=
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

It says 'no' here, not because t1 doesn't exist, but because it cannot
find freetype. From the config.log:

configure:35897: checking for T1_StrError in -lt1  

configure:35916: gcc -o conftest -g -O2  -Wl,-rpath,/usr/local/lib
-L/usr/local/lib  -Wl,-rpath,/opt/gnome/lib -L/opt/gnome/lib conftest.c
-lt1  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm -ldl -lnsl  -lxml2 -lz
-lm -lxml2 -lz -lm 1>&5 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype  


Probably because the /usr/X11 path is not included.



Expected result:

I'd expect the path from --with-freetype-dir to be included in all
places where it is needed.

Sorry if I'm incorrect here... I'm not an expert programmer.







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

#37359 [Opn->Fbk]: with-freetype-dir not used for libt1 test

[pajoye]

 ID:   37359
 Updated by:   [EMAIL PROTECTED]
 Reported By:  john at jcoppens dot com
-Status:   Open
+Status:   Feedback
 Bug Type: *Configuration Issues
 Operating System: Linux
 PHP Version:  5.1.4
 Assigned To:  pajoye
 New Comment:

Please use the t1lib directive and run the configure without LD_FLAGS.

"If I disablet1lib in the config, the same problem appears with another
library (also because of not finding freetype)"

Can you be more clear? Please paste the exact errors here, and which
libraries do not work, for which extensions.


Previous Comments:


[2006-05-08 16:00:03] john at jcoppens dot com

Below is the config command. I did not use --with-t1lib-dir for two
reasons: 
1) I thought that was for only for t1lib, which is found
2) It's not only a problem compiling t1lib. If I disable
   t1lib in the config, the same problem appears with
   another library (also because of not finding freetype)

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/mysql --with-apxs
--with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp --with-gd
--enable-gd-native-ttf --with-ttf=/usr/X11 --with-freetype-dir=/usr/X11
--enable-sockets --with-t1lib --with-truetype --prefix=/usr
--enable-mbstring --with-libxml-dir=/opt/gnome



[2006-05-08 14:46:51] [EMAIL PROTECTED]

What's your configure line?

Did you use --with-t1lib-dir?



[2006-05-08 14:42:16] john at jcoppens dot com

I've solved the problem for the moment adding LDFLAGS:

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/ ...

but I doubt that is the elegant solution.



[2006-05-08 05:08:51] john at jcoppens dot com

Description:

I (tried) to run configure with

--with-freetype-dir=/usr/X11

(among other options, of course). This works fine for libfreetype
itself, but the config process stops
on (failing) to detect libt1:
If configure fails try --with-xpm-dir=
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

It says 'no' here, not because t1 doesn't exist, but because it cannot
find freetype. From the config.log:

configure:35897: checking for T1_StrError in -lt1  

configure:35916: gcc -o conftest -g -O2  -Wl,-rpath,/usr/local/lib
-L/usr/local/lib  -Wl,-rpath,/opt/gnome/lib -L/opt/gnome/lib conftest.c
-lt1  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm -ldl -lnsl  -lxml2 -lz
-lm -lxml2 -lz -lm 1>&5 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype  


Probably because the /usr/X11 path is not included.



Expected result:

I'd expect the path from --with-freetype-dir to be included in all
places where it is needed.

Sorry if I'm incorrect here... I'm not an expert programmer.







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

#37359 [Fbk->Opn]: with-freetype-dir not used for libt1 test

[john at jcoppens dot com]

 ID:   37359
 User updated by:  john at jcoppens dot com
 Reported By:  john at jcoppens dot com
-Status:   Feedback
+Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Linux
 PHP Version:  5.1.4
 Assigned To:  pajoye
 New Comment:

Below is the config command. I did not use --with-t1lib-dir for two
reasons: 
1) I thought that was for only for t1lib, which is found
2) It's not only a problem compiling t1lib. If I disable
   t1lib in the config, the same problem appears with
   another library (also because of not finding freetype)

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/mysql --with-apxs
--with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp --with-gd
--enable-gd-native-ttf --with-ttf=/usr/X11 --with-freetype-dir=/usr/X11
--enable-sockets --with-t1lib --with-truetype --prefix=/usr
--enable-mbstring --with-libxml-dir=/opt/gnome


Previous Comments:


[2006-05-08 14:46:51] [EMAIL PROTECTED]

What's your configure line?

Did you use --with-t1lib-dir?



[2006-05-08 14:42:16] john at jcoppens dot com

I've solved the problem for the moment adding LDFLAGS:

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/ ...

but I doubt that is the elegant solution.



[2006-05-08 05:08:51] john at jcoppens dot com

Description:

I (tried) to run configure with

--with-freetype-dir=/usr/X11

(among other options, of course). This works fine for libfreetype
itself, but the config process stops
on (failing) to detect libt1:
If configure fails try --with-xpm-dir=
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

It says 'no' here, not because t1 doesn't exist, but because it cannot
find freetype. From the config.log:

configure:35897: checking for T1_StrError in -lt1  

configure:35916: gcc -o conftest -g -O2  -Wl,-rpath,/usr/local/lib
-L/usr/local/lib  -Wl,-rpath,/opt/gnome/lib -L/opt/gnome/lib conftest.c
-lt1  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm -ldl -lnsl  -lxml2 -lz
-lm -lxml2 -lz -lm 1>&5 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype  


Probably because the /usr/X11 path is not included.



Expected result:

I'd expect the path from --with-freetype-dir to be included in all
places where it is needed.

Sorry if I'm incorrect here... I'm not an expert programmer.







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

#37366 [Com]: IIS 6.0 w3wp process crash with PHP 5.1.4

[gravityworksllc at hotmail dot com]

 ID:   37366
 Comment by:   gravityworksllc at hotmail dot com
 Reported By:  chris dot schreiber at fast4gl dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows 2003 Server
 PHP Version:  5.1.4
 New Comment:

I can validate this error.  I get this along with the pool process
crashing.  This was fine in version 5.12.  If you need more information
on the errors please let me know.

Kind regards,
Mynd

www.myndpollution.com


Previous Comments:


[2006-05-08 14:07:47] chris dot schreiber at fast4gl dot com

Description:

This problem occurs using the newest builds of PHP, both 5.1.3 and
5.1.4.  This did not happen with 5.1.2 or earlier versions.

Running IIS 6.0 on Windows 2003 Server Enterprise.  Running PHP in
ISAPI mode.

w3wp.exe processes crash throughout the day, about 20-30 times. 
Several process instances will usually crash together at the same time,
and then be ok for a couple of hours until happening again.

Error is:
w3wp.exe - Application Error : The instruction at "0x01b55c80"
referenced memory at "0x01b55c80". The memory could not be "read".

The memory address is always either "0x01b55c80" or "0x01b55c90".

Here is a link to my PHPinfo():
http://mail.fast4gl.net/phpinfo.php

Reproduce code:
---
Running vBulletin (3.5.4).  Can't track down any code which produces
the crash.






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

#37359 [Opn->Fbk]: with-freetype-dir not used for libt1 test

[pajoye]

 ID:   37359
 Updated by:   [EMAIL PROTECTED]
 Reported By:  john at jcoppens dot com
-Status:   Open
+Status:   Feedback
 Bug Type: *Configuration Issues
 Operating System: Linux
 PHP Version:  5.1.4
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

What's your configure line?

Did you use --with-t1lib-dir?


Previous Comments:


[2006-05-08 14:42:16] john at jcoppens dot com

I've solved the problem for the moment adding LDFLAGS:

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/ ...

but I doubt that is the elegant solution.



[2006-05-08 05:08:51] john at jcoppens dot com

Description:

I (tried) to run configure with

--with-freetype-dir=/usr/X11

(among other options, of course). This works fine for libfreetype
itself, but the config process stops
on (failing) to detect libt1:
If configure fails try --with-xpm-dir=
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

It says 'no' here, not because t1 doesn't exist, but because it cannot
find freetype. From the config.log:

configure:35897: checking for T1_StrError in -lt1  

configure:35916: gcc -o conftest -g -O2  -Wl,-rpath,/usr/local/lib
-L/usr/local/lib  -Wl,-rpath,/opt/gnome/lib -L/opt/gnome/lib conftest.c
-lt1  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm -ldl -lnsl  -lxml2 -lz
-lm -lxml2 -lz -lm 1>&5 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype  


Probably because the /usr/X11 path is not included.



Expected result:

I'd expect the path from --with-freetype-dir to be included in all
places where it is needed.

Sorry if I'm incorrect here... I'm not an expert programmer.







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

#37359 [Opn]: with-freetype-dir not used for libt1 test

[john at jcoppens dot com]

 ID:   37359
 User updated by:  john at jcoppens dot com
 Reported By:  john at jcoppens dot com
 Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Linux
 PHP Version:  5.1.4
 New Comment:

I've solved the problem for the moment adding LDFLAGS:

LDFLAGS=-L/usr/X11/lib ./configure --with-mysql=/opt/ ...

but I doubt that is the elegant solution.


Previous Comments:


[2006-05-08 05:08:51] john at jcoppens dot com

Description:

I (tried) to run configure with

--with-freetype-dir=/usr/X11

(among other options, of course). This works fine for libfreetype
itself, but the config process stops
on (failing) to detect libt1:
If configure fails try --with-xpm-dir=
checking for FreeType 1 support... no - FreeType 2.x is to be used
instead
checking for T1_StrError in -lt1... no
configure: error: Problem with libt1.(a|so). Please check config.log
for more information.

It says 'no' here, not because t1 doesn't exist, but because it cannot
find freetype. From the config.log:

configure:35897: checking for T1_StrError in -lt1  

configure:35916: gcc -o conftest -g -O2  -Wl,-rpath,/usr/local/lib
-L/usr/local/lib  -Wl,-rpath,/opt/gnome/lib -L/opt/gnome/lib conftest.c
-lt1  -lfreetype -lpng -lz -lbz2 -lz -lresolv -lm -ldl -lnsl  -lxml2 -lz
-lm -lxml2 -lz -lm 1>&5 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lfreetype  


Probably because the /usr/X11 path is not included.



Expected result:

I'd expect the path from --with-freetype-dir to be included in all
places where it is needed.

Sorry if I'm incorrect here... I'm not an expert programmer.







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

#37365 [Opn]: apache2 cannot load libphp4.so

[mluisfer at gmail dot com]

 ID:   37365
 User updated by:  mluisfer at gmail dot com
 Reported By:  mluisfer at gmail dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: tru64 v5.1A
 PHP Version:  4.4.2
 New Comment:

using IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version
2.90.FC4

the process to startup apache2 dont drop a core dump but hangs and need
a ctrl-c o ctrl-z to kill the process. In the logs file send the same
messages about symbol "aio_prefork" unresolved.


Previous Comments:


[2006-05-08 13:47:02] mluisfer at gmail dot com

Description:

I'm using 
apache2 2.0.58
IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.FC2

commands make and make install works fine, but when I want to statup
the apache2 send the next message :

exception system: exiting due to internal error: exception dispatch or
unwind stuck in infinite loop
exception system: exiting due to internal error: exception dispatch or
unwind stuck in infinite loop
./apachectl: 326203 Abort - core dumped

The php cli binary (/usr/local/apache2/bin/php) generated by the make
install works fine, I can run a php script with the following command
"/usr/local/apache2/bin/php testifx.php", it has a single connection to
informix database and make a sql.

is possible to mention that php libphp4.so works without the
--with-informix option.


Actual result:
--
my configure options:


./configure --prefix=/usr/local/apache2/php
--with-apxs2=/usr/local/apache2/bin/apxs --disable-rpath --with-ndbm
--with-yp --enable-ftp --enable-calendar --with-pear --enable-mbstring
--with-zlib-dir=/usr/local/lib --with-informix=yes 

this is the apache2 log:
Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp4.so into server: dlopen:
libaio.so: symbol "aio_prefork" unresolved

compiled modules in php cli binary (php -m):
[PHP Modules]
calendar
ctype
dba
ftp
informix
mbstring
mysql
overload
pcre
posix
session
standard
tokenizer
xml
zlib







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

#37363 [Fbk->Opn]: Doesn't compile with PDO-PHP

[fpazzatura at email dot it]

 ID:   37363
 User updated by:  fpazzatura at email dot it
 Reported By:  fpazzatura at email dot it
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Ubuntu Linux (Breezy Badger)
 PHP Version:  5.1.5CVS
 New Comment:

The version of my libmysql package is 4.1.12, the my compiler is gcc
4.0.1

With same libraries and compiler, PHP 5.1.3 compiles greetly...


Previous Comments:


[2006-05-08 13:20:45] [EMAIL PROTECTED]

When version of MySQL library are you compiling pdo_mysql 
against?



[2006-05-08 08:35:54] fpazzatura at email dot it

Description:

my config flags

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--mandir=/usr/share/man --disable-cgi --with-config-file-path=/etc
--enable-libcc --disable-short-tags --without-pcre-regex --with-zlib
--with-bz2 --with-gd --with-ming --with-pdo-mysql --without-pdo-sqlite
--without-sqlite --disable-tokenizer --without-pear

already with apache2 and no cli (the error with loading in apache2)

There's the error:

ext/pdo_mysql/pdo_mysql.o: In function `zm_info_pdo_mysql':
pdo_mysql.c:(.text+0x109): undefined reference to
`mysql_get_client_info'
ext/pdo_mysql/mysql_driver.o: In function `_pdo_mysql_error':
mysql_driver.c:(.text+0xd6): undefined reference to `mysql_stmt_errno'
mysql_driver.c:(.text+0x11f): undefined reference to `mysql_error'
mysql_driver.c:(.text+0x145): undefined reference to
`mysql_stmt_sqlstate'
mysql_driver.c:(.text+0x196): undefined reference to `mysql_errno'
mysql_driver.c:(.text+0x24a): undefined reference to `mysql_sqlstate'
mysql_driver.c:(.text+0x266): undefined reference to `mysql_error'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_closer':
mysql_driver.c:(.text+0x37a): undefined reference to `mysql_close'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_doer':
mysql_driver.c:(.text+0x402): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x410): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_last_insert_id':
mysql_driver.c:(.text+0x491): undefined reference to `mysql_insert_id'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_quoter':
mysql_driver.c:(.text+0x518): undefined reference to
`mysql_real_escape_string'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_get_attribute':
mysql_driver.c:(.text+0x5ee): undefined reference to `mysql_stat'
mysql_driver.c:(.text+0x63f): undefined reference to
`mysql_get_host_info'
mysql_driver.c:(.text+0x651): undefined reference to
`mysql_get_client_info'
mysql_driver.c:(.text+0x68b): undefined reference to
`mysql_get_server_info'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_set_attribute':
mysql_driver.c:(.text+0x79c): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x82e): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_begin':
mysql_driver.c:(.text+0x892): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x8d6): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_commit':
mysql_driver.c:(.text+0x932): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x976): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_rollback':
mysql_driver.c:(.text+0x9d2): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0xa16): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_preparer':
mysql_driver.c:(.text+0xacd): undefined reference to
`mysql_get_server_version'
mysql_driver.c:(.text+0xb1f): undefined reference to `mysql_stmt_init'
mysql_driver.c:(.text+0xb3e): undefined reference to
`mysql_stmt_prepare'
mysql_driver.c:(.text+0xb61): undefined reference to
`mysql_stmt_param_count'
mysql_driver.c:(.text+0xc47): undefined reference to `mysql_errno'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_handle_factory':
mysql_driver.c:(.text+0xde5): undefined reference to `mysql_init'
mysql_driver.c:(.text+0x122f): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x12c3): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x133f): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x13c3): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x149e): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x1574): undefined reference to
`mysql_real_connect'
mysql_driver.c:(.text+0x1606): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x164d): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_statement.o: In function `pdo_mysql_stmt_dtor':
mysql_statement.c:(.text+0x19): undefined reference to
`mysql_free_result'
mysql_statement.c:(.text+0x52): un

#37220 [Com]: LOB Type mismatch when using windows & oci8.dll

[contact at infochallenge dot com]

 ID:   37220
 Comment by:   contact at infochallenge dot com
 Reported By:  lbouteille dot ext at francetelecom dot com
 Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Win 2000
 PHP Version:  5.1.2
 Assigned To:  tony2001
 New Comment:

The oracle documentation says InstantClient is required for connecting
php to a remote oracle server, what about Local Oracle?
Installing Instant Client on an already existing oracle server doesn't
help, instant client was designed for remote machines


Previous Comments:


[2006-05-03 14:11:14] [EMAIL PROTECTED]

Oracle Client and Oracle INSTANT Client are different things. 
OCI8 Win32 builds are done using Instant Client, so you can't use OCI8
dlls with outdated Oracle8 and Oracle9 client libraries anymore.
You need to install Oracle Instant Client 10.x (or native Oracle Client
10.x, but it doesn't make any sense, since installing instant client is
much more easier).




[2006-05-03 13:57:29] lbouteille dot ext at francetelecom dot com

It's installed, I can find the OCI.dll in the oracle client BIN
folder.. 
the ORACLE_HOME var is set... 

What's next ?



[2006-05-03 13:52:11] [EMAIL PROTECTED]

Yes, Oracle Instant Client is required.



[2006-05-03 13:43:14] lbouteille dot ext at francetelecom dot com

I can't start my Apache Server with the latest snapshot..
say something wrong :

can't find OCIStmtPrepare2 in the OCI.dll

did something wrong ?



[2006-05-01 07:12:55] [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





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

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

#37366 [NEW]: IIS 6.0 w3wp process crash with PHP 5.1.4

[chris dot schreiber at fast4gl dot com]

From: chris dot schreiber at fast4gl dot com
Operating system: Windows 2003 Server
PHP version:  5.1.4
PHP Bug Type: Reproducible crash
Bug description:  IIS 6.0 w3wp process crash with PHP 5.1.4

Description:

This problem occurs using the newest builds of PHP, both 5.1.3 and 5.1.4. 
This did not happen with 5.1.2 or earlier versions.

Running IIS 6.0 on Windows 2003 Server Enterprise.  Running PHP in ISAPI
mode.

w3wp.exe processes crash throughout the day, about 20-30 times.  Several
process instances will usually crash together at the same time, and then
be ok for a couple of hours until happening again.

Error is:
w3wp.exe - Application Error : The instruction at "0x01b55c80" referenced
memory at "0x01b55c80". The memory could not be "read".

The memory address is always either "0x01b55c80" or "0x01b55c90".

Here is a link to my PHPinfo():
http://mail.fast4gl.net/phpinfo.php

Reproduce code:
---
Running vBulletin (3.5.4).  Can't track down any code which produces the
crash.


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

#37365 [NEW]: apache2 cannot load libphp4.so

[mluisfer at gmail dot com]

From: mluisfer at gmail dot com
Operating system: tru64 v5.1A
PHP version:  4.4.2
PHP Bug Type: Apache2 related
Bug description:  apache2 cannot load libphp4.so

Description:

I'm using 
apache2 2.0.58
IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.FC2

commands make and make install works fine, but when I want to statup the
apache2 send the next message :

exception system: exiting due to internal error: exception dispatch or
unwind stuck in infinite loop
exception system: exiting due to internal error: exception dispatch or
unwind stuck in infinite loop
./apachectl: 326203 Abort - core dumped

The php cli binary (/usr/local/apache2/bin/php) generated by the make
install works fine, I can run a php script with the following command
"/usr/local/apache2/bin/php testifx.php", it has a single connection to
informix database and make a sql.

is possible to mention that php libphp4.so works without the
--with-informix option.


Actual result:
--
my configure options:


./configure --prefix=/usr/local/apache2/php
--with-apxs2=/usr/local/apache2/bin/apxs --disable-rpath --with-ndbm
--with-yp --enable-ftp --enable-calendar --with-pear --enable-mbstring
--with-zlib-dir=/usr/local/lib --with-informix=yes 

this is the apache2 log:
Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp4.so into server: dlopen:
libaio.so: symbol "aio_prefork" unresolved

compiled modules in php cli binary (php -m):
[PHP Modules]
calendar
ctype
dba
ftp
informix
mbstring
mysql
overload
pcre
posix
session
standard
tokenizer
xml
zlib



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

#37363 [Opn->Fbk]: Doesn't compile with PDO-PHP

[iliaa]

 ID:   37363
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fpazzatura at email dot it
-Status:   Open
+Status:   Feedback
 Bug Type: PDO related
 Operating System: Ubuntu Linux (Breezy Badger)
 PHP Version:  5.1.5CVS
 New Comment:

When version of MySQL library are you compiling pdo_mysql 
against?


Previous Comments:


[2006-05-08 08:35:54] fpazzatura at email dot it

Description:

my config flags

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--mandir=/usr/share/man --disable-cgi --with-config-file-path=/etc
--enable-libcc --disable-short-tags --without-pcre-regex --with-zlib
--with-bz2 --with-gd --with-ming --with-pdo-mysql --without-pdo-sqlite
--without-sqlite --disable-tokenizer --without-pear

already with apache2 and no cli (the error with loading in apache2)

There's the error:

ext/pdo_mysql/pdo_mysql.o: In function `zm_info_pdo_mysql':
pdo_mysql.c:(.text+0x109): undefined reference to
`mysql_get_client_info'
ext/pdo_mysql/mysql_driver.o: In function `_pdo_mysql_error':
mysql_driver.c:(.text+0xd6): undefined reference to `mysql_stmt_errno'
mysql_driver.c:(.text+0x11f): undefined reference to `mysql_error'
mysql_driver.c:(.text+0x145): undefined reference to
`mysql_stmt_sqlstate'
mysql_driver.c:(.text+0x196): undefined reference to `mysql_errno'
mysql_driver.c:(.text+0x24a): undefined reference to `mysql_sqlstate'
mysql_driver.c:(.text+0x266): undefined reference to `mysql_error'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_closer':
mysql_driver.c:(.text+0x37a): undefined reference to `mysql_close'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_doer':
mysql_driver.c:(.text+0x402): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x410): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_last_insert_id':
mysql_driver.c:(.text+0x491): undefined reference to `mysql_insert_id'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_quoter':
mysql_driver.c:(.text+0x518): undefined reference to
`mysql_real_escape_string'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_get_attribute':
mysql_driver.c:(.text+0x5ee): undefined reference to `mysql_stat'
mysql_driver.c:(.text+0x63f): undefined reference to
`mysql_get_host_info'
mysql_driver.c:(.text+0x651): undefined reference to
`mysql_get_client_info'
mysql_driver.c:(.text+0x68b): undefined reference to
`mysql_get_server_info'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_set_attribute':
mysql_driver.c:(.text+0x79c): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x82e): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_begin':
mysql_driver.c:(.text+0x892): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x8d6): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_commit':
mysql_driver.c:(.text+0x932): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x976): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_rollback':
mysql_driver.c:(.text+0x9d2): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0xa16): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_preparer':
mysql_driver.c:(.text+0xacd): undefined reference to
`mysql_get_server_version'
mysql_driver.c:(.text+0xb1f): undefined reference to `mysql_stmt_init'
mysql_driver.c:(.text+0xb3e): undefined reference to
`mysql_stmt_prepare'
mysql_driver.c:(.text+0xb61): undefined reference to
`mysql_stmt_param_count'
mysql_driver.c:(.text+0xc47): undefined reference to `mysql_errno'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_handle_factory':
mysql_driver.c:(.text+0xde5): undefined reference to `mysql_init'
mysql_driver.c:(.text+0x122f): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x12c3): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x133f): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x13c3): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x149e): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x1574): undefined reference to
`mysql_real_connect'
mysql_driver.c:(.text+0x1606): undefined reference to
`mysql_real_query'
mysql_driver.c:(.text+0x164d): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_statement.o: In function `pdo_mysql_stmt_dtor':
mysql_statement.c:(.text+0x19): undefined reference to
`mysql_free_result'
mysql_statement.c:(.text+0x52): undefined reference to
`mysql_stmt_close'
mysql_statement.c:(.text+0xba): undefined reference to
`mysql_more_results'
mysql_statement.c:(.text+0xca): undefined reference to
`mysql_next_result'
mysql_statement.c:(.text+0xda): undefined reference to
`mysql_store_result

#37354 [Opn->Bgs]: sleep() does not work as expected

[iliaa]

 ID:   37354
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jbricci at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Windows 2003 ISAPI
 PHP Version:  5.1.4
 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

PHP numbers sizes are limited by the bitsize of your system. 
For example when you create a number in excess of 2.14 billion 
it overflows the integer causing it to go into the negative 
teritory, hence the error message.


Previous Comments:


[2006-05-08 08:24:33] judas dot iscariote at gmail dot com

works perfectly fine in linux.. this may be a Windows only issue ..



[2006-05-08 00:09:38] jbricci at gmail dot com

Description:

sleep() does not work as it did before...

sleep() now only seems to work up to a certain number of seconds, I
haven't figured what that number is. But if this now how sleep() will
work in PHP, could you please add the maximum value, (number of seconds
allowed to be used in sleep()) to the manual.

Reproduce code:
---


Expected result:

script should sleep...

Actual result:
--
script continues without sleeping, and triggers a warning, that makes
no sense at all. 

PHP Warning:  sleep() [function.sleep]:
Number of seconds must be greater than or equal to 0 in
x:\www\docs\run\load.php on line 4


PHP 5.1.3 and in older versions, sleep() would sleep, no matter how
many seconds were used! snaps.php.net (5.2.dev-latest, 6.0-dev-latest)
also seem to follow version 5.1.3 and older version, sleeping no matter
how many seconds are used in sleep()!






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

#37361 [Com]: prepare statement alter the datatype of a parameter

[smlerman at gmail dot com]

 ID:   37361
 Comment by:   smlerman at gmail dot com
 Reported By:  axel dot azerty at laposte dot net
 Status:   Open
 Bug Type: PDO related
 Operating System: Fedora Core 5 - Linux 2.6.16
 PHP Version:  5.1.4
 New Comment:

bindParam and bindValue treat the parameter as a string by default,
which means the value has special characters escaped and the entire
value quoted. Your code produces COALESCE(MAX('id_board'),0), which is
probably not what you want. You'll most likely need to place the field
name directly in the query instead of trying to bind it as if it were
normal data.


Previous Comments:


[2006-05-08 07:01:03] axel dot azerty at laposte dot net

Description:

The prepared statement in PDO seems to lost or to have its type
altered.

When typing a 'SELECT COALESCE(MAX(field),0) FROM table' under
postgresql shell, no problem.
When using this query as is in PHP (with PDO), no problem.
When trying SELECT COALESCE(MAX(?),0) FROM table as a prepared
statement, the execution fails.

Replacing "MAX(?),0" by "MAX(?),'0'" solves the problem, but the
returned value is a string, and not an integer.



Reproduce code:
---
$stmt = $dbh->prepare("SELECT COALESCE(MAX(?),0) FROM board");
$stmt->bindParam(1,$fld);
$fld = "id_board";
if(!$stmt->execute()) print_r($stmt->errorInfo());

Expected result:

The expected result is "0" , in the case or the table is empty or the
number of lines in the table.

Actual result:
--
The statement->errorInfo() returns : 
Array
(
[0] => 42804
[1] => 7
[2] => ERREUR:  Les COALESCE types text et integer ne peuvent pas
correspondre
)

In english : "the COALESCE types text and interger can't match".






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

#36526 [Bgs]: compressed data corruption when passed to another script via _REQUEST

[bjori]

 ID:   36526
 Updated by:   [EMAIL PROTECTED]
 Reported By:  terry at kryogenic dot co dot uk
 Status:   Bogus
 Bug Type: *Compression related
 Operating System: Debian
 PHP Version:  5.1.2
 New Comment:

You need to change the status of the report yourself if you 
still belive this is a bug.
However, I can't reproduce it with latest CVS so please 
check it out before you change the status.




Previous Comments:


[2006-05-08 11:52:13] terry at kryogenic dot co dot uk

Well?



[2006-02-25 17:38:12] terry at kryogenic dot co dot uk

No, it doesn't work. Like I said I should have given more details into
what I tried when I wrote the report, I tried urlencode with and
without base64_encode. I also tried without compression and it worked
which is why I clearly thought wrongly that it was a bug.

I tested it by pointing the script to itself, urlencode worked but not
base64_encode (which obviously clears up the fact I should have used
urlencode anyway). Interestingly, I can decode the string and
decompress it with no problem without sending the data to itself or
another script.



[2006-02-25 17:26:30] [EMAIL PROTECTED]

I don't get it.

Does it work now or not?




[2006-02-25 16:20:03] terry at kryogenic dot co dot uk

Sorry if this seems like its not a bug but I have been through the
relevant channels already. urlencode does not work either, I should
have mentioned that here (sorry). There is a difference between the
strings after a decode of any sort.

It sure looked like a bug when I reported it. Sorry I wasted your time.



[2006-02-25 16:09:10] [EMAIL PROTECTED]

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.

Treat the base64 encoded string with urlencode() prior passing in a
link.



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

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

#37360 [Opn->Csd]: imageCreateFromGIF have a memory-leak bug

[pajoye]

 ID:   37360
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cnteacher at discuz dot com
-Status:   Open
+Status:   Closed
 Bug Type: GD related
 Operating System: win32/*nix
 PHP Version:  5CVS-2006-05-08 (snap)
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

This bug has been fixed in CVS.

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

All branches contain the fix.


Previous Comments:


[2006-05-08 08:36:38] cnteacher at discuz dot com

I regret that you see it like that.

Did you have a test of my file?

I've already read bug #37346 , and got the newest version GD from
http://snaps.php.net/ ( Stable 5.2.x-dev Built On: May 08, 2006 06:30
GMT ). But, when I test it with the special file, my server was down.



[2006-05-08 08:19:22] [EMAIL PROTECTED]

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.

Dup of bug #37346



[2006-05-08 08:16:49] judas dot iscariote at gmail dot com

duplicated of http://bugs.php.net/bug.php?id=37346

already fixed in CVS



[2006-05-08 05:59:03] cnteacher at discuz dot com

Sorry.

If you get an Forbidden error,

you must visit www.freediscuz.net first, and than type the file's url
in brower.



[2006-05-08 05:44:44] cnteacher at discuz dot com

The test gif url

http://www.freediscuz.net/tools/specialgif.zip



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

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

#36526 [Bgs]: compressed data corruption when passed to another script via _REQUEST

[terry at kryogenic dot co dot uk]

 ID:   36526
 User updated by:  terry at kryogenic dot co dot uk
 Reported By:  terry at kryogenic dot co dot uk
 Status:   Bogus
 Bug Type: *Compression related
 Operating System: Debian
 PHP Version:  5.1.2
 New Comment:

Well?


Previous Comments:


[2006-02-25 17:38:12] terry at kryogenic dot co dot uk

No, it doesn't work. Like I said I should have given more details into
what I tried when I wrote the report, I tried urlencode with and
without base64_encode. I also tried without compression and it worked
which is why I clearly thought wrongly that it was a bug.

I tested it by pointing the script to itself, urlencode worked but not
base64_encode (which obviously clears up the fact I should have used
urlencode anyway). Interestingly, I can decode the string and
decompress it with no problem without sending the data to itself or
another script.



[2006-02-25 17:26:30] [EMAIL PROTECTED]

I don't get it.

Does it work now or not?




[2006-02-25 16:20:03] terry at kryogenic dot co dot uk

Sorry if this seems like its not a bug but I have been through the
relevant channels already. urlencode does not work either, I should
have mentioned that here (sorry). There is a difference between the
strings after a decode of any sort.

It sure looked like a bug when I reported it. Sorry I wasted your time.



[2006-02-25 16:09:10] [EMAIL PROTECTED]

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.

Treat the base64 encoded string with urlencode() prior passing in a
link.



[2006-02-25 13:21:32] terry at kryogenic dot co dot uk

$decStr = bzdecompress(base64_decode($_REQUEST['error'])); should be
$decStr = bzdecompress(base64_decode($_REQUEST['object'])); in the
example code. My bad :)



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

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

#37364 [Opn->Bgs]: Login with cookies works with firefox but not with IE

[bjori]

 ID:   37364
 Updated by:   [EMAIL PROTECTED]
 Reported By:  blunt_bill at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Slackware 10.2
 PHP Version:  5.1.4
 New Comment:

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

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




Previous Comments:


[2006-05-08 11:33:46] blunt_bill at hotmail dot com

Description:

I use cookie authentication a page to allow administration to users.
The problem is when i try to login with Internet explorer (different
machines, all operating with MSIE 6 and windows XP). The cookies are
not set (when i access temporary internet files the files with the
cookie contents are not created).
If i try to login with firefox the cookies are written and work 100%.
I tried to use setcookie() and setrawcookie().

My PHP version is 5.0.5 from linuxpackages.net, Apache2 and apache2php
from there too.

Reproduce code:
---
setrawcookie('admin-user', $username, time()+$expiry, "/", false, 0);
setrawcookie('admin-pass', $password, time()+$expiry, "/", false, 0);

Expected result:

cookies should be set with both browsers (IE and firefox)

Actual result:
--
firefox cookies are set, IE cookies are not.





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

#37364 [NEW]: Login with cookies works with firefox but not with IE

[blunt_bill at hotmail dot com]

From: blunt_bill at hotmail dot com
Operating system: Slackware 10.2
PHP version:  5.1.4
PHP Bug Type: Unknown/Other Function
Bug description:  Login with cookies works with firefox but not with IE

Description:

I use cookie authentication a page to allow administration to users.
The problem is when i try to login with Internet explorer (different
machines, all operating with MSIE 6 and windows XP). The cookies are not
set (when i access temporary internet files the files with the cookie
contents are not created).
If i try to login with firefox the cookies are written and work 100%.
I tried to use setcookie() and setrawcookie().

My PHP version is 5.0.5 from linuxpackages.net, Apache2 and apache2php
from there too.

Reproduce code:
---
setrawcookie('admin-user', $username, time()+$expiry, "/", false, 0);
setrawcookie('admin-pass', $password, time()+$expiry, "/", false, 0);

Expected result:

cookies should be set with both browsers (IE and firefox)

Actual result:
--
firefox cookies are set, IE cookies are not.

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

#37292 [Com]: loading CLOBs crashes php in oci8

[sswpwp at poczta dot onet dot pl]

 ID:   37292
 Comment by:   sswpwp at poczta dot onet dot pl
 Reported By:  crescentfreshpot at yahoo dot com
 Status:   Open
 Bug Type: OCI8 related
 Operating System: WinXP
 PHP Version:  5.1.3
 New Comment:

I have the same problem. After fix for bug #36934 PHP crashes when
reading BFILES with OCI8. 
I receive the same backtrace as crescentfreshpot.
Here is the code to reproduce the bug:

$conn = oci_connect('rtg_owner', 'rtg', $tnsname);
$stmt = oci_parse($conn, "SELECT BFILE FROM IMAGES WHERE  IMAGE_ID =
3872");
oci_execute($stmt);
$row = oci_fetch_assoc($stmt);

$img = $row['BFILE'];
var_dump($img);
$img->read(128); // this line causes a crash
echo $img->tell();

I'm using PHP 5CVS-2006-05-08(snap), Apache 2.0.55 and Oracle Instant
Client 10.2.0


Previous Comments:


[2006-05-06 22:29:43] crescentfreshpot at yahoo dot com

Two side notes:

1) Seems to me that any calls to OCI-Lob::xxx() methods in user code
will wipe out oci8 from turning up in the call stack window. 

E.g. adjusting reproduce code like:


oci_execute($stmt);
$lob = oci_fetch_array($stmt,OCI_ASSOC);
var_dump($lob['LOBDATA']->load());


and no more oci8 in the call stack window

2) Related to bug #37331



[2006-05-06 22:25:33] crescentfreshpot at yahoo dot com

> Sorry, I don't see a word about OCI8 in these backtraces.

That's all that's there.

However, I've adjusted the reproduce code slightly and oci8 does turn
up in the backtrace now:

Reproduce Code
--
http://bugs.php.net/37292

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

#37362 [Opn->Bgs]: Make halts on semicolon in function declaration

[helly]

 ID:   37362
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lobster2 at xs4all dot nl
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX 5.2 ML07
-PHP Version:  5.1.4
+PHP Version:  *
 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.

This is a generated file. So the problem is either the generator, you
need byacc not yacc. Or detection of your build environment.

For build environment requirements check this:
http://www.php.net/anoncvs.php


Previous Comments:


[2006-05-08 08:17:49] lobster2 at xs4all dot nl

$ diff zend_language_parser.c.orig zend_language_parser.c 
2582c2582,2583 
< ; 
--- 
> # Next line commented out on AIX 5.2 ML07 with xlc 6.0 
> #; 
 
 
$ diff zend_ini_parser.c.orig zend_ini_parser.c 
1078c1078,1079 
< ; 
--- 
> # Next line commented out on AIX 5.2 ML07 with xlc 6.0 
> #;



[2006-05-08 08:15:16] lobster2 at xs4all dot nl

Description:

During make of PHP 5.1.3 and PHP 5.1.4 on AIX 5.2 ML07  
with xlc 6.0 the process halts on syntax errors. 
 

Reproduce code:
---
$ make
[...]
"Zend/zend_language_parser.c", line 2585.1: 1506-046 (S)   
Syntax error.   
[... and after fixing the previous error ...]   
"Zend/zend_ini_parser.c", line 1081.1: 1506-046 (S) Syntax   
error.

Stop.

Expected result:

Fix: comment out the line previous to the one reported, 
with the single semicolon on its own. 






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

#37360 [Bgs->Opn]: imageCreateFromGIF have a memory-leak bug

[cnteacher at discuz dot com]

 ID:   37360
 User updated by:  cnteacher at discuz dot com
 Reported By:  cnteacher at discuz dot com
-Status:   Bogus
+Status:   Open
 Bug Type: GD related
 Operating System: win32/*nix
 PHP Version:  5CVS-2006-05-08 (snap)
 New Comment:

I regret that you see it like that.

Did you have a test of my file?

I've already read bug #37346 , and got the newest version GD from
http://snaps.php.net/ ( Stable 5.2.x-dev Built On: May 08, 2006 06:30
GMT ). But, when I test it with the special file, my server was down.


Previous Comments:


[2006-05-08 08:19:22] [EMAIL PROTECTED]

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.

Dup of bug #37346



[2006-05-08 08:16:49] judas dot iscariote at gmail dot com

duplicated of http://bugs.php.net/bug.php?id=37346

already fixed in CVS



[2006-05-08 05:59:03] cnteacher at discuz dot com

Sorry.

If you get an Forbidden error,

you must visit www.freediscuz.net first, and than type the file's url
in brower.



[2006-05-08 05:44:44] cnteacher at discuz dot com

The test gif url

http://www.freediscuz.net/tools/specialgif.zip



[2006-05-08 05:40:23] cnteacher at discuz dot com

Description:

When I use the function 'imageCreateFromGIF' with some special images
(GIF), the memory will be ran out. I test it with all GD version (above
2.0.28).

Reproduce code:
---
$file = 'specialimg.gif';
$im = imagecreatefromgif($file); 

Expected result:

the memory ran out, and my web server is down.

Actual result:
--
I put the special gif file on my friend's web, you can download it from
http://www.freediscuz.net/specialgif.zip.
I think some one can use this bug to attack web server. It's so danger.





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

#37363 [NEW]: Doesn't compile with PDO-PHP

[fpazzatura at email dot it]

From: fpazzatura at email dot it
Operating system: Ubuntu Linux (Breezy Badger)
PHP version:  5.1.5CVS
PHP Bug Type: PDO related
Bug description:  Doesn't compile with PDO-PHP

Description:

my config flags

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--mandir=/usr/share/man --disable-cgi --with-config-file-path=/etc
--enable-libcc --disable-short-tags --without-pcre-regex --with-zlib
--with-bz2 --with-gd --with-ming --with-pdo-mysql --without-pdo-sqlite
--without-sqlite --disable-tokenizer --without-pear

already with apache2 and no cli (the error with loading in apache2)

There's the error:

ext/pdo_mysql/pdo_mysql.o: In function `zm_info_pdo_mysql':
pdo_mysql.c:(.text+0x109): undefined reference to `mysql_get_client_info'
ext/pdo_mysql/mysql_driver.o: In function `_pdo_mysql_error':
mysql_driver.c:(.text+0xd6): undefined reference to `mysql_stmt_errno'
mysql_driver.c:(.text+0x11f): undefined reference to `mysql_error'
mysql_driver.c:(.text+0x145): undefined reference to
`mysql_stmt_sqlstate'
mysql_driver.c:(.text+0x196): undefined reference to `mysql_errno'
mysql_driver.c:(.text+0x24a): undefined reference to `mysql_sqlstate'
mysql_driver.c:(.text+0x266): undefined reference to `mysql_error'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_closer':
mysql_driver.c:(.text+0x37a): undefined reference to `mysql_close'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_doer':
mysql_driver.c:(.text+0x402): undefined reference to `mysql_real_query'
mysql_driver.c:(.text+0x410): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_last_insert_id':
mysql_driver.c:(.text+0x491): undefined reference to `mysql_insert_id'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_quoter':
mysql_driver.c:(.text+0x518): undefined reference to
`mysql_real_escape_string'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_get_attribute':
mysql_driver.c:(.text+0x5ee): undefined reference to `mysql_stat'
mysql_driver.c:(.text+0x63f): undefined reference to
`mysql_get_host_info'
mysql_driver.c:(.text+0x651): undefined reference to
`mysql_get_client_info'
mysql_driver.c:(.text+0x68b): undefined reference to
`mysql_get_server_info'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_set_attribute':
mysql_driver.c:(.text+0x79c): undefined reference to `mysql_real_query'
mysql_driver.c:(.text+0x82e): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_begin':
mysql_driver.c:(.text+0x892): undefined reference to `mysql_real_query'
mysql_driver.c:(.text+0x8d6): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_commit':
mysql_driver.c:(.text+0x932): undefined reference to `mysql_real_query'
mysql_driver.c:(.text+0x976): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_rollback':
mysql_driver.c:(.text+0x9d2): undefined reference to `mysql_real_query'
mysql_driver.c:(.text+0xa16): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_preparer':
mysql_driver.c:(.text+0xacd): undefined reference to
`mysql_get_server_version'
mysql_driver.c:(.text+0xb1f): undefined reference to `mysql_stmt_init'
mysql_driver.c:(.text+0xb3e): undefined reference to `mysql_stmt_prepare'
mysql_driver.c:(.text+0xb61): undefined reference to
`mysql_stmt_param_count'
mysql_driver.c:(.text+0xc47): undefined reference to `mysql_errno'
ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_handle_factory':
mysql_driver.c:(.text+0xde5): undefined reference to `mysql_init'
mysql_driver.c:(.text+0x122f): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x12c3): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x133f): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x13c3): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x149e): undefined reference to `mysql_options'
mysql_driver.c:(.text+0x1574): undefined reference to
`mysql_real_connect'
mysql_driver.c:(.text+0x1606): undefined reference to `mysql_real_query'
mysql_driver.c:(.text+0x164d): undefined reference to
`mysql_affected_rows'
ext/pdo_mysql/mysql_statement.o: In function `pdo_mysql_stmt_dtor':
mysql_statement.c:(.text+0x19): undefined reference to
`mysql_free_result'
mysql_statement.c:(.text+0x52): undefined reference to `mysql_stmt_close'
mysql_statement.c:(.text+0xba): undefined reference to
`mysql_more_results'
mysql_statement.c:(.text+0xca): undefined reference to
`mysql_next_result'
mysql_statement.c:(.text+0xda): undefined reference to
`mysql_store_result'
mysql_statement.c:(.text+0xe6): undefined reference to
`mysql_free_result'
mysql_statement.c:(.text+0xf2): undefined reference to
`mysql_more_results'
ext/pdo_mysql/mysql_statement.o: In function `pdo_mysql_stmt_execute':
mysql_statement.c:(.text+0x186): undefined reference to
`mysql_stmt_bind_p

#37354 [Com]: sleep() does not work as expected

[judas dot iscariote at gmail dot com]

 ID:   37354
 Comment by:   judas dot iscariote at gmail dot com
 Reported By:  jbricci at gmail dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Windows 2003 ISAPI
 PHP Version:  5.1.4
 New Comment:

works perfectly fine in linux.. this may be a Windows only issue ..


Previous Comments:


[2006-05-08 00:09:38] jbricci at gmail dot com

Description:

sleep() does not work as it did before...

sleep() now only seems to work up to a certain number of seconds, I
haven't figured what that number is. But if this now how sleep() will
work in PHP, could you please add the maximum value, (number of seconds
allowed to be used in sleep()) to the manual.

Reproduce code:
---


Expected result:

script should sleep...

Actual result:
--
script continues without sleeping, and triggers a warning, that makes
no sense at all. 

PHP Warning:  sleep() [function.sleep]:
Number of seconds must be greater than or equal to 0 in
x:\www\docs\run\load.php on line 4


PHP 5.1.3 and in older versions, sleep() would sleep, no matter how
many seconds were used! snaps.php.net (5.2.dev-latest, 6.0-dev-latest)
also seem to follow version 5.1.3 and older version, sleeping no matter
how many seconds are used in sleep()!






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

#37360 [Opn->Bgs]: imageCreateFromGIF have a memory-leak bug

[derick]

 ID:   37360
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cnteacher at discuz dot com
-Status:   Open
+Status:   Bogus
 Bug Type: GD related
 Operating System: win32/*nix
 PHP Version:  5CVS-2006-05-08 (snap)
 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.

Dup of bug #37346


Previous Comments:


[2006-05-08 08:16:49] judas dot iscariote at gmail dot com

duplicated of http://bugs.php.net/bug.php?id=37346

already fixed in CVS



[2006-05-08 05:59:03] cnteacher at discuz dot com

Sorry.

If you get an Forbidden error,

you must visit www.freediscuz.net first, and than type the file's url
in brower.



[2006-05-08 05:44:44] cnteacher at discuz dot com

The test gif url

http://www.freediscuz.net/tools/specialgif.zip



[2006-05-08 05:40:23] cnteacher at discuz dot com

Description:

When I use the function 'imageCreateFromGIF' with some special images
(GIF), the memory will be ran out. I test it with all GD version (above
2.0.28).

Reproduce code:
---
$file = 'specialimg.gif';
$im = imagecreatefromgif($file); 

Expected result:

the memory ran out, and my web server is down.

Actual result:
--
I put the special gif file on my friend's web, you can download it from
http://www.freediscuz.net/specialgif.zip.
I think some one can use this bug to attack web server. It's so danger.





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

#37362 [Opn]: Make halts on semicolon in function declaration

[lobster2 at xs4all dot nl]

 ID:   37362
 User updated by:  lobster2 at xs4all dot nl
 Reported By:  lobster2 at xs4all dot nl
 Status:   Open
 Bug Type: Compile Failure
 Operating System: AIX 5.2 ML07
 PHP Version:  5.1.4
 New Comment:

$ diff zend_language_parser.c.orig zend_language_parser.c 
2582c2582,2583 
< ; 
--- 
> # Next line commented out on AIX 5.2 ML07 with xlc 6.0 
> #; 
 
 
$ diff zend_ini_parser.c.orig zend_ini_parser.c 
1078c1078,1079 
< ; 
--- 
> # Next line commented out on AIX 5.2 ML07 with xlc 6.0 
> #;


Previous Comments:


[2006-05-08 08:15:16] lobster2 at xs4all dot nl

Description:

During make of PHP 5.1.3 and PHP 5.1.4 on AIX 5.2 ML07  
with xlc 6.0 the process halts on syntax errors. 
 

Reproduce code:
---
$ make
[...]
"Zend/zend_language_parser.c", line 2585.1: 1506-046 (S)   
Syntax error.   
[... and after fixing the previous error ...]   
"Zend/zend_ini_parser.c", line 1081.1: 1506-046 (S) Syntax   
error.

Stop.

Expected result:

Fix: comment out the line previous to the one reported, 
with the single semicolon on its own. 






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

#37360 [Com]: imageCreateFromGIF have a memory-leak bug

[judas dot iscariote at gmail dot com]

 ID:   37360
 Comment by:   judas dot iscariote at gmail dot com
 Reported By:  cnteacher at discuz dot com
 Status:   Open
 Bug Type: GD related
 Operating System: win32/*nix
 PHP Version:  5CVS-2006-05-08 (snap)
 New Comment:

duplicated of http://bugs.php.net/bug.php?id=37346

already fixed in CVS


Previous Comments:


[2006-05-08 05:59:03] cnteacher at discuz dot com

Sorry.

If you get an Forbidden error,

you must visit www.freediscuz.net first, and than type the file's url
in brower.



[2006-05-08 05:44:44] cnteacher at discuz dot com

The test gif url

http://www.freediscuz.net/tools/specialgif.zip



[2006-05-08 05:40:23] cnteacher at discuz dot com

Description:

When I use the function 'imageCreateFromGIF' with some special images
(GIF), the memory will be ran out. I test it with all GD version (above
2.0.28).

Reproduce code:
---
$file = 'specialimg.gif';
$im = imagecreatefromgif($file); 

Expected result:

the memory ran out, and my web server is down.

Actual result:
--
I put the special gif file on my friend's web, you can download it from
http://www.freediscuz.net/specialgif.zip.
I think some one can use this bug to attack web server. It's so danger.





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

#37362 [NEW]: Make halts on semicolon in function declaration

[lobster2 at xs4all dot nl]

From: lobster2 at xs4all dot nl
Operating system: AIX 5.2 ML07
PHP version:  5.1.4
PHP Bug Type: Compile Failure
Bug description:  Make halts on semicolon in function declaration

Description:

During make of PHP 5.1.3 and PHP 5.1.4 on AIX 5.2 ML07  
with xlc 6.0 the process halts on syntax errors. 
 

Reproduce code:
---
$ make
[...]
"Zend/zend_language_parser.c", line 2585.1: 1506-046 (S)   
Syntax error.   
[... and after fixing the previous error ...]   
"Zend/zend_ini_parser.c", line 1081.1: 1506-046 (S) Syntax   
error.

Stop.

Expected result:

Fix: comment out the line previous to the one reported, 
with the single semicolon on its own. 


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

#37358 [Opn->Asn]: date_sunrise() date_sunset() handle main zone offset but not count summer time

[derick]

 ID:   37358
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ache at nagual dot pp dot ru
-Status:   Open
+Status:   Assigned
 Bug Type: Date/time related
 Operating System: FreeBSD
 PHP Version:  5.1.4
-Assigned To:  
+Assigned To:  derick
 New Comment:

Interesting, as it works fine for me in Europe/Oslo. Will check it out.


Previous Comments:


[2006-05-08 04:35:14] ache at nagual dot pp dot ru

Description:

In php_date.c I see some (unsuccessful) effort to calculate proper
offset, I mean line

gmt_offset = timelib_get_current_offset(t) / 3600;

but it gets only _main_ zone offset, without current summer time added.
I.e. for Europe/Moscow it _always_ gets 3, but in the summer it must be
4.

This code can't work in any case, because it consider 'time' argument
only few lines later: 

timelib_unixtime2local(t, time);

but at the moment timelib_get_current_offset(t) called, 'time' arg
simple unused, so you can't get summer offset this way, only main one.

Please fix the code to count summer time too,

Reproduce code:
---
I have following lines in my php.ini:
date.default_latitude=55.75
date.default_longitude=37.61
date.timezone=Europe/Moscow

and call this test script when summer time (+0400) is active:


Expected result:

Two echo calls must produce the same sunrise/sunset results when summer
Moscow time (GMT+4, specified directly in the second echo call) is
active.

Actual result:
--
Sunset/sunrise time of the first echo is one hour behind (GMT+3), when
script called with summer time active. 
date() call itself reports +0400 properly.
Moreover, I consult astronomical tables, first sunrise/sunset is
definitely one hour behind.





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

#37361 [NEW]: prepare statement alter the datatype of a parameter

[axel dot azerty at laposte dot net]

From: axel dot azerty at laposte dot net
Operating system: Fedora Core 5 - Linux 2.6.16
PHP version:  5.1.4
PHP Bug Type: PDO related
Bug description:  prepare statement alter the datatype of a parameter

Description:

The prepared statement in PDO seems to lost or to have its type altered.

When typing a 'SELECT COALESCE(MAX(field),0) FROM table' under postgresql
shell, no problem.
When using this query as is in PHP (with PDO), no problem.
When trying SELECT COALESCE(MAX(?),0) FROM table as a prepared statement,
the execution fails.

Replacing "MAX(?),0" by "MAX(?),'0'" solves the problem, but the returned
value is a string, and not an integer.



Reproduce code:
---
$stmt = $dbh->prepare("SELECT COALESCE(MAX(?),0) FROM board");
$stmt->bindParam(1,$fld);
$fld = "id_board";
if(!$stmt->execute()) print_r($stmt->errorInfo());

Expected result:

The expected result is "0" , in the case or the table is empty or the
number of lines in the table.

Actual result:
--
The statement->errorInfo() returns : 
Array
(
[0] => 42804
[1] => 7
[2] => ERREUR:  Les COALESCE types text et integer ne peuvent pas
correspondre
)

In english : "the COALESCE types text and interger can't match".


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